This is the fifth in a series of blog posts detailing the ongoing development of LogCabin. This entry describes a new cluster-wide monotonic clock used for client session expiry, a new tool to dump out the contents of a LogCabin server's log and snapshot, a couple of performance improvements, and several changes around how server IDs and addresses are assigned and used.
This is the fourth in a series of blog posts detailing the ongoing development of LogCabin. This entry describes LogCabin's new storage module and several other recent improvements.
Now that I've graduated, Stanford has deleted my university email account,
ongaro@stanford.edu. If you tried to send to that address and received an
autoreply, please resend your email to the same username at cs.stanford.edu
instead, which should remain valid for life. (Yes, I had a very similar
post for my Rice email account a few years
ago.)
This is the third in a series of blog posts detailing the ongoing development of LogCabin. This entry describes a new tool to extract information from LogCabin servers and a tricky bug that occurred when unregistering handlers from the event loop.
This is the second in a series of blog posts detailing the ongoing development of LogCabin. This entry describes the battle of adding timeouts to the client library API. Timeouts are useful for implementing leases in client applications. For example, a client might want to assert its lease but give up after few seconds, and in case of a timeout, it might need to crash or stop other processes from doing things that may no longer be safe.
This is the first in a series of blog posts detailing the ongoing development of LogCabin. This first entry catches up on the developments from when I started working with Scale Computing in November, so it's longer than most of the future updates will be.
The theme of this entry is getting started in a new environment. Up until now, I'd done nearly all of the development of LogCabin on my laptop and on the RAMCloud cluster. Running it somewhere new uncovered a bunch of implicit assumptions baked-in about the environment, so it exposed a new set of issues and bugs. This is fairly inevitable when it comes to low-level systems code, and there's a lot of value in working through it. LogCabin is significantly easier to run now than it was before, and it should be easier for the rest of you to install on your systems, too.
Well, I spent the last five years getting my Ph.D. in Stanford's Computer Science department. I won't do that justice here, but I'll fill in the story briefly so that subsequent posts make sense. I was part of Professor John Ousterhout's group, which is primarily focused on RAMCloud, a large-scale in-memory distributed storage system.
I use Linux exclusively but run Microsoft PowerPoint for some presentations. I won't go into the details of why here, but I wanted to record and share a few tips I use for getting it to run well. Your mileage may vary, obviously.
This is the second part of a series on making the i3 window manager work the way I want. I left off last time with the goal of changing the way windows are placed as they are created, and I had a couple of pointers from the i3 hacking howto for where to start looking. This post covers how I've set up my test environment.
I've been using tiling window managers for the past couple of years. I started with awesome, then Notion (a fork of Ion; Ion is no longer maintained), and now I'm in the process of moving to i3. For those of you that aren't familiar with it, the screenshots all look the same. They all behave differently, though, and I guess you just have to find one that fits your mental model.
When you open a new window in most tiling window managers, your existing windows get rearranged or resized to make room for it. This is kind of one main idea, actually, and it works reasonably well when opening your second or third window. Beyond two or three, depending on the screen size and applications, it starts to suck.