I was cleaning out my GitHub repos the other day when I stumbled across this old gem I’d long forgotten, and I thought I’d share it. When I was at the Open Networking Foundation, I did some research developing a low-latency consensus algorithm that achieves consensus in a single round trip in the normal case using an SDN-enabled clock synchronization protocol to order changes, and falls back to a more traditional consensus protocol (largely derived from Viewstamped Replication) when network ordering fails. The protocol was inspired by NOPaxos and was an attempt to build upon that work by replacing its single-point-of-failure sequencer with a high precision clock synchronization protocol implemented with programmable network devices.

The repo is a TLA+ spec describing the JIT Paxos protocol. I feel it prudent to warn that this project was just an experiment to see if/how high-precision clock synchronization could enable new consensus algorithm. NOPaxos was an innovation in consensus with software-defined networks, and their work inspired me to see if I could take that innovation even further. IIRC the protocol still had at least one glaring performance issues when I left it (not to mention the obvious issue that low latency can only be maintained with low concurrency). But nevertheless, there seems to be some interest in this work on Twitter, so I thought I’d share it here as well.

Perhaps my work can inspire someone to think outside the box and take consensus to the next level, as NOPaxos did for me.

We’re not attempting to replace any of the existing Go logging frameworks. Dazl is an abstraction layer above structured loggers like slog. We could add a slog plugin (we have zap and zerolog plugins already). Essentially, what you would get from that is the ability to configure slog loggers (log levels, fields, outputs/writers, sampling, etc) via dazl configuration files.

But the fundamental role of dazl is really to eliminate dependencies on frameworks like slog as much as possible, particularly in Go libraries. If libraries use dazl rather than a framework like slog, users of the library can then import whatever logging backend they want to use (slog, zap, zerolog, etc). This becomes really useful when dazl is used by multiple libraries depended on by a Go application. Often different libraries will use different logging frameworks (if they even have logging at all), and this can produce inconsistent log messages with no unified interface for configuring loggers across your dependencies. In a perfect world, those libraries you depend on would use dazl for logging instead, enabling the top-level project that depends on those libraries to configure a single logging backend that’s shared across all the dependencies.

I believe slog is also intended to sit above existing loggers. It is quite new.

“Consisteny without clocks” seems like a misnomer considering Raft indexes are tantamount to a logical clock. Perhaps it should be “consistency without wall clocks.” But that’s not really novel by itself, except in the context of geo-distributed databases.

Copycat is a complete extensible implementation of the Raft consensus algorithm that was heavily influence by some of ZooKeeper's algorithms. You can read extensively about the Raft implementation in the architecture section of the docs. http://atomix.io/copycat/docs/

This is not totally true. There are ways to ensure a read from a follower sees the latest writes from the same client. You do this by sending the index of a client's write back to the client upon success and the client sends that index to a follower when reading. The follower awaits logs up to that index before servicing the read. Some Raft implementations do this, but clearly it can cause greater latency when switching between writes and reads and still only gets you sequential consistency and not linearizability.

I totally agree. I recently moved to LA for a job. A couple of months before moving I had bought a nice road bike. Even though I live 2.5 miles from work now, that road bike still sits in my closet every day. I would love to ride it to work, but LA doesn't even have enough lanes to support both driving and parking, let alone biking. The roads are full of traffic and impatient drivers and I value my life too much to risk riding my bike on the couple feet of shoulder that might exist on those roads.

I sympathize and hope you could find out how to cycle to work; as a side note, however, a "nice road bike" is not very good for commuting 2.5 miles to work.

1) road bikes are not good for taking you and a laptop a short distance to work; they are optimized for doing long journeys on free roads, not city traffic. What you want is a bike where you sit upright and which enables you to look around more conveniently, a bike with no clip pedals which enables you to stop at traffic lights at ease, and a bike with a rack which enables you to put your bag on it, etc.

2) a nice bike will be stolen in no time unless you keep it in closet (even here, and my country/city has actually very little crime).

That said, I understand your problem if roads are too scary. Where I live I have a dedicated bike/pedestrian lane 98 % of my work commute (10 km) and I mostly use a cyclocross bike which is almost like a road bike (slightly more agile, because there are many turns and crossings on the way, but I do use clip pedals).

Too often people buy "fashionable" bikes for commute (a carbon-fibre road bike, a BMX or downhill bike, or a fat bike) when the best one would be a cheap, general-purpose hybrid bike that rolls relatively easily but can take you across stone slabs or grit without puncture, and has a relatively upright sitting position with efficient access to pedals.

Congratulations on a very manageable LA commute! Having biked many miles for commuting and for pleasure in LA when I lived there, I suspect this is a discomfort you can get over rather than a strictly rational risk assessment. Maybe you could try riding the route at times other than rush hour, like over the weekend, just to get familiar with the route and the basic mechanics of traveling it? Perhaps there is a longer route, over less obvious residential streets, that will be more comfortable? If there is one section that really concerns you, just walk your bike on the sidewalk for that part. There are a number of riding clubs and meetups, with varying degrees of formality and expectations; you might find riding in LA traffic less intimidating with a group. You will find that driving lanes are biking lanes. Swerving from shoulder to shoulder is a mistake you don't have to make.

And I echo sibling's suggestion to get a more practical bike. When you get "off the map" [away from routes that cars are forced to travel] you might find all sorts of sketchy but bike-friendly shortcuts, through parks, parking lots, industrial areas, etc. Skinny road bike tires don't like these routes, but LA streets are full of all the same hazards.

What part of the city? I used to work in Santa Monica and biking there, while not perfect, wasn't too terrible. There are plenty of tech jobs in SM, or Venice for that matter.

I agree that LA on the whole is a decrepit hellhole for cyclists, though.

I think the two business arguments for open source are:

Open sourcing software assists in its stability by creating a larger user base (users who report bugs) and attracting contributors (free development).

At the same time, open source contributions can promote a favorable view of the company as giving back to the community from which they presumably take. This can be attractive to prospective employees. I've been fortunate enough to be able to work on open source projects and indeed contribute them back to the open source community, and I likely would not be interested in any position where that were not the case to some extent.

Of course, there is always a need for a lot of software to remain proprietary. But at the same time, there are plenty of cases where the benefits of the open source community (testing and contributions) outweigh the risks of helping your competitors (open source generally useful tools, not specific competitive advantages in your industry).

I have to say, as a young engineer working at a startup full of cutting-edge technologies, this seems to be the best advice I've seen yet (if that type of environment is what you're looking for).

The proposed optimizations are pretty interesting, but I think my favorite such optimization has been proposed by Ayende Rahien. As with the optimizations outlined in this paper, his is related to leader election.

One of the issues with leader election in Raft is the potential for split votes. Raft tries I guard against this by randomizing election timeouts in order to discourage two candidates from requesting votes at the same time. What Ayende suggests, though, is to add a pre-vote stage wherein followers poll other nodes to determine whether they can even win an election prior to actually transitioning to candidates and starting a new election. This ensures that only up-to-date followers ever become candidates and thus prevents nodes that will never win an election from ever transitioning to candidates in the first place.