Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux greybeards release beta of systemd-free Debian fork

theregister.co.uk

Post reply on HN
Print view View original

181–189 of 189 posts

Re: Linux greybeards release beta of systemd-free Debian fork

#181

Post by JdeBP »

INTPenis wrote: post #179
JdeBP wrote: post #157

Earlier quoted context omitted.

> I don't remember any clear differences between sysvinit and rc van Smoorenburg rc and Mewburn rc are noticably different. * https://news.ycombinator.com/item?id=11550802 They are both rc, by the way. Don't conflate init and rc. > If you want to add more complexity you can write a start script for the service but that should not be the norm. In some fields, it appears that it is. * http://homepage.ntlworld.com./jona…

Java is notorious, even with systemd. The biggest problem with java is knowing when the service is started. And that's actually a problem with other clustered services like wsrep in mariadb for example. You need to get an OK from the service, by checking logs or APIs, before you know that the restart worked. So services like that will always require an added layer of abstraction. But that's not the norm, far from it.

On the contrary, and as I already said, in some fields it appears that it is. Moreover, as demonstrated, those services do not require all of that extra layering. Indeed, it actively breaks functionality.

Ironically, MariaDB is not one of those fields, and your chosen example is actually a counterexample. The push in MariaDB is to use systemd's "notify" readiness notification protocol and actually get rid of the wrapper shell scripts completely.

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/un...

* https://mariadb.atlassian.net/browse/MDEV-5713

* https://github.com/MariaDB/server/pull/26

* https://github.com/MariaDB/server/pull/83

* https://github.com/MariaDB/server/commit/20c2ae39db3dd0ec4c3...

As in MySQL and PostgreSQL.

* http://bugs.mysql.com/bug.php?id=65809

* http://www.postgresql.org/message-id/E1aQnE5-0003Cj-CN@gemul...

* http://postgresql.nabble.com/PATCH-better-systemd-integratio...

Re: Linux greybeards release beta of systemd-free Debian fork

#182

Post by chris_wot »

JdeBP wrote: post #160
CSDude wrote: post #2

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

Ahem! * https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132

Those StackExchange answers are awesome.

Re: Linux greybeards release beta of systemd-free Debian fork

#183

Post by geofft »

chris_wot wrote: post #180
geofft wrote: post #172

Earlier quoted context omitted.

A ps roughly like that is how I got the number. That doesn't explain what they do. I'm sure I could dig into kernel sources, but... for instance, why am I running "xfsalloc", "xfs_mru_cache", and "xfslogd" when I have no XFS file systems? The point I'm making is not so much that I'm curious (although I am), but that the kernel is exempt from the scrutiny that systemd gets, and the kernel has a ton of fragile crap run…

You either have the xfs filesystem module loaded or compiled into your kernel. I just tested this out: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$ sudo modprobe xfs [sudo] password for chris: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs root 6731 2 6731 0 1 16:53 ? 00:00:00 [xfsalloc] root 6736 2 6736 0 1 16:53 ? 00:00:00 [xfs_mru_cache] chris@libreoffice-ia64:~$ chr…

I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko.

My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general, about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are contributing to the existing efforts already in Debian to officially support alternative kernels.)

Re: Linux greybeards release beta of systemd-free Debian fork

#184

Post by welterde »

chris_wot wrote: post #175
welterde wrote: post #141

Earlier quoted context omitted.

> The biggest problem with init is that it's just init. Why does init have to service supervision? What's wrong with having init just launch the service supervision process and afterwards just reap dead processes (which allows init to be a very simple program indeed [1]). As for the requirements to the init+rc system.. mine look a bit different: it should be reliable and predictable first.. performance not so much. O…

Here are how services are monitored on a few different projects: daemontools A series of scripts that run the supervise program. It initially runs svscanboot [1], which enables logging and uses svscan [2] to look through a service directory in order to execute the supervise executable for each service. [3] Supervise loads the run command, and unlike runit (which was inspired by daemontools) when run ends, it waits a…

> systemd uses socket activation for it's dependency tracking.

Not just that though. Otherwise it would have no dependency tracking at all for all those daemons that don't support socket activation (let alone stuff that has to be started in a certain order and doesn't communicate via sockets).

In regards to runit: it does have a mechanism for handling dependencies - starting the other service in the start script (not great imho, but works).

Also I don't quite see/understand your argument (edit: say why I should switch away from it) against OpenRC (or OpenRC+runit) - since it does do dependency tracking and has sane service scripts.

And regards to systemd making everyones life easier: not mine sadly - had plenty of problems I never had with other init+rc systems (OpenRC, the OpenBSD one, the old Arch one, etc.), while gaining nothing I didn't already have previously (hell.. doesn't even boot faster - on average it boots & shuts down slower than before - median about the same).

> And as with other systems, you use a utility to start and stop services - which some object to, but when you objectively look at it I really think you'd be hard pressed to be terribly worried about it.

You mean that you start/stop services with something like systemctl start foo? Yeah, I don't see why one would have a problem with that.

> The ancilliary utilities are not running in PID 1 though.

I am not a fan of integrating everything under the kitchen sink (network management, dhcp, NTP, udev, cron, logging, etc.) into one big project though.

Re: Linux greybeards release beta of systemd-free Debian fork

#185

Post by makomk »

chris_wot wrote: post #110
gkya wrote: post #109

Earlier quoted context omitted.

Udev (AFAIK a program that recognises and mounts plug-in devices, but I'm not sure) is developped by systemd guys and they recently told that they won't care about the case where it is used w/o systemd. It is an important part of GNU/Linux distros. Tho I used Arch for about two-three years I guess (since just before it switched to systemd as default til two monts ago), and I never had to fiddle with it, so I don't kn…

Yeah, that's precisely what it does - it's a daemon that interacts with the kernel for hotplug devices, etc. Is udevd used by anything other than the kernel though? If not, then I don't think it's a huge issue if those who want to use a different init system maintain their own version!

udevd is used by everything, sometimes directly, other times indirectly. It's needed to create device nodes for everything from audio devices to webcams to storage devices to stuff like modems and terminals, graphics cards, etc. Most desktop environments call it directly for stuff like USB drive automounting. Some non-desktop systems like Android and OpenWRT with very constrained hardware have their own replacements for it, but that's not officially supported by the kernel developers and the kernel APIs it relies on aren't documented or guaranteed to remain stable - they want you to use udev (and soon that'll mean systemd too).

Basically, the only people who've managed to get away with not using udev are those with their own kernel fork and a completely customised stack on top. I'm not sure if any of them even use glibc or the GNU userland either.

Re: Linux greybeards release beta of systemd-free Debian fork

#186

Post by chris_wot »

geofft wrote: post #183
chris_wot wrote: post #180

Earlier quoted context omitted.

You either have the xfs filesystem module loaded or compiled into your kernel. I just tested this out: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs chris@libreoffice-ia64:~$ sudo modprobe xfs [sudo] password for chris: chris@libreoffice-ia64:~$ ps -eLf | grep '\[' | grep xfs root 6731 2 6731 0 1 16:53 ? 00:00:00 [xfsalloc] root 6736 2 6736 0 1 16:53 ? 00:00:00 [xfs_mru_cache] chris@libreoffice-ia64:~$ chr…

I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko. My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general , about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are cont…

Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.

Re: Linux greybeards release beta of systemd-free Debian fork

#187

Post by digi_owl »

makomk wrote: post #185
chris_wot wrote: post #110

Earlier quoted context omitted.

Yeah, that's precisely what it does - it's a daemon that interacts with the kernel for hotplug devices, etc. Is udevd used by anything other than the kernel though? If not, then I don't think it's a huge issue if those who want to use a different init system maintain their own version!

udevd is used by everything, sometimes directly, other times indirectly. It's needed to create device nodes for everything from audio devices to webcams to storage devices to stuff like modems and terminals, graphics cards, etc. Most desktop environments call it directly for stuff like USB drive automounting. Some non-desktop systems like Android and OpenWRT with very constrained hardware have their own replacements…

The basic problem is that the same people that maintain udev also maintain the kernel API it relies on. How Torvalds have allowed this to continue for so long i do not know.

Never mind that udev existed as a independent project for nearly a decade before being folded into systemd, thus leaving various distros high and dry. Either adopt systemd, or develop an alternative to udev (that still have to rely on the badly documented and changing kernel API).

http://www.landley.net/notes-2015.html#05-07-2015

At this point in time it seems that GregKH has mastered the art of passive-aggressiveness...

Re: Linux greybeards release beta of systemd-free Debian fork

#188

Post by digi_owl »

chris_wot wrote: post #186
geofft wrote: post #183

Earlier quoted context omitted.

I mean, I know exactly why it's there. :-) GRUB's os-prober is trying to mount all filesystems as all possible types, which autoloads xfs.ko. My point isn't so much what my three kernel threads are doing as why nobody asks these questions, in general , about the kernel. Just about every criticism of systemd applies double to the kernel, but nobody is forking Debian to replace the kernel. (And very few people are cont…

Ah, I'm following :-) I think perhaps the kernel is more esoteric than systemd, and as a team they have proven themselves over time. I think they get a fair amount of scrutiny from competitors (the BSDs, and Microsoft) and they have a very robust development process so that might explain why it's not as controversial.

The kernel also lives in kernel space, so unless one go micro-kernel, and dumps everything but the bare minimum into user space, a kernel will always be a big blob of code (most of it drivers, btw).

Re: Linux greybeards release beta of systemd-free Debian fork

#189

Post by the_why_of_y »

phantom_oracle wrote: post #73

Everybody mentions the Unix philosophy and that is a very valid point, but I would like to mention the freedom philosophy that open-source/Linux gives (or used to). These guys who wanted systemd muscled their way in to get this software into the Debian system. They also adopted an "all or nothing" approach, depriving the greater community of something bigger than "do 1 thing and do it well", which is "freedom to do a…

https://lists.debian.org/debian-devel-announce/2014/08/msg00...
Post reply on HN