Positions forming in the Debian init system discussion

Posted Dec 30, 2013 16:40 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Positions forming in the Debian init system discussion by tjc
Parent article: Positions forming in the Debian init system discussion

What is this "simplicity" everyone's talking about?

Upstart is no less simple than systemd. Can you tell me why the hell upstart uses ptrace, for example? Do you even know that it uses it?

And portability is a non-argument. Both upstart and systemd are about equally non-portable to other operating systems. Both exist only on Linux.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:01 UTC (Mon) by dan_a (guest, #5325) [Link] (10 responses)

I disagree that they are equally non-portable.

As I understand it, systemd exists only on Linux and the maintainers are against the idea of it being ported, whereas upstart exists only on Linux and the maintainers are in favour of it being ported provided that someone else carries the burden of that work.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:03 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

Nope. Upstart maintainers simply made polite noises about supporting portability.

They have not committed any resources to porting projects or even promised to merge changes back into the upstream upstart trunk.

Systemd people are simply more honest in that regard.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 19:36 UTC (Mon) by anselm (subscriber, #2796) [Link]

The old saying goes, »There is no portable software – there is only software that has been ported.«

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 2:23 UTC (Tue) by CameronNemo (guest, #94700) [Link] (7 responses)

Actually, they have a roadmap for porting Upstart, and the first milestone is 95% done. libnih has been ported to kFreeBSD, except for abstract namespace sockets. This is a huge step, as there is only a small amount of non portable code in Upstart itself (there is, for example, only one use of epoll, in upstart-socket-bridge, an optional component).

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 17:20 UTC (Wed) by misc (subscriber, #73730) [Link] (1 responses)

So there is only 5% to do, and then upstart will see freebsd as a official port ( ie, they will not start to rely on linux-only features ), or will it be seen as a 2nd class citizen with features being disabled if they cannot be ported ( like the future cgroups integration ) ?

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 18:15 UTC (Sat) by CameronNemo (guest, #94700) [Link]

Not what I said. There are multiple milestones. The first one is porting libnih. All that is left with that is nih_watch, and it is done. nih_watch can easily be implemented using kqueue.

I do not know what the next steps are, but I assume them to be related to porting upstart proper, and then write a devd-bridge for hotplug integration. Anyway, Upstart proper is close. Very close.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 13:00 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

Software is always 95% done :-)

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 15:10 UTC (Thu) by rriggs (guest, #11598) [Link] (1 responses)

The last 5% always takes 95% of the time.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:33 UTC (Thu) by marcH (subscriber, #57642) [Link]

... according to the 80-20 rule.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 4:10 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (1 responses)

is the libnih porting actually done? Or has the porting just been done to the point where libnih will compile and pass the simple tests provided in the libnih, basically faking successful tests? My last understanding of the situation was not as far as long as you are indicating.

The last message with regard to the start of the porting effort says the kevents have not been integrated to replace inotify for example.
https://lists.debian.org/debian-ctte/2013/12/msg00322.html

Sort of important....

And let's be very very clear here... this is full fork of libnih by people who are NOT maintainers of libnih. The upstart devs and Canonical devs who want to see upstart adopted by Debain are not on the upstream development team for libnih. Libnih is not a Canonical controlled project and thus they have to fork it to get the changes in that they want, on the timescale that they need, to influence the debian discussion. libnih upstream is not onboard with these changes.

libnih.la packaging as proposed, is not a set of patches being applied to libnih in the debian packages. This is a completely new source package, which will necessarily conflict with the existing libnih package and being introduced without upstream libnih buyin.

Effectively holding onto a debian specific fork of libnih is no different then trying to hold onto a debian specific fork of systemd. Except that libnih is effectively no longer seeing actively development. If libnih can be _forked_ for portability then so can systemd. And this is exactly what systemd devs said from the start about portability...downstream fork and replace the linux specific API calls to meet Debian's goals. What the upstart devs are doing with libnih, is exactly what systemd devs expected debian to do to get portability...fork and replace the API calls and maintain the fork downstream as a separate source level project. systemd.la is no less better or worse than libnih.la from a maintenance burden.

I fully expect the libnih.la fork to start diverging from libnih over time. Its clear from the github activity that the libnih upstream maintainer, is not onboard with the full set of changes necessary as merge requests have lingered for weeks now. Why else would Debian need to consider including a forked version of the codebase as a new package? Instead of just a set of patches ontop of the standard one? The only reason to take that route is the expecation that the featureset, beyond portability, is going to diverge over time and that upstream is not going to be onboard with a significant subset of the patches.

If the upstart maintainers/developers are serious about forking libnih like this, then they need to start using that forked sourcecode tree in Ubuntu _and_ Debian to get better coverage for bug reports and patches. It's absolutely silly for them to be spinning up libnih.la fork just for Debian, while continuing to eat from the mainline libnih project.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 6:47 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

The following is from the description of the ITP for libnih.la[1]:

"This is separate source package as the supported set of APIs is not yet
fully same as of the Linux port of libnih. For example kqueue/kevent
technology is not yet used to provide, e.g. file level notification as
done with inotify in the linux port.

...

Together with this effort, I am staging patches for Upstart itself for
kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It
compiles, but at the moment is still incomplete. The test-suite does not
pass yet and there are no kFreeBSD specific bridges yet (e.g. devd
events, instead of udev, etc.). I'm hoping to have a bootable
kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on
5th of November 2014."

So it's a fork, but it aims to be a temporary one.

Porting Systemd to GNU/kFreeBSD is possible, theoretically. In practice AFAIK people looked at it and gave up for technical reasons. There seems to be some initial work on porting systemd to the HURD: [2] (A post from about half a year ago which I can't seem to read right now).

[1] http://bugs.debian.org/733743
[2] https://teythoon.cryptobitch.de//posts/what-will-i-do-nex...