I'd love to see a side-by-side comparison of systemd vs SMF. (I just searched for one but could not find it.) I wonder if those Linux folks who are so anti-systemd would feel the same way about SMF? When SMF came out, I don't remember any of my Solaris sysadmin friends complaining about it, they all seemed pretty excited.
I'm in the "Loves SMF but not a huge fan of systemd" camp
SMF took over and replaced things that made sense for it to replace. It didn't attempt to replace everything everywhere, which as best I can tell, seems to be the overall summary of the systemd roadmap.
I would love SMF on Linux, but unfortunately it would be quite difficult to port over - it makes extensive use of contracts and doors.
It would be interesting to know how large this demographic is: one of the interesting possibilities we have with LX-branded zones on SmartOS[1] is that "SMF for Linux" is a distinct possibility, albeit by bringing Linux to SMF rather than the other way around.
I'll go on the record and say that, as someone who uses SmartOS in production, I've thought about spending the time to try to coerce SMF to manage things running in LX-branded zones.
If nothing else, it would make building reliable services a little more accessible to some of the systems administrators that I support who aren't quite in love with the idea of using runit and monit over SysV init and cron.
As an originally Linux admin, and then a UNIX admin, and now back to Linux..
I liked SMF.. Fuck SystemD with a rake in the rain on a Monday.
SMF had a lot of improvements also after opensolaris died off and we were left with openindiana.. the thing is, it didn't fly in the face of the current system, logs were referred to not 'journaled' away, and it didn't try to gobble up the networking stack at all, but it did allow the system to verify networking ability.
it was very nice, and I regret not understanding it more.
Although I didn't like that it was XML, yaml,JSON or even INI would be preferable in my mind.
It sounds like you've had specific bad experiences with systemd, would you mind sharing what they were? A lot of the criticisms I've seen of it were philosophical and many hadn't actually ever used it, so I'm curious to hear some practical complaints. Personally, I've been using it for a while and it's been pretty good to me, so it is interesting to hear from people who have been less fortunate.
I've also used SMF a bit and thought it was pretty decent.
mostly in the logging, it's hard to get anything truly meaningful when shit hits the fan, I even studied the man pages fairly religiously but because the native application had it's own logging mechanism which was removed by the distro maintainer/packager (fedora) it took a while to realise and reenable. this is the first listed not because it's a big deal but it cost me a day of work, which is hard to explain to my boss.
There are multiple issues in how it handles networking, notably that 802.3a/d bonding is kinda broken and nobody seems to give a crap, which means using it in production is somewhat dangerous for me, the same way that loading modules breaks, gets fixed then rebreaks in odd ways (lsmod/modprobe)
the fact that nobody seems to give a crap about the previous bug, and that bugs get introduced and the developers hostile attitude also rubs me wrong.
FirewallD is a shitshow, and yes it can be disabled, but that doesn't mean that it's -not- going to be the officially supported method of interfacing with netfilter in the kernel.
I've had systems become unbootable because systemd introduced a bug which caused it to segfault and I couldn't "revert" the change like I would with a bad kernel, but this is the cloud era and I should really be adopting ephemeral builds- but if it ever happened on a stageful machine I'd be angry, I can HA all I want but I want to be able to recover and more robustness is significantly better than less.
My problems are fewer because I never wanted to touch systemd, I've been skeptical and rewarded somewhat for my skepticism when i actually started using it out of curiosity or because I really hate being on the previous version of a thing.
Actually, what I really hate most is not the issues I've had, new systems often have warts and we should encourage discussion to get them fixed.. not shut them down when problems are shown because there _are_ problems.. my issue is how under-represented other init systems are, I didn't like systemd and was basically told (by developers, mostly) to "suck it up" and to stop "getting in the way of progress", and while I've never tried to defend sysVinit, I was always keen to have a discussion about a _well engineered_ solution to this would be.. somehow SystemD has taken over and it's more windowsy than we imagined and growing daily.. it even has a bootloader now.
Nosh is a cleaner implemented init system and so is SMF, they fix a problem and do so well..
systemd works great on my laptop though! (arch linux)
So, this isn't exactly a tech support forum, but...
Does your Arch Linux system consider nr_inodes=0 to be a valid mount parameter for tmpfs? If it does, does it use systemd 225?
I upgraded to Kubuntu 15.10. On first reboot, I found that my boot failed because the system claims that tmpfs does not accept a value of 0 for the nr_inodes parameter.
It has been documented for a very long time that "0" for nr_inodes, nr_blocks, or size means "unlimited". My Gentoo Linux systems running kernels from 3.x through 4.2.x have always happily accepted this value, so I know this isn't a mainline kernel change. Kubuntu 15.04 also accepted this value.
