One release every 4 years. So this is like monit or systemd-supervisord and so on, a process manager. I have to say the thing I most enjoy about it is the fact that it's got the classic GNU trend of "here's an obviously pronounceable spelling; let's say it a different way".
Used it inside of containers a few times when I wanted to keep things simple and have a container that ran both a web server and PHP-FPM at the same time and kept them up.
Are the collection of components run in some kind of namespace? Say I run a Pies for Gitlab (which in itself had lots of components), and I run a Pies for Frpd, do they share the same space or are they isolated from each other? Am I maybe overthinking this? Perhaps its just a program manager.
Most systemd components do rely on some core systemd components like systemd (the service manager) and journald. I would say that a core thesis of systemd is that Linux needs/needed a set of higher-level abstractions, and that systemd-the-service-manager has provided those abstractions. The fact that other parts of systemd-the-project rely on those abstractions does not imply that the project is monolithic.
Explain the existence of "elogind" and "eudev" then?
It might be the case that one can disable some components of systemd, on a systemd system. It is certainly not the case that they are "loosely coupled", or there would be no incentive to maintain forks of core systemd components with the sole and explicit purpose of decoupling from systemd.
It's a collection of tightly-coupled components that are functionally a monolith because large distros tend to rely on the various components rather than allowing modularity.
In theory. In practice, systemd is a mess of different components that have subtle dependencies on each other. And while the core of systemd is solid enough, everything around it is not.
The area where I've seen the most homegrown implementations of things like these is HFT, with the caveat it's also designed to be distributed, integrated with isolation systems, start/stop dependency graphs...
I once worked for a company which chose to use Kubernetes instead, they regretted it.
I was in a group who began pronouncing the dashes in command-line options as "tack" and they said it was military lingo, but I cannot now find any connection to dash, hyphen, "minus", or Morse code "dah".
Everyone needs to have made a web framework. Everyone needs to have made a programming language. Everyone needs to have made a supervisor. Everyone has to have made a container manager. Everyone needs to have made a text editor.
Absolutely. I recently wrote my first compiler to get it off the bucket list… brainf*ck compiler/interpreter #100010134 or such? :-) Well… it was a fun half hour.
In some industries it’s critical. Think about aerospace where code is almost always homegrown or done by specialized company, and are specific implementations for specific needs. You don’t have that many COTS due to the criticality etc.
The thing about specific needs is that they are usually narrow. You could throw darts at the dartboard of problems, working on very narrow problems for years and never get a job solving any of them. If a problem calls out to you and you won't stop until you get a job with it, then the effort could be worth it. But sometimes, even if you get THE job, you'll have a slight twist in constraints that makes most of your prep go by the wayside.
I agree, but we all have to pick our battles. Do you want to solve real problems, enjoy other things in life, or solve some problem that a guy on the internet said is essential for any "real" programmer?
I disagree with all of this. If you have time and interest, or a real need, then go ahead. I've never met a programmer who's made all of these things in my 20 years of programming, and that includes PhDs, professors, and old graybeards about to retire.
reply