systemd Clocks In At More Than 1.2 Million Lines

[aht0]

FreeBSD devd when you get the project its from is quite a monster.

https://github.com/freebsd/freebsd/tree/master/sbin/devd

Longest C file in the folder is 1183 loc.

Yes devd is in the Freebsd project that happens to include everything you need to boot the system from the kernel to bootloaders to file system validation tools.

WHAT? It's a user space daemon...

Configuration errors in sysvinit done by distributions could end up in a fork bomb so claiming bogs down slower than sysvinit ever managed is wrong if you include distribution errors in configuration. Systemd does put an upper limit how bad a distribution configuration screw up can be.

You missed the fact there are race conditions systemd is in fact dealing with that are in fact coming from the Linux kernel implementation of processes.

Said upper limit could exist in other implementations as well. If it didn't, logical conclusion is, it never posed sufficient problem to be added.

Further logical extrapolation leads to another conclusion: that the issue might be 'create some problem, solve it successfully, justify existence based on solving said problem'.

Hard reality you cannot compare systemd issues to darwin/lauchd of apple vs freebsd boot scripts. Yes launchd on darwain is better performance than freebsd current solution. Why you cannot compare is systemd is dealing with a defective process handling in the Linux kernel this increase your overhead a lot. Or if you don't increase overhead and ignore the elephant in the room that pkill killing processes using pidfile in fact killing the wrong process randomly. You use sysvinit and claim faster but it faster by random-ally killing the wrong process.

With how broken the Linux kernel is systemd is the best option at this time. Now Linux kernel 5.1 or 5.2 someone should be able to implement a pkill program that in fact works right.

1) projects with only 1 developer key to boot the system need to be merged into a large project. Like it not systemd did this first. Maybe some of the parts like udev that were merged into systemd should have been merged into kernel tree. BSD had done this merge before a single line of code was written in the Linux kernel. So Linux is kind of late to the party on this bundling.

Why? When there is demand, there are providers. Multiple providers are always better than single mega-monopoly. It's been proven over and over, not only software-wise. It's time-proven tenet of economy.

Now, one corporation has next best thing to vendor lock on GNU/Linux or what's left of it.

You only talk about sysV init and it's deficiencies - there were alternatives. Even on BSD I do have alternatives to old robust RC: runit and openRC.

2) Posix/sysv compatible init systems that people tried for over the first 15 years of Linux resulted in developers being userspace and never fixing the low level Linux kernel faults. Freebsd init and kernel are in the same development tree so issues in init that are kernel caused have been fixed kernel side.

Sorry, but have you (systemd devs) done any better? systemD is almost 10 years old AND yet you still blame kernel. Instead of building knowingly on broken kernel functionality and blaming the kernel - your time would perhaps been better spent sending kernel patches upstream and trying to fix those in advance - only then building your thing.

You seem to have completely forget, which project is the more important one. Without kernel, systemd would be meaningless, at least as long as you haven't come up with systemd-kernel of your own.

3) When ever the is change people get upset and totally go back to old broken instead of looking at the replacement and working out what need fixed so their old broken ceases to be old broken and becomes old and fixed.

From user's perspective, there is some difference to whether 'broken thing' is new or old. It's still broken but 'old broken' is at least familiar and can be worked around using past experience. With 'new broken' you'll have to spend extra time finding ways around it. For most of us, computer is a tool for doing things. Fixing the tool does not enter into things we want to do before doing our jobs.

Think about it with cgroups systemd working on a service management system at long last started putting bugs against the Linux kernel and getting those low level issues fixed. Its not only been init systems that have been failing to put bugs against the Linux kernel to fix core defects there are a lot of things that have not be working on fixing core defects.

Patched a patch of a patch covering hole in the wall, or what?

[oiaohm]

BSD is NOT like GNU/Linux. LINUX is a kernel ONLY. GNU provides the userland. That is the biggest, most obvious difference between BSDs and GNU/Linux.

This is not the history. Sysvinit that Linux used did end up hosted at GNU but early Linux this was not a gnu project.

Linux has had a userland mostly made up of GNU parts. But even right from the start there were non GNU parts.

Also if you look in the tools directory of the Linux kernel not everything in there is Linux kernel only. The Linux kernel has never merged stuff in like early freebsd did and the other BSD followed that lead.

BSD has and always will integrate the base set of utilities with the kernel, with the design decision that this provides tight integration. Get it?

No this is not true. late 1993 freebsd was the first time they did what was called self hosting. This was basically bring the individual parts of the core under 1 single project. Before that you have split tar.gz files making upBSD/OS in early 1993. Yes the merge its that far back the current BSD users forget it happened.

So FreeBSD can have everything in one project and systemd can't ?

Exactly the double standard much.

People complain about systemd merging stuff into 1 package this is exactly what world BSD did with kernel and all in 1993 yet people meant to migrate to a BSD to get away from systemd merging thing. So pure double standards.

BSD different OS made using it source show it make sense to merge the init stuff up into a single package so it all is tested with each other and works.

[oiaohm]

Why? When there is demand, there are providers. Multiple providers are always better than single mega-monopoly. It's been proven over and over, not only software-wise. It's time-proven tenet of economy.

This is not always true. Multiple providers causes a particular problem will be explained latter.

Now, one corporation has next best thing to vendor lock on GNU/Linux or what's left of it.

Systemd is resulting in the foundations being fixed this will come clear latter.

You only talk about sysV init and it's deficiencies - there were alternatives. Even on BSD I do have alternatives to old robust RC: runit and openRC.

Old robust RC was in fact used by slackware and with a Linux kernel end up killing the wrong processes. Yes runit on Linux kernel also kills the wrong processes.
OpenRC half kind of works with cgroups.

Sorry, but have you (systemd devs) done any better? systemD is almost 10 years old AND yet you still blame kernel. Instead of building knowingly on broken kernel functionality and blaming the kernel - your time would perhaps been better spent sending kernel patches upstream and trying to fix those in advance - only then building your thing.

Without systemd developers cgroup would still be cgroupv1 and still broken to hell. Without systemd developer proven past question there is no way at all to do pidfile safely on Linux is the reason why 5.1/5.2 Linux kernel are finally getting fixed.

You seem to have completely forget, which project is the more important one. Without kernel, systemd would be meaningless, at least as long as you haven't come up with systemd-kernel of your own.

I have not. There is a basic problem with sysvinit/runit/upstart... these were multi source assemble solutions. So when there was a issue did the user import a bad version of udev or some other incompatible part or init solution is wrong or is it a real kernel issue.

Systemd pulling the core init part into a single project means when you have a Linux kernel defect that systemd combination of parts is finding fingers can only be pointed in 2 directions either systemd is wrong or the Linux kernel is wrong. This has resulted in many hot debates on linux kernel mailing list and has resulted in a lot of core issues being fixed.

Basically systemd is providing the Linux kernel with the self host test freebsd has had since 1993. As in a bundle of software that should work. Freebsd merge is still better because you get down to 1 party. But being at 2 parties is better than the 20+ before systemd.

From user's perspective, there is some difference to whether 'broken thing' is new or old. It's still broken but 'old broken' is at least familiar and can be worked around using past experience. With 'new broken' you'll have to spend extra time finding ways around it. For most of us, computer is a tool for doing things. Fixing the tool does not enter into things we want to do before doing our jobs.

If the old broken is made up of multi parts doing a massive game of finger pointing the faults are never going to fixed. So the result has been before systemd you have been working around the same defects over and over again never fixing them. Systemd causing the kernel to fix stuff means in future lot of defects will disappear for good.

Patched a patch of a patch covering hole in the wall, or what?

With cgroupv1 vs cgroupv2 is basically systemd triggered a complete wall in the Linux kernel to be ripped down and basically rebuilt from the ground up fixed. Same with what is going on with file handles for sending signals to processes this is basically another rebuild. There is a long list of sections that systemd has triggered to be rebuilt from the ground up because finger pointing could not work.

To quite Australian politician "the recession we had to have" Paul Keating . "Systemd is the init system Linux had to have" after the Linux kernel internal issues are fixed up then we can restart the init solution fight this time instead of having stack broken badly behaving init systems in fact have init systems that do work.

Basically just like a recession once you get out the other side and everything fixed up then you can get rid of it.

[aht0]

This is not the history. Sysvinit that Linux used did end up hosted at GNU but early Linux this was not a gnu project.

Linux has had a userland mostly made up of GNU parts. But even right from the start there were non GNU parts.

Also if you look in the tools directory of the Linux kernel not everything in there is Linux kernel only. The Linux kernel has never merged stuff in like early freebsd did and the other BSD followed that lead.

Slackware used and is still employing BSD style init. It was one of the first Linux distros (excepting even earlier SLS it was based on). It did not even have SysV compatibility until 2000 or so. I was studying IT back around then and we used Slackware during courses. SysV compatibility appeared around then.

SysV was chosen by later distros for it's perceived advantages - which now seem to be have turned into purely "SysV init is baaaad..". One of them being complaint that service management sucked. Instead of fixing it, just using BSD style init or any of the alternatives, no, NIH - we need brand new super project.

No this is not true. late 1993 freebsd was the first time they did what was called self hosting. This was basically bring the individual parts of the core under 1 single project. Before that you have split tar.gz files making up BSD/OS in early 1993. Yes the merge its that far back the current BSD users forget it happened.

Exactly the double standard much.
People complain about systemd merging stuff into 1 package this is exactly what world BSD did with kernel and all in 1993 yet people meant to migrate to a BSD to get away from systemd merging thing. So pure double standards.
BSD different OS made using it source show it make sense to merge the init stuff up into a single package so it all is tested with each other and works.

FreeBSD itself appeared first time officially November 1993. It could not have done any self-hosting earlier. BSD/OS (or BSD/386) was separate distinct proprietary operating system, which finally died about ten years later. I don't know, maybe you thought 386BSD (free), which was indeed 'parent' for NetBSD and FreeBSD. I took a look at it's source, what's available of it (partial public repo online), and it looks like it followed the same pattern: kernel and world developed together.
Those 'split files' you do see even today: https://download.freebsd.org/ftp/sna...4/12.0-STABLE/ - I would thus not be putting much stock in your claims about things being done differently on early nineties.
Split up archive files make it easier for installer to install/unpack files according to certain pattern (like debug kernel vs ordinary kernel, ports sources, system sources, lib32 compatibility libs and so forth). It makes sense separating such files into distinct packages.

[aht0]

Old robust RC was in fact used by slackware and with a Linux kernel end up killing the wrong processes. Yes runit on Linux kernel also kills the wrong processes.
OpenRC half kind of works with cgroups.

Without systemd developers cgroup would still be cgroupv1 and still broken to hell. Without systemd developer proven past question there is no way at all to do pidfile safely on Linux is the reason why 5.1/5.2 Linux kernel are finally getting fixed.

Slackware still is using rc.

I am gonna install Slackware again somewhere to see, what 'wrong processes' get killed so persistently. Been long time.

[oiaohm]

Slackware still is using rc.

I am gonna install Slackware again somewhere to see, what 'wrong processes' get killed so persistently. Been long time.

Its using pkill on PIDFILES Linux does not have any protection here. So if process dies while you trying to kill it and that PID gets recycled you have a kill race. Yes this can happen when you are attempting to restart a service because you think it locked up.

End up killing the wrong process is not something that is easy to do at will. But it will kind of Murphy law you. Its not just kill either if you use signals between processes thing can also get wacky.

[aht0]

Its using pkill on PIDFILES Linux does not have any protection here. So if process dies while you trying to kill it and that PID gets recycled you have a kill race. Yes this can happen when you are attempting to restart a service because you think it locked up.

End up killing the wrong process is not something that is easy to do at will. But it will kind of Murphy law you. Its not just kill either if you use signals between processes thing can also get wacky.

Frankly, does not look like a situation I should meet more often than winning a million in lottery. Unless there is gazillion processes, software isn't quite stable and/or I somehow try to mass-kill many processes at once. Is the latter reason causing timeouts when trying to shut down systemd Linux machine? I remember it completely baffled me when I used OpenSUSE awhile a go - boot was actually fine but something during shutdown ALWAYS timed out..

[tildearrow]

I know right?
The other day, my dog came in and pissed on my power supply. It caused my computer with Arch Linux and systemd to short circuit. Solution? Get rid of systemd. How is this unstable garbage even popular?

Instead, I'm going to move to a poorly supported distro that uses out dated bash scripts that are specific to Debian, can't be reasonably supported by the daemon developer themselves, and that everyone hates working with. That way, I can have some sense of stability.

50 to 18. I switched to systemd in my Arch install now, and I can finally:

- Mount my disks without root (Artix can't do this)
- Power off from the desktop (without logging out)

[Bsdisbetter]

This is not the history. Sysvinit that Linux used did end up hosted at GNU but early Linux this was not a gnu project.

Linux has had a userland mostly made up of GNU parts. But even right from the start there were non GNU parts.

Also if you look in the tools directory of the Linux kernel not everything in there is Linux kernel only. The Linux kernel has never merged stuff in like early freebsd did and the other BSD followed that lead.

Look, you're digging a deeper hole in which to bury yourself. Linux was and is a kernel. The other stuff is fluff.
Unix/UNIX/SYSV and then BSD was kernel plus userland binaries, ALWAYS.

No this is not true. late 1993 freebsd was the first time they did what was called self hosting. This was basically bring the individual parts of the core under 1 single project. Before that you have split tar.gz files making upBSD/OS in early 1993. Yes the merge its that far back the current BSD users forget it happened.

Again, what the hell are you talking about? "self hosting"? "1 single project"? This is just plain gibberish.

I've been using *BSD since 386BSD with my first exposure being Unix/BSD on Pyramids, I've seen the history unfold. I remember loading tapes of the thing.

You're talking nonsense.

The kernel has always been the kernel. Your attempt to obfuscate your argument into one of "the kernel" equals "the project" is just plain desperation.

If I can recall correctly, the original BSDs had a /src directory rather than a /sys but apart from that little has changed in structure, even across multiple branches, though I do admit not using openbsd at all.

Exactly the double standard much.

People complain about systemd merging stuff into 1 package this is exactly what world BSD did with kernel and all in 1993 yet people meant to migrate to a BSD to get away from systemd merging thing. So pure double standards.

BSD different OS made using it source show it make sense to merge the init stuff up into a single package so it all is tested with each other and works.

Again, you're talking nonsense.

Just to make it clear, you're totally wrong. Absolutely.

You're also wrong, as is this topic, in comparing lines of code to some sort of metric of efficiency or waste. It's neither. It's a failed metric that means nothing apart from a meaningless comparison of lines. It's akin to measuring lines in a book and considering their worth based on that fact. Utter nonsense and long discredited by anyone who deals with large projects.

That's why I originally wrote that this article posted by Michael seems to be an attempt to draw out the trolls and ignoramuses. Mission accomplished.

Going back to your original accusation:

FreeBSD devd when you get the project its from is quite a monster.
https://github.com/freebsd/freebsd/t...ster/sbin/devd
Yes devd is in the Freebsd project that happens to include everything you need to boot the system from the kernel to bootloaders to file system validation tools.

If you are suggesting Linux copies how FreeBSD does it you are in fact suggesting merging systemd into the Linux kernel tree.

You are clearly wrong. devd is a userland utility it is not part of the kernel.
But rather than accept your error, you continue with this fantasy.
So, continue believing BSDs are a kernel with all the userland included (nonsensical argument by virtue of the name 'userland', but hey, that's the depth of your argument).


I'm done conversing with you. I can argue points with logical beings but no matter how hard I try, this would not occur with you.

[aht0]

50 to 18. I switched to systemd in my Arch install now, and I can finally:

- Mount my disks without root (Artix can't do this)
- Power off from the desktop (without logging out)

I believe you could do either from Artix too. Polkit & udisks/udisks2 for the former, systemd-logind & polkit for the latter (Edit: somehow escaped me that you initially didn't use systemd. In that case polkit/upower combo would probably work, it does for me in BSD. Combined with doas but you could replace it with sudo and give your user shutdown/reboot rights. Should enable powering off from desktop)