2,195 karma · joined August 15, 2018
I started writing a post about this many years ago, but never finished it. I took a few slow-changing projects of mine that had a pinned Rust compiler, and then updated both the compiler and dependencies to the latest versions. Invariably, everything got slower to compile, even though the compiler update in isolation made things faster!
Lots has been written about this topic, https://www.lesswrong.com/posts/j9Q8bRmwCgXRYAgcJ/miri-annou... is one of the more pessimistic takes. I wrote a more neutral introduction a while back at https://ruudvanasseldonk.com/2024/ai-alignment-starter-pack.
That’s a very misleading take, this is lossless audio and the majority of the bits are spent encoding noise. You can encode way more audio at perceptually but not technically lossless level in that space.
Chorus One operates validators on many proof-of-stake blockchains (the ones where security is based on a Byzantine fault-tolerant consensus algorithm rather than wasting energy). We are hiring for several roles, but the one I will highlight is what we call Platforms Engineer. Some companies call this Site Reliability Engineering or DevOps.
The main thing we do is take upstream software, build it, run it on our infrastructure, and then monitor it and optimize that setup. Some things that make this interesting are:
* Building automation that enables us to do this for many networks (70+ currently).
* Doing this with high uptime, building automation for failover, etc.
* Working with software that is on the one hand cutting-edge and doing interesting things (consensus algorithms, distributed systems, cryptography), but on the other hand that means it’s immature and often not easy to operate and monitor. Often we have to build custom tools, and dive into the source code of the project. We contribute patches upstream when it makes sense.
* Some of these projects are exercising the limits of what a machine can do, we have to do some low-level investigation that requires understanding of what the Linux kernel and network hardware are doing to properly identify what’s going on.
We do have a small cloud footprint, but run primarily on bare metal. We are looking for people who can not just configure services offered by the public clouds, but who deeply understand what lies below; people who could build their own cloud. That sounds a bit pretentious and it’s not exactly what we do, but it does involve many of the same aspects.A recent example of what I personally find fascinating: last March, Ethereum’s Holesky testnet experienced loss of liveness. This is a real-world, globally distributed system that implements Byzantine fault tolerance, with multiple independent implementations of the protocol. Several of these implementations had a bug in an update, which caused a split in the network. The protocol is designed to handle this situation in theory, but in practice it is triggering previously unexplored failure modes in the implementations, that are hard to test for in synthetic small-scale tests. I think there are very few places where you get to be involved in a planet-scale distributed system exhibiting “interesting” behavior, especially one that is not in control of a single entity. Of course, there is also the less fun part that the testnet was broken, alerts are firing, and it was hard and chaotic to coordinate a fix when the network is not controlled by a single entity. Fortunately it’s a testnet.
We’re looking for platforms engineers and software engineers to help build the automation, but also to dive into the node software of the blockchains we validate and see if there are opportunities for us to outperform the rest of the network; Rust experience is valuable there.
Apply at https://careers.chorus.one/o/platforms-engineer-remote. There are more open roles at https://careers.chorus.one.
Chorus One operates validators on many proof-of-stake blockchains (the ones where security is based on a Byzantine fault-tolerant consensus algorithm rather than wasting energy). We are hiring for several roles, but the one I will highlight is what we call Platforms Engineer. Some companies call this Site Reliability Engineering or Devops.
The main thing we do is take upstream software, build it, run it on our infrastructure, and then monitor it and optimize that setup. Some things that make this interesting are:
* Building automation that enables us to do this for many networks (70+ currently).
* Doing this with high uptime, building automation for failover, etc.
* Working with software that is on the one hand cutting-edge and doing interesting things (consensus algorithms, distributed systems, cryptography), but on the other hand that means it’s immature and often not easy to operate and monitor. Often we have to build custom tools, and dive into the source code of the project. We contribute patches upstream when it makes sense.
* Some of these projects are exercising the limits of what a machine can do, we have to do some low-level investigation that requires understanding of what the Linux kernel and network hardware are doing to properly identify what’s going on.
We do have a small cloud footprint, but run primarily on bare metal. We are looking for people who can not just configure services offered by the public clouds, but who deeply understand what lies below; people who could build their own cloud. That sounds a bit pretentious and it’s not exactly what we do, but it does involve many of the same aspects.A recent example of what I personally find fascinating: last month Ethereum’s Holesky testnet experienced loss of liveness. This is a real-world, globally distributed system that implements Byzantine fault tolerance, with multiple independent implementations of the protocol. Several of these implementations had a bug in an update, which caused a split in the network. The protocol is designed to handle this situation in theory, but in practice it is triggering previously unexplored failure modes in the implementations, that are hard to test for in synthetic small-scale tests. I think there are very few places where you get to be involved in a planet-scale distributed system exhibiting “interesting” behavior, especially one that is not in control of a single entity. Of course, there is also the less fun part that the testnet was broken, alerts are firing, and it was hard and chaotic to coordinate a fix when the network is not controlled by a single entity. Fortunately it’s a testnet.
Apply at https://careers.chorus.one/o/platforms-engineer-remote.
Edit, the article says “across”, not a #1 album in every decade. In the 90s she only reached #4.
https://www.reuters.com/article/lifestyle/thats-crazy-kylie-...
As for reducing boilerplate in the CI configs, GitHub Actions is a programming language with support for functions! It's just that function calls can only appear in very limited places in the program (only inside `steps`), and to define a function, you have to create a Git repository. The function call syntax is also a bit unusual, it's written with the `uses` keyword. So there is a lot of boilerplate that you can't remove this way, though there are several other yaml eDSLs hidden in GitHub Actions that address some points of it. E.g. you can create loops with `matrix`, but again, not general-purpose loops, they can only appear in a very specific syntactic location.
To really duplicate stuff, rather than copy-pasting blocks of yaml, without using a mix of these special yaml eDSLs, in the past I've used Nix and Python to generate json. Now I'm using RCL for this (https://rcl-lang.org). All of them are general-purpose yaml deduplicators, where you can put loops or function calls anywhere you want.
If you want to run multiple applications, how about ... just running them? It sounds like you already do that, so what is the real problem that you are trying to solve?
If it's annoying to start them by hand one by one, you could use Foreman or Overmind to start them with a single command, and interleave their output in a terminal.
Oops!
I had an XPS 15 with 4k display in 2016, yet in 2025 it’s somehow difficult to find a laptop with that pixel density?
I wonder the same with phones actually, my Nexus 6P from 2015 (10 years ago!) had an amazing 518 ppi display. When the modem died I got a Pixel 2 which had only 441 ppi, and the display was a really noticeable downgrade, text looked significantly uglier, I could see the pixels and hinting artifacts again. I expected high pixel densities to become mainstream to the point where every screen has a density at the limit of what the human eye can perceive, yet here we are 10 years later, and Google’s flagship phones have only 495/486 ppi, worse than the Nexus 6P!
The ThinkPad X1 and Framework 13 have a much lower resolution display. Also, I appreciate Framework’s mission, but it’s not the build quality that I’m looking for.
And then there is Apple who pack everything I want in a sleek 14" or 15" device, plus a very fast CPU and battery life that is years ahead of anything else ... Why is there no competition here? I'm willing to compromise on battery life, and I don't need the fastest CPU, just a good quality work laptop where I can run `cargo build` / `docker pull` without worrying about filling up the disk, and mostly just a browser aside from that. Why is the gap so large?