Sorry to raise the dead a little... but if the problem with sysvinit-style booting is too many processes, wouldn't it be simpler to modify the interpreter so it doesn't spawn new processes for each script launched? If the problem is interpreted code speed, what about just-in-time compilation?
|
Quote:
If I have both fetchmail and getmail installed, which one gets run? How about wicd? I'll also mention that starting a bunch of subsystems in parallel can (not will) result in some very difficult to nail down timing related issues. Especially if one or more unit files failed to record a dependency; sometimes it works, sometimes it doesn't. Software engineering is a big game of whack-a-mole; the annoying things that you fixed by implementing feature X tends to pop up new and different annoying things. :D |
Quote:
Quote:
2. Not true for desktop distributions - almost all daemons included in a standard desktop distribution are either started by D-Bus, or include systemd units already; server (or power-user) distributions can stick with sysvinit since fast boot is not required there Quote:
|
Does systemd have a reliable configuration utility written in something other than gtk or pygtk? For example something that can be used in the linux console.
|
Actually, the GTK interface is mostly there as an example - I'm not sure it's even usable! Most of the enabling/disabling is done via. the CLI interface.
|
Quote:
Quote:
Quote:
Look, "better" depends upon what criteria you weigh more than others. From a support perspective, being able to reproduce a problem so that you can fix it is pretty important. Shaving a small amount of time off the boot process doesn't weigh a lot in my view of the word. Your mileage may vary. |
Quote:
http://cgit.freedesktop.org/dbus/dbu...bus.service.in Quote:
Alot of people seem to be against it mostly out of the sake of change - or, do you have technical disadvantages to using a quicker, more intelligent init system? |
Code:
That doesn't make any sense to me. What is the difference between a "desktop" and a "server" distribution in terms of system initialization? The sad part is that when systemd came, it received a big amount of attention, while nobody ever cared that much about initng. Initng (despite being unmaintained) is a great dep-based init daemon which uses simple configuration files. Also, another big strength of it is the fact that it comes with pre-made configuration files which automatically integrate for your distribution upon install. That makes maintenance of init scripts (in this case, configuration files) pretty unnecessary. The distribution I maintain is using initng and the time from the start of initng to gdm is never more than 4 seconds. |
Quote:
|
This is entirely true. Systemd also has many advantages over initng. The thing is, some of the previous attempts, although being worse than systemd, were better than sysvinit.
|
Maybe this ought to be read before ignorantly bashing systemd :
http://0pointer.de/blog/projects/why.html Quote:
* Writing a shell boot script requires many redundant, error-prone lines of shell code. Making a systemd unit is 4-5 lines of configuration. So it's actually more KISS. * One other (big) advantage is that most of the maintenance required would be done upstream. Freeing time to do something else instead of reinventing the wheel with custom error-prone shell scripts. * It replaces/deprecates ConsoleKit which "works" in a hackish way on Slackware. * It supports many of the newer linux kernel features. * Someone already did the work to get systemd working on Slackware. That said, it might be still a little too early yet to adopt it. But it's definitely something to consider very seriously. |
I would not consider systemd for this reason only: it is being written specifically to work only on the Linux platform.
I am very much an advocate of cross-platform development, UNIX is bigger than Linux alone. Systemd is expected to be used by "userland" programs like KDE and Gnome. However these are also used on BSD, Solaris, HP UNIX etcetera. It is as if Poettering expects that the userland programmers (KDE/Gnome and other desktop environments) and distributors of UNIXes should deal with the incompatibilities and patch their code to make it work on non-Linux OS-es where systemd will be unavailable. Code that shows this amount of contempt for anything that is not Linux, should be buried without ceremony. Poettering also said his code is "more efficient" because he does not stick to POSIX compliant programming. The programming shortcuts he takes are non-portable. I think "more efficient" and "cross-platform" should not be mutually exclusive. Taking shortcuts to make your program do fancy stuff is an immature coding style and better suited for the demo scene. You can optimize code and still keep it cross-platform, there is a lot of software that proves this - look at the multimedia applications that use platform-specific assembler code to squeeze all the available performance out of a computer. Still those applications compile cleanly and can be used on Linux, UNIX, and on several hardware platforms. It takes effort to make software portable and you have to be willing to spend that time - you do it for the users of your software. Poettering defends his systemd with vigor, but his comments reflect his contempt for any other way of thinking. One of his typical statements is that all his critics are "amazingly badly informed". You can not go into a dialogue with the guy, he just won't listen to your arguments. So, what are the advantages of systemd? Using "error-prone shell code" instead of systemd is bullshit - it's not as if we have to write new init scripts every week. Replaces consolekit? Poettering and Zeuthen are two Redhat employees who infest computers with half-assed software that they deprecate faster than distros can adopt it. Does it make your computer boot faster? Well wow... how many seconds of productive time do you gain per day?. It is not worth the hassle. Eric |
OS portability is highly overrated *yawn* It's been keeping Linux back for years waiting for others to catch up.
|
You could have anticipated my reply, judging by your introductory message on LQ:
Code:
I really dislike the "developer knows best" policy of Slackware Eric |
Quote:
Quote:
|
All times are GMT -5. The time now is 03:49 PM. |