HN user

xylophile

45 karma
Posts1
Comments32
View on HN

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.

Trying to be genuinely helpful here:

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.

You can always edit the file in the container and re-upload it with a different tag. That's not best practice, but it's not exactly sorcery.

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.

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?"

Why is ordering startup important?

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.

It is literally "worth it" for companies much smaller than Meta due to the reduced infra management costs plus increased hardware utilization. A few hundred unique VMs is a boatload of work (even if you distribute it down to the dev teams), and most of those VMs will be sitting idle most of the time, just burning electricity to keep the RAM on.

The pendulum has swung (is swinging?) for many companies back to on-prem for cost savings. Self-hosted FAAS allows your developers to retain the abstraction over the compute platform (a step beyond what containers provide), and grants those running the physical infra significant flexibility in managing it. It's also arguably less complex than k8s for basically everyone, if your use case supports short-lived functions.

which would draw attention

Unless you're disrupting military / police / aviation frequencies, there is virtually no enforcement. The FCC does not routinely police the airwaves - they can be asked to investigate egregious disturbances, but if they do choose to respond (which is rare), that response will not start for weeks or months. Nobody is going to show up with guns drawn for an encrypted LoRa connection.

Do you routinely download unsigned binaries of unprovable provenance and run them? Because if you do, you might eventually find reason to appreciate the additional isolation that namespaces et al give you very conveniently via Docker (or your favorite alternative).

"I don't need to know anything about the problems you've solved in order to determine that you've solved them incorrectly, and that I'm smarter than everyone, and I'm going to be rich."

Let us know how that works out for you.

Even the brightest minds are not immune to the human tendency to force everything through a black/white filter. Buckminster, like Elon, and like many other people/topics, must be either a demon or a saint. Tribalism ensues.

Regardless of which team you're on or why, the base installs of almost every distro includes vi or vim, but many leave out emacs and nano. Since you have to pick one editor to be the first one taught, it makes sense to teach vim to avoid losing the learner.

You're spot on about simplicity, and it's the reason AWS may not remain the top cloud provider for much longer. There is no effort to implement any sort of consistency across their famed two-pizza teams -- that wouldn't be "Day one". So each service has its own IAM quirks, making basic security at scale a nightmare, and in some cases impossible.

Azure policies are comparatively a breeze, making it the smart and increasingly obvious choice for any regulated (read: large) corporation.