# Replacement of Init System



## Amzo (Nov 16, 2012)

Personally my views on this matter are my opinions and some may not agree with my views, but I feel as tho the init system with FreeBSD is becoming a little dated, and a replacement would be a good idea.

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.

Currently, I have been testing and trying OpenRC on my FreeBSD install which is coded in a C and multi-platform init system, and also released under the BSD license.

While there is opinions over using an init system that relies on shell code, and one that is coded in C, I can say I have experienced a dramatic improvement using openRC and it is feature rich compared to the standard init system. The only problem I have, is that I have to write scripts for OpenRC to start some services as ports do not provide this.

A list of features that OpenRC supports that FreeBSD init doesn't includes:

* Parallel service startup
* Per-service resource limits (ulimit)
* Separation of code and configuration (init.d / conf.d )
* Stateful init scripts (is it started already?)
* Automatic dependency calculation and service ordering
* Proper integration into container/virtualization (Linux-VServer, OpenVZ, ...)
* Expressive and flexible network handling (including VPN, bridges, ...)

As well as this, I find it is also more visually appealing. ( Tho I have added color to my original FreeBSD init) The pros of a new, more updated init systems seems to be beneficial to a system, and greatly improves my desktop usage:

OpenRC in use on my FreeBSD machine:


----------



## sossego (Nov 16, 2012)

Let me be the first to state that you are not running a pure FreeBSD system.

https://github.com/Amzo/ArchBSD

If you are not running a pure/clean only FreeBSD system, then why are you suggesting this?

Let's say that I am running DebianKFreeBSD and suggest to others that Gnome3 is better than KDE4. There's a problem in my statement because I am running a bastardized system.

Try your idea on a pure FreeBSD system and tell us what the results are.


----------



## Amzo (Nov 16, 2012)

That was a clean install. Currently to get my ArchBSD system up and running. I install the FreeBSD world into a destdir~/archbsd_world. from there I continue to work on my packages toolchains, but overall, that was a base FreeBSD with OpenRC.

As well as it not being a clean system, the standard base is FreeBSD and any third party applications are exclusively packaged to /usr/local as it should be. That git was just a test project I was working on, and no way reflects my views.


----------



## sossego (Nov 16, 2012)

ftp://ftp.freebsd.org/pub/FreeBSD/releases/


And where do you see "*i686*" on that page?


Sorry, but, I'm not believing it is a pure system.


Again, try a fresh install with no scripts of any sort. That means no package manager which is Linux influenced.


----------



## Amzo (Nov 16, 2012)

sossego said:
			
		

> ftp://ftp.freebsd.org/pub/FreeBSD/releases/
> 
> 
> And where do you see "*i686*" on that page?
> ...



It is completely pure. the machine arch is available in hw.machine in the sysctl and also is available in /usr/src/sys/i386/i386/identcpu.c which then can proceed to compile with: make MACHINE=blah build kernel. Those apart from this little modification, it is as you put it; a pure FreeBSD except with the arch changed. I only changed this in the iso as I specifically compiled and optimized it for my i686 machine.


However this little project of mine, was to address issues I currently had with FreeBSD: One was the package manager and the other was the init system. Tho someone else also had the same views as me, but wanted to go with GNU userland while I don't like the cestpool franken OS known as kFreeBSD.

I originally did replace the package manager and used pacman, but not long after, pkgng was released. Then my package manager problem was solved, and instead of going the Linux way with a package manager here, there and everywhere, I abandoned it.

And still I experiment with OpenRC on FreeBSD, whether you call it a pure FreeBSD install or not because of my little kernel patches the fact was, it booted a lot quicker in a virtual machine, then my standard FreeBSD installed on my machine using the default init.

When testing the iso on my actual machine and booting from CD, it booted up extremely fast, in around 10 ~ 15 seconds, completely out performing the FreeBSD default.

Any how, I have  a test iso which uses OpenRC for anyone to try in a virtual machine if they wish.


----------



## graudeejs (Nov 16, 2012)

You should write this to FreeBSD mailinglist (perhaps hackers@).
Where can I get cd to test this (in VirtualBox)?


----------



## jnbek (Nov 16, 2012)

Why screw around with openrc? systemd is so much faster and far superior in pretty much every way... if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd. <my_two_cents> All this is likely a moot point anyways, since the FreeBSD devs will likely reject such ideas immediately. </my_two_cents>


----------



## drhowarddrfine (Nov 16, 2012)

jnbek said:
			
		

> if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd.


Because the question remains, even in the Linux community, about whether systemd is a 'bastardization' of "The Unix way". I'm leaning toward the idea that it is but I don't have the time to get a handle on it.


----------



## _martin (Nov 16, 2012)

To comment on these: 



			
				Amzo said:
			
		

> A list of features that OpenRC supports that FreeBSD init doesn't includes:
> * Separation of code and configuration (init.d / conf.d )
> * Stateful init scripts (is it started already?)
> * Automatic dependency calculation and service ordering
> * Expressive and flexible network handling (including VPN, bridges, ...)



1) Yes there is - rc.conf and an actual start-stop script (I can't be thankful enough FreeBSD didn't go with rcX.d nonsense) 

2) I think /etc/rc.d/<service> status approach suffice 

3) You have PROVIDE/REQUIRE for that

4) What's wrong with current setup? 

I understand that's your opinion and feeling about it. I surely don't want to argue or start flame.. but .. if anything, I hope FreeBSD goes the Solaris way if it's decided to rewrite init scripts or lean towards newer (different) solution.


----------



## phoenix (Nov 16, 2012)

Amzo said:
			
		

> A list of features that OpenRC supports that FreeBSD init doesn't includes:
> 
> * Parallel service startup



There's a couple of different proofs-of-concept for this out there for RCng already.



> * Per-service resource limits (ulimit)



This can be done using the normal tools provided by FreeBSD (limits.conf, login.conf, etc).



> * Separation of code and configuration (init.d / conf.d )



This exists in RCng:  /etc/rc.conf vs /etc/rc.d/



> * Stateful init scripts (is it started already?)



This is handled via the "status" option to every RC script.



> * Automatic dependency calculation and service ordering



This is handled by rcorder(8) and the REQUIRES:, BEFORE:, and AFTER: lines in every RC script.



> * Proper integration into container/virtualization (Linux-VServer, OpenVZ, ...)



Those are Linux features, so what's the point of supporting them in a FreeBSD RC setup?    And, we already have jail(8) which is integrated into the existing RC framework.



> * Expressive and flexible network handling (including VPN, bridges, ...)



This is all supported by rc.conf.  Anything you can do with ifconfig(8) at the command-line can be done in rc.conf.



> As well as this, I find it is also more visually appealing. ( Tho I have added color to my original FreeBSD init)



There are a couple of projects out there that add colour to RCng on FreeBSD, although I don't know of any attempts to commit/integrate them.

So, not really seeing the overwhelming need for OpenRC.


----------



## UNIXgod (Nov 16, 2012)

Betcha that puppy is full of bashisms!


----------



## nakal (Nov 16, 2012)

Yes. And please don't even try to port this unholy piece of crap named systemd, which even does not work on Linux boxes properly. But hey... since when does Lennartware work at all?


----------



## Amzo (Nov 16, 2012)

jnbek said:
			
		

> Why screw around with openrc? systemd is so much faster and far superior in pretty much every way... if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd. <my_two_cents> All this is likely a moot point anyways, since the FreeBSD devs will likely reject such ideas immediately. </my_two_cents>



Systemd is full of linuxism and under the GPL and works closely with the Linux kernel, while OpenRC is multi-platform, and released under the BSDL, so it wouldn't taint the FreeBSD base.


----------



## Amzo (Nov 16, 2012)

UNIXgod said:
			
		

> Betcha that puppy is full of bashisms!



OpenRC doesn't rely on scripts or shells, it's completely coded in C and has a small finger print.


----------



## UNIXgod (Nov 16, 2012)

Amzo said:
			
		

> OpenRC doesn't rely on scripts or shells, it's completely coded in C and has a small finger print.



So I have Funtoo on my laptop which uses OpenRC. If I replace the current link from /bin/sh to dash instead of bash will I have no issues there? Just curious.

I wouldn't get your hopes up. There is nothing wrong with wanting something in base. There's more to it than "it's got BSD license". Also I can't see replacing a 30 year old rc(8) system is going to become a high priority for the devs.


----------



## Amzo (Nov 16, 2012)

Non at all, in fact, I used dash as a system link to /bin/sh when I was making tests isos with OpenRC.

Anyways, there was a discussion on the mailing list, between FreeBSD developers and OpenRC developers.

It can be found here: Replacing rc(8) (Was: FreeBSD Boot Times)


----------



## Markand (Nov 20, 2012)

jnbek said:
			
		

> Why screw around with openrc? systemd is so much faster and far superior in pretty much every way... if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd. <my_two_cents> All this is likely a moot point anyways, since the FreeBSD devs will likely reject such ideas immediately. </my_two_cents>



The day FreeBSD switch to systemd I'll probably switch to windows. The total lines of code of systemd is at least more than the half of the total of FreeBSD kernel sources


----------



## kpedersen (Nov 20, 2012)

website said:
			
		

> ArchBSD is a *distro* based on FreeBSD



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

Run for the hills!


----------



## Markand (Nov 20, 2012)

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 don't know why people still want to use GNU user land over a FreeBSD kernel, that just sucks. There is no real reason to do that.


----------



## Amzo (Nov 20, 2012)

kpedersen said:
			
		

> Argh! It has begun. They have broken Linux so much, the distro kiddies are now coming to BSD!
> 
> Run for the hills!



Incorrect. I started that project as something to do.. However, I have always used FreeBSD, that idea of that project was to optimize FreeBSD for a specific arch and offer latest binary updates as the original FreeBSD repos are always terribly outdated and not everyone has the power to compile constantly.

It was also to improve the terrible and outdated pkg_* and sluggish init system.

This is no longer the case since pkgng has arrive. I have discontinued the project.


----------



## Markand (Nov 21, 2012)

kpedersen said:
			
		

> Argh! It has begun. They have broken Linux so much, the distro kiddies are now coming to BSD!
> 
> Run for the hills!



By the way, this won't apply on FreeBSD because Linux is just a kernel thus there is a lot of distributions however since FreeBSD is a real OS with base, kernel and ports you will still be able to install a PURE FreeBSD OS, so we don't care if people create 100 FreeBSD derivates as you can still install the REAL FreeBSD


----------



## Amzo (Nov 21, 2012)

Markand said:
			
		

> By the way, this won't apply on FreeBSD because Linux is just a kernel thus there is a lot of distributions however since FreeBSD is a real OS with base, kernel and ports you will still be able to install a PURE FreeBSD OS, so we don't care if people create 100 FreeBSD derivates as you can still install the REAL FreeBSD



This ^: FreeBSD allows people to change it as they please. Everyone has their different opinions. I was simply changing these to suit 'MY' needs. I found that a new init system and package manager suited me more than the current defaults.


----------



## fonz (Nov 21, 2012)

Amzo said:
			
		

> This ^: FreeBSD allows people to change it as they please. Everyone has their different opinions. I was simply changing these to suit 'MY' needs.


There is of course nothing wrong with that. Nor is there anything wrong with suggesting well thought out improvements or doing it yourself and sharing your work. However, one ought to keep in mind that things often are the way they are for good reasons and that FreeBSD tends to be on the conservative side when it comes to major changes. In fact, the tendency to resist the temptation of quickly adopting every new thing is part of what makes FreeBSD clean, stable and well-structured.

Anyhow, there are several projects working on changes to the init system. Feel free to check them out, report your findings and contribute code (if you can program). When something is sufficiently matured and an improvement over the current init system, it may find its way into base.

Regards,

Fonz

Note to add: I too wouldn't mind an init system with somewhat niftier and/or tidier output, but I am absolutely no fan of the SysV-style init as used by most Linux distros. That's just a mess.


----------



## kpa (Nov 21, 2012)

If there's anything I'd like to be changed in the init system it's the customization of REQUIRE/PROVIDE for rcorder(8). Now you have to edit the files directly but i'd prefer a system where you could use for example /etc/rcorder.d/<service> to add or override REQUIRE/PROVIDE without touching the original files in /etc/rc.d or /usr/local/etc/rc.d.


----------



## fonz (Nov 21, 2012)

kpa said:
			
		

> If there's anything I'd like to be changed in the init system it's the customization of REQUIRE/PROVIDE for rcorder(8).


At first glance I'm inclined to say that this shouldn't be too difficult to achieve by tweaking /etc/rc.subr a bit.

Fonz


----------



## zspider (Nov 21, 2012)

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.


----------



## Amzo (Nov 22, 2012)

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.


----------



## throAU (Nov 23, 2012)

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.


----------



## donduq (Nov 29, 2012)

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!*


----------



## tankist02 (Nov 30, 2012)

I am wondering why launchd is not getting more attention from developers?


----------



## wblock@ (Nov 30, 2012)

Lack of serious problems with the current system?


----------



## throAU (Dec 4, 2012)

^^ 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.


----------



## Sebulon (Dec 4, 2012)

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


----------



## swa (Dec 4, 2012)

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 ?


----------



## wblock@ (Dec 4, 2012)

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.


----------



## marwis (Dec 4, 2012)

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.


----------



## Kt (Dec 4, 2012)

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
> ...



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.


----------



## kpa (Dec 4, 2012)

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.


----------



## wblock@ (Dec 4, 2012)

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.


----------



## Kt (Dec 4, 2012)

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.


----------



## zspider (Dec 5, 2012)

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.


----------



## UNIXgod (Dec 5, 2012)

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.


----------



## throAU (Dec 5, 2012)

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.


----------



## jb_fvwm2 (Dec 5, 2012)

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...


----------



## sossego (Dec 5, 2012)

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?".


----------



## Martillo1 (Dec 5, 2012)

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.


----------



## Kt (Dec 5, 2012)

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?


----------



## Kt (Dec 5, 2012)

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 ...


----------



## throAU (Dec 5, 2012)

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


----------



## serverhamster (Dec 5, 2012)

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.


----------



## jb_fvwm2 (Dec 5, 2012)

serverhamster said:
			
		

> 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.
> ...



Read that link, and I was reminded of another reason why the status quo seems fine for now. If I want to explain in one paragraph (say, in an email) how to do something ( establish a crontab
entry...) it is helpful if an overview is included (Say, a complete newbie receiving the email).
Thus, crontab doable... sendmail a bit more difficult (I'd have to
be semi-expert...)  but, yet  another aspect?  (an XML file to edit and process...) should
prove to add no more than a sentence or two to the entire explanation. Potentially less easy...
Also, I appreciate one-by-one (rc.d)... loadings at the boot so messages hinting and not-done
configurations, etc appear.  A front-end which may hide those would move the tweaks which may
be due from "soon" to "never"... ( If this or any other reasoning I've posted in this thread should be unfounded due to
misinformation or mistaken first impressions, I apologize and will be eventually shown to
be in error.)


----------



## Crivens (Dec 5, 2012)

> 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.



There is a saying which goes like this: There are two kinds of fools. One who say that _this is old and therefore good_, and those who say that _this is new and therefore better_.

If it takes me 5 minutes to migrate a system to a startup system which saves me 5 seconds on bootup, then I need to restart this thing 60 times to break even. And that does not include bugs introduced. I also think that the time is better spent in getting hibernate working.


----------



## wblock@ (Dec 5, 2012)

Suspend or hibernate are a distraction, it's not the same people working on both and therefore not an either/or choice.  Volunteers cannot be assigned to work on projects.

If there were a noticeably better startup system and an easy way to migrate, a lot of people would switch.  As an example, look at pkgng.

However, when you start talking about features that touch on bigger compatibility issues, like XML or converting config files from plain text into another format, it becomes much, much harder to sell.


----------



## throAU (Dec 5, 2012)

Crivens said:
			
		

> If it takes me 5 minutes to migrate a system to a startup system which saves me 5 seconds on bootup, then I need to restart this thing 60 times to break even.



Conversely, if it takes one team of 5 developers 1 week to get ALL instances of the operating system to save 5-10 seconds on every single boot up for the next 10+ years, the economics add up pretty quick for it being a net benefit to the community (numbers pulled at random, but you get the point).

I think the configuration file problem is a somewhat parallel issue, that launchd solves for startup and daemon management only.  Ideally, if you were to go to XML you'd want all config files to be XML - eventually.  Make no mistake, that will not happen any time soon, but that doesn't mean no one should at least attempt to try and use standard configuration files in future projects...

No, I don't particularly like XML myself either, but at least it is standardized (which is more than we can say of the mish-mash of configuration file formats on a typical box) - and that will be beneficial to future users.

If i need to configure a new Unix box (this isn't just a FreeBSD issue) to say, run a few DNS zones, SMTP mail relay, and a few periodic jobs from cron, I need to deal with 5 different configuration file formats there for a start - each with their own syntax to learn.  And that's just a fairly simple, limited-function machine.  Anyone trying to make it "friendly" via a GUI or web configuration app needs to write and debug 5 different parsers...

Sure, I've spent 15 years doing this stuff and I know how to do it, but for someone starting out, it's a bit of a pain.

And really, there's not any real need for it - none of the programs are storing any magic in their configuration file that couldn't be stored in a standardised way.


----------



## Kt (Dec 5, 2012)

Crivens said:
			
		

> There is a saying which goes like this: There are two kinds of fools. One who say that _this is old and therefore good_, and those who say that _this is new and therefore better_.
> 
> If it takes me 5 minutes to migrate a system to a startup system which saves me 5 seconds on bootup, then I need to restart this thing 60 times to break even. And that does not include bugs introduced. I also think that the time is better spent in getting hibernate working.



You'll never know if something is better or not unless your actually willing to try something out rather than projecting your fears on an imaginary situation.

If I understood the original OP properly, he'd tried it with OpenRC, had favourable results, was reporting that fact, and was then dumped on by the status quo vested interests for daring to suggest change be considered.

He then tried to defend his suggestion and got dumped on a bit more.

Frankly, I couldn't care less whether his suggestion made it in to base or not but as he, generously has done some work and was prepared to share then I believe he deserves better than he got.

Personally, I'll look at anything that might improve the rather appalling boot times I'm finding on the latest FreeBSD and PCBSD releases since I'm interested using BSD in a commercial product that could benefit from being as near to instant on as possible.

I'm quite happy to have my own custom version of BSD thats better than base and has encryption in ZFS and not share at all. I was just sticking up for the OP.


----------



## Crivens (Dec 5, 2012)

Kt said:
			
		

> You'll never know if something is better or not unless your actually willing to try something out rather than projecting your fears on an imaginary situation.


That is exactly the point. You need to check the suggestions and provide hard data.
The "this is new and therefore better" argument is no argument at all, and it got several projects (Linux user land, I'm looking at you) in the sorry state where some parts are these days. The opposite is also true, it keeps us back for no reason other than "was good enough for my grandfather, thus good enough for me".


			
				Kt said:
			
		

> If I understood the original OP properly, he'd tried it with OpenRC, had favourable results, was reporting that fact, and was then dumped on by the status quo vested interests for daring to suggest change be considered.


If I remember correctly, he was testing this also in a complete different user land, thus making the results a bit un-portable. 


			
				Kt said:
			
		

> He then tried to defend his suggestion and got dumped on a bit more.
> 
> Frankly, I couldn't care less whether his suggestion made it in to base or not but as he, generously has done some work and was prepared to share then I believe he deserves better than he got.


Yes, he deserves credit. But I would not call it being 'dumped on' what happend to him. He was told that he was not running a reference system, then he tried to defend the view that running a gnu user land does not make it a clean install. That is where his credibility tanked a bit, IMHO. After that, it diverged a into comparison of different startup systems. And when someone threw systemd into it, the thread was doomed.


			
				Kt said:
			
		

> Personally, I'll look at anything that might improve the rather appalling boot times I'm finding on the latest FreeBSD and PCBSD releases since I'm interested using BSD in a commercial product that could benefit from being as near to instant on as possible.


Since most time is spent during the HW probe, and not after init has been started (at least on my machines), you may have best luck to get the different drivers to work in parallel during startup of the kernel. Usually I have about 3-4 seconds between init and xmd. Not using the login managers of kde/gnome can save a lot of time. But for servers, a boot usually ends in a tty login.
So this depends on the thing you want to do.


----------



## Kt (Dec 6, 2012)

Crivens said:
			
		

> That is exactly the point. You need to check the suggestions and provide hard data.
> The "this is new and therefore better" argument is no argument at all, and it got several projects (Linux user land, I'm looking at you) in the sorry state where some parts are these days. The opposite is also true, it keeps us back for no reason other than "was good enough for my grandfather, thus good enough for me".
> 
> If I remember correctly, he was testing this also in a complete different user land, thus making the results a bit un-portable.
> ...



I would call it dumped on. To my mind the initial responses the OP received came across as rude and yob-ish.

I don't believe I said the OP's thing would be better but I was prepared to consider the possibility that it might have been while also being prepared to be wrong.

I do think that the whole of the boot sequence needs to be made as fast as possible and naturally as that is a core part of the system then it will involve risk.

On some recent default installs of both FreeBSD and PCBSD both on different types of bare metal and in VM's the boot sequences were taking more than a minute due to significant pauses in the BTX loader and then the init sequence going slow. Scanning the forums here and the PCBSD ones seems to indicate that others are finding similar delays.

So far the objections raised to even considering changes in the init area seem to relate to:

Projected risk of instability
Perceived learning curve due to that change
"it's ok as it is because it's working"
we don't need faster because we run servers

I recently read some responses on the [post=34581]Why is BSD failing[/post] thread that said a long time BSD server user who'd gone to Linux was afraid of a bit of hard work. I find that sad and ironic (_broad brush strokes_).

According to here: http://www.freebsd.org/about.html FreeBSD prides itself on performance.

Currently, the boot sequence doesn't seem to meet that criteria.

On the same hardware and vm setups I did a comparison with Chrome OS and some research OS's and they booted within < 5 seconds to a GUI in the VM and even faster on bare metal.

As I said before, I don't really care if FreeBSD et all was to accept changes that made it faster but I'll look at any efforts by others and re-use, re-apply etc as necessary to make my own installs faster.


----------



## Crivens (Dec 6, 2012)

Kt said:
			
		

> I don't believe I said the OP's thing would be better but I was prepared to consider the possibility that it might have been while also being prepared to be wrong.


As should anyone. Closing the mind to solutions beforehand should be left in the realm of politicans IMHO.


			
				Kt said:
			
		

> I do think that the whole of the boot sequence needs to be made as fast as possible and naturally as that is a core part of the system then it will involve risk.


The question is if you consider the tradeof as sufficient. If you need reliability and reboot once a year, then this question is easily answered. You do not take that risk. If your typical use involves a lot of rebooting, then the answer might be something else.

As stated before, my systems spend only some seconds between calling init and offering the login screen, so for my typical usage pattern I have spend more time in this thread than I could save by speeding up the boot sequence. So this is about academica for me.



			
				Kt said:
			
		

> On some recent default installs of both FreeBSD and PCBSD both on different types of bare metal and in VM's the boot sequences were taking more than a minute due to significant pauses in the BTX loader and then the init sequence going slow. Scanning the forums here and the PCBSD ones seems to indicate that others are finding similar delays.


The boot can be divided into three parts:

BIOS
Kernel
init

How much time is spent in the BIOS can not be changed by the kernel. The time spent in BIOS or Kernel can not be changed by the init system. Speeding up system init can introduce risks for little benefit, speeding up kernel bootup can (at least on my typical use cases) save a lot more time. That is why I use custom kernels, without the SCSI delay and without the drivers I do not need to boot the machine. This may save only little in space in the kernel file, but not probing for the hardware which is not there speeds up the boot process damatically. Maybe this is what you experience.


			
				Kt said:
			
		

> So far the objections raised to even considering changes in the init area seem to relate to:
> 
> Projected risk of instability
> Perceived learning curve due to that change
> ...



Point 1: should be taken into account.
Point 2: should also matter, but I do not see how that point was made.
Point 3: who made that point?
Point 4: this point is not accurate I think. Servers typically are rebooted once in a blue moon, thus the savings from speeding up booting are not as vital as taking the risk of bricking the system. Speeding up startup is simply less important.


			
				Kt said:
			
		

> I recently read some responses on the [post=34581]Why is BSD failing[/post] thread that said a long time BSD server user who'd gone to Linux was afraid of a bit of hard work. I find that sad and ironic (_broad brush strokes_).


Ahm, I suspect a C&P error here because I do not see how clamav plays into this...


----------



## kpa (Dec 6, 2012)

Parallel execution of start up shell scripts is always a potential minefield because of dependencies to for example proper time and network connectivity.

Here's a nice thread about net/sixxs-aiccu on OpenWRT and why it's no longer integrated in OpenWRT.


http://www.sixxs.net/forum/?msg=general-7418538
Basically the developers of OpenWRT made changes to aiccu service that made it to try to connect to the central server even if it failed repeatedly because of wrong time, many devices where OpenWRT is used lack a proper hardware clock and require setting the time trough ntp. This resulted in the central server being hammered with many connections and the client being banned for excessive number of connections.

The SixXS developers refused to "fix" their service not to ban clients that kept hammering the central server because in their opinion OpenWRT should guarantee that the ntp service sets proper time before starting aiccu and the aiccu service could either fail immediately in case of wrong time or succeed and continue as normal.

I'm completely on SixXS's side on this argument if it's not clear.


----------



## Kt (Dec 6, 2012)

Crivens said:
			
		

> The question is if you consider the tradeof as sufficient. If you need reliability and reboot once a year, then this question is easily answered. You do not take that risk. If your typical use involves a lot of rebooting, then the answer might be something else.
> 
> As stated before, my systems spend only some seconds between calling init and offering the login screen, so for my typical usage pattern I have spend more time in this thread than I could save by speeding up the boot sequence. So this is about academica for me.
> 
> ...



Thanks for explaining a boot sequence, not really necessary as  I already know this, but perhaps useful to other readers. Just because your experience is fine, doesn't mean others are. 



> Point 1: should be taken into account.



Agreed it should be a factor, but not a reason for not investigating something and trying different options. Using it as a reason for not doing the investigation or trying different ways of improving it is rather poor.

Any change, of any kind, involves risk. If any users are so concerned by that risk then they probably should never upgrade since there will always be a chance that their specific setup will tank.

In any event, anyone truly concerned by stability would never be seen dead running the latest and greatest version of any operating system. The prudent thing to do is to lag behind a couple of releases and wait until its been throughly tested by the wider community.



> Point 2: should also matter, but I do not see how that point was made.



I suggest you read back through the thread I don't really want to make this personal.

So your saying that if there is a learning curve (i.e. make some sort of effort) then it should be a reason not to have a change. Well, that could pretty much rule out most changes.

Then again, people concerned about having to learn could always decide not to upgrade and stay with their safe and stable versions that require no extra learning on their part.



> Point 3: who made that point?



Sorry, I'm not going to make this personal and name names. Read back through the thread.



> Point 4: this point is not accurate I think. Servers typically are rebooted once in a blue moon, thus the savings from speeding up booting are not as vital as taking the risk of bricking the system. Speeding up startup is simply less important.



For *you* specifically yes, but not for other server uses - spinning up VM's (ala AWS) would be one I can think of right now. Also, FreeBSD is not just for server uses is it.

In any event since you don't need to reboot that often then you shouldn't mind if its faster and of course since stability is *so* important to you then your safest bet would be be several OS's releases behind anyway.



> Ahm, I suspect a C&P error here because I do not see how clamav plays into this...



[thread=34581]Try this one, I'd use the wrong bb code[/thread]

I must say that I find the reactions on here quite amazing sometimes - on the one hand there seems to be a huge amount of quite rightly deserved pride in the BSD Community's ability to implement well thought out skillfully designed solutions while on the other hand from some quarters at least an absolute inability to put individual needs aside and as a result outright rejection of investigating how to achieve said skill fully designed solutions to a problem.

According to this: http://www.freebsd.org/advocacy/myths.html



> BSD makes a great server. It also makes a great desktop.



Slow startups on default installs of both PCBSD and FreeBSD would seem to make that statement no longer as valid as it could be if we look at the startup times of others.


----------



## jb_fvwm2 (Dec 6, 2012)

Kt said:
			
		

> Agreed it should be a factor, but not a reason for not investigating something and trying different options. Using it as a reason for not doing the investigation or trying different ways of improving it is rather poor.
> Any change, of any kind, involves risk. If any users are so concerned by that risk then they probably should never upgrade since there will always be a chance that their specific setup will tank.
> So your saying that if there is a learning curve (i.e. make some sort of effort) then it should be a reason not to have a change.
> I must say that I find the reactions on here quite amazing sometimes - on the one hand there seems to be a huge amount of quite rightly deserved pride in the BSD Community's ability to implement well thought out skillfully designed solutions


My apologies, but...
Here, I see this "different option" "improving it" "some sort of effort" "skillfully
designed solutions" as an unproven  assumption, or set of assumptions,  that the init process undergoing a fundamental change is already proven to be advantageous to the majority of 
present and future users of the operating system.  Nothing in these threads or the links from
them have shown that to be the case so far, at least from this viewpoint, and several others, so far in
this thread...  *even if* it is indeed advantageous.


----------



## Kt (Dec 7, 2012)

jb_fvwm2 said:
			
		

> My apologies, but...
> Here, I see this "different option" "improving it" "some sort of effort" "skillfully
> designed solutions" as an unproven  assumption, or set of assumptions,  that the init process undergoing a fundamental change is already proven to be advantageous to the majority of
> present and future users of the operating system.  Nothing in these threads or the links from
> ...



You won't know unless you try.

Anything else is just "Change is bad and scary" talk based on the points previously mentioned in earlier posts and lots of assumptions as to what a real implementation might entail.

By all means, if *you* wish to live in fear, and never evolve your personal situation then that is your personal choice.

I love it when people claim to speak for the many or the majority. I think I'd rather hear from 'the many' individually thanks.

Again as with anyone who doesn't want to evolve their system out of fear, the extreme solution is don't upgrade .. ever.

The rather more rational, level headed, responsible approach is to delay your upgrades, and allow things to settle in.

I rather bet that the dissenters do upgrade their systems from time to time. *gasp*
I also bet that those upgrades sometimes effect core parts of the OS.

As for advantageous, If you don't think speed is an advantage then don't upgrade. Don't accept any kernel performance enhancements either.

I suspect, although I wouldn't dream of speaking for the many, that speed is considered advantageous.


----------



## jb_fvwm2 (Dec 7, 2012)

And the canonical method of proving an assumption wrong is by a presentation why it is so, vs simply arguments why it is so. 

Such a presentation in this case, I surmise would take a lot of development time and effort. If that is the reason for many of the posts in this thread, maybe the case should be put directly to those who would be involved. (Or I am misunderstanding and this thread is for that purpose, just not explicity stated as such).


----------



## Kt (Dec 8, 2012)

jb_fvwm2 said:
			
		

> And the canonical method of proving an assumption wrong is by a presentation why it is so, vs simply arguments why it is so.
> 
> Such a presentation in this case, I surmise would take a lot of development time and effort. If that is the reason for many of the posts in this thread, maybe the case should be put directly to those who would be involved. (Or I am misunderstanding and this thread is for that purpose, just not explicity stated as such).



What assumptions ? Why is this to be about proving assumptions wrong ? What do you need to prove ?

This thread is about "Replacement of the Init System"

If a Replacement was proposed for the init system then it should be "discussed", "goals set", "designed", "implemented" and "tested" before it could be "accepted" or "rejected" by an individual user of BSD.

Instead what's happened is quite different.

I'll paraphrase "No, init is sacred, we mustn't touch init because (_insert whatever sweeping objection I can think of/personal reason for not having to deal with a change_)"

Nothing should be sacred in an OS.


----------



## Kt (Dec 8, 2012)

(damn i really wish I could edit my posts - sorry - that last one isn't quite right but it will have to do.)


----------



## fonz (Dec 8, 2012)

I'm not saying that the current init system is perfect, but here's an anecdote:

A buddy and I walk into a computer lab. I dig my netbook out of its case, set it down, go find a free socket and plug it in, insert the boot stick (it's a laptop, so full encryption), boot (requiring a password (encryption, remember?)), login (also requiring a password), start X, open a terminal and get to work. In the meantime, my buddy is still waiting for a login prompt on the lab's Windows PC that was already running...

Can FreeBSD's init system be improved? Sure, some people like parallelisation and admittedly the output could be a bit tidier/niftier. Should the work on that be a top priority? Based on the above: nah, whenever someone gets around to it that's quite good enough.

Fonz


----------



## phoenix (Dec 8, 2012)

I've never understood the fixation people have on 'boot must be faster'. How often are people booting? Are there really people rebooting their systems 30 times a day?  Does is really matter if a system takes 15 seconds to boot vs 1 minute?

Parallel running of init scripts is great ... until you need to debug why a certain service isn't starting.

Everyone who is advocating for change needs to stop, think, and fully instrument the current system. Where, exactly, are the slow parts of the boot process? Does it really matter that bit takes 30 seconds to run through all the rc.d scripts, when it takes 30 seconds to POST, 10 seconds in the loader, and 45 seconds to probe all the hardware?

Until someone site down and times out every single part of the POST, BIOS, loader, kernel, hardware probe, init, login process, this entire conversation is moot.


----------



## donduq (Dec 8, 2012)

phoenix said:
			
		

> I've never understood the fixation people have on 'boot must be faster'. How often are people booting? Are there really people rebooting their systems 30 times a day?  Does is really matter if a system takes 15 seconds to boot vs 1 minute?



Here here. I fully agree.

I also don't understand why people try to bring so much irrelevant arguments to the table:



			
				Kt said:
			
		

> By all means, if *you* wish to live in fear, and never evolve your personal situation then that is your personal choice.



It's also none of your concern. This isn't a therapy session and apart from the fact that your remark is rudely judgemental, it's also highly irrelevant.

The fundamental question of this thread (which I think still hasn't been answered by anyone in favour of making arbitrary _Linuxey_ changes to the current init system), is, "*Why should the init system be changed to something different?*"

I see this as nothing more than a rhethorical question. But if I were to answer it I'd say; given all the recent hackery dackery in working Linux distributions that are only interesting for a few aggressive and almost parasitic "tinkerers", FreeBSD should stay as far away from this as it possibly can.


----------



## Kt (Dec 8, 2012)

donduq said:
			
		

> Here here. I fully agree.
> 
> I also don't understand why people try to bring so much irrelevant arguments to the table:
> 
> ...



Why shouldn't it be my concern ? I'm a BSD user too. I like BSD. No thing is perfect though and as such it can evolve

I also believe that allowing "fear-based reasoning" or "laziness-based reasoning" to be used as an excuse for not even attempting or looking at something to be  wrong. 

As it happens, I believe there is some effort underway to look in to this so its all moot.

Have a good day. 

Namaste.


----------



## UNIXgod (Dec 8, 2012)

Kt said:
			
		

> Why shouldn't it be my concern ? I'm a BSD user too. I like BSD. No thing is perfect though and as such it can evolve
> 
> I also believe that allowing "fear-based reasoning" or "laziness-based reasoning" to be used as an excuse for not even attempting or looking at something to be  wrong.
> 
> ...



I don't know. It becomes obvious when someone hasn't taken the effort or responsibility of acknowledgement of what works and why. I don't need to be an engineer or computer scientist to understand how *BSD is stable. Also taking a step back and realizing that though FreeBSD isn't owned by any one specific entity it's governed by it's committers and core.

Also if you look at how some of the linux distros run into the same administrative issues by attempting to fix layers upon layers of what's already broken to some extent is do to corporations who don't actually care about anything but lock-in policies while poisoning the current ecosystem. Case in point.... Look at redhat's business model to tie centos users back into their M$ linux. Then again Lennart Poettering thinks posix and BSD are irreverent.

More of the same:

http://www.itwire.com/business-it-n...m-vendors-can-harm-small-projects-openbsd-dev

https://queue.acm.org/detail.cfm?id=2349257


----------



## Kt (Dec 9, 2012)

UNIXgod said:
			
		

> I don't know.



Clearly. I refer the right honourable gentleman to the previous posts.



> Also if you look at how some of the linux distros run into the same administrative issues....[/quote
> More of the same:
> 
> Your political views and the failings of others should have no relationship to the topic at hand.


----------



## Crivens (Dec 9, 2012)

phoenix said:
			
		

> Everyone who is advocating for change needs to stop, think, and fully instrument the current system. Where, exactly, are the slow parts of the boot process? Does it really matter that bit takes 30 seconds to run through all the rc.d scripts, when it takes 30 seconds to POST, 10 seconds in the loader, and 45 seconds to probe all the hardware?
> 
> Until someone site down and times out every single part of the POST, BIOS, loader, kernel, hardware probe, init, login process, this entire conversation is moot.



That is the point I tried to make. But since this is now more about how a different init system can speed up reaching the point where init is actually started...



			
				Kt said:
			
		

> Why shouldn't it be my concern ? I'm a BSD user too. I like BSD. No thing is perfect though and as such it can evolve.


That most likely was a reminder that people do not like other people to p*ss into their porridge, even when they currently have toast for breakfast. Making rude remarks and personal attacks does not help your cause either, and I may need to point out that I, too, found these remarks rude and childish.



			
				Kt said:
			
		

> Your political views and the failings of others should have no relationship to the topic at hand.


To cut this short: Do you claim that no one but you has any idea of what's best here? Yes or No?

And, BTW, I heard that good old DOS is booting so fast on modern HW that it reaches the GUI some seconds BEFORE power on.


----------



## Kt (Dec 9, 2012)

Crivens said:
			
		

> To cut this short: Do you claim that no one but you has any idea of what's best here? Yes or No?



God No.

I never claim to know whats best, but I do rather like the idea of what's best being discovered without personal bias in an open forum.

I also:

Don't intentionally claim to speak for anyone other than myself.
Don't use such claims to bolster my arguments
Don't reject out of hand ideas or the suggestion that some change be considered/investigated because of my own individual needs or fears or unwillingness to learn
Don't allow my political/activist views (which I do hold) to affect my judgement on software related matters

What I do do is:

Try to Listen & Learn all the time
Feel free to make mistakes as often as is necessary in order to learn from and admit those mistakes to myself and others
Stand up to people who to my mind use bullyboy tactics to shut me down
Defend those being attacked (_according the to merits of the case_)
Try to appreciate the value in all even though that can be hard sometimes
Look at suggestions with as open a mind as possible, and in this particular context, try to look at it from a community-wide perspective.

If anything I have written in my posts thus far have sounded rude then I can only apologise for any offence that has really been felt by those who felt that offence but since I know that has not been my intention and I also know to well that I have absolutely no control how others freely choose to perceive me I won't beat myself up about it. My days of feeling a need to 'fit in' or 'modify my behavior' in order to please others are long gone.

I am the first to admit that one of my biggest failings is my passion for IT (_it's a huge time sink_) which combined with a difficulty of suffering fools gladly (_that's just a turn of phrase not meant as an attack on anyone other than myself_) sometimes leads me to make quite impassioned and very honest statements.

If I have a pet forum related peeve, it's those people on the forums that run in to an ongoing discussion, clearly haven't taken the time to read and understand the flow of an interesting debate, often say that they haven't even, and then spout something seemingly quite random in an attempt to try and score some sort of point. To my mind that sort of activity is rather rude and shows a singular lacking on their part but thats ok they are free to show themselves in that way. I imagine I'm not the only one that sees those sorts of postings for what they truly are.

As a person, I am very direct and honest with myself and sometimes perhaps a too honest with others but then I prefer that people are like that like to me really. It's often not the case and leads to all sorts of misunderstandings. :\

I'm afraid I'm not the sort of person to ask "_Does my backside look big in this outfit?_" when the person asking is really looking for some sort of ego boost but then that's because I value how people behave rather than how they look and so show my support by being honest instead. :e

All too often, in the open source communities, I am faced with people that fail (_actively or passively_) to see beyond their own individual needs and I feel that in the process opportunities for the community as a whole are stifled and lost. Something I've never gotten on with is the sometimes outright hate-based zealotry that occurs but that's another story which I won't bore you with.

Anyway, enough, I'm tired of this exchange. It's been interesting and educational in a variety of ways thus far so "Thank you for that"  but I won't be commenting further on this particular topic.

I'll hand the microphone to the next poster, this soap box is about to be vacated 

Good luck and Namaste.


----------



## throAU (Dec 9, 2012)

To clarify my stance:
I don't believe FreeBSD *needs* to replace init.

However, I think there's opportunity for improvement there. And I don't even believe that boot speed is the major potential win out of it (although it would be nice).  My angle is that currently there is a multitude of different daemons/scripts (init, inetd, cron, etc.) to start/stop services depending on different circumstances.  

In my view, it makes sense to streamline all those different methods of service start/stop scenarios into a single subsystem.

Yes, it would break x0 years of tradition/sysadmin compatibility, etc.  But long term it could be worth it.  With that in mind, I'd be swayed more towards something popular and not written by Lennart


----------



## jb_fvwm2 (Dec 9, 2012)

Suppose eight daemons, twenty scripts, three services.  Streamline init(d) is something I'd not want to attempt (XML breaking mergemaster...)... Long term, yes, but maybe because it may take years of beta testing to be proven as reliable. In my view, different scripts/daemons/services could be improved individually, and we might have more improvement in the end than the introduction of an additional facet to it all, given the limited man-hours of coding persons might wish to nominally persue.


----------



## donduq (Dec 10, 2012)

Kt said:
			
		

> I'll hand the microphone to the next poster, this soap box is about to be vacated



Thanks, then we can get back on topic.

My own main concerns with any new init system is that I can also choose from a hundred other, more important tasks to work on. I'd prefer to be free in this without having to worry about this new init system beast coming my way and eating my routines at an unchosen point in the future. I haven't fully thought that out mainly because I hoped that the entire discussion wouldn't come any time soon.

I'd prefer an analysis on the content of what I said rather than being subjected to an arbitrary psychological examination of my character. For example, rather than telling me how stuck I am in my routines and how I am lazy due to my unwillingness to change them, one could also simply describe how to facilitate an init change in a convenient way that does not scare people like me away... the Ball is in your court.

Like I said before: It is mostly _because_ of the tinkering with init in Linux land; because of the many inconsistencies between distributions; because of all the drama evolving from all of this that I moved to FreeBSD! FreeBSD is stable. Changing something that is stable requires substantial effort if it wants to remain stable. Everything not stable should be optional.

Until the dust of the current rise of "the Knights For The New Init" has settled I'd prefer to wait it out and not partake. Personal preference; we all have one.


----------



## break19 (Dec 10, 2012)

"replacement init" ? No.  "Tweak the existing init" ? - MAYBE. Those tweaks would need to be -WELL- thought out.. and -WELL- tested before I want them coming anywhere NEAR my boxen.


----------

