Debian Still Debating Systemd vs. Upstart Init System

[Ibidem]

You probably didn't read into the details then. No such port that actually works currently exists and none of the porting efforts are anywhere close to being functional at all. In other words, no real practical relevance.

From http://lists.debian.org/debian-ctte/...msg00273.html:

On Mon, Dec 30, 2013 at 11:56 AM, Russ Allbery <[email protected]> wrote:

The latest that I have seen on this porting effort is here: http://blog.surgut.co.uk/2013/11/lib...ported-to.html

I asked previously on this bug if someone had later news. Do you have more information than that?

The above is definitely not "upstart running on BSD." That's upstart's underlying support library mostly working on BSD after disabling two features (that are required for upstart).

I know inotify is working on kFreeBSD with the libinotify-kqueue software (recently packaged in Debian). https://github.com/dmatveev/libinotify-kqueue

That leaves only abstract domain name sockets left, which should not be too complicated.

Upstart still does not run on kFreeBSD, though.

Then there's this:

https://code.launchpad.net/~xnox/upstart/kfreebsd

Which sounds like most of the Linux-specific issues needed to build Upstart for kFreeBSD have been taken care of, and it's probably a lot closer to working than a systemd port or a hypothetical "systemd replacement for *BSD".

(Note: I'm actually one of the folks who prefer a more shell-oriented init system, whether OpenRC or SysV based. Remember, I have no idea what atrocities Red Hat committed in their initscripts, since I use Debian.)

[profoundWHALE]

Switch to systemd and use that extra time you spent discussing an easy answer (anything but Upstart is that answer) to port it to BSD or Hurd and then there's not worries about portability.

[mether]

Which sounds like most of the Linux-specific issues needed to build Upstart for kFreeBSD have been taken care of

There is a lot more Linux specific API's in upstart. eventfd(), epoll(), singlafd() and more. They are not close.

[BeardedGNUFreak]

Switch to systemd and use that extra time you spent discussing an easy answer (anything but Upstart is that answer) to port it to BSD or Hurd and then there's not worries about portability.

LOL!

I would love to see the reaction from the BSD devs that someone was porting the GIGANTIC STINKING PILE OF FAIL that is systemd to BSD.

[nightmarex]

Whatever they choose (and for whatever reasons), hopefully the users won't get screwed over by it. I seriously doubt they will anyway but just saying

That's the thing I find funny about all this... When arch switched to systemd, you have to understand there were a ton of init scripts that were being used. If arch users can switch (people who were actively editing and scripting initiation services and sequences) users who never had to because their OS is responsible for management, shouldn't have a problem. Chances are you wouldn't be able to tell what was under the hood. With that said, the only thing you have to watch out for with systemd is race sequences(actually failed inits) because it may try to load a deamon before a system is available due to it's async nature. You can specify it to start after something has init'ed or use the after= but that's about the only problems from a user standpoint...

[Ibidem]

There is a lot more Linux specific API's in upstart. eventfd(), epoll(), singlafd() and more. They are not close.

http://lists.debian.org/debian-ctte/2013/12/msg00284.html

and the previous link to Launchpad appear to differ.

AIUI, upstart itself built out of the box once libnih was available, because
all the portability issues are encapsulated in libnih. (The single use of
epoll in the upstart source is in the upstart-socket-bridge, which is an
optional component from upstart's perspective and certainly not needed for
booting a Debian base system - so presumably Dimitri just built with this
bridge disabled.)

With libinotify-kqueue (that Dimitri maintains), kfreebsd 10 (in
experimental), eglibc 2.18 (also in experimental), and Dimitri's branch of
libnih, it seems that all the portability requirements for upstart are met,
except for abstract socket support. There are evidently still some porting
problems that aren't detected at build time, because upstart doesn't yet
boot on kfreebsd. But all things considered, the port is rather far along.

[endman]

Debian should take all the people responsible for kfreebsd out into the courtyard and have them shot along with their families and friends. Then go back inside and switch to systemd.

Besides, currently BSD is trying out launchd....

Please god let Debian chose systemd.

Watching the systemd fiasco unfold and spread throughout the Linux world is like a horrible car accident you just can't help from gawking at.

You’ll see what happens when BSD starts to seriously considers launchd it’ll be like famine and flooding in North Korea. The argument in Debian about choosing systemd or upstart will be nothing compared to the shit storm that is about to come to BSD due to launchd and discussions and debates in Debian will appear very gentlemanly and professional by comparison.

As you can see, there are many grumpy old unixtards in BSD that want to stick to 1970s style BSD init scripts and much of them are in the higher ranks of the BSD projects and they are well known to be ruthless and corrupt bending over only when given bribes by Apple and M$. What I can see that the issue will be raise on the mailing list, followed by massive infighting and then a massive purge of BSD project members. Sometime later, new BSD variants appear (BSD becomes more fragmented) and we start seeing old BSD variants dumping pkgng, pkgin, KMS, ZFS, HAMMER etc. under the pretence that they are “obsolete”. Finally BSD as a whole will become even more of a mess.

[Vim_User]

With two Canonical employees in the Debian Technical Committee and Ian (Ex-Canonical employee), there are currently atleast three votes in favor of upstart.

So you are now accusing the TC to be biased? Maybe you should tell that those members, they already declared that they will not vote if this accusations come up.

[Vim_User]

No we don't

Sorry, but I (and I think many others) have never elected you to speak for us. You can have your opinions, but don't speak for me.

[mether]

http://lists.debian.org/debian-ctte/.../msg00284.html
and the previous link to Launchpad appear to differ.

Not really. Debian ports include KfreeBSD AND Hurd. I think supporting all of these forcing a lowest common denominator mindset which makes it unattractive for developers to integrate well with any kernel but free free to post an update when there is a Hurd port in progress too.