Live data from Hacker News

Linux distros without systemd

ungleich.ch

281–290 of 449 posts

Re: Linux distros without systemd

#281
post #211

One of my biggest concerns about systemd is the ownership. Sure it is open sourced, however RedHat has a lot of pull on its maintainers (Soon to be IBM). What is to stop them from dual licensing it or close sourcing it. They have lots of products like that (jboss/wildfly...spacewalk/satellite). After everything runs on systemd the ball in in their court. Sure people can say they are going to fork it, but in reality h…

The moment it stops being free Debian drops/forks it. Furthermore, if Red Hat can monetize a system manager daemon, well ... I mean, good for them. Oracle tried with the JVM (they had some commercial features). Furthermore, if systemd provides a lot of basic facilities (global/user services, device management, login sessions, cron, ntp, DNS resolving) someone ought to maintain and support it, and if a for-profit comp…

Systemd is not GPLv2, according to wikipedia it is LGPLv2.1+.

Of course someone here at work told me i am splitting hairs and they are pretty much the same thing and compatible.

Re: Linux distros without systemd

#282

Earlier quoted context omitted.

I don't mean in terms of the binary, but in terms of the whole system.

You would have to write quite a bit of code... The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd. And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts tog…

I didn't mean that everything was in a single binary, but that everything is tightly coupled. Just because a binary is replaceable, doesn't mean the replacements that have existed for decades will be "drop in" or integrate as well, which leads to feeling like a second class citizen or the overhead originally mentioned.

Re: Linux distros without systemd

#283
post #248

Earlier quoted context omitted.

> I just want my systems to boot, run my simple applications, then shutdown when I ask them to Which is what you get out of the box with systemd. The only problems you mentioned either apply equally (e.g. shutdown delays due to blocked processes — having supported NFS clients, let me tell you that was not a new problem in the 90s…) or are due to misunderstandings about how to use other components. For example, if you…

you are not listening or being are deliberately obtuse I have stated three times that I accept that these processes are incorrectly specified, and that my problem is not this -- the problem is that I cannot discover these missing dependencies by any reasonable process whoever set them up 20 years ago is long gone, and what was reliable is now not this is a regression (and let's not get started that my brand new insta…

Suppose you run your system on a new, better, and faster computer architecture, newly supported by Linux. Now, let’s assume that this is a new architechure which in many ways is different in style to other processors, but let’s say GCC supports it and can generate 100% correct code from it. Your problem now is that much of all the old software was written and tested only on older architectures, and this new architecture exposes many bugs such as previously unknown reliance on undefined behavior, which worked on all old architectures, but not this new one.

Now. Do you blame the new architecture for this bad situation? Or do you blame the old software, which technically always had bugs but those bugs were previously not triggered?

Re: Linux distros without systemd

#284

Earlier quoted context omitted.

> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the fut…

Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. That said I agree they should have picked Go instead /s.

> People do not write million lines of code applications in bash, for a reason, trade-offs are to be made.

Isn't that basically what SysVinit and a good-sized chunk of the management tooling in Linux is?

To their credit, Bash is a _weird_ language, but it's not going to corrupt memory when it crashes, and its failure modes are pretty well understood by the distro maintainers writing those scripts.

Re: Linux distros without systemd

#285
systemd is good, but I think it came too soon. A lot of the comments here are about memory safe languages are spot on. systemd was written with two major assumptions in mind:

1. Linux system complexity has exploded and needs a top-to-bottom rewrite

2. It's safe to do such a rewrite in C

Since the systemd project, I'd say #1 has been largely affirmed. I like the result of systemd because it provides uniform tooling around complex Linux systems.

I'd also say the tide has shifted against #2 in a big way, there's much greater skepticism that anyone on this planet (short of djb or a few others) can write safe C, let alone safe C with concurrency and side effects.

This is really unfortunate, because it probably means the solution is to rewrite systemd in a memory safe language, and that's a huge undertaking.

Re: Linux distros without systemd

#286
post #274

Earlier quoted context omitted.

Given the timeframe, something like OCaml would likely have been a better option.

Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)

The topic is memory safety, not concurrency support, FWIW.

Lua would have been a good candidate: memory safe, coroutine to structure the code in a concurrent-ish way if needed, and you have a configuration file parser for free (just use Lua as the configuration language, it was its very first purpose after all).

Re: Linux distros without systemd

#287
post #30

Earlier quoted context omitted.

In the benefits of Alpine, you have put that the sound is great. Out of curiosity, what makes it better than other Linux distros?

Simplicity mostly. It just works. It feels so clean, nothing running there that is not supposed to be there. Installing something takes only sub-seconds, because packages are small. Alpine really is a beauty.

I believe your questioner was specifically referring to your assertion that audio on Alpine is unusually good. It is a somewhat odd observation, since ALSA is entirely a kernel API and Alpine is using the same kernel as everyone else. The only possible source of audible difference would be not running Pulseaudio, which resamples audio (some say, badly). However, you can install Pulseaudio on Alpine, and you can not-install Pulseaudio on most anything else, so it wouldn't really be fair to call that a feature of Alpine.

Re: Linux distros without systemd

#288
post #201
post #178

Earlier quoted context omitted.

By that standard SystemD proponents' fetishization of ineptly implemented change for change's sake clearly makes their position invalid.

Why on earth do systemd haters insist on capitalizing the D? It's really amazing how people think mistyping the name is some kind of useful or novel criticism of the software.

However juvenile, it is useful – as soon someone writes “SystemD”, I know that they’re either very inexperienced and don’t really know much, or they’re deliberately being spiteful and want to signal their hatred to other haters. Either way, I then know that I can safely ignore them completely, since they’re not part of a constructive conversation.

Re: Linux distros without systemd

#289

I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate. The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes. Also, it seems to make writing a service a lot easier. Instead of the service…

As much as I'd love to get into the rancor and bikeshedding good time as someone who just wants to manage some services on a few hundreds of thousands of instances and not worry about it systemd does that exceedingly okay.

Re: Linux distros without systemd

#290
post #196

This anti-systemd meme is getting tiring. I generally find it is perpetuated by people who use Linux at a hobby level. Rarely do I speak with guys in Ops who dislike systemd. I am not trying to discredit people here, there are hobby users who are more knowledgeable about Linux related systems than many guys who are professionals. My point is that Linux and systemd are both meant for use on servers, in production, whe…

Being dismissed as a meme is tiring as well. I like hacking on my system at boot time, and dismissing my use case because of your own is kinda hostile.

The anti-systemd group contains vocal trolls, memers, and ranters, so anyone who’s on same side will have to live with being grouped with them.
Post reply on HN