Guest post by A significant new development as Haiku continues pushing towards a stable release.
Since the switch to our package manager, there was no longer a way to influence the boot process at all. The only file you could change was the UserBootscript which is started only after Tracker and Deskbar; the whole system is already up at this point.
The launch_daemon gives the power back to you, but also allow software you install to automatically be started on system boot as well. You can also even prevent system components from being started at all if you so wish.
A summary of features:
Furthermore, it allows for event based application start, start on demand, a multi-threaded boot process, and even enables you to talk to servers before they actually started.
Read the full article for a detailed description.
I want to get out ahead of the “OMG systemd is coming to Haiku OS, we’re all gonna die!” crowd: This is not systemd, this is a very nice new launch daemon that is inspired by what systemd started out as, not what it has become. Whether you love, hate, or simply don’t care about systemd, that’s not what this is.
So with that being said, I’d just like to say WOOT! I love seeing great leaps in Haiku development.
You should read all the neckbeards over at /. that always get rabies when they only read SystemD somewhere.
(I think SystemD is pretty cool and most people who know a lot about distributions (the people who build them) think so too.)
But my guess is that the Haiku version will be more like launchd and much more limited in scope than SystemD.
I’ve never found anything about systemd that actually bothers me, apart from the controversy itself. I’ve mostly remained on the sidelines running Slackware and OpenBSD, because I do feel the rapid pace of development surrounding it means it’s far from stable enough for daily use, at least for my taste. I definitely don’t like the way it was abruptly pushed into stable Debian; of all the distros that’s one I thought would have kept it in testing for much longer before adopting it, and I suspect there was a lot of backroom politics behind that decision.
That said, I’ve been hanging out in Antergos for a while too, and its presence there hasn’t summoned any demonic forces or caused my computer to start bleeding from its USB ports.
I’m sure it will end up being a good thing for Linux in the long run, it just needs to get over its growing pains and get out ahead of the conspiracy theories and political crap.
Probably best that way. Heck, they even named it launch_daemon, so I’d say modeling the concept after launchd is a given. Better to have small, fully-functional subsystems that concentrate on their jobs. I think that’s most people’s problem with systemd: it tries to do too much too fast, and isn’t really stable with any of it. Jack of all trades, master of none is the appropriate cliche here.
“I think that’s most people’s problem with systemd: it tries to do too much too fast, and isn’t really stable with any of it. Jack of all trades, master of none is the appropriate cliche here.”
I think you need to read more facts about systemd and not just the posts of the anti-group. it is stable and it doesn’t do everything.
I’d think so too. Systemd relies on some linux specific features such as cgroups so it couldn’t be a clone anyway.
Given that they use the term “event based” i would liken it more to upstart than systemd.
And yes, talking about systemd as if it is just another init process is missing the mark.
Systemd comes with a whole lot of daemons/services(*barf*) that are tied to having systemd running as init. While they may appear optional now, at least one major DE seems to become more and more dependent on having the whole systemd shoggoth present.
All those other services have always been optional, only systemd runs as PID1. Unless someone starts maintaining ConsoleKit all DE’s will eventually use logind. Gnome had the option to avoid being systemd dependent as the developers wrote a library for them to sidestep it, but they *chose* to use logind instead of this bit of software.
Systemd makes a lot of sense in a desktop setting, so this is appropriate.
Is that even a real word, signification?
It is*, though I suspect charlieg meant “significant”.
* http://dictionary.reference.com/browse/signification
I can confirm that I did. How the ‘ion’ got in there, I will never know.
…and through the magic of editing…!
Good one guys.
Not seeing the SystemD connection.
Keep it up!
There isn’t one, except to the extent that replacing a shell-script boot with a system for manage services is like Systemd (and like Upstart, LaunchD, and a number of other things that pre-date SystemD).
It’s in the first sentence of the article:
“Since some time, I am working on a replacement of our current shell script based boot process to something more flexible, a similar solution to Apple’s launchd, and Linux’s systemd.”
Also, see this comment by axeld:
https://www.haiku-os.org/blog/axeld/2015-07-17_introducing_launch_da…
The fun part of BeOS was that you could take a drive out of one machine put it in another and everything still worked. (if you had the supported hardware) Windows just died when you did that.
Does a systemd thing breaks that kind of behaviour?
No, not at all.
Actually with the right preparation you can successfully swap a Windows drive to another system. You have to go into the device manager and set the drive controller to the Windows generic one before you swap. I don’t know if this is necessary (or even possible) in Windows 8 and up, but it works like a charm in Windows 7 and lower. If you forget to do that beforehand (or if it isn’t possible, i.e. your old motherboard has died), you can usually go into safe mode and reset the drive controller, then boot normally and it will pick up the correct new drivers.
Of course, you then have to contend with licensing/activation issues since you’ve just changed most of the hardware, which is not an issue with most other OSes.
Edited 2015-07-20 12:43 UTC
Well, Windows 8 has an option for installing onto a USB drive meant for moving from computer to computer.
Another option (And, the one I always used) was to nuke HKEY_LOCAL_MACHINE/System/CurrentControlSet/Enum
Very useful when ALL of your hardware changes – like, say, pulling your drive out of an Intel-based computer with ATI graphics and putting it into an AMD system with nVidia graphics.
No. It’s more likely that the problem would be Grub and fstab in that case, and only if you still has that really bad behavior of the old days of using Linux drive naming convention instead of UUID in their configuration.
Without cgroups and dbus, its not systemd. Its upstart. Its prone to all sorts of unsolvable issues because of that. But, just like upstart, its better than what came before. Plus on a desktop single user machine, I doubt too many people will care.
Nobody said it would be systemd. Just very similar to its system-init part, and very similar to Apple’s launchd.
But removing dbus, and cgroups doesn’t make systemd to upstart. There is a lot more that differentiates the two. And Haiku doesn’t use dbus anyway, as it has its own IPC messaging system. And it utilizes it in pretty much the same way as systemd does dbus.
cgroups would be nice, but Haiku doesn’t support anything in this regard yet. They are also not an essential feature of systemd; systemd is just using a Linux feature the way it’s supposed to be used.
I can recommend reading http://0pointer.de/blog/projects/systemd.html if you are interested the systemd basics. It’s pretty much the same as launchd, and now Haiku’s launch_daemon.
While launch_daemon (as its counterparts) support dependencies, and events, they are just one option to launch something.