Replacement of Init System

kpedersen said:
Argh! It has begun. They have broken Linux so much, the distro kiddies are now coming to BSD!

Run for the hills!

Yeah, I look at half Linux/BSD systems as a kludge, it can't be a good thing to mix operating systems like that:\. The current system on FreeBSD of rc.d, works perfectly fine and I see no reason why it should be changed. If the Linuxites don't like FreeBSD the way it is, then leave it alone. Linux can keep systemd and many people came here to get away from all that mess, please leave it at the door.
 
zspider said:
Yeah, I look at half Linux/BSD systems as a kludge, it can't be a good thing to mix operating systems like that:\. The current system on FreeBSD of rc.d, works perfectly fine and I see no reason why it should be changed. If the Linuxites don't like FreeBSD the way it is, then leave it alone. Linux can keep systemd and many people came here to get away from all that mess, please leave it at the door.

There is a problem with systemd, a lot of projects are stopping work as systemd is replacing them, which I see can cause problems in the future.

Consolekit, has stopped development and xfce4 and gnome are working to integrate with systemd.
 
jnbek said:
Why screw around with openrc? systemd is so much faster and far superior in pretty much every way...

Wash your mouth out.

In my (admittedly biased and uneducated opinion) launchd would be the way to go, it is on far more machines than systemd, and isn't written by an idiot.

It has also already been ported and is under a BSD friendly license. OS X is mostly BSD userland as far as the command line goes, imho it would make more sense for BSD to be compatible with OS X the other way as well.


But... IMHO, the RC system does not need to be changed.

Details on the FreeBSD launchd project here.
 
Let's just keep FreeBSD's init system as it currently is, except for small changes.

Nothing made me more sad than the sudden maniacal switch to systemd of distributions that used to work fine. Look at Arch Linux, one day this was very close to a FreeBSDish style. I liked it. But then I got emails about how they would break my system (moving /lib to /usr/lib, really?!), and now the sweet init system it used to have is "deprecated" as well.

Seriously, who cares about parallel startup? Linux land going to systemd is a bad bad idea.

"And so I weep." Well, I would have wept if it were not for the semi-recent migration of most of my systems to FreeBSD. High five!
 
^^ pretty much that I would wager.

Also, parallel startup is all nice for speed and all, but I would suspect that trying to debug problems will be significantly more difficult.

As with any major change such as this, you have to ask:
Is the benefit of the change worth breaking compatibility over, and potentially also incurring another set of trade-offs?

For the uses FreeBSD typically finds itself in (servers, which generally don't re-start unless there is a major upgrade or major problem) - breaking compatibility and forcing all your admins to re-learn to shave a few seconds off reboot (which generally doesn't happen much) is probably not worth it. I.e., it's a solution to a problem that doesn't really exist.


Linux is full of change for change's sake. FreeBSD tends to be far more conservative.
 
Maybe launchd should be something for the PC-BSD crew to have a look at?

And if it proves to be beneficial, it could get sucked back into base.

/Sebulon
 
Somehow the discussion is leading to what should be the new init system. But shouldn't the order of discussion be:
1. WHY
2. What
3. How

I fail to see number 1. Why should there be a change ?
 
There are improvements that could be made to the init system. Parallelizing it, for example. New features would be nice, but they have to be compelling enough to make it worth the change.
 
Amzo said:
While replacing something that isn't broken is generally a bad idea, I have had a lot of improvements replacing my init system on my FreeBSD install.

I really like to way sysutils/daemontools works. It is written by Daniel Bernstein, the author of mail/qmail and dns/djbdns. The port installs easy-to-use svc(8) and svstat(8). A simple comparison with init.d and others is available at the project's homepage.

The most important feature for me is the watchdog: if the service dies, it is restarted almost instantly. Reliable logging using multilog(8) as a separate process is handy, as well.
 
swa said:
Somehow the discussion is leading to what should be the new init system. But shouldn't the order of discussion be:
1. WHY
2. What
3. How

I fail to see number 1. Why should there be a change ?

Perhaps because the current system is old, 30 years apparently according to someone who posted above, and as such is old fashioned not really suited for the desktop setting where having to wait ages for a system to boot is just silly when it could be made to be much faster.

If something being old or the fact that it works was really a good reason not to change then we could all just have stuck with paper and not bothered having computers in the first place.
 
That's still not very convincing, why are you booting your system so often that a slightly longer boot time would make a difference? We are talking about a system that is used for work, you don't reboot such system just for the heck of it.
 
My FreeBSD desktop is rebooted frequently as a result of tracking -STABLE. It boots fairly quickly, but any improvement there would be welcome.

The current rc system is not thirty years old. In fact, it was revamped a few years ago. Which is not to say it could not be improved, but it is not bad.
 
kpa said:
That's still not very convincing, why are you booting your system so often that a slightly longer boot time would make a difference? We are talking about a system that is used for work, you don't reboot such system just for the heck of it.

I didn't say I was booting very often, although I can think of perfectly reasonable scenarios when thats necessary.

If I wanted to use any of the BSD derivatives in a product that was aimed at the consumers of the world, then joe public would prefer that product to start as quickly as possible .. 'Instant On' is the ideal ...

I like FreeBSD, I especially like the BSD licensing ... and if necessary I make whatever changes I want myself.
 
I don't see why there should be a change to the base system, it works fine, if people want this, they can fork FreeBSD into their own version.
 
Kt said:
Perhaps because the current system is old, 30 years apparently according to someone who posted above, and as such is old fashioned not really suited for the desktop setting where having to wait ages for a system to boot is just silly when it could be made to be much faster.

If something being old or the fact that it works was really a good reason not to change then we could all just have stuck with paper and not bothered having computers in the first place.

So it's for desktop users. No reason to consider those running networks.

I was referencing against the man pages history section but find it funny how that could have been used to used as a straw-man to reenforce "shiny and new" vs "stable and secure" debate.

HISTORY
The rc utility appeared in 4.0BSD.
 
launchd handles stuff other than basic system re-start - it can spawn daemons on demand by monitoring network ports. It can also do periodic jobs, replacing cron, and a whole bunch of other stuff. It does so much more than init.

There's a document that outlines most of the why and how, with an overview of migrating from other systems available here.

Another neat thing is that because the config is all XML, you should be able to process the configuration with widely available XML tools, without needing to write a parser for whatever init or cron related configuration file you need to deal with the achieve a particular task.

Probably not such an issue for those who have been command line unix admins for a while, but probably quite useful for writing tools for desktop users to use.
 
I read that link, and its reasoning at first glance seemed "too little, too late" *unless* it was very slowly integrated (first cron... then rc.d/netif ... then...). Then its example of XML appeared. I can see maybe configuring inetd over several hours to do a task; writing over several hours a rc.d script from one of the many example on the freebsd-questions list. But toss in that I'd not only have to write it "into" XML, but also understand how and the wherefor of how that XML unifed whole would be better than the many various shell scripts which would serve its purpose as they do now, and I'd probably prefer the latter[1]. After all, my ppp.conf (56k) took two weeks to setup back in 2004. (Windows ppp dialog took an equal amount of time, several years before that, but every time I started it, I had to click on the one item in one way, or that two weeks of work would somehow evaporate and I'd be offline.)
[1] uschedule/, tweak, configure, optimize
... anacron, tweak configure, optimize
... wpa-supplicant, tweak, configure, optimize
XML is a deal-breaker [2] if I'd want to do any new task, as it is less readable and would take more time. (AFAIK. I am not an
expert in XML, but year after year, it is one tweak at a time,
and the less stuff to learn that is past any plain-text
configuration file is somewhat discouraging. ) So here, at first
glance, it appears slightly good in theory, maybe, but in my experience an greatly unneeded complexity.
(Those reading the post would please excuse any viewpoint here that is simply due to inexperience in some part of system administration, or based on forgotten or not comprehended concepts.)
[2] For the foreseeable time being...
 
Now, if I'm able to get what I'm needing for my PowerBook soon....

For one, myself, I'm not interested in parallel startup of services. Seeing with [CMD="grep $VALUE"][/CMD] (Apologies but there is no vertical separator on this keyboard) is sometimes necessary.

The UNIX way has been around for forty-three years.

The last project which actually forked from FreeBSD was Dragonfly(BSD). Using the base to make a product does not denote a "new" flavor, just a different application of the system.

If one wanted to know what the benefit could possibly be of using a mixed system could be- and this is with the hope that nothing will go wrong:

1. Using two graphics cards with the initial set on Linux and the second added through a jail with FreeBSD.
2. Comparing native Linux binaries to those running on the Linuxlator. Even though one is not running a Linux kernel, the version of libc used approximates such. See more on libc for this matter.
3. Comparing virtual systems by running one natively and the other through a jail. The former oe would be virtualbox while the latter would be a qemu instance.


There's nothing stopping you from installing qemu on your machine, setting up virtual machines with different startup scripts, and comparing the performance of each.

I'll agree that the Linux community has gone into the "Here's something I've got to make a name for myself" and less of "Can we make this secure and stable?".
 
Kt said:
I didn't say I was booting very often, although I can think of perfectly reasonable scenarios when thats necessary.

If I wanted to use any of the BSD derivatives in a product that was aimed at the consumers of the world, then joe public would prefer that product to start as quickly as possible .. 'Instant On' is the ideal ...

I like FreeBSD, I especially like the BSD licensing ... and if necessary I make whatever changes I want myself.

Maybe the focus should be on a working suspend/hibernate functionality instead.
 
  • Thanks
Reactions: Kt
Martillo1 said:
Maybe the focus should be on a working suspend/hibernate functionality instead.

Indeed ... or both! ;)

While I perfectly agree that 'stable' and 'secure' are excellent goals, I also like 'reasoned' progress.

Those who say that they want stability are welcome to not upgrade. That stable enough for you?
 
UNIXgod said:
So it's for desktop users. No reason to consider those running networks.

You've been considered thus far, and no its not just for desktop users although why they should count any less as you seem to be implying I don't know. Improving boot efficiency applies to any situation where booting happens.

Time is money remember ...
 
jb_fvwm2 said:
XML is a deal-breaker [2] if I'd want to do any new task, as it is less readable and would take more time. (AFAIK. I am not an
expert in XML, but year after year, it is one tweak at a time,
and the less stuff to learn that is past any plain-text
configuration file is somewhat discouraging. )

XML is like HTML, it looks different to other config files, however the advantage is that a standard XML parser (and that includes your brain, once you learn XML) can parse any XML file.

Which means that you can write a GUI/console tool to read/write XML files, and that single tool can then be used to tweak all the XML config files on the system. On the Mac, that tool is the plist editor.

As opposed to the Unix status quo - needing a GUI parser for crontab options, another one for the rc.d syntax, etc. You don't end up with a heap of different parsers to write and debug. You don't run into the situation where (for example) in this particular config file, whitespace means something, and in the another file it doesn't, etc.


Note: I'm not saying FreeBSD *needs* init to be replaced. Just that OS X has done it and I can see several reasons why.

It will, however be an adjustment for users to get used to, and the cost in terms of adjustment time for the entire userbase shouldn't be underestimated.

But in terms of launchd vs. systemd I think it's a no-brainer.



And as far as I'm concerned, the whole boot efficiency thing is a minor benefit of something like launchd replacing init, cron and friends. The standard configuration file format and start/stop on demand are bigger benefits IMHO.


edit:
In fact, I might try and get my head around putting launchd into a copy of 9.1 myself. I haven't tried anything of this magnitude before so it will be an experience :D
 
  • Thanks
Reactions: Kt
Ubuntu tries to use Upstart. It was introduced some years ago, and still leads to several unstable situations.
Mounting NFS shares is unreliable. Sometimes they are mounted, sometimes they are not.
RAID devices are sometimes not assembled on time.
The boot log (when finally reintroduced) is full of errors like Failed to resolve server... because of parallelization.
libvirtd tries to start virtual machines on boot before the network is up when those machines need network storage. Things like that.
On top of that, by default, the user sees an animation on boot, but no information. This isn't evolution. Sounds bad? It is! Fast booting is nice, but if it can't be done reliably, I don't want it. Let's look closely at Ubuntu and Fedora and learn from their mistakes.

On a positive note, all those issues drove me to seek a reliable system. So I ended up here.
 
Back
Top