FUCK YOU OPEN SOURCE FREAKS clause to any contributions.
And after you sign this idiotic anti open source agreement you are allowed to contribute to an inferior init system soon to be capable to do session management for the sole purpose of vendor lockin. 'Yes thats right; We will end with a bunch of apps developed for "Ubuntu Linux" not Linux. and they will use upstart session. Pretty smart tactics by Canonical to do away with "the competition". There is a major risk of a damaging fragmentation coming to the linux desktop and people think it is funny because they can mock some systemd developers who work in the open without skunkwork agendas.
Anyone who will accept a deal going: "Give us your copyright and we will grant you a less capable init and session system guaranteed to create further fragmentation" is a bunch of neckbeards. This is gonna be years of "fun" if people really accept Canonicals crap.
OpenRC scripts are similar enough to Upstart jobs that modification of Upstart to support OpenRC scripts was proposed for the Google Summer of Code.
Distributions like what? All that I can find are based on Gentoo.Quote:
Originally Posted by ryao
For one the project is/was under CLA/Copyright Assigment. Then there's the question of what kind of patches the upstream is willing to accept. Then there are the architectural, philosophical and technical differences and so on.Quote:
Originally Posted by ryao
Having spent quite some tweaking time in sysv, upstart and systemd environments, I have to say that upstart felt like a small improvement over sysv init, not much more than parallelizing startup processes, and a few more lifecycle events you can hook into.
With systemd on the other hand I really felt I had total control over when, where and how processes were started. Yes it will take some time to learn the new semantics, but there's much much more control over the processes' lifecycle and context. Running as a certain uid/gid, control over (rt) scheduling, memory, oom, limits and multiprocessor behaviour, controlling where logging is sent to, control over failure situations, tieing a process' fate to another, it's all declaratively handled in systemd.. This is all stuff that upstart and sysv either need shell voodoo for, or isn't possbile at all.
This all started to work very well AFTER I disabled sysv compatibility in systemd though.
Here's an example of how its manpages are self-contained, straight from systemd(1).Quote:
The manpages alone constitute sufficient conventional documentation.
"For more information about the concepts and ideas behind systemd please refer to the Original Design Document (link).
Note that some but not all interfaces provided by systemd are covered by the Interface Stability Promise (link).
Units may be generated dynamically at boot and system manager reload time, for example based on other configuration files or parameters passed on the kernel command line. For details see the Generators Specification (link).
Systems which invoke systemd in a container or initrd environment should implement the Container Interface (link) or initrd Interface specifications (link), respectively."
Let's inspect the boundaries between systemd and udev for instance. udevd used to be separated from systemd. Then it got merged within it, with the authors promising that "nothing would change" as it was merely a matter of sharing code. Then it turned out that things would actually change, as udev would lose its build infrastructure and one would have to use systemd's one. Then it became apparent that one had to compile and install the whole systemd (and its gazillion dependencies, some of which not cleanly cross-compilable), then manually rip the udev binary from the resulting installation (binary which had in the meantime been renamed as systemd-udevd, an undocumented compatibility break). But the developers promised that running udev without systemd would always be possible. When somebody complained that having to rip a working executable image out of systemd wasn't exactly a nice solution, they were awarded with friendly responses such as:Quote:
The boundaries and functions of systemd, udevd and journald are all perfectly well defined and documented. You can perfectly well obtain complete knowledge of this chain, foresee its behaviour, and debug it. The boundaries and behaviour are different from sysv, but they certainly meet your conditions.
"do what source distro's do best."
"pick mdev" or "stay on udev-182."
"Another option I'm hoping Gentoo uses is to standardize on systemd instead of dozen of half backed utilities to do the same things."
Then some time passed, and in case there was some doubt about the real intentions of the systemd+udev maintainers about "defining the boundaries" between the two, systemd developers reveal their true intentions:
"(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)"
So much for the well-definedness of the boundaries and functions of udevd and systemd. But I actually was talking more generally about the big picture: I appreciate the difference between "a server that starts and stops processes" versus "a server that manages mount points, listens on sockets, writes the syslog, handles dbus, starts recurring processes, handles hardware devices". In particular, I like the former approach because I can study and understand most of it and its interactions with my system, whereas my limited intelligence has much more difficulty in doing the same for a complex and continuosly changing coalition of subsystems such as systemd. So for me and those like me, upstart is better.
The "fully automatic" way that devfs worked was no voodoo. It wasn't more complex than the previous method. The previous method involved populating a directory on the root filesystem with all the device nodes one might think he would ever need. The devfs mothod required nothing: as the directory appeared just there, and that was it. It's not a matter of learning new things. It's a matter of changing from a model which required learning a few concepts to a model which requires learning ten times more concepts, is more cumbersome to use, and is less flexible in the end.Quote:
I have to say I tend to read this line of argument as 'I took the time to learn how the old way worked, and now I don't want to do it again'. Learning new stuff is a pain, yeah, but describing it as 'voodoo' is unwarranted. The 'fully automatic' way that devfs worked was just as much 'voodoo' to someone who was used to the previous method as udev's method is to you. More than anything, your perspective on what is perfectly comprehensible and sensible code and what is 'voodoo' depends on when you came in...
The primary source of workforce for OSS software is made up by grassroots users. Replacing simple systems with complex ones for no reason will create barriers to entry for those people. Making Linux workable only by distribution professionals will turn it into another OpenSolaris in the long run.
Which point is inaccurate? Am I lying? Where exactly?Quote:
This is a fairly inaccurate description of that whole kerfuffle.
Nobody is questioning the fact that bugs happen. I was just saying that if a software is released without even being compile-tested, a user might consider alternatives to it if they are available.Quote:
So you hit a bug. Presumably it got fixed. I can't really discuss it in any more detail since I don't know anything about that specific case. But bugs happen...
Because upstart requires writing "recipes" to manage services, so services don't have to be modified to take advantage of it. And I can't feel any difference in boot time when I run an upstart-based distribution versus a systemd-based one. Except that in the second one, the servers have become init-system specific, and it's more difficult to maintain.Quote:
The fact that projects are not buying into upstart is not a *good* thing for upstart, it indicates that they don't have confidence enough in that project to take advantage of the capabilities it offers. Why is it a good thing for upstart if upstart offers a native service format that provides extended capabilities, but few projects want to take advantage of that?
The only things init on a linux system should do is stay alive and reap zombies.
Anything more, anything at all, be it socket activation, integrated logging, or latest whizzbang 4566, increase the risk of bugs, thus decreasing the software's stability and security. From here it clearly follows that sysvinit is much superior to systemd; and BSD init to sysv.
The 1970 guys were completely correct in their philosophy of "do one thing, and do it well". It has been proven time and time again.