Live data from Hacker News

Linux distros without systemd

ungleich.ch

391–400 of 449 posts

Re: Linux distros without systemd

#391

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

And that reason is that one rarely needs to write a million lines of Bash: http://catb.org/esr/writings/unix-koans/ten-thousand.html

Re: Linux distros without systemd

#392

Alpine is great. I have nothing against systemd but Alpine stands on it's own for containers and VMs. I haven't given it a try on baremetal but I imagine it does just as well there. Not really desktop focused but if you want to run it with a GUI on a laptop it's technically possible.

I don't trust a "security-oriented" distribution with a small developer community: https://threatpost.com/alpine-linux-docker-images-unlocked/1...

Note this is only an issue for docker images using non default tools. Not good but not unique, for instance here is another high scored CVE for PAM issues in Ubuntu/Debian https://www.cvedetails.com/cve/CVE-2009-3232/

I challenge you to find any decade+ old OS software community you couldn't make the same comment towards.

Re: Linux distros without systemd

#393
post #345

Earlier quoted context omitted.

Sure, there are other concerns and bash is not an ideal language, but memory safety is responsible for quite a large number of security flaws, since its lack turns bugs into code execution vulnerabilities on a regular basis. I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.

To be fair, erlang would have been the better choice here. Memory safety, concurrency and solid error handling all in one.

I think I know what my next Erlang project's gonna be. Erlang-as-PID-1, here we come!

EDIT: or maybe as PID 2, per https://github.com/omisego/ewallet/issues/108 , though I'd be interested in the idea of writing an OTP application that can reap zombies and forward signals.

Re: Linux distros without systemd

#394
post #267

SysV init had the ability to restart, allowing upgrades without rebooting. Can systemd do that? The mechanism was kind of interesting: SysV init would create socketpair, then fork. The parent (with PID 1, required for correct functionality) would then exec the new SysV init binary with an option specified to make it receive state over the socket. The child would supply that state, then exit.

You’re looking for `daemon-reexec`:

https://www.freedesktop.org/software/systemd/man/systemctl.h...

> Reexecute the systemd manager. This will serialize the manager state, reexecute the process and deserialize the state again. This command is of little use except for debugging and package upgrades. Sometimes, it might be helpful as a heavy-weight daemon-reload. While the daemon is being reexecuted, all sockets systemd listening on behalf of user configuration will stay accessible.

Re: Linux distros without systemd

#395

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…

> Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. It's not really the same, some systemd-based distros diverge a lot and anything non-systemd much more so, including FreeBSD. Even something as basic as network configuration could be completely different on systemd distros, like Ubuntu with its netplan weirdness and Archlinux going into the opposite di…

By managing services I really mean starting/stopping/checking status of/etc daemons. On a systemd distribution, you make a unit file that describes the daemon and use systemctl to manage it. It seems like sanity for deployment can be accomplished by delivering a template unit file and letting the distro maintainer or sysadmin customize it as required.

Networking is a little out of scope here - I'd guess that changing basic network configuration is something that's less frequent than the service management tasks.

Re: Linux distros without systemd

#396
post #381
post #363

Earlier quoted context omitted.

I'm interested in which points you disagree, because I, in the opposite, agree with almost everything the guy said.

> there is a tragedy Systemd was criticizes right from the start for the same things that it is criticized now. No misunderstanding. No bad timing. No tragedy present. > People don't like change Wrong! People love change if it is an improvement. People don't like change if things get worse. > Services, System configuration, daemons, etc are separate distinct things and need distinct C code to be managed Nope. They ar…

None of those are arguments, they're just "nuh-uhs".

Re: Linux distros without systemd

#397

Earlier quoted context omitted.

"How do I remove" - I dunno, because I don't care to remove it. Somebody's probably done it. Search on Google? It's open source, so look at the code, submit a patch, fork if you gotta? "Buggy attack surface" - I am unaware of attacks that target journald; can you point me to a practicable PoC attack? "Why should I have to" - because other people are building your distros, expending their effort on open source project…

Then you are commenting on the wrong post. This post is about the systems that do not use systemd. Justifying your own use by demanding examples of failure is... odd here.

So when systemd comes up it's cool for people who Don't Even Own A systemd to go on endlessly about how it's terrible and An Conspiracy, but it's not cool for people to discuss that it might not be the Snidely Whiplash evildoers thing by evil people when the shoe's on the other foot?

Weird flex, but okay.

Re: Linux distros without systemd

#398
post #201

Earlier quoted context omitted.

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.

the -d suffix is traditionally for service daemons. SystemD is not a service daemon. Lowercase is a UNIX convention. SystemD does not have a UNIX approach. Since SystemD is not a Unix service daemon it shouldn't be spelled "systemd" to prevent confusion.

This is...bizarre.

Should I pejoratively call you "CRaIg" because I think you don't match up to my standards of what a Craig, or even a craig, is? Is that okay?

I don't think it's okay. Names have meaning. It is a really minor bit of respect to use them correctly.

Re: Linux distros without systemd

#399
post #121

Earlier quoted context omitted.

None of that makes any sense to me. It's all open source. Your last paragraph is absurd and internally inconsistent. Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Open source has succeeded because it was easy to improve and replace things piece…

> Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Linux-the-kernel was largely just in the right place at the right time, but to the extent that it had development advantages they were an openness to contributions and the absence of an imposed to…

None of that makes any sense to me.

It's all open source.

Suggesting that you can fork cron and you can't fork systemd is patently absurd.

You say that "people who disagree can't just fork the logging component and swap it out for their piece" when in reality you really can. Getting systemd to output text logs is trivial, just point it to syslogd instead of journalctl. It sounds like you weren't aware of that. So much for being a tightly coupled design.

Re: Linux distros without systemd

#400
post #121

Earlier quoted context omitted.

None of that makes any sense to me. It's all open source. Your last paragraph is absurd and internally inconsistent. Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Open source has succeeded because it was easy to improve and replace things piece…

> Linux (the larger operating system environment) exists only because of its monolithic approach to kernel-space development. Far from suffering from it, it made it all possible when the utopia of the GNU kernel flat-lined. Linux-the-kernel was largely just in the right place at the right time, but to the extent that it had development advantages they were an openness to contributions and the absence of an imposed to…

You say the Linux kernel had an "absence of an imposed top-down design"?

Ha.

Haha.

Am I supposed to take that seriously? The Linux kernel wasn't a top-down design? Do you remember the Linux kernel? Do you know who Linus Torvalds is?

Post reply on HN