I love Zellij but it doesn't play well with Neovim. If you try to use both tools heavily (Neovim splits + stacked Zellij panes), your Neovim layouts will get trashed. And if I have to choose between Neovim or basically anything else, Neovim will win.
Sadly, these issues are low priority for the main dev. Instead they are focusing on things like serving terminal sessions over the web, which is useless to me if I can't use Neovim in it.
If somebody announces that their project is written in Rust but nobody complains, what happens?
Writing any non-trivial video game with Rust is (arguably) interesting in itself since developer velocity in gamedev is generally considered paramount, and Rust has a reputation (rightly or wrongly) for hindering velocity.
So yes, the fact that this is written in Rust is actually relevant and valuable. As opposed to your hollow snark.
Now, OP: tell us more about how that's played out for you.
Not a popular opinion, but RedHat (now IBM) funds an enormous amount of critical open source. They pay people to contribute to hundreds of upstream projects. And RHEL is 100% focused on stability. Sounds like a good match for your priorities / goals.
Any optimizations discovered at runtime by a JIT can also be applied to precompiled code. The precompiled code is then not spending runtime cycles looking for patterns, or only doing so in the minimally necessary way. So for projects which are maximally sensitive to performance, native will always be capable of outperforming JIT.
It's then just a matter of how your team values runtime performance vs other considerations such as workflow, binary portability, etc. Virtually all projects have an acceptable range of these competing values, which is where JIT shines, in giving you almost all of the performance with much better dev economics.
It is accomplishing something. When 40 different applicants are equally able to do the job, the only selector you have is "culture fit", which is where bias starts to easily kick in (race, age, whatever), and that is a legal risk.
The leetcode hoops exist to provide a provably objective measure for hiring, even though that measure is unrelated to job performance. It's purely a lawsuit avoidance mechanism.
I came to this thread purely to see if I was the only enlightened one.
Stalwart is perfect for small self-hosters: a single binary, a single-directory resilient datastore (by default), a UI for every setting, and defaults that guide you to a DNS config which maximizes your sender score. Plus support for all of the "power user" features such as ManageSieve and shared CalDav folders.
Honestly, I love hosting my email now. And the last remaining battery which could possibly be included is now WIP: webmail!
Unix philosophy need not apply when there is exactly one use case for integrating these tools. (Or at least, one case which covers 99% of users. The remainder can keep their managerie of arcane config formats and susceptibility to unsafe language CVEs.)
The executive class is entirely based on personal branding. If you're not changing anything, it's like being a TikTok influencer without posting any new videos. It doesn't matter what you post really, and often the more controversial you are the better. If you play your cards right, you're not an "idiot" for making the company worse, you're a "bold and innovative thought leader".
You often see the same thing from ambitious managers. Aka, "managers gonna manage".
The other part of the equation is pure politics and PR, which at least does provide some real value to the company (if only temporarily, and at long-term net negative). Amazon made it pretty clear that their RTO was all about maintaining their relationship with politicians.
Docker daemon runs as root, and runs continuously.
If you're running rootless Podman containers then the Podman API is only running with user privileges. And, because Podman uses socket activation, it only runs when something is actively talking to it.
After many years of "I want stability and evergreen", I finally realized that this is Fedora. Each release is very stable, and they arrive more often than once an eon.
I know everyone wants "just one more feature", but I've been looking for a tiny kv for a side project that allows you to query by key prefix. I haven't had time to build one yet, and have honestly been hoping to stumble across one. Only the huge kv's seem to offer this, despite the existence of off-the-shelf hashing algorithms that will preserve lexicographic ordering.
Just FYI, you may also enjoy systemd-machine. It's essentially the same thing as toolbx but it handles the system bus much more sanely, and you can see everything running inside the guest from the host's systemctl.
Lorin is always on point, and I appreciate the academic backing he brings to the subject. But for how many years do we need to tell MBAs that "running with scissors is bad" before it becomes common knowledge? (Too damn many.)
Sorry, I didn't mean you specifically. I meant, if someone values simplicity above all else, they can choose an init that matches those values (like the one you described). Your approach is perfectly valid given that set of values.
Debian and other distros asked their userbase which values to prioritize, and the users chose what systemd provides. Hope that helps explain "why does systemd exist / why have most distros chosen it?"
This is pretty fundamental stuff. You can't run a program if the disk that it's sitting on hasn't been made accessible yet. You can't start a network service that listens on a certain IP address if that IP address hasn't been configured yet, or if the destination for service logs isn't ready, or if our service needs to talk to some other service like a database which isn't running yet. Etc etc. Booting up a modern system to a graphical environment requires hundreds of things to happen in the right order.
As for everything else, the project announcement blog post from 2010 does a pretty great job summing up the shortcomings of doing "the simplest possible thing": https://0pointer.de/blog/projects/systemd.html . You can certainly still do things that way if you want, but most people value the benefits gained from a more intricate approach.
It's fundamentally the same as a job queue, but the difference is that the people writing the job are not creating a running OS process. You literally just write a function, and it gets compiled into a process owned and executed by the job system.
Why would you want that? Well, who really wants to think about the OS, or how to get their data into main()? You just want to write business logic, and FaaS lets your developers focus on that. It's a small development process optimization, but a significant one at scale if you have enough developers / unique jobs being created. And it lets platform engineers focus on the best way to shovel data into main() in your particular environment.
> But you would still need a boatload of a hundred unique VMS
No, you would have a boatload of generic worker VMs that could all be spun up as needed (autoscaled) from a common base image and deleted without any need to preserve state. Effectively, you're managing one VM image, which can be rolled out across your entire fleet very quickly and with zero downtime / disruption. This is even less disruption than with k8s because FAAS design is fundamentally short-lived processes, resulting in more automation (less work) for your SRE / VM team.
Sadly, these issues are low priority for the main dev. Instead they are focusing on things like serving terminal sessions over the web, which is useless to me if I can't use Neovim in it.