Haiku OS Will Get New Service Manager 93
jones_supa writes: Axel Dörfler writes in his blog that he is working on a replacement for Haiku OS's current shell script based boot process. It would be replaced with something more flexible, a solution similar to OS X's launchd and Linux's systemd. While there is still a lot to do, the new project called launch_daemon is now feature complete in terms of being able to completely reproduce the current boot process. Since the switch to their 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 new service manager gives the power back to you, and also allows arbitrary software to be launched on startup. Alternatively, you can prevent system components from being started at all if you so wish. 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.
Just mutteriing out loud (Score:3)
I always thought that system startup should be controllable by the user, but that dependencies ought to be mapped graphically so that you have some idea of what ELSE you're going to be knocking out by stopping, for instance, system interrupts or the RTC.
That said, I'm pretty fond of init.d and crew. :/
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
No no no.
The summary even says: "The new service manager gives the power back to you"
Re: (Score:2)
"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."
Re: (Score:1)
Nobody has convinced me that systemd is actually bad, as opposed to different.
All the bitching seems to be people just hating different and others marching in lockstep.
So WAH!
Hogwash! Poppycock! Rubbish! (Score:2, Insightful)
The people complaining about systemd aren't complaining because it's different. They're complaining about it because it's utter shit!
For crying out loud, systemd's most vocal opponents are career sysadmins with the most experience. These are the people who are least bothered by change! They're completely accustomed to it. Change has been the story of their careers. In fact, they're the biggest supporters of change, when it's done right.
When you're a professional admin who has dealt with various versions of
Re: (Score:3)
Re: (Score:2, Insightful)
The problems with systemd go far beyond mere bugs. They are flaws with its design philosophy and architecture. These aren't fixed with simple patches and some testing! The only way to fix these is by completely throwing away what's there, and starting from scratch, doing things completely differently. When you start doing this, then you end up with the sorts of init systems that we've been using very successfully for so many decades: init systems that are truly modular (a bunch of non-portable, highly depen
Re: (Score:2, Insightful)
...and that only focus on providing an init system (unlike systemd which tries to handle logging, logins, network configuration, time-setting, virtual terminal support, and so many things totally unrelated to an init system). Maybe Linux does need a new init system. But that init system sure as hell isn't systemd, or anything like systemd!
I wish people could stop just for a second to think of systemd as an init system. It's not. Even the systemd web site says it's not, it says "systemd is a suite of basic building blocks for a Linux system." Treat it like that, a number of essential system components, one of them happens to be an init system. It's not the init portion of systemd that handles all the other things you say it does, systemd does. The init system itself in systemd handles only init and nothing more.
Re: (Score:2)
And that is the problem. There is no need for a "suite of basic building blocks for a Linux system." There are well-working components that have stood the test of time that already offer this functionality. There is zero need to break what works well here and people with actual system administration experience do not like it when people try to do that.
In addition, there is countless software for Linux that must also run on other UNIX-like systems and the systemd-philosophy seems to be outright hostile to th
Re: (Score:2)
"There are well-working components that have stood the test of time that already offer this functionality." - you can say that for virtually every bit of software on your system, i'm sure the init system before sysvinit also had well working component that stood the test of time.
" t
Re: (Score:2)
You actually have something to contribute besides propaganda? Because you are just lying through your teeth here. But I guess as a systemd-shill, you are being paid to do so. Still makes you a bad person.
Re: (Score:2)
After 15 years of doing Linux system administration, I do not see any need for a new init system except in special situations. And you know what, I am fine with there being alternatives. I am not being fine with being pressured to move to systemd. That is a hostile and destructive act, nothing else.
Re: (Score:2)
Re: Hogwash! Poppycock! Rubbish! (Score:1)
You must have been sleeping for the last couple of years and thus have missed what is going on.
Systemd-the-init is just an init. What makes that interesting is that it makes it really easy to consistently apply cgroups to everything it starts. Yes, you can do cgroups manually, but then they are neither convenient to use nor consistently applied.
That is a big thing as this enables other programs to make good use of those cgroups. What you call an entangled mess is a traditional layered architecture: systemd-
Re: Hogwash! Poppycock! Rubbish! (Score:2)
Re: (Score:3)
That's the other major problem with it. systemd has turned Linux into such a tangled mess of interlocking dependencies specifically because it gets into everything from logging to GUI lib dependencies.
Re: (Score:2)
Re: (Score:2)
List all the dependencies then,
I started counting Gnome apps but I gave up.
Re: (Score:2)
All non-trivial software packages have bugs.
Which is why the init process needs to be trivial.
Sure, shell scripts are slower, but you can easily fix any bugs you find in them, or modify them with very little risk. And they don't take down your hole system.
Boot time is a non-issue for sysadmins. When it takes more than five minutes pre-boot just to enumerate the RAID disks, whether you save 15 seconds at boot time is irrelevant. If anything, running things serially is a boon, as you avoid hidden race conditions and can step through the boot and sh
Re: (Score:2)
Re: (Score:2)
you can still use your shell scripts within systemd
That's not the issue, but I am unsurprised to see you get this wrong because your reading comprehension is for shit and you are willfully disingenuous when it comes to systemd. The issue is not being able to use shell scripts, the issue is the additional unnecessary complexity of systemd. See, all you need is init and some very small shell scripts, of about the same complexity it would take to replace you.
Boot time is a side product of systemd not a target but it does benefit those that load and kill VMs a lot, perhaps not an issue for your systems.
It doesn't really. Saving four or five seconds off the boot is quite irrelevant.
Re: (Score:2)
Re: (Score:2)
Once it's shown you can still use scripts you have to find another spurious angle.
You can call script snippets, but they are not allowed to do the same as init scripts did, including calling each other, detaching, or prompting. You're shoehorned into the limited context of systemd.
Why have loads of duplicated code in all those scripts? They all do basically the same thing.
The answer is in your one word "basically". There is a word for "95% the same", and that's "different". There's another word for not dealing correctly with the 5%, and that's "broken".
So what do you do to monitor those services started by the scripts? Manually watch them or add another binary to watch and restart them?
When something needs to know the status, it calls the start/stop script with a "status" parameter. And for most jobs, you
Re: (Score:2)
you can still use your shell scripts within systemd
That's not the issue, but I am unsurprised to see you get this wrong because your reading comprehension is for shit and you are willfully disingenuous when it comes to systemd. The issue is not being able to use shell scripts, the issue is the additional unnecessary complexity of systemd. See, all you need is init and some very small shell scripts, of about the same complexity it would take to replace you.
Cute insult. If it had come from someone significant that is, now it's just as pathetic as yourself.
And while you could be sort of right in an embedded system most people complaining aren't using Systemd in that context. In a dynamic context like a desktop machine/notebook computer/workstation your idea of "small shell scripts" really goes out of the window.
Re: (Score:1)
Most people will agree that systemd adds a number of important features to GNU/Linux that the old alternatives didn't offer.
This is very true. Most people will also agree that it accomplishes this at the cost of significant downsides inherent to the design of systemd, and sacrificing important features that the old alternatives do offer. The controversy is about whether the upsides are worth the downsides.
Adopting systemd will over time lead to a better system.
Depending on your position regarding the aforementioned tradeoff.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re:Hogwash! Poppycock! Rubbish! (Score:5, Interesting)
Re: (Score:2)
I feel for you, that sucks. On the plus-side, you have learned what to not compare your work to.
Re: (Score:2)
Re: (Score:1)
Are you going to be able to create a log reading tool like journalctl? Once you've used journalctl a few times, you'll see the binary logging is appropriate.
What's pathetic is that you are so unfamiliar with Unix that you can't write your own log analysis script yourself, so you think binary logging is a good idea.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
I know i'd rather my admins use journalctl to extract logs for a specific time span using one line rather than spend time writing and debugging scripts to extract logs from all separate files, merge and sort them into order before looking into the problem. journalctl is basically a time saver that has more data than current logging systems and time coded logs that reflect time zones correctly.
Re: (Score:2)
Well said. Besides its architectural and design problems, systemd does not have any reasonable level of stability for a productive release. They are still busily adding features to it! Maybe in 5-10 years, if the feature-set is kept mostly stable in that time, it would be ready for prime-time, but decidedly not now.
Re: (Score:3)
Re: (Score:2)
"They're complaining about it because it's utter shit!" - no its not.
"For crying out loud, systemd's most vocal opponents are career sysadmins with the most experience." - no, its the trolls like you with no knowledge of systemd that are the loudest
the rest of your post is as full of crap as the first bit, go to Devuan if Debian has screwed the config.
One of Many to Come (Score:5, Funny)
Bad existing manager?
Hopefully this one not suck.
Nice to see it still going (Score:2)
It's nice to see the team still working on Haiku.
Re: (Score:1)
Re: (Score:1)
I'm not encouraged when I see "x86 GCC 2".
x86?! Jesus Christ, that platform was obsolete back in 2005! We've had x86-64 for well over a decade now, and it has been the standard even for shitty consumer-grade hardware for just about as long.
GCC 2?! That's even worse than x86! My God, the latest release of GCC 2 [gnu.org] was on March 16, 2001! GCC 2.0 was first released on February 22, 1992! Even GCC 3, which has long been considered obsolete, saw its latest release almost a decade ago, on March 06, 2006. GCC 5 was released earlier this year.
I know you'll give "compatibility" as the justification for why it's still targeting a long-obsolete platform, and using a long-obsolete compiler system. But that's just a failed excuse at this point.
If Haiku is to be a relevant operating system in 2015, then it needs to get its shit together. It needs to target the CPU architecture that has been in use for the past decade. It needs to use a compiler system released this century. This "x86 GCC 2" bullshit needs to end. We need to see "x86-64 GCC 5" or even "x86-64 LLVM/Clang".
Well, fine, take the 4.4 version: http://download.haiku-os.org/n... [haiku-os.org] or the 64-bit 4.4 version: http://download.haiku-os.org/n... [haiku-os.org] They just won't be able to run BeOS binaries, as the ABI changed from gcc 2 to gcc 4. I'm sure 5.0 binaries will come eventually, but gcc 5 is relatively new, so it will take some time, as new gcc releases have and cause tons of bugs.
Re: (Score:3, Interesting)
Re: (Score:3)
The irony is that BeOS was designed specifically to take advantage of modern computer hardware of the day and cared nothing for binary compatibility with other OSes, and today Haiku is clinging to an ancient compiler and a dead x86 architecture... in the name of compatibility with BeOS apps, no less. BeOS itself moved from Hobbit to PowerPC to Intel x86 with little care for compatibility.
What made BeOS exciting 20 years ago was it promised to give users better multimedia support and responsiveness. Other
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'd argue that the reason for low OSS OS adoption on the desktop has much more to do with the target market. Haiku can basically exist as a little niche OS with very few users who only care about their specific hardware configurations because at the end of the day it's an OS for people who were fans of BeOS. It doesn't have some killer feature or some market it's aiming to grab.
Linux on the other hand can be made into what you want. While there are some vendors who build out to catch the desktop market ther
They're still working on this? Really? (Score:2)
Re: (Score:2)
It will be THE OS of choice on the world Post-skynet but pre-Reploid maverick era.
Re: (Score:2)
You are sadly wrong. If Haiku didn't still have the goal of being a BeOS clone instead of a modern OS inspired by BeOS we maybe could have had a useful system instead of the half-ready mess that it is now.
But improvements of the bad parts of BeOS isn't the problem.