261–270 of 317 posts
Earlier quoted context omitted.
One service per server? That seems incredibly wasteful.
One service per kernel. Hypervisors allow you to run many kernels on the same physical hardware.
So like containers, but heavier weight and you need to pre-allocate ram for every ~~process~~ kernel?
It sounds like you've reinvented the multiprocessing operating system.
Earlier quoted context omitted.
> and there should be Linux distros packaged without systemd. systemd should be an optional package on all distros. Shoving it down throats is one of the valid major criticisms. What should have happened instead is systemd was optional on Debian at setup and Debian was forked to include it by default. It is simply backwards that Debian needed to be forked for purity. Duvuan shouldn't need to exist, but it very much d…
>systemd should be an optional package on all distros. Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what define…
Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel. They pretty much do what is expected, sometimes they do more, but not by much.
Systemd? It is not a good replacement for an init system for the users. Instead, it is an OS functionality accretion for the benefit of distributors, a baroque monstrosity that provides mediocre buggy solutions to too many problems that have nothing to do with init. It boots nondeterministically (socket activation is not such a universally great idea), sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition, or launching zillions of bogus hog processes for every user login event. Some of these can be mitigated on a production server, but bad taste remains.
Earlier quoted context omitted.
And what kind of fuel would it add? That systemd has corporate backers? Systemd was 100% created by redhat, so no, corporate backers aren't the problem. The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish. Many in the OSS community consider Microsoft to be pure evil. And if their historical behaviour is any indication, nothi…
> The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish. And now they're one of the major backers. All the work is being done in the open, so it's not like there's a nefarious hidden agenda there (an agenda that would have needed to somehow stay dormant for 10+ years). The idea that working for Microsoft is something dirty tha…
Earlier quoted context omitted.
> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. I only learned about that a few days ago, here on HN (some thread or some old comment). It is completely insane and gives lots of fuel to the systemd haters. I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff…
And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing. All the changes to gnome, which depended 100% upon systemd at the time, were pushed by redhat, gnome contributers. This one of the biggest reasons given, for getting systemd into debian at the time. When systemd was being pushed origionally, fast boot times, predictable names, and a few other things were big reason…
I have long been an advocate against systemd for the typical reasons (overreaching responsibilities, lock-in, lack of choice, software assumption "it will be there", complexity, driven by large corporate interests [see lock-in], being modeled after launched, etc etc). I feel like the chickens are coming home to roost. That said, if one wants to use it, then use it. However, there are alternatives which I would love t…
Why s6 over other options? I've long considered switching from arch to something without systemd since I use almost zero systemd features but have not had time to discern which init system to use.
I'm sure other available init systems have their selling points - but to be honest, after reading s6's reasoning and design goals I was sold. I'm happy to report that after a year and a half I'm pleased with the decision.
Earlier quoted context omitted.
Systemd is a somewhat successful non-unix operating system, marketed to people who want a unix-like operating system using force. This isn't what anyone wants but you'll go along or they'll unleash a hell of sophistry about how this is "really" what everyone wants even if its the opposite, made up stories about the opponents, or only bad people don't want what we want and you don't want to be tagged as one of the bad…
Rubbish. Linux+GNU is either a Unix operating system or it is not. Having systemd on board changes exactly nothing, since there never was a system services interface anyway. Files in a directory you say? That's not an interface, it's a recipe for failure. Or why do you think that every distribution used to ship their own init scripts? You EV car dealership is awfully flawed, especially with Linux+GNU you can even bui…
You're right that systemd provides useful things that sysvinit was not strong about. That is not enough to make systemd as distributed a good init system. It is a bloated C codebase with no definition of goals, instead it suffers never-ending mission creep.
In mainstream distros, while it does init, it also meddles in too many things it should not, like spawning zillions of needless user session processes hogging the system, mutilated system and service logging and others. It hangs randomly nondeterministically on boot too often, disrespects the user by ignoring keyboard input, etc.
The major point of critique of systemd push is to make people know that many don't like the offered product for its mediocre results as an init system, and uncalled for meddling in other business such as system logging. And we welcome new leaner init systems, such as s6.
I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.
It's quite simple: many people had atrocious experiences with systemd. Systemd ruined Debian for me, for example. I'd been using Debian testing for years and years, on multiple systems. Despite its name, I'd always found Debian testing to be more reliable than the stable releases of other major distros. When performing updates and upgrades during those many years of using Debian testing, I had only ever experienced t…
https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
Earlier quoted context omitted.
I guess their UX for a simple cron-like use-case. I remember trying to set it up and it wasn't a great experience. Just trying to see if others agree or not.
The arch wiki has really good documentation on them. And they are so much more debuggable than cron it's insane, they are a lot easier for anything non-trivial.
Earlier quoted context omitted.
No, I don't have to do that at all, I can in fact use the standard unix way of making a process not terminate on SIGHUP by telling it to ignore SIGHUP. SIGHUP is not a signal to shut down, it's a signal that says the controlling terminal is gone. The action taken by the process at that point is the decision of the process and the user that launched it, not the init system. This is exactly what it is for. Changing tha…
>And it showed off just how little the writers of the service knew about how users actually use their systems. Huge red flag. Why do you assume they didn't know about this quite basic mechanism? They added 2 configuration options, one at compile time (to set the default) and another configurable by the user. In fact, distro maintainers didn't look up what it did and they just compiled it as is, resulting in the surpr…
Even then, the default broke decades of standard behaviour so systemd failed users here.
> long-running processes are services.
Not all of them. A data processing/computation job running for tens or hundreds of hours is usually not a service. What is "long-running" anyway? Again, people used nohup for running their jobs for decades without being logged in. That is the standard usage of nohup, systemd broke it.