I like FreeBSD but after getting used to systemd I can't go back to systems without useful init systems anymore.
Maybe at some point one of the BSDs will implement a new, cleaner init system.
Maybe at some point one of the BSDs will implement a new, cleaner init system.
Could you eloborate where you had problems? The BSD init system is already quite clean, much cleaner than sysvinit.
I'm not sure what systemd features you need but most if not all can be replaced by small unix tools - that's kind of the point of the BSD philosophy.
(I know these topics can get quite heated, but I'm genuinely not looking to start a flame war).
While systemd clearly helped consolidate and make administration more predictable across linux distros, there are deficiencies and regressions due to systemd which for the most part didn't exist in the pre-systemd era. It may be due to the scope of functionality systemd aims to cover, but some of the unconventional or missing command line options don't help either. However, it's used by enough mainstream distros that I expect the kinks to be fixed with time.
I was more interested in why the OP didn't consider FreeBSD to have a "useful init system". Just wondered if it was a preference thing or if there were features s/he considered it to be missing or were perhaps unaware of.
I keep seeing this argument, and i keep wondering what it is actually trying to say.
Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working.
But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Then again, maybe i am not the laptop packing dev convention goer that seems to use their laptop more like an oversized phone than a laptop (never mind a desktop).
Edit: damn keyboard ignored the copy command somehow, so i had the wrong quote pasted...
Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc. Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.
There's a new version of nosh ready on the new WWW site. I'll be announcing in the usual places soon. I believe that it has a few things of interest to people, including (given what was said above) a slight further extension on the cross-platform front.
URL: https://jdebp.eu/Softwares/nosh/
> It has moved. There's an article on the new WWW site about what happened.
Can't find the article though.
That's not the nosh 1.28 announcement, by the way. I have yet to do that.
> That's not the nosh 1.28 announcement, by the way. I have yet to do that.
Okay, will that include the "article on the new WWW site about what happened"?
As I said, it's on the new WWW site, and you can read it there.
For want of a better place, I put it on the new WWW site in the "author" section. For now. The change of WWW site motivated me to do some restructuring of things that I laid out decades ago and tidy up stuff that was only there for some old URLs that were floating around (that don't point to the new WWW site of course, making the fixes for them irrelevant). I still haven't settled on the layout of the "author" section, and it might change. Any URL valid now might not be valid in months and years to come when this comment is still visible to the world. And I have just been tidying up the long-term consequences of stale URLs on discussion fora from years ago.
So just follow an author hyperlink, from pretty much any page, to the (current) author section and proceed from there.
BSD init is pretty small and clean. I would argue systemd is much less so because of the large scope of the project. The more lines of code and features you have means there's going to be more bugs and more ugliness, and that's true for all large programs. New doesn't mean better either. If it isn't broken and still works well, then you don't need a replacement, which really is why systemd exists to begin with. Sysvinit was a god awful and byzantine program IMO.