systemd Clocks In At More Than 1.2 Million Lines

[oiaohm]

So you are justifying 1,2m LOC monster's existence with a functionality achieved elsewhere with a fraction of code? I could do that with devd in FreeBSD. And systemd nowhere to be seen.

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

https://github.com/freebsd/freebsd/tree/master/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.

Don't tell me about 'native'. Linux is a jiggzaw puzzle around kernel. Only piece native is it's kernel..

So you want systemd merged into the kernel tree??? Be-careful what you ask for.

Hmm.. Do I? 1m30s - 5m timeouts when systemd randomly bogs down are slower than SysV init ever managed. Sometimes it's a configuration error in distros, sometimes it's race condition in systemd, sometimes it's dbus fucking up. And that happens often.

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. Freebsd you have always been able to open a process as a file handle so locking that PID from change from the point of view of your application. In fact the first BSD kernel had this feature and the Linux kernel only starts getting that in kernel 5.1. Yes systemd is using cgroups at times to make up for lack of this feature. Its having other stalls making up of this missing feature.

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.

There are a few things to learn from the Linux init system disaster.

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.

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.

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.

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.

[Bsdisbetter]

why don't you go upstairs and ask your mom if you can go and play outside, the fresh air will do you good.

LOL. touche

[Bsdisbetter]

The only solution I see with systemd is rewriting it completely in Rust...

No, Forth

[Bsdisbetter]

What about Void?

MX-18?

[Bsdisbetter]

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.



So you want systemd merged into the kernel tree??? Be-careful what you ask for.



[...snip...[

[i cut the rest out tl;dr after this paragraph. Anything else you have to say about bsd is... dare i say, rot...]

What the hell are you on about? devd is not in the kernel, it's a userland daemon. You even linked to its git repository, hint /sbin part... A project does not a kernel make... or vice versa. Boy oh boy.

[Cape]

??tools?? ??advanced GUIs??? ???? A data structure is just an address in memory. You 'pass around' using pointers.

OR

You create an object in C++ and don't care about allocation/deallocaction.

[Bsdisbetter]

OR

You create an object in C++ and don't care about allocation/deallocaction.

Neither do you in a structure unless it or its contents are dynamically allocated.
..
Horses for courses. Either one is good, but neither is superior to the other.

[oiaohm]

[i cut the rest out tl;dr after this paragraph. Anything else you have to say about bsd is... dare i say, rot...]

What the hell are you on about? devd is not in the kernel, it's a userland daemon. You even linked to its git repository, hint /sbin part... A project does not a kernel make... or vice versa. Boy oh boy.

Really look again.
https://github.com/freebsd/freebsd this is the project /sbin/devd is in. The same personal who modify the devd in freebsd can also modify the kernel source.
Freebsd the kernel and devd like it or not are in exactly the same project.

https://github.com/systemd/systemd/tree/master/src/udev

Yes if your logic was true. src/udev means that udev is not part of project systemd right because it in a sub-directory.

So lines of code systemd vs freebsd core project that is call freebsd. Yes without question the freebsd one is bigger.

[Bsdisbetter]

Really look again.
https://github.com/freebsd/freebsd this is the project /sbin/devd is in. The same personal who modify the devd in freebsd can also modify the kernel source.
Freebsd the kernel and devd like it or not are in exactly the same project.

https://github.com/systemd/systemd/tree/master/src/udev

Yes if your logic was true. src/udev means that udev is not part of project systemd right because it in a sub-directory.

So lines of code systemd vs freebsd core project that is call freebsd. Yes without question the freebsd one is bigger.

What the hell are you talking about?

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.

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?

Therefore, utilities that appear in /sbin, /bin etc are just that, utilities.

The kernel source is in /sys

devd is NOT in /sys.

Therefore it is not in the kernel. Get it?

Your logic defies every known concept of kernel source trees and userland binaries. I am not going to explain it further because you are unable to grasp this simple concept.

Your argument is specious and attempts to bolster your other specious and fallacious argument about LOC. Either way, I've explained the BSD concepts, it's up to you to accept reality or continue being delusional.

[Britoid]

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