Will there be a new init for FreeBSD anytime soon?

I'm a 7+ year Linux user and I've been experimenting with FreeBSD for 1+ years, sometimes trying it out on my laptop and sometimes PC-BSD magically appearing on my sisters laptop which she asks to fix all the time. I find FreeBSD very stable the the new package management pkgng very useful, ports was super slow sometimes and would churn out the most annoying errors sometimes.

I couple of months to a year I remember some FreeBSD guy talking about how systemd was a great idea and that FreeBSD should have something like it, perhaps porting Upstart, Launchd, or that other Solaris init which everybody totally forgot about. Where did all that talk go and has there been anything so far?
 
It's not impossible, it would just be a big deal. For example, switching to pkg was a pretty big deal, but it happened.
 
It's not impossible, it would just be a big deal. For example, switching to pkg was a pretty big deal, but it happened.

I remember at last years BSDCan Jordan Hubbard spoke about his opinions on rc.d, and it seems like all the improvements he suggested has to do with mobile devices or ones that are run on a battery; so I'm assuming better power consumption management through implicit dependency tracking? Does the project plan on gravitating towards such devices in the future?

I've instrumented the current setup (from POST to login), and iI can't think of anything that would benefit (or at least improve) FreeBSD for it's intended purpose (servers) by using something else, or even altering current rc.d.

I still don't know why iXsystems is using launchd for FreeNAS 10 when our current init system is perfectly fine, IMO. If they have reasoned progression with what they're doing, maybe it could compelling enough for FreeBSD to adopt.

That's what I got out his spiel at least.

As a developer, what do you think?
 
I've instrumented the current setup (from POST to login), and i can't think of anything that would benefit (or at least improve) FreeBSD for it's intended purpose (servers) by using something else, or even altering current rc.d.
My servers spend most of their boot time doing various BIOS and add-on card things - RAID controller w/ 16 drives, PCIe SSD, SAS adapter for external tape drives, and 10GbE network cards all demand their piece of BIOS initialization. I could disable some of the add-on card BIOSs, but I don't reboot often enough for it to be a big concern, and for some of the cards, "disabling" the BIOS means erasing it, so I would lose the ability to diagnose things pre-boot.

I think the "low-hanging fruit" for FreeBSD startup speed improvement is the memory test (or whatever it is doing) between the loader spin and the first line of kernel output. On large-memory (48GB and up) systems, this takes a lot of time and it isn't apparent what it is doing. There's some discussion here, but I don't think it was ever determined what it was doing that took so long.

Desktop systems are generally a lot faster getting through their BIOS startup. With "fast boot" enabled on a Dell Optiplex, I barely have enough time to catch the BIOS and hit F2 for setup when I reboot Windows (which I do a lot more often than I reboot FreeBSD).
 
FreeBSD is a professional, Unix system. To do what Linux does would make it not a Unix system. Linux is not a Unix-like system. So, no, FreeBSD will not implement systemd or anything like it.
 
I've spoken to several people who would really like to have launchd or something similar. Like our present init system, but able to do more and react better. Better power management is just one thing it allows, but that alone might be worth it. Servers can save power (and money) by putting temporarily unused hardware in standby, too. A faster startup and better power savings on my notebooks would be nice, and embedded hardware could benefit too.

It would be a relatively big project, possibly more for public relations than the technical side. But big changes do happen in FreeBSD from time to time. The switch from CVS to Subversion, and from GCC to Clang are other examples.
 
FreeBSD is a professional, Unix system. To do what Linux does would make it not a Unix system. Linux is not a Unix-like system. So, no, FreeBSD will not implement systemd or anything like it.

FreeBSD is UNIX like, legally and technically, not UNIX. If you still think its a professional UNIX system, then please fix it's Wikipedia entry, we would be grateful.

Regards.
 
I've spoken to several people who would really like to have launchd or something similar. Like our present init system, but able to do more and react better. Better power management is just one thing it allows, but that alone might be worth it. Servers can save power (and money) by putting temporarily unused hardware in standby, too. A faster startup and better power savings on my notebooks would be nice, and embedded hardware could benefit too.

It would be a relatively big project, possibly more for public relations than the technical side. But big changes do happen in FreeBSD from time to time. The switch from CVS to Subversion, and from GCC to Clang are other examples.

Hmm, I guess once you start scaling systems power starts to become issue, and being able dynamically control consumption would be nice. Makes sense.
 
FreeBSD is UNIX like, legally and technically, not UNIX. If you still think its a professional UNIX system, then please fix it's Wikipedia entry, we would be grateful.

Regards.

FreeBSD is genetic UNIX (through heritage), but it can't legally use the UNIX trademark. So it has to be called "Unix-like". But it is UNIX.
 
If what you're hoping for is that your FreeBSD experience will soon closely resemble your Linux experience, you can do away with that notion right now. Many aspects of FreeBSD's development model and underlying philosophy are opposed to the way things are done in the Linux world. If a new init system ever appears, it will be because that init system does something the devs believe will be of benefit to FreeBSD while conforming to the FreeBSD way of doing things. Example:

...perhaps porting Upstart...

The chances of any new GPL project making it into the base system are (in my admittedly limited assessment) virtually nil--licensing consistency was one of the reasons Clang was adopted. What's more, a new init system would almost certainly have to be a re-imagining of the *BSD-style init, something that could both work with and improve upon the existing system without requiring drastic change. Hence the new packaging system being designed from the bottom up to work with (in fact, be dependent upon) the FreeBSD ports system. Simply having a binary package manager wasn't the point--it had to be a package manager that was part of FreeBSD, and improved upon FreeBSD, not just some extra convenience. As has been said, FreeBSD tends to put more weight on professionalism than experimentation or "what might be cool." That pkg(8) makes life easier for people administering multiple vital systems is more important than the fact that it makes life easier for noobs who don't understand or have the patience for ports.
 
The simplest thing you can do to speed up the boot time is to put autoboot_delay="1" in /boot/loader.conf. On the (rare) occasions when you want to change the default selection or look at the Orb (or Beastie with loader_logo="beastie") longer, just hit space at the right time.
 
Just posted today to the freebsd-hackers mailing list:
The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging.

The site is at http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html, and
nosh is of course simply licensed under the MIT Expat Licence, the ISC Licence, and the FreeBSD Licence (in the belief that they are all in essence identical and in order to avoid BSD Licence Hell).
 
This is quite interesting indeed. If I read the information on the site correctly, it would potentially fix some of the problems of ported applications that depend on/parts of systemd(among other things). That would be excellent in and of itself. A much better idea than trying to shoehorn launchd into FreeBSD in my humble opinion.
 
If I read the information on the site correctly, it would potentially fix some of the problems of ported applications that depend on/parts of systemd(among other things).

No, nosh just comes with a script to translate systemd service units into nosh service units, and wrappers to interact with nosh via systemd commands. It does nothing to obviate application dependencies on systemd components like logind, systemd.mount and udev.
 
No, nosh just comes with a script to translate systemd service units into nosh service units, and wrappers to interact with nosh via systemd commands. It does nothing to obviate application dependencies on systemd components like logind, systemd.mount and udev.
Ah, ok. Makes sense. I just skimmed the page and some of it is a little over my head at this point so thanks for the correction. :) Even with my limited understanding however, I still think this is a much better idea than trying to make launchd work.
 
Fortunately, Nope.
Not so sure... https://wiki.freebsd.org/launchd
20150629: The TrueOS fork of FreeBSD 10 has launchd running as init and a JSON-aware launchctl utility, along with notifyd, libdispatch and ASL integrated. This work has also been forward-ported to FreeBSD -CURRENT. FreeNAS 10, which is also based on FreeBSD 10.1, will be using launchd and a host of other tools ported from OS X / iOS. It has used the original, and latest, Apple sources and ported them along with MACH IPC.
 
I don't think launchd will be ready for FreeBSD 11. Since the init system touches so many parts of base, it would have be proven stable before customers adopt it, IMO. Who knows though.

Exciting stuff nonetheless. This is going to be huge for FreeBSD on embedded devices, and server scaling.
 
I don't think launchd will be ready for FreeBSD 11. Since the init system touches so many parts of base, it would have be proven stable before customers adopt it, IMO. Who knows though.

Exciting stuff nonetheless. This is going to be huge for FreeBSD on embedded devices, and server scaling.
How so?
 
Back
Top