Hacker News Reader

Comment by dijit | Hacker News Reader

Honestly, SMF is superior to SystemD and it’s ironic it came earlier (and, that shows based on the fact that it uses XML as its configuration language.. ick).

However, two things are an issue:

1) The CDDL license of SMF makes it difficult to use, or at least that’s what I was told when I asked someone why SMF wasn’t ported to Linux in 2009.

2) SystemD is it now. It’s too complicated to replace and software has become hopelessly dependent on its existence, which is what I mentioned was my largest worry with a monoculture and I was routinely dismissed.

So, to answer your question. The argument must be: IllumOS over Linux.

View on HN

> software has become hopelessly dependent on its existence

With some effort, Devuan has managed to support multiple init systems, at least for the software packaged by Devuan/Debian.

> SMF is superior to SystemD ... [CDDL]

OSS workalike opportunity, as new Devuan init system?

> The argument must be: IllumOS over Linux.

Thanks :)

SMF is OSS. The CDDL is an OSI approved licence. I'm not aware of any reason one couldn't readily ship user mode CDDL software in a Linux distribution; you don't even have the usual (often specious) arguments about linking and derivative works and so on in that case.

>Honestly, SMF is superior to SystemD

Maybe 15 years ago, not by a mile now. systemd surpassed SMF years ago and it's not even close now. No one in their right mind would pick SMF over systemd in 2024.

I regularly pick significantly less featured init systems over systemd whenever it is feasible, because systemd and it's related components have caused some of the largest amounts of work for me over the past decade.

I don't really want to litigate the systemd vs. everything else argument, but as someone that has issues with systemd but is not particularly in love with sysvinit derivatives, I wouldn't mind SMF as an alternative.

The fact that its less opinionated about logging and networking and doesnt ever force any reload of itself are all reasonable reasons to prefer it.

You don’t lose socket activation or supervison. SMF is designed to help work in the event of hardware failure too, which systemd definitely cant handle.

>The fact that its less opinionated about logging

It's simple and straightforward to use any other logging or network configuration system you wish.

>doesnt ever force any reload of itself are all reasonable reasons to prefer it.

It doesn't force reload it self.

>You don’t lose socket activation or supervison.

You don't lose that in systemd either.

>SMF is designed to help work in the event of hardware failure too

So is systemd.

>which systemd definitely cant handle.

It definitely can handle that. One of systemd's core functions is handling hardware events.

The confidence here is breathtaking.

Did AI write this? its completely incorrect.

>The confidence here is breathtaking

Tends to happen when facts are on your side.

>Did AI write this?

"Everything I dislike is AI."

>its completely incorrect.

No it's not.

Yeah, it is. Systemctl reload, journald binary logging being forced on (is an opinion) and so on.

Blisteringly fucking moronic that you double down.

“not losing socket activation” was a reference to the fact that systemd actually gives you that.

>Yeah, it is.

No, it isn't

>Systemctl reload

Yes, that is a feature.

>journald binary logging being forced on

Again, no one is forcing you to use that, this is old FUD.

>Blisteringly fucking moronic

Ad hominem means I'm right and you can't handle it.

>that you double down.

Yes, the facts haven't changed, I double down on the facts.

>“not losing socket activation” was a reference to the fact that systemd actually gives you that.

Good feature.

Reply on news.ycombinator.com