maybekerneldev

> and they're probably not open late or even open at all early in the week (maybe this is a pandemic artifact; I moved here in 2021)

No, it's a Seattle thing. One of my major peeves with this city (and entire region) is how hard it is to find places that close later than 9pm, even in the summer when the days are really long.

I think the outdoors culture here is so strong that people don't really care about having things to do late at night in the city.

> - Distributed systems. Everything is distributed these days with NUMA, cache coherency, PCI transactions, etc. You’ll have to know how to use the right kind of atomic memory ordering, debug lockless algorithms, and know how the OS scheduler works at a deep level. If this doesn’t excite you, the job might not be a good fit.

I'm familiar with the things you mentioned, except PCI transactions. In this context, do you also have to deal with distributed transactions, lost responses, eventual consistency, and the like? Do you have to account for "response lost, don't know if it went through" situations?

Definitely going for it after all the responses here :)

Those are fair points. I should've expanded a bit on my list though, since a lot of my points could be interpreted in a way that I didn't mean.

1. Yeah, I have no doubt about that. My peeve with k8s is not its inherent complexity, but just how much worse it made our day-to-day work. When we ran things on managed services, everything was a lot more understandable and straightforward. k8s is piles and piles of hard-to-discover yamls and I (and other folks in the team) feel that it made our infra a lot harder to understand and change.

2. This was my most unclear point. What turns me off about my current experience debugging distributed systems is having to trudge through millions of log messages coming in constantly. I just can't say I like the ELK stack, despite its popularity.

3. Fair point, though I'm aware of the distributed nature of things even within a single host. I do expect it to be different though. Will I still have to account for "the response was lost, you don't know what happened" situations? My understanding is that being close to the metal I can at least trust that the wires are all still there and working, and if they aren't, well, I can say the machine (or something within it) is broken and needs to be replaced. Do you have to do things like sagas or deal with eventual consistency at the kernel level? Hardware guarantees seem a lot stronger than what you get in networked systems.

4. Yay!

5. The difference here is that even a distributed system that's built correctly will still page someone one day. There'll be more traffic than it was built for, or some network dependency will be down (like, not the things you accounted for, but something fundamental like a DNS server or whatever), etc. My expectation (and past experience) is that in code that's intended to run on a single host, I'll either get it right and it'll just work as intended, or there'll be bugs that I have to fix, and once I do things will just work. What I find extremely frustrating about services is that it seems that no matter how much effort you put into quality, there will still be times when it just goes down and people have to put out a fire.

Definitely going for it after all the responses here!

> > 3. Designing systems in general. Some people love the challenge of distributed transactions, eventual consistency and all that jazz, but it just rubs my brain the wrong way. I'm not interested at all in that problem space [1].

>I'm not sure I understand this issue. I mean, kernels have subsystems for doing stuff; you might need to design one someday? But it won't be dull-as-dishwater web technology stacks, it'll be you writing data structures directly in C/C++ or Rust if MS goes there.

Ah, I meant designing distributed systems. Like, figuring out the difference services, storage requirements, databases, then planning out the infrastructure. It's really not my cup of tea. I do enjoy designing systems/subsystems/components as long as they're within a single host :)