Debian Init System Discussion Is Still Unsettled

[nanonyme]

In case anyone is interested on systemd vs upstart on Hurd discussion: http://www.gnu.org/software/hurd/ope...s/systemd.html. Would be nice to have Lennart consulting them on exact requirements, probably?

[liam]

yes, most of it
you need a "hook" for events like launching some processes and a bit of common sense
i read Lennart put a public post about how hard it is, too hard for the KDE guys (and thus mostly anybody)

yes like systemd, and like openrc and like... idk

'cuz i don't need all this crap
i wont limit my computer session...
i wont... in fact lets go over that list

i wont interface my init with dbus, its desktop bus
i wont have a shell free bootup, i think shell is a great programming language
i wont have modular coded early boot services (what ever the f that is)
i wont... hmm actually read ahead is good in some circumstances, but i hear my hard drive working for ~80% of the boot (and there are programs that do that already)
i wont have socket based activation on any daemon, its just useless
bus based and device based... what is that udev ?
i wont use "Configuration of device dependencies with udev rules", if they are udev rules then udev ? whatever that means (i guess its about not liking /usr on a diff disk)
i wont use path based activation, wtf, not for an init system
i use timer based activation, its called cron
i handle mounts...
i handle fsck...
i dont care about quota, but can handle it easy
i dont automount, i click on things or use fstab (not that i cant)
i dont even have swap, but if i did.. fstab and swapon/off, its easy
i wont snapshot, but if i wanted btrfs is good at it
XDG_RUNTIME_DIR Support... rly ? "export XDG_RUNTIME_DIR=/somewhere/over/the/rainbow" i wonder
i wont kill other users processes, i dont have other users (but if i did... you know how it goes)

this list treats sysvinit as the init program itself, not the scripts
what is hypocritical since on the first page of he's propaganda he talks for a while about how "bash" is bad (bash, not shell... bash... debian uses dash by default so they safe)

also cgroups are made for containers
it's just the way they are made (good) that makes them suitable for multi-seat and limiting daemons/users/whatever resources

I hope you're trolling but just in case...

Talk to David Hermann if you think the shell is such a great environment for boot.

DBUS is an IPC... and so is kdbus. Don't get hung up on the name. The people who know say we need this so I tend to agree. Besides it doesn't prevent from doing anything I should've been able to do before.
You are complaining about something you don't understand, which is fine, but it seems like you are determined to not like systemd regardless. That in mind it really confuses me why you started off by asking what it is (reasonably) but often responded in an argumentative tone. Why did you want to know how it worked if you were always against the ideas (which seems clear from you responses)?

[profoundWHALE]

Hurd port of systemd might actually make even a tad of sense. (Hurd not being anti-GPL like eg FreeBSD)

You have some terrible logic there.

[droste]

[..] Why did you want to know how it worked if you were always against the ideas (which seems clear from you responses)?

Yes, it's quite obvious that he just doesn't want to use systemd, regardless of arguments. That's why I stopped responding

[Chousuke]

think about it
you have a 1MB daemon that starts idk an hour after boot instead of on boot
well... useless, but ok its fun

then you have an init system that for whatever reason you must have to do that socket activation
it uses 20MB and runs from the start

That 1MB daemon argument is just a strawman, so I'll ignore it.

However... where do you get those numbers?

Systemd on my desktop system uses less than 5MB of memory, which is not even noticeable. I'm also willing to bet that it could be tuned to use much less if needed eg. in an embedded system. Socket activation is not some magical feature which makes systemd drain all your memory.

[JX8p]

Socket activation is not some magical feature which makes systemd drain all your memory.

It certainly isn't. It's a feature that has been with us since inetd, which was written in the mid-1980s.

[gens]

I hope you're trolling but just in case...

Talk to David Hermann if you think the shell is such a great environment for boot.

DBUS is an IPC... and so is kdbus. Don't get hung up on the name. The people who know say we need this so I tend to agree. Besides it doesn't prevent from doing anything I should've been able to do before.
You are complaining about something you don't understand, which is fine, but it seems like you are determined to not like systemd regardless. That in mind it really confuses me why you started off by asking what it is (reasonably) but often responded in an argumentative tone. Why did you want to know how it worked if you were always against the ideas (which seems clear from you responses)?

ofc i don't think a shell is perfect for the boot process
i know what it does and how it does it since i wrote one (in assembly non the less, my first "big" project)
thing is i use bsd stile init so if i talked about like upstart people would keep correcting me about minor things and the point would be lost

i'm not hung on the name of dbus
what i was pointing at that there should be a well designed standard, like netlink + protocol (maybe +virtualfs for it)
not a quasi filesystem like... whatever you wanna call it that changes every once in a while
(what is ironic since Lennart and Kay dislike the idea of a virtual fs, that could give that info)

why not something like that, that delivers information about started processes, opened sockets and so on in a standardized way (maybe even block them until checked)
that would make writing a "complicated thing" like a cgroups arbitrator easy
(the kernel already has mechanisms that can notify like when setsid() is called)


and ofc my tone is argumentative
the only technical data i get about systemd is "read this on lennarts blog"
Lennarts blog is written as if he is selling something to me (i know, i sold useless things on the street)
it is filled with assumptions and sometimes even half lies

i'm sorry but it makes me angry when people repeat stuff without context in order to make a point that really does not matter in the grand scheme
i know computing in schools is not... lets be honest, some things they teach you... and students think computers work like that
i want people to think for their own and learn about how things work, not what things do


the only valid argument for systemd i got so far is socket activation
(cgrouping i think should be done in userspace by the DE or something, and just set up at boot for system daemons then left alone)


but hey, i dont know shit !

[gens]

PS

http://felipec.wordpress.com/2013/11/04/init/

it's not that complicated...
unless you make it complicated for no reason

[Gusar]

PS

http://felipec.wordpress.com/2013/11/04/init/

it's not that complicated...
unless you make it complicated for no reason

Does this init system actually supervise services and restart them if they go down?
Does it make sure all service output, be it to syslog, stdout or stderr is logged?
Does it make sure all processes a service starts are accounted for and will it terminate all of them when you stop the service?
Does it take care of service dependencies?
Does it make sure a service can't hog the entire CPU?
Does it provide interfaces that DEs want to use, most notably logind?
Does it...

In short, systemd isn't complex for the sake of being complex. It's complex because it solves real issues, and does so better than anything that came before it.

Please try to understand systemd before you speak further, and don't dismiss it with a silly nonsensical "I don't need all this crap".

[erendorn]

what i was pointing at that there should be a well designed standard, like netlink + protocol (maybe +virtualfs for it)
not a quasi filesystem like... whatever you wanna call it that changes every once in a while
(what is ironic since Lennart and Kay dislike the idea of a virtual fs, that could give that info)

why not something like that, that delivers information about started processes, opened sockets and so on in a standardized way (maybe even block them until checked)
that would make writing a "complicated thing" like a cgroups arbitrator easy
(the kernel already has mechanisms that can notify like when setsid() is called)

I think the difference between systemd and "something like that" is that systemd exists, runs on multiple distros already, with unit files for thousands of packages.
If someone comes with a better init system than systemd, then all the better. When Upstart was created, it was not perfect yet better than alternatives, and some distros started to use it (including commercial ones). Now systemd is there, not perfect yet but better than Upstart.
If enough contributors lack features with systemd (such as modularity, or smallness), then they'll create alternatives (some have already done), and usage will tell. But that's hypothetical, and in the future.