User: Password:
|
|
Subscribe / Log in / New account

Positions forming in the Debian init system discussion

Some of the members of the Debian Technical Committee are starting to post their conclusions regarding which init system the distribution should use in the future. In particular, Ian Jackson has come out in favor of upstart: "Firstly, unlike the systemd maintainers, I think portability to non-Linux systems is important. It may be that our existing non-Linux ports are not very widely used, undermaintained, and/or not of production quality. However, I think it is important for us to keep those options open."

Russ Allbery, meanwhile, is in favor of systemd. "There are two separate conceptual areas in which I think systemd offers substantial advantages over upstart, each of which I would consider sufficient to choose systemd on its own. Together, they make a compelling case for systemd."

In both cases, the authors have extensively documented their reasons for their decisions; reading the full messages is recommended.


(Log in to post comments)

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 15:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

The last few days of debian-ctte mailing list looked like heavy astroturfing against systemd.

A pity. Debian is going to live in its own insular world, choosing a clearly inferior technical solution.

I guess I'm going to start learning YUM command line options and switch to CentOS. A pity, Debian package repository is still way better than Fedora's or CentOS's.

various options

Posted Dec 30, 2013 15:56 UTC (Mon) by coriordan (guest, #7544) [Link]

As Allbery says, it's not about upstart v. systemd. The latter is an umbrella term for a group of projects and almost all of them are being adopted by Debian. The debate is only about the init component.

Upstart init is one option. Forking systemd and making it portable is another. Adding the "Linux" features to kFreeBSD and Hurd so that both can use systemd init is another.

If the decision was mine, systemd's current lack of interest in portability would be a show stopper for the "pure systemd" option.

various options

Posted Dec 30, 2013 16:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

>The latter is an umbrella term for a group of projects and almost all of them are being adopted by Debian. The debate is only about the init component.
And journald - it's mostly useless without systemd.

I've been using systemd-based systems for half a year now and switching to upstart crap feels like going back into stone age.

For example, here's a simple file to run a Flask server for development:
>setuid ck
>setgid ck
>script
> . /home/ck/sourceme.bashrc
> exec /home/ck/deploy/gatk-app/devserver.py
>end script

Simple, yes? Let's run it!
>root@gatk-main:/etc/init# service gatk stop
>gatk stop/waiting
>root@gatk-main:/etc/init# service gatk start
>gatk start/running, process 7980

Looks great, everything works just swell!

Except:
>root@gatk-main:/etc/init# tail /var/log/upstart/gatk.log
> * Running on http://0.0.0.0:5000/
>Traceback (most recent call last):
> File "/home/ck/deploy/gatk-app/devserver.py", line 14, in <module>
> app.run(threaded=True, debug=True, processes=0, host="0.0.0.0")
> File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 772, in run
> run_simple(host, port, self, **options)
> File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 706, in run_simple
> test_socket.bind((hostname, port))
> File "<string>", line 1, in bind
>socket.error: [Errno 98] Address already in use

Whoopsie. Upstart is as dumb about process hierarchies as SysV init. So it can't detect that devserver forks children and passes a listening socket to them.

On systemd-based systems I can expect that services ALWAYS stop completely and free all the resources. I can get useful log output from my systemctl commands (it saved me many hours of debugging time!) and so on.

And portability is basically a non-issue. Upstart maintainers simply made polite noises about supporting kFreeBSD development but without committing any real resources to that or promising to integrate it into the upstream trunk. There's simply no practical difference compared to systemd - both porting projects are going to require comparable amount of work.

various options

Posted Dec 31, 2013 15:56 UTC (Tue) by cwillu (guest, #67268) [Link]

It doesn't detect it, unless you ask it to with "expect fork" or "expect daemon".

http://upstart.ubuntu.com/cookbook/#expect

various options

Posted Dec 31, 2013 15:57 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Neither of them works. I tried.

Besides, "expect fork" should go away. It's a flaky buggy POS.

various options

Posted Dec 31, 2013 16:36 UTC (Tue) by ThinkRob (subscriber, #64513) [Link]

> Upstart init is one option. Forking systemd and making it portable is another. Adding the "Linux" features to kFreeBSD and Hurd so that both can use systemd init is another.

Those aren't really realistic options.

Forking a piece of software where the authors take an actively hostile approach towards portability with the goal of portability is going to result in you [the forker] doing a *ton* of work over and over again, as upstream will invariably keep adding non-portable code, and breaking code that you had made portable. Basically, you're volunteering to always being several steps behind and hoping that you're lucky enough that upstream doesn't make something impossible to port. (I've been in this position before with closed-source software that was kept unportable due to internal organizational politics. It sucks. A lot. You do not want to be in this position as the maintainer of any software that your group considers vital.)

I don't know about Hurd, but adding the "Linux features" to the FreeBSD kernel would likely result in two things: 1) plenty of tension trying to get them merged upstream 2) adding a bunch of features that -- in the eyes of some FreeBSD people -- accomplish the same thing as existing solutions or solve problems that the FreeBSD project isn't interested in or doesn't have, solely to support a single piece of software used by a single downstream project.

In other words, even if you were willing to take on the large amount of work necessary to build equivalents for the Linux features into FreeBSD, you'd find little support from upstream on the FreeBSD side, no support from upstream on the systemd, and you'd be left doing all the work.

So no, "forking systemd" or "implementing the Linux features" are not realistic options.

various options

Posted Dec 31, 2013 17:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Forking systemd is realistic. Or rather not forking but reimplementing it with local features.

Besides, systemd has well-documented external interfaces which are guaranteed to remain stable. So there's a clear-cut target for the porting effort.

various options

Posted Dec 31, 2013 17:49 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Those interfaces, while certainly well-documented and stable, are not portable, there's literally dozens of linux-specific configuration options in systemd.exec(5) alone, therefore lots of those options couldn't possibly be shared between systemd and its hypothetical FreeBSD-based reimplementation. There seem to be some folks working on launchd for FreeBSD. It remains to be seen whether that works out this time(the last attempt in 2008 failed), but to me that seems a more feasible approach than writing an init system from scratch. Of course it's not clear whether Apple will be helpful in that regard.

various options

Posted Dec 31, 2013 18:19 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Most of the Linux-specific options can be safely ignored. For example, all the selinux crap and most of per-directory permissions.

various options

Posted Dec 31, 2013 18:55 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I'm not at all sure that security related options in service startup configs can be just "safely ignored"

various options

Posted Jan 1, 2014 2:54 UTC (Wed) by HenrikH (subscriber, #31152) [Link]

Are they supported today with the SysVinit scripts?

various options

Posted Jan 2, 2014 21:26 UTC (Thu) by drag (subscriber, #31333) [Link]

> I'm not at all sure that security related options in service startup configs can be just "safely ignored"

They have to be ignored unless you want to support SELinux on FreeBSD also.

If the functionality is missing on another platform and has no equivalent you cannot 'abstract' it away with a library or some other hack and expect it to make any sense.

various options

Posted Jan 2, 2014 21:47 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I understand that, I was just pointing out that there are probably unintended and unsafe consequences of doing so, where things are worse than if the startup config was rewritten for the platform to use the appropriate platform-specific technologies, like jails for example. A privileged daemon whose security relies on syscall filters set during startup isn't going the have the same security properties if that setup silently fails, as an example that comes immediately to mind.

various options

Posted Jan 2, 2014 22:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, if FreeBSD has corresponding security features than it'd make sense to add FreeBSD-specific stanzas (which will be ignored on Linux) to unit files.

Anyway, right now SysV-based daemons rarely do anything complicated with read-only directories, so on non-Linux systems it'd simply be the continuation of status quo.

various options

Posted Jan 1, 2014 9:34 UTC (Wed) by Pawlerson (guest, #74136) [Link]

The best solution is to drop kfreebsd crap, so Debian can go with systemd and focus on Linux. Debating on something which has less than 1% usage is plain stupid. Compatibility with non Linux systems isn't important at all.

various options

Posted Jan 2, 2014 0:43 UTC (Thu) by vivo (subscriber, #48315) [Link]

LOL Linux used to have much less than 1% usage

various options

Posted Jan 2, 2014 17:19 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Indeed.

However when people said in the 1990s "We can't worry about Linux, it has less than 1% usage, so let's require ACLs because those work on the systems we do care about" (for example) did Linus respond by having a tantrum and asserting that Linux would never under any circumstances offer ACLs? I think not.

'cos the Linux system I've got here seems to have ACLs. Never really used them, but I suppose if I had a need for them I'd either be glad they're on Linux or I'd be using a different kernel.

Allowing a third party kernel to decide what Debian Linux chooses for init amounts to the tail wagging the dog, and the percentage is just making sure people understand we are talking about a very small tail on a very big dog.

various options

Posted Jan 9, 2014 23:47 UTC (Thu) by Wol (guest, #4433) [Link]

I've never used linux ACLs, but I have used them on Pr1mos. And the version on Windoze is crap - I hope linux didn't copy that!

Doze *adds* user and group ACLs together. I gather you can get round that, but ...

Pr1mos gives you your user ACL *or* your group ACLs (or the default ACL if neither apply).

Thus making it extremely easy to control who has what access. "any old user" will get $DEFAULT. You can give group acls to departments or whatever, and people then get the access they need by default (Pr1mos adds group acls together so you get the sum of all your group rights).

BUT - if you explicitly set a user ACL, then that is *exactly* what they get! If their group acls give them a bunch of rights that their user acl doesn't, then the group acls are ignored (well, they're ignored anyway :-)

In order to take away rights on Windows, you need special contortions. In Pr1mos, you just set a user acl.

Cheers,
Wol

various options

Posted Jan 13, 2014 14:24 UTC (Mon) by nye (guest, #51576) [Link]

>In order to take away rights on Windows, you need special contortions.

Or you could set it to 'deny', rather than leaving it at the default of 'inherit'. If you're already setting a user ACL, this adds no extra work. No contortions required, and it allows a greater flexibility in how permissions are assigned.

various options

Posted Jan 6, 2014 1:43 UTC (Mon) by Arker (guest, #14205) [Link]

"Debating on something which has less than 1% usage is plain stupid. Compatibility with non Linux systems isn't important at all."

Sad to see that today, in 2014, people are still proud to spew such nonsense.

Debian does not exist merely to make it easy for you to install and upgrade the software you want, today. Debian has a much broader mission, and keeping the infrastructure kernel-agnostic is an important part of their mission and their long-term strategy.

If you dont like their mission, and you dont like their strategy, fair enough, use another distro. But criticising Debian simply for being Debian as you do here, that's not fair, that's just dumb.

various options

Posted Jan 6, 2014 8:49 UTC (Mon) by anselm (subscriber, #2796) [Link]

Debian has a much broader mission, and keeping the infrastructure kernel-agnostic is an important part of their mission and their long-term strategy.

The Debian Project's »mission« is outlined in its Social Contract. The last time I checked, being »kernel-agnostic« was not actually part of the Social Contract.

The Social Contract does say that »We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.« More than 99% of Debian's users are on Linux. Who are you to decree that these users should not be able to take advantage of a technically superior and long-overdue infrastructure improvement that, incidentally, seems to be adopted by most other mainstream Linux distributions? Doing that doesn't seem to be in those users' interests.

Supporting Debian on other kernels is a nice thing to do but it is not explicitly part of the project's goals. As such it is upon those who want to support Debian on, say, a FreeBSD kernel to contribute most towards that actually happening. Individual Debian developers, for example, are not required to actively test their packages on Debian/kFreeBSD; they are simply requested to take on board any patches that Debian/kFreeBSD developers have come up with, just like we would like them to look at other patches that fix bugs.

By that reasoning, should the Debian project decide to make systemd the default init system on Linux, we would expect the maintainers of non-Linux Debian ports to contribute most heavily to a solution that would ensure that Debian continues working on those platforms. Whether that would be by forking systemd, writing a rudimentary clone, adding various missing bits of functionality to the other kernels, creating a way of automatically translating systemd units to whatever configuration their init system is using, or a mixture of these approaches remains to be seen. But in no case should these marginal platforms be allowed to hold back the vast majority of Debian's user base, in contravention of Debian's Social Contract, just to save themselves some work.

various options

Posted Jan 6, 2014 9:00 UTC (Mon) by smurf (subscriber, #17840) [Link]

You cannot "keep the infrastructure kernel-agnostic".

Not using systemd means missing out on some interesting features which (almost) every other Linux system out there has, and which people will take for granted in short order, and they will not choose Debian if it's not available.

I for one definitely plan for 2014 to be the year I forcibly eject Debian from my (non-trivial) infrastructure if they decide not to fully support systemd. Which system they switch to on non-Linux kernels, if any, is Somebody Else's Problem – none of these kernels supports a relevant fraction of my hardware.

various options

Posted Jan 6, 2014 17:38 UTC (Mon) by hummassa (subscriber, #307) [Link]

> You cannot "keep the infrastructure kernel-agnostic".

Sure you can. Debian has, for the last twenty years or so, QED.

Debian can even keep its cake (keep the infrastructure kernel-agnostic) and eat it (use systemd). The cost of that is keeping a fork/patch either over systemd (so it does not need/use linux-specific syscalls) or kFreeBSD + the Hurd (AFAICT this last one is almost done, so that they implement the used linux-specific syscalls).

> [...] and they will not choose Debian if it's not available.

You are foretelling the doom of ubuntu (that does not use systemd) and I somehow doubt that (at least in the short to medium run).

> [...] none of these kernels supports a relevant fraction of my hardware.

Of course it runs NetBSD! :D

various options

Posted Dec 31, 2013 18:30 UTC (Tue) by raven667 (subscriber, #5198) [Link]

It would seem that if you want something with a similar feature set on FreeBSD then you can use systemd as a guide of how it should be done but with an independent code base that uses the FreeBSD-specific kernel features. The problem of trying to make something like systemd portable is that the underlying APIs for hardware management, process, container, virtualization, security, etc. are different on each OS kernel. For normal applications this often isn't a problem, because they aren't managing the OS, or differences are abstracted away by libraries, but managing OS services is an inherently non-portable task.

Really, the task of re-implementing a systemd like system for BSD isn't impossible, systemd itself has only existed for a few years and any new effort has a reference implementation to speed along development that didn't exist before.

delusional portability

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

> The problem of trying to make something like systemd portable is that the underlying APIs for hardware management, process, container, virtualization, security, etc. are different on each OS kernel. For normal applications this often isn't a problem, because they aren't managing the OS, or differences are abstracted away by libraries, but managing OS services is an inherently non-portable task.

Why don't we (I?) read this more often?

Look at what we have now: on the one hand poor old SystemV init which is portable but for a heavy price, on the other hand every operating system still alive has re-implemented its own OS-specific tool. That tells something doesn't it?

Maybe Debian/Linux should have systemd while Debian/kFreeBSD has launchd. There could also be - maybe - some higher compatibility layer on top of them to support the dumbest and least demanding daemons with a single config file. Doesn't systemd support some basic shell scripting already?

delusional portability

Posted Jan 2, 2014 12:09 UTC (Thu) by anselm (subscriber, #2796) [Link]

The reason System V init is »portable« is that it practically doesn't do anything in the first place. It doesn't depend on the Linux kernel features that systemd depends on simply because System V init has no conceivable use for them.

System V init is portable in the way »hello world« is portable.

delusional portability

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

This is exactly what I had in mind when I wrote "heavy price" above; thanks for clarifying.

delusional portability

Posted Jan 2, 2014 15:06 UTC (Thu) by smurf (subscriber, #17840) [Link]

systemd supports ye olde sysv init scripts without any problem.
So the perfect solution (in my opinion) would be to continue shipping sysv init files (necessary for the transition period in any case) _and_ systemd .service files.

I have no idea which distribution I'll use if Debian decides to go with Upstart, but it won't be Debian. *shrug*

delusional portability

Posted Jan 2, 2014 21:31 UTC (Thu) by drag (subscriber, #31333) [Link]

> Doesn't systemd support some basic shell scripting already?

Of course it does. It did from the beginning.

But if systemd is available people are going to use it because sysvinit scripts suck massively in comparison.

Nobody is going to want to support both a shitty way of doing things along side of a good way of doing things if they are given a choice.

delusional portability

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

Yes, and Debian/kFreeBSD+launchd developers won't really have this choice.

various options

Posted Dec 31, 2013 17:50 UTC (Tue) by gioele (subscriber, #61675) [Link]

> Besides, systemd has well-documented external interfaces which are guaranteed to remain stable. So there's a clear-cut target for the porting effort.

Indeed a shim for systemd has been created, based on the published dbus interfaces: http://packages.debian.org/sid/systemd-shim

various options

Posted Jan 3, 2014 19:13 UTC (Fri) by zuki (subscriber, #41808) [Link]

> Indeed a shim for systemd has been created, based on the published dbus
> interfaces: http://packages.debian.org/sid/systemd-shim
Very interesting.

systemd-shim uses systemd sources directly. I had a look at virt.c in the debian package http://ftp.de.debian.org/debian/pool/main/s/systemd-shim/..., which is a copy of http://cgit.freedesktop.org/systemd/systemd/commit/src/sh.... The problem is that since that commit, this file has been modified... Xen detection has been fixed, UML support has been added, some minor fixes have been done. What is the sense of copying a function that is outdated?

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 16:37 UTC (Mon) by tjc (guest, #137) [Link]

I wouldn't stop using Debian if they chose either option, but at this point I prefer upstart, since I value simplicity and portability over the technical advantages of systemd. Upstart appears to be as good or better than sysvinit in all areas under discussed, but systemd is a regression as far as portability is concerned.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 16:40 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

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 (subscriber, #5325) [Link]

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]

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]

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]

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 (subscriber, #31018) [Link]

Software is always 95% done :-)

Positions forming in the Debian init system discussion

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

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]

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...

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:38 UTC (Mon) by torquay (guest, #92428) [Link]

    but at this point I prefer upstart, since I value simplicity and portability over the technical advantages of systemd. Upstart appears to be as good or better than sysvinit in all areas under discussed, but systemd is a regression as far as portability is concerned.

So you're willing to sacrifice a major and very useful feature like cgroups, all in the name of supposed portability. Portability to what exactly?

According to Debian's popcon, the number of reported kFreeBSD and Hurd kernels is around 0.09% in comparison to Linux i386 and amd64 kernels. This percentage drops even lower when Linux kernels on other platforms are taken into account (eg. powerpc).

You're in effect advocating that Debian maintainers and users are to be forecefully prevented from using available features in the Linux kernel, all while systemd's use of cgroups and other Linux kernel features is clearly a major advantage over upstart.

The very very tiny minority of Debian non-Linux kernel users are more than welcome to port Linux features such as cgroups to the respective kernels.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:25 UTC (Mon) by SEJeff (subscriber, #51588) [Link]

Seems like they are trying to drive away users that actually are excited to use new and interesting linux technologies. Not to start a distro war, but stuff like this is precisely what drove me away from Debian/*buntu and to Fedora.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:18 UTC (Tue) by tjc (guest, #137) [Link]

> You're in effect advocating that Debian maintainers and users are to be forecefully prevented from using available features in the Linux kernel, all while systemd's use of cgroups and other Linux kernel features is clearly a major advantage over upstart.

I'm not advocating anything. I'm saying that I would be fine with either choice, but I prefer upstart, for reasons you consider erroneous.

Positions forming in the Debian init system discussion

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

So you are willing to sacrifice a useful feature like cgroups, all in the name of functionality?

Cgroups is a valuable tool for containment, and systemd's use of it hinders frameworks like Google's let me contain that for you (lmctfy).

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 15:31 UTC (Tue) by amaranth (subscriber, #57456) [Link]

If you're referring to the removal of cgroups multiple hierarchy support and systemd being the controller of the new single hierarchy system you're going to have that problem anyway. Not having systemd here means you're going to need something to handle this task in its place that is probably going to expose the same API and work in a similar manner. Rejecting systemd doesn't change the reality of what is happening with cgroups.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 19:18 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

The problem is that systemd isn't exposing the whole cgroup API. Instead, it's implemented its own policy that allows only a subset of the full capabilities that cgroups offer, even given the new limits of having a single cgroup manager. Any system that wants to use capabilities that systemd doesn't offer is stuck. They can either live with the more limited systemd cgroup API or do without systemd; there is no intermediate choice.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 21:36 UTC (Thu) by drag (subscriber, #31333) [Link]

> They can either live with the more limited systemd cgroup API or do without systemd; there is no intermediate choice.

Which is a technical decision by kernel developers that has nothing to do with systemd. You will be forced to choose either-or no matter what method you use to configure cgroups.

Use a complicated way and people will be denied the sane, easy, and secure way of doing things. Add cgroup features to upstart and then you will only e able to up upstart to manage them.

Meanwhile systemd being open source people can work with the developers to get the features they need for their applications that systemd cannot support in it's current form.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 1:30 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link]

Which is a technical decision by kernel developers that has nothing to do with systemd.

The decision about having a single cgroup manager isn't under systemd's control, but the decision about how to manage cgroups certainly is. Systemd isn't exporting features that some people have come to expect, and that's a real problem for those people.

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 7:40 UTC (Sun) by jspaleta (subscriber, #50639) [Link]

I think you've missed something critical.

The new cgroups API that is being crafted, and which requires a single userspace manager model, and which systems can switch to with the "sane_behavior" cgroupsfs mount option does take things away. It absolutely takes things away from users. That's sort of the point of the refactoring of the API.

What systemd does is abstract the cgroupsfs controls a bit, to make it possible to use the new cgroups API even though its a moving target. If new capabilities group or existing capabilities get pruned, the systemd abstraction will hopefully prevent code other than systemd, from having to be re-written to deal with that.

I would encourage you to look at development tip for cgroup stuff and see which items are only available when "sane_behavior" is not specified. You can grep through the code for INSANE or SANE to get a since of how the new api is differing from the old one. INSANE of old api, SANE for new api. For example, I believe recently the tasks item in the filesystem layout is no longer exposed with sane_behavior. or at least that's my understanding reading through the cgroups discussion threads.

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 17:52 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> The new cgroups API that is being crafted, and which requires a single userspace manager model
I've asked that about 10 times - why does it REQUIRES the single writer?

So far - no answer at all, only strange noises like: 'cgroups can eat your dog'.

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 19:01 UTC (Sun) by raven667 (subscriber, #5198) [Link]

It's not that this question doesn't have an answer, it's just that you don't _like_ the answer, the maintainer in the kernel doesn't think that the current delegation model is safe or well implemented, is running screaming from it and doesn't want to support it. Tejun Heo isn't the only one who thinks the cgroup implementation in the kernel has problems, I clearly recall Al Viro making complaints about it right here.

https://lwn.net/Articles/453529/

Actually skimming that is funny, it's an article from 2011 about Debian debating the finer points of systemd. We've been going around this merry-go-round for a while now, haven't we?

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 20:36 UTC (Sun) by khim (subscriber, #9252) [Link]

Actually skimming that is funny, it's an article from 2011 about Debian debating the finer points of systemd.

Indeed. That's for pointing out that piece which was written in 2011 and claims that “cgroups can eat your dog” and that “that's one hell of a badly written lump of code”.

Note that it also includes this piece: If you want kernel/cgroup.c code review, I can probably post it a bit after -rc1. Well, it's 2014 and we still have no explanations for what's so bad with it.

Note that it's not the first time code was rejected or ever ripped out because it was badly written: devfs and reiser4 come to mind. But there criticism was in the form “if you'll do this and that then you can cause kernel oops” or “if you'll do this and that then normal user can exhaust all the kernel memory and ulimits will not help” or “if you'll do this or that then kernel will lock down… hard”. That's understandable, valid criticism: if code in kernel (or proposed for inclusion in kernel) breaks said kernel in certain circumstances, then it's objectively bad and must be ripped out. One can discuss if it's fixable or not and if it's not fixable it's not included and/or ripped out.

Unfortunately cgroups criticism does not look like that. Instead it's bunch of hot words and little substance. The most objective criticism is “the maintainer in the kernel doesn't think that the current delegation model is safe or well implemented, is running screaming from it and doesn't want to support it”.

If, indeed, this is the gist of the problem then it makes it a social problem and not a technical one. The natural response to this is: we need a new maintainer. Today's code was written by someone, perhaps that person can be a maintainer? If not then why not? If author of the code does not want to support it then it certainly puts him (or her) in bad light and if noone else want to support it then it may be a valid justification for removal of the code because this essentially makes code orphan, but if the justification is not that code is objectively bad (== can break kernel) but that current maintainer does not like it then the natural question is: have other venues been tried? Who was contacted WRT maintainance of said code and why such discussions never surface when cgroups are discussed?

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 20:41 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>It's not that this question doesn't have an answer, it's just that you don't _like_ the answer
I still haven't heard about a scenario where the current delegation model causes problems. And I'd read the Cgroups mailing list and tried to googling.

There are only vague handwavings about "it might eat your cat", and that's all.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 16:42 UTC (Mon) by Wol (guest, #4433) [Link]

One thing I will point out, though. Linus is an ENGINEER, not an ivory tower Computer "Scientist".

Along with a fair few other kernel guys.

Now let's add that "pretty code is usually good code" (yes I know, people can write code that is crap but pretty).

But if engineers like Linus and Al can look at a hairball like that and say "how the hell do I prettify that!" then there's a damn good chance that "there be grues".

If the only way forward they can see is a single cgroup hierarchy, then I'm inclined to suspect they're right and that's the only way to do it.

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 16:39 UTC (Mon) by acollins (subscriber, #94471) [Link]

A year ago I would have disparaged systemd, but since then I've spent some time getting familiar with it and now, I completely agree. Upstart is better than sysv init, but clearly inferior to systemd.

Portability seems to be a bit of a red herring. *Neither* init system is portable today, and it seems unfortunate to hamstring debian with a one-off inferior init system in the hopes that someday it can be portable to the <1 % of users on debian/kfreebsd.

I never thought an init system would drive my distro choice, but after using systemd it's going to be tough to want to continue using a distribution without it.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 2:28 UTC (Thu) by wahern (subscriber, #37304) [Link]

Inferior solutions abound. Systemd is not The Best(tm) solution to daemon management.

A better solution would be process descriptors, like in FreeBSD, and process group descriptors and capabilities. That follows in the unix-tradition of kernel facilities that allow user space to synthesize complex operations without being unduly hindered by the inevitably short-sightedness of the guy creating The One and True Solution.

The Capsicum project has thought through all of these things, coming up with a solution that merges the traditional unix process models with modern, programmatic privilege isolation.

We'd all be better off if all this energy went into getting something like Capsicum integrated into Linux.

http://www.cl.cam.ac.uk/research/security/capsicum/

There's already Google a project to do this:

http://www.cl.cam.ac.uk/research/security/capsicum/linux....


Positions forming in the Debian init system discussion

Posted Jan 2, 2014 2:53 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

I don't follow you.

Process descriptors are just a way to handle processes. They might or might not be better than filesystem-based cgroups. Ditto for Capsicum caps - they might be better than SELinux/AppArmor, but they are not relevant by themselves.

You still need a daemon that manages all of the processes, starts them, checks that they are truly stopped and so on. On Linux this daemon is called 'systemd'.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 9:40 UTC (Sat) by smurf (subscriber, #17840) [Link]

Umm, what advantage do these process descriptors have, compared to cgroups?
Do you want these in addition to, or as replacement of, cgroups?

Anyway, systemd is there and it's the best tool for replacing init there is (IMHO). How long do you want to wait before replacing SysVinit, given that this Google Code project is a year from having widely-tested production code which can replace PID 1?

Also, Capsicum/Linux is implemented as an LSM. It's not yet part of the kernel. Plus there is no stacking of LSMs in the kernel yet (let alone one that's tested widely enough). So you'd have to tell people that they can't use AppArmor or SElinux any more. For this reason alone, Capsicum may be interesting, but its chance of being adopted as "the" init by Debian are precisely zero.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 15:50 UTC (Mon) by aigarius (subscriber, #7329) [Link]

Issues that involve adding technical features or changing technical features are often far easier to resolve than issues involving attitude. Also, Debian has a long tradition of having an option of switching out core parts, such as the init system or login screens. From the discussion it looks to me that systemd forces some design choices that will impact ALL Debian users and all users of all its derivatives, including Ubuntu and SteamOS, which is likely to cause a lot of social tension among most powerful Linux distributions in existence. Not a good thing for us.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:35 UTC (Mon) by drag (subscriber, #31333) [Link]

The difference between Debian choosing systemd versus Debian maintaining 3 separate Init systems is the difference between have a simple, robust, well designed operating system, with good documentation and clear administrative tools versus forcing application developers to support multiple low-level OS personalities with dramatically different features sets, libraries, utilities, and capabilities all wrapped up in a huge mess of shell includes, Debian-specific patching of daemons that causes user and app developers to be forced to interact with the system buggy abstraction layers and exponentially higher complexity with absolutely no inherent benefit at all.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 6:16 UTC (Tue) by nirbheek (subscriber, #54111) [Link]

impact ALL Debian users and all users of all its derivatives, including Ubuntu and SteamOS
SteamOS is based on Debian and already uses systemd, so Debian choosing Upstart would cause social tension. OTOH, Ubuntu has already moved away from GNOME, Debian, and everyone else, so they'd have no problem working on Upstart by themselves—which is what they already do.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 6:28 UTC (Tue) by foom (subscriber, #14868) [Link]

Why do people keep saying steamos uses systemd? The news articles about it say it uses sysvinit, the default init of Debian wheezy which it's based off of. I don't see why SteamOS would much care what init system is used, really.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 6:32 UTC (Tue) by nirbheek (subscriber, #54111) [Link]

Ah, you're right. SteamOS doesn't use systemd. Apologies.

In which case, I think from their perspective, Debian moving to either Upstart or systemd would be the same, so the argument employed by the comment I replied to continues to be invalid.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 19:47 UTC (Fri) by whiprush (guest, #23428) [Link]

Uhh, Ubuntu has not moved away from being a Debian derivative.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 16:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Also, let's see Ian's arguments:

>So, to recap this and my previous mails and summarise:
> * upstart is simpler than systemd (which leads to fewer bugs, etc.)
It's not simpler.

> * upstart integration fits better into a daemon source code
It doesn't. The code difference is trivial.

> * upstart is easier to package for than systemd
WTF? Systemd packaging is basically one file per package. That's it.

> * upstart's community is much better to work with
Subjective.

> * systemd's non-portability is (for me) a near-blocker
Red herring.

> * upstart's remaining disadvantages are readily fixable SMOP
Nope. No cgroups support, faulty socket activation logic, no support for dependency autodetection and so on. These are not trivial features.

> * upstart is therefore ready for adoption in jessie
Not an argument but a conclusion.

So basically the only valid argument is "upstart people were nicer to me".

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:03 UTC (Mon) by dan_a (subscriber, #5325) [Link]

I also noticed that Russ mentioned migrating a daemon over to both upstart and systemd but Ian did not. I wonder if that would change his views on the two at all.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:58 UTC (Mon) by andrewsomething (subscriber, #53527) [Link]

Apparently, you didn't notice the beginning of the message:

> I have reported on my impressions and experiences of
> both systemd and upstart in my previous messages.

That thread starts here: http://lists.debian.org/debian-ctte/2013/12/msg00179.html

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:31 UTC (Tue) by misc (subscriber, #73730) [Link]

"upstart were nicer to me" is hardly relevant. e can find case where the patch were ignored for a few years ( and some being rescued mostly due to the tech-ctte discussion, given the time frame ) :

https://bugs.launchpad.net/upstart/+bug/595774
https://bugs.launchpad.net/upstart/+bug/388746
https://bugs.launchpad.net/upstart/+bug/252997
https://bugs.launchpad.net/upstart/+bug/568288

Or we can also see how the upstream of upstart could have been seen as "problematic", on some others bugs :
https://bugs.launchpad.net/upstart/+bug/557177

So the whole appreciation of being helpful is quite misleading. The whole init have seen much more scrutiny than most if not all software pushed in Debian, especially on non technical matters.

Positions forming in the Debian init system discussion

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

Those were conclusions, not arguments. You should evaluate the body of his email.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:00 UTC (Tue) by HelloWorld (guest, #56129) [Link]

There are no sensible arguments there either :-(

Ian Jackson is spreading falsehoods

Posted Dec 30, 2013 17:07 UTC (Mon) by HelloWorld (guest, #56129) [Link]

It makes me sad that leading members of the debian community spread such unfounded accusations on systemd. To quote his email:

My experiences with systemd's Debian maintainers (and, indirectly, systemd's upstream) have been far from satisfactory in this regard. Instead of taking a flexible approach, and being willing to provide a range of glue facilities and approaches for different daemon upstreams, the systemd community seems doctrinaire. Daemon authors are expected to do as they are told by systemd upstream, rather than systemd upstream making things comfortable for daemon developers.

This is IMO the opposite of the proper attitude.

This statement is so vague that it's hard to write a proper rebuttal, especially since it lacks examples. I'd just like to make two remarks:
  1. systemd supports sysvinit scripts just fine. If a daemon needs some quirky initialization logic not supported by systemd, it can use a shell script to achieve that. systemd just does the right thing here by making the common case easy and fast while not making the quirky case impossible.
  2. I personally think that it's good to have a force in the Linux ecosystem that tries to gently push (daemon) developers towards certain best practices, i. e. being able to work in a clean environment etc.. What Ian Jackson calls flexibility, I call working around other people's bugs in the init system, which doesn't seem a good idea to me.
And here's one that really makes me mad:
The same appears to be the case for systemd's interactions with Debian as a downstream. Pressure has had to be applied on issues such as separate /usr (and much documentation still contains claims that this is "broken");
As Lennart Poettering explained many many times by now, systemd isn't and never was the problem. It just prints a warning (which can be ignored!) because many other programs seem to have problems with that – and it's not like Poettering is making this up. Ian Jackson should know better than spreading such falsehoods. And if debian really can't take that warning, it's a patch of like 3 lines. This is the point of open source software!
I asked for systemd to be able to execute programs from PATH rather than requiring unit files to specify the absolute path and was rebuffed (#...)
This can be trivially handled by using env(1) for ExecStart.
Finally, the systemd community seems to havve a programme of replacing many other facilities throughout the system (including ones which other software already does better - see eg binfmt-support, #716812, and Colin's comments, which I agree with). This is to be discouraged IMO.
It's true that systemd is more than an init system, and it's not like its developers are making a secret of that. But nobody forces debian to use any of that code: systemd-binfmt doesn't need to be built (configure scripts ftw!), installed (we have package managers, hooray!) or used. Rejecting systemd as an init daemon due to a systemd-binfmt issue is to throw out the baby with the bath water.
Furthermore, in my view the responses of Debian's upstart maintainers to my bug reports about upstart have been exemplary. There has been, for example, no resistance (from them or AFAICT from upstream) to supporting the systemd socket activation protocol.
In fact, there was a decent flamewar about this on upstart-devel: “Upstart socket activation”. So we have yet another falsehood right there. Also, why would one pick a program that might get a desirable functionality at some point in the future over one that has it already? Not to mention that Jackson doesn't even scratch the surface of the functionality that systemd provides. What about the security features? Multiseat? Cgroups? Kdbus? And unlike the “issues” that he mentioned (PATH, binfmt, /usr), these are not “a simple matter of programming”.

Comments on Ian Jackson's commentary

Posted Dec 30, 2013 19:01 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

> and it's not like its developers are making a secret of that.
> But nobody forces debian to use any of that code: systemd-binfmt
> doesn't need to be built (configure scripts ftw!), installed (we have
> package managers, hooray!) or used.

How optional is it? Is it as optional as the CGROUPS support?

And will it continue to be optional in the future? Or will systemd 305 require the binfmt support (otherwise the new and cool feature will not work)?

unhelpful comments

Posted Dec 30, 2013 19:44 UTC (Mon) by HelloWorld (guest, #56129) [Link]

How are comments like your's supposed to help anybody? What's the point of asking whether something is “as optional as cgroups” when everybody knows that cgroups aren't optional for systemd? Hell, what's the point of asking this question at all when you could just go to systemd's gitweb and check if there's a configure flag for that? Here, I even give you a link:
http://cgit.freedesktop.org/systemd/systemd/tree/configur...
What's the point of making up some silly theory that this stuff might be mandatory in the future?

Really, I don't get it.

unhelpful comments

Posted Dec 30, 2013 20:39 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

OK. Maybe CGROUPS was a bad example. But then again, it also depends on when you ask. See https://lwn.net/Articles/453666/ .

But this is not the only example of an optional component becoming required in systemd.

unhelpful comments

Posted Dec 30, 2013 21:00 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

That is nitpicking at best and you haven't really shown any real examples at all. systemd had (still has?) rudimentary fallback just for being able to boot on a kernel without cgroup. You obviously won't get any of the real features of systemd that is built on top of cgroups if you do that. In particular, you will lose the ability to guarantee that stopping a service will really kill all child processes that may be spawned by a daemon and there is no real alternative to using cgroups here. In comparison, binfmt support is very minimal and not an important part of systemd at all.

unhelpful comments

Posted Dec 31, 2013 16:25 UTC (Tue) by ThinkRob (subscriber, #64513) [Link]

> What's the point of making up some silly theory that this stuff might be mandatory in the future?

I don't think it's *that* silly of a theory, actually.

systemd started as an init system.

But in the last couple years it's also encompassed a *ton* of other areas of low-level Linux functionality.

Maybe that was the plan from the beginning, I don't know. But it certainly wasn't obvious to a lot of people if that was the case -- and to these people it seems like the plan is for systemd to become crucial to everything and everyone in the Linux community.

I guess the question on these people's minds is: where does it end?

It's no big secret that an integrated, monolithic stack can deliver better results than a stack designed to let every single piece be swapped out. But I suppose some people see that line of thinking and wonder "Well, gee, maybe someone will decide to make the basic shell utilities depend on systemd too so they can get better results. And maybe $my_de_of_choice will become dependent on it too, since it'll produce better results. And surely my web browser could be more secure if it used systemd..." etc.

Basically, some people are worried about a future where systemd/Linux is the One True OS which open source software supports, and anyone not using it is left out.

---

I happen to be a cathedral person myself, so I'm all for systemd taking over tons of low-level functionality in the Linux world. But then again, I prefer FreeBSD, so the idea of a kernel/userland stack being developed together isn't that scary to me. :D

unhelpful comments

Posted Dec 31, 2013 18:06 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> I don't think it's *that* silly of a theory, actually.
It is.

> But in the last couple years it's also encompassed a *ton* of other areas of low-level Linux functionality.
Yes, and the vast majority of that is optional and can be disabled with a configure switch, or installed separately, or just turned off. There is *no* way a mandatory dependency on systemd-binfmt could be justified, and tzafrir didn't even try to. It's thus perfectly obvious that he only came up with that silly theory because my argument is impossible to disprove otherwise given the status quo. Conjecturing about what might happen is a classic FUD tactic.

unhelpful comments

Posted Dec 31, 2013 21:00 UTC (Tue) by ThinkRob (subscriber, #64513) [Link]

> Yes, and the vast majority of that is optional and can be disabled with a configure switch, or installed separately, or just turned off.

I suspect that the people who are concerned about this are similar to those who are concerned about Secure Boot on x86.

They're not worried about the status quo. They're worried about what happens when "optional" becomes "required".

unhelpful comments

Posted Dec 31, 2013 22:13 UTC (Tue) by dlang (subscriber, #313) [Link]

> What's the point of making up some silly theory that this stuff might be mandatory in the future?

when you have posts like this one https://plus.google.com/+LennartPoetteringTheOneAndOnly/p... that are very uapologetic about taking over more an more things (and I was not aware that systemd had decided it was taking over dbus as well) with statements like

>> I believe ultimately this really boils down to this: the Linux userspace plumbing layer is nowadays developed to a big part in the systemd source tree.

That is a far bigger land grab than we have seen before, because just about everything except end-user applications can be classified as "userspace plumbing"

I don't have any objection to him creating such an OS, just like I don't have an objection to Android having a completely different userspace.

But I do object to trying to claim that it's the standard Linux platform and that anyone who isn't just accepting what's provided is just resisting progress.

unhelpful comments

Posted Jan 2, 2014 14:20 UTC (Thu) by isilmendil (subscriber, #80522) [Link]

My thoughts exactly.

unhelpful comments

Posted Jan 2, 2014 17:32 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> But I do object to trying to claim that it's the standard Linux platform and that anyone who isn't just accepting what's provided is just resisting progress.
These people *are* resisting progress. systemd is clearly the technically best available init system today, nobody other than the upstart developers really disputes that. And even more importantly, systemd can be a unifying force across distros, enabling them to work together more constructively, and that's precisely what the linux ecosystem as a whole needs.
In fact, I think that Ian completely misses the big (ecosystem) picture in his email, instead resorting to handwaving and pseudo technical arguments (look up binaries in $PATH, seriously?). Russ otoh clearly understands what's going here and what opportunity systemd provides. I can only hope that the remaining CTTE members also do.

unhelpful comments

Posted Jan 20, 2014 19:46 UTC (Mon) by amck (subscriber, #7270) [Link]

In fact, I think that Ian completely misses the big (ecosystem) picture in his email, instead resorting to handwaving and pseudo technical arguments (look up binaries in $PATH, seriously?). Russ otoh clearly understands what's going here and what opportunity systemd provides. I can only hope that the remaining CTTE members also do.
I think that Ian here is seeing the big picture, and this example highlights it. Looking up binaries in $PATH is done in Debian because of things breaking during upgrades, etc. where binaries move. If systemd doesn't work this way, then upgrading Debian breaks hard. You need to look beyond the immediate technical solution to overall maintainability. One of Debian's strengths is its large technical developer base, with an institutional history of previous problems solved. Here systemd developers ignore a problem outside their experience but which will break other code. This is a worrying feature and a real fear.

unhelpful comments

Posted Jan 20, 2014 21:01 UTC (Mon) by neilbrown (subscriber, #359) [Link]

I agree that if the core developers appear uninterested in any problems but their own, then that is a cause for concern.

On the other hand, looking up binaries in $PATH has a well-known solution. Just run

    /usr/bin/env some-binary some-arguments
and /usr/bin/env does the path lookup. i.e. it is a feature that is trivially added after-market. If lots of distros start doing this, that might help convince systemd upstream to make it a native feature.

unhelpful comments

Posted Jan 20, 2014 20:54 UTC (Mon) by rodgerd (guest, #58896) [Link]

As opposed to the landgrab of making a free software distribution depend on the CLA-ed software of a for-profit company as a core component?

Ian Jackson is spreading falsehoods

Posted Dec 31, 2013 5:38 UTC (Tue) by foom (subscriber, #14868) [Link]

One of my favorite mails from the whole thread has got to be this one:
http://lists.debian.org/debian-ctte/2013/12/msg00208.html

...in which Steve Langasek writes a very long, very poorly researched email about how socket activation -- one of the best features of systemd -- is actually a "red herring that will never deliver the promised benefits" [1], and uses that to justify upstart's socket activation implementation being essentially completely broken and useless.

IMO, that just speaks volumes to the accuracy of Russ's comment, "My impression now is that systemd's init and service management component is a substantially more mature piece of software." [2] It seems to me that not only is systemd currently vastly better, but the Upstart developers don't even seem to have paid proper attention to any of its VERY REAL and well documented(!) advances. Given that, it seems to me very unlikely that upstart will ever be able to catch up at this point.

[1] quote from the next email, http://lists.debian.org/debian-ctte/2013/12/msg00209.html
[2] http://lists.debian.org/debian-ctte/2013/12/msg00191.html

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:08 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Very impressive and in-depth analysis from both Russ and Ian. Steve and Colin are involved in Upstart and work for Canonical so they seem to be speaking more as Upstart developers rather than Technical Committee members. I do recommend a read through http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 for all the details.

Looks like we have,

Steve, Ian and Colin for Upstart
Russ for systemd
Other members? Unknown and silent

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:15 UTC (Mon) by HelloWorld (guest, #56129) [Link]

I completely fail to see how Ian's analysis is either impressive or in-depth. Most of his arguments are easily debunked, which is why I did just that in my comment above your's...

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:27 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

I find it succinctly summarizes the common objections. It is helpful to be reminded that decisions like these are often based on factors like distribution specific perspectives and impressions of how friendly or prescriptive upstream is and while I don't agree with them, the rebuttals added clarity to the discussions and I found them a useful data point.YMMV

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 18:39 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> I find it succinctly summarizes the common objections.
It doesn't matter for an analysis if an argument is common, what matters is that it's correct! And I don't think Ian's email is a good example of that. It simply doesn't contain many well-argued, well-researched points. It certainly explains why Ian Jackson doesn't like systemd (which boils down to “it's not portable” and “its upstream is mean to me”), and that's legitimate and useful, but that doesn't make it a good analysis.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 19:52 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

You don't have to convince me of the merits of the discussions but I think common objections in a single place is actually quite valuable and seeing them addressed as part of the discussion makes it easier for everyone to understand the viewpoints of the people involved.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 19:57 UTC (Mon) by HelloWorld (guest, #56129) [Link]

As for summarising common arguments for and against the contenders, I think the Debian Wiki is far more informative.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 20:08 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

The debate in the wiki is useful from the point of advocates of the respective technology but the discussion in the committee is useful to understand the decision points. I find both perspectives very interesting.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 19:07 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

Yes, his arguments were interesting, but after reading Russ'detailed analysis, Ian's mail merely seemed superficial...

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:17 UTC (Mon) by deconfliction (guest, #94407) [Link]

I'll offer the residential paranoiac take-

Perhaps Ian's arguments were "superficial" because of the elephant in the room. That elephant being a mistrust of large complex core infrastructure coming out of Redhat, and Redhat's seeming in-lineness generally with the NSA et al. Fundamentally I think this quote from Ian's position succinctly summarized the key difference between Redhat/Fedora-land, and Debian/Ubuntu-land-

"
My experiences with systemd's Debian maintainers (and, indirectly,
systemd's upstream) have been far from satisfactory in this regard.
Instead of taking a flexible approach, and being willing to provide a
range of glue facilities and approaches for different daemon
upstreams, the systemd community seems doctrinaire. Daemon authors
are expected to do as they are told by systemd upstream, rather than
systemd upstream making things comfortable for daemon developers.

This is IMO the opposite of the proper attitude.
"

When I read that, I don't think "superficial", I think- rational mistrust of the NSA (via Redhat/SELinux/Systemd proxy). I know, maybe I'm paranoid. And I absolutely do believe that evil-spy collusion with major open source infrastructure is inevitable. But what you must do is to look the gift-horse squarely in the mouth and say- yes, the code may be awesome, do lots of awesome things, *but just in case* we're going to keep our options *way open*.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:29 UTC (Mon) by bojan (subscriber, #14302) [Link]

> I think- rational mistrust of the NSA (via Redhat/SELinux/Systemd proxy).

Oh, dear. I think Red Hat must be the worst spies in history, pinning their hopes on code everyone can see. :-)

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:33 UTC (Mon) by louie (subscriber, #3285) [Link]

Insecurity through obfuscation under huge piles of code is a real problem. But so is insecurity through smaller amounts of code only a small number of developers read. Simply being open, in either case, is not a magic bullet. You've really got to pick your poison there.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:46 UTC (Mon) by bojan (subscriber, #14302) [Link]

Are you trying to say that when Snowden revealed the extent of spying by NSA and others, you (or someone else) already knew about (or went back and verified) it from (in) Red Hat's (I'm guessing SELinux, systemd and what not) code? Please, do provide links.

I'll just say for the sake of simplicity: if the accusation from the post I originally replied to (that Red Hat are involved in spying for NSA through SELinux/systemd) is true, they must be a bunch of raving lunatics giving everyone source code of their spying activity.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:05 UTC (Tue) by deconfliction (guest, #94407) [Link]

"they must be a bunch of raving lunatics giving everyone source code of their spying activity."

Or just pretty good at their jobs. The NSA depends on linux and redhat and various related open source infrastructure for many of its tools and systems. It is hardly paranoid to imagine they enjoy a certain level of influence within a company like Redhat.

Organizations like the NSA, if they have any intelligence at all - and I give them credit that they do - are going to be playing on every major side of every major game. I.e. they are going to want to be in a position of premier influence within a closed source OS company like Microsoft, as well as an open source OS company like Redhat. Are you really so naive as to believe that with their budget, and the talent out of college it affords them, and the general secrecy and oaths they use to control that talent going forward, that they can't have dozens of very high IQ contributors to very critical open and closed source products. And I give them credit for being able to just develop as normal- not trying to intentionally introduce holes (often, i'm sure some NSA employees do have intentional missions). All they have to do is have ordinary developers, that by being in the position they are in, are simply best able to discover _their own ordinary security implicating program errors and withold them for exclusive NSA use_. Is that really all that paranoid a suspicion? Really?

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:37 UTC (Tue) by niner (subscriber, #26151) [Link]

It is just as likely that the NSA and/or GCHQ have premier influence with Canonical. Thus we are back to a choose your poison position. And in this position, I'd much rather at least gain some considerable features and go with the codebase that is or will soon be used by most distributions and has many more developers looking at the code. And that is clearly systemd.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 1:03 UTC (Wed) by deconfliction (guest, #94407) [Link]

I think (and certainly could be completely wrong) that Debian enjoys a bit of premier influence here in _driving_ what "is or will soon be used by most distributions and has many more developers looking at the code", than being driven by that. I personally like the 'keep your options open' track, especially at this precarious snowden+6months timeframe. I mean ultimately I guess, open source is open source. If there are multiple opinions held by large groups, we'll see debian forks that reflect that. Sounds all good to me. I agree after these many years, that pulseaudio isn't doing too shabbily. But in the early years where it was forced on fedora users, and I literally had a second of severe ear pain discovering that my volume could go (via bug) to 400% and that my sony earbuds had no overload failsafe... well, lets just say that I wouldn't mind letting systemd simmer upstream for another year. If like pulseaudio, it is here to stay and useful, then letting it mature like a wheel of cheese for another year before jumping in with both feet sounds reasonable to me.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:44 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I think you are ascribing nearly magical powers to the NSA. We have plenty of evidence for things they are in fact doing that make us all less safe, we don't need to invent impossible, world-encompassing, threats absent any eveidence.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:47 UTC (Tue) by bojan (subscriber, #14302) [Link]

I am not doubting the ability of NSA engineers at all. I am also not doubting that they are trying to influence companies to do their bidding.

However, putting that into open source code would be the most idiotic thing to do. So, I very much doubt they would be doing that.

Because, if they did, folks like spender and PaXTeam would be all over them like a cheap suit (which they already are, for an apparently flawed security model). No Snowden-style "inside job" required.

Your theory is basically they they are hiding in plain sight. Well, I would say that if they were actually trying that, they selected the wrong target audience - which is essentially a group of hackers - people that can read code. So, no, I'm not buying it. At least not without some kind of proof (limited examples of which may as well exist, which would only emphasise the futility of the effort).

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:06 UTC (Tue) by raven667 (subscriber, #5198) [Link]

> Your theory is basically they they are hiding in plain sight.

It's even worse than that, it's that any lack of evidence is just more proof as to how sinister and wily the NSA engineers are and how deep the rabbit hole goes. It's a flawed and inaccurate model of thinking.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:12 UTC (Tue) by deconfliction (guest, #94407) [Link]

you are trying to put words in my mouth. Nowhere did I get near the idea of "it's that any lack of evidence is just more proof as to how sinister...".

Note there was a lack of evidence before 2013 of much of what got into the news due to Snowden. It didn't mean the shit wasn't actually happening before 2013. It just means now you know about it. Maybe in 2014 we'll learn more interesting things about the vulnerability of popular open source projects. Call it a new years prediction/speculation.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 10:12 UTC (Tue) by Wol (guest, #4433) [Link]

Is your irony/sarcasm/whatever meter faulty?

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 22:23 UTC (Wed) by deconfliction (guest, #94407) [Link]

I'll pick my irony/sarcasm/whatever meter off the floor, and start trying to fix it, if you agree to pick your reality meter off the floor, and start trying to fix it as well.

The days of shouting down with accusations of mental illness people with a clue who understand how insecure our technologies are, and how likely they are being successfully covertly exploited due to ordinary human natures are over.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:08 UTC (Tue) by deconfliction (guest, #94407) [Link]

I think you missed the part of my comment where they weren't intentionally introducing holes (at least that's the likelyest/commonest suspicious angle I'm focusing on). But rather being ordinary developers, having a very easy job of even withholding a small fraction of the security implicating fixes they discover throughout the course of their development carreer.

And it isn't that if this were the case they 'selected the wrong target'. Basically as I mentioned, I imagine they select all interesting targets. And an init system used by a significant fraction of the worlds most significant computers seems like a real obvious target to me. A target an organization like the NSA would find irresistable to pass up. Speculation- sure.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:00 UTC (Tue) by bojan (subscriber, #14302) [Link]

> having a very easy job of even withholding a small fraction of the security implicating fixes they discover throughout the course of their development carreer.

Withholding from folks like spender or PaXTeam or even your regular black hat trying to penetrate your system is pretty difficult. Futile, even - particularly in an open source system, where people can actually identify who committed what. You just open yourself up to ridicule, as we've seen many a time here on LWN.

> And an init system used by a significant fraction of the worlds most significant computers seems like a real obvious target to me.

I mean, this is a pretty serious accusation, right there. You essentially just speculated that systemd is a trojan that has been inserted into people's computers by Red Hat, as ordered by NSA. Good luck with that.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:20 UTC (Tue) by deconfliction (guest, #94407) [Link]

I don't think it sounds as Futile as you suggest. Sure, due to the nature of open source, such bugs are far likelier to be discovered, and after a shorter period of time. So yes, compared to the same attack vector on e.g. MS-Windows, I would expect the number of usable exploits to be a small fraction. But it seems we disagree on the estimates of what those numbers could be. I seem to think they are significant, you seem to think they are insignificant.

Yes, I am glad there are many security researchers combing over the code. But a significant number of bugs become exploitable for significant periods of time.

And there was *no outright accusation*. As raven was at least so reasonable as to state- I presented a threat model for consideration and debate. And you absolutely are trying to twist my argument by using the word 'trojan' for systemd. I'll refer to how I stated the issue originally-

"
But what you must do is to look the gift-horse squarely in the mouth and say- yes, the code may be awesome, do lots of awesome things, *but just in case* we're going to keep our options *way open*.
"

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:38 UTC (Tue) by bojan (subscriber, #14302) [Link]

> I seem to think they are significant, you seem to think they are insignificant.

I don't think that at all.

I just think that leaving holes open in your own code while knowing about them is a pretty sure way of losing the trust of other developers. Not a very good spying technique, IMHO.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:54 UTC (Tue) by deconfliction (guest, #94407) [Link]

I think agencies like the NSA have enough resources to get away with it. They can fund 10 devs, and if 8 of them are exposed, they've still got 2 on the inside. And they can always fund more. And leaving holes in code while knowing about them is what I've discussed so far. Another angle is to suppress alternate ideas and implementations that are less vulnerable to their favorite weaknesses.

What makes me most suspicious of your arguments is how *completely* dismissive of my threat models you are. The phrase "drinking the open source kool-aid" comes to mind. Yes, open-source has these wonderful benefits, but they are not absolute. In the real world, the kernel devs are not shiny marble programming gods. All these devs are mere mortals, and I think bugs that get through their imperfect dev process are far more common than you make it sound like.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 5:26 UTC (Tue) by bojan (subscriber, #14302) [Link]

I don't actually dismiss your theory completely. I just think it is very unlikely, because the undisputed trace of evidence would lead directly to them. We are not talking about whistle-blowers and such here - one just needs to read the commit logs. It is like broadcasting your guilt. Doesn't make much sense to me.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 19:57 UTC (Wed) by oldtomas (guest, #72579) [Link]

> However, putting that into open source code would be the most idiotic thing to do.

They seem to try, from time to time though:

http://blog.0xbadc0de.be/archives/155

and they seem to be fairly good at it :-(

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 22:12 UTC (Wed) by bojan (subscriber, #14302) [Link]

If they are so good at it, how did they get caught out? And by Microsoft employees (according to the link you posted), of all people. I mean, these guys are supposed to be in NSA's pocket, just like the guys from Red Hat etc., right?

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:29 UTC (Wed) by deconfliction (guest, #94407) [Link]

You don't get it. When people like me theorize about NSA infiltration of Microsoft and Redhat and Google, we don't mean that every employee is knowingly 'in the NSAs pocket' like you describe. A very small number of infiltrated or influenced employees in these organizations can compromise basically the major product and service lines. So in the case you are talking about, yes, it would be a natural part of the threat model applied to open source to have some innocent/unaware member of some company with compromised code and developers, to discover such a flaw in some other open source project. You keep trying to twist the debate to imply that the other side of the debate thinks "most of MS/RH/G employees are all in a vast secret spying conspiracy with the NSA". That is not what I am discussing at all. Remember, it took Snowden, a plausibly lone sysadmin gunman to basically rip a gaping hole in the security of the NSA organization. Why does it seem so unlikely to you that the NSA isn't doing that to large, otherwise unwilling/not-cooperating-enough corporations like MS/RH/G? In all likelyhood, perhaps that is where Snowden got/learned the tactical strategies to accomplish what he did?

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:38 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

There's a much easier way to obtain the same end result - just ensure that a company's security team is mostly made up of people obsessed with following federal security requirements rather than actually writing secure software, and everything else falls out naturally without anyone in the company knowing they're doing the NSA's job.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 0:58 UTC (Thu) by bojan (subscriber, #14302) [Link]

> Why does it seem so unlikely to you that the NSA isn't doing that to large, otherwise unwilling/not-cooperating-enough corporations like MS/RH/G?

You mentioned that they are doing that (possibly) through SELinux and systemd code and Red Hat employees. So, let's discuss that, because both MS and G can hide their tracks better, since they made no promise to open source anything.

Both of these code bases have easily identifiable commits, pointing directly back at the person that wrote each line. I am trying to imagine who would be stupid enough to do such a thing where every last shred of proof leads right back to them and I have a hard time doing it.

Also, they work alongside very smart people (both within their own company and outside), with access to the same code. Once they get made, what are their career choices? Who on earth is ever going to believe that Dan Brown guy, for instance?

But, as I said before (http://lwn.net/Articles/578406/), I never completely discarded that possibility. Apparently, there are idiots willing to try it, no matter how unlikely it is for them to actually pull it off.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 9:12 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Both of these code bases have easily identifiable commits, pointing directly back at the person that wrote each line. I am trying to imagine who would be stupid enough to do such a thing where every last shred of proof leads right back to them and I have a hard time doing it.

You only need to pretend it was just yet another unintentional bug among many others - happens all the time.

You keep presenting open-source like the final answer to software quality. It is a fantastic weapon but it's nowhere near enough. Have you never heard about the massive shortage of Linux reviewers for instance? Static analyser reports published for free and never being looked at? Etc.

Seriously, who has enough expertise, time and money to audit the thousands of lines of SELinux policies? Only a few subtle security holes are needed in the whole haystack.

Just like any other war, the security war is mainly a question of means and logistics: basically money.

> Once they get made, what are their career choices? Who on earth is ever going to believe that Dan Brown guy, for instance?

1) See above
2) I am sure the NSA has plenty of other, less visible opportunities
3) Some employers won't care (or even better: they'll appreciate)
4) People forget

(Apologies to Dan Brown for keeping him as the rhetorical example here)

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 8:58 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Your theory is basically they they are hiding in plain sight. Well, I would say that if they were actually trying that, they selected the wrong target audience - which is essentially a group of hackers - people that can read code.

I does not look like the NSA is "selecting" any target in particular.

Sure open-source must be among the most difficult targets in everything they do but you don't think that's enough to stop them trying, do you?

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 2:14 UTC (Sat) by vonbrand (guest, #4458) [Link]

If they are oh so smart and have truckloads of money to waste, why would they go after the Linux kernel, Red Hat, SELinux, and systemd only? Why not also bribe/blackmail a gaggle of Debian developers, some folks around Slackware, a few in the Python crowd, selected Ruby enthusiasts, and the list can go on for a long time?

This whole conspiracy theory makes litke sense if they don't try to target open source in general (at least they should be taking a stab at the more popular systems). And doing that in turn is way too expensive for little gain. Just purchase a few 0-day exploits, or have a few CS interns look for vulnerabilities. Much cheaper, quite effective given the right tools and and enough compute power (unfortunately), nearly zero risk of getting caught.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 11:24 UTC (Sat) by smurf (subscriber, #17840) [Link]

The point is that a multi-pronged approach will yield better results overall. They improve their chances of *some* approach working – and if more than one would work, they can choose which has the better cost/benefit ratio.

They did not consider the cost to society when (not if) the whole kaboodle becomes public knowledge, but that seems to be an ingrained part of the military genome – neither did the a**hats back in the 60s who tried to talk Kennedy into a pre-emptive nuclear strike against the Soviet Union.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 11:27 UTC (Sat) by marcH (subscriber, #57642) [Link]

> This whole conspiracy theory...

There is absolutely no need to elaborate any conspiracy theory to justify that spy agencies are spying.

> And doing that in turn is way too expensive for little gain. Just purchase a few 0-day exploits, or have a few CS interns look for vulnerabilities. Much cheaper,...

I agree with your logic except for the "much cheaper" assertion. The same persons can be paid to do both. Why limit themselves? Whatever gets the job done.

I think the risk of getting caught is extremely small since developers write bugs all the time anyway.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 8:07 UTC (Wed) by jengelh (subscriber, #33263) [Link]

>Insecurity through obfuscation under huge piles of code is a real problem.

I would rather take an actively-eyeballed huge pile than a rotting small pile; in the latter, the insecurity may be discovered or fixed much later, if at all.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:31 UTC (Mon) by louie (subscriber, #3285) [Link]

That's some spectacularly high-grade paranoia there. Perhaps more importantly, I also suspect that if that is what Ian actually meant, he would have said it; he's not a guy to pull punches.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:10 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I'm not sure how seriously we should take this presentation of a threat model, the systemd code is fairly small and is heavily gone over by multiple parties, it seems a near impossibility for any kind of NSA backdoor, or for RH involvement as that fails any kind of deniability test. For similar reasons I don't think SELinux has a backdoor as the downsides of discovery are stronger than any upside, I'm sure the NSA is sitting on a long list of kernel exploits anyway which make SELinux policy moot.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:17 UTC (Tue) by deconfliction (guest, #94407) [Link]

How can you at the same time say "I'm sure the NSA is sitting on a long list of kernel exploits anyway" and then in the same breath staunchly disbelieve that any of those exploits on that long list is part of the SELinux code?

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:30 UTC (Tue) by bojan (subscriber, #14302) [Link]

It would be pretty stupid for any spy to leave clues pointing right back at them, don't you think?

SELinux code authors have been embarrassed right here on LWN many times about the ineffectiveness of their security design and code. I am quite sure that if any malicious intent was discovered, that would have been broadcast by the same folks in a similar fashion. My impression was that the complaints were mostly about incompetence, not caring enough and appeal to authority.

So, unless you're willing to claim that the whole Linux community, including Linus, committers from China, Russia, India etc. are in on it with NSA, I'd say this whole theory is pretty far fetched.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 3:38 UTC (Tue) by deconfliction (guest, #94407) [Link]

Listen, I'll grant I was *speculating* that Redhat effectively backdoored systemd for the NSA. And 'trojan' was appropriate.

But I don't concede your dismissing my alternate opinion that malicious intent could not be successfully cloaked by the NSA as mere 'incompetence'.

It sounds to me as if you believe 100% of the communities you described are *not in it with the NSA*. I find that unlikely. And at the same time, I am not arguing that 100% of the communities you listed *are in it with the NSA*.

You are not trying to argue with me logically. You are twisting my arguments, and then responding to those. (though I'll admit I erred when I tried to claim my threat model wasn't the same as systemd being a trojan for the NSA via RH).

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 11:16 UTC (Tue) by Wol (guest, #4433) [Link]

Bear in mind that systemd is a LOT easier to audit than SysVInit. If the NSA want an easily-compromised system, it'd be a lot easier to hide dodgy code in SysVInit.

SystemD init has a few binaries that do the same thing as thousands of lines of shell duplicated across hundreds of scripts ...

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 4:16 UTC (Tue) by deconfliction (guest, #94407) [Link]

"
SELinux code authors have been embarrassed right here on LWN many times about the ineffectiveness of their security design and code. I am quite sure that if any malicious intent was discovered, that would have been broadcast by the same folks in a similar fashion.
"

So lets see, if my threat model were actually true, we agree it would result eventually in the infiltrators being publicly shamed for their insecure code? Is that not exactly the situation you just described as having already happened wrt SELinux specifically?

And for further re-iteration- Malicious intent as a developer on an open source project *is easy to mask as ordinary dev imperfection*. If you think it is *hard* to accidentally write insecure code even as a well educated developer, then I call you out as not likely being a well educated developer.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 5:42 UTC (Tue) by bojan (subscriber, #14302) [Link]

Of course it's not hard to write bad code or create a bad design. That's the whole point. No conspiracy required for that. Occam's razor and all that.

In the end, all you have is FUD against Red Hat (who I do not work for). From your comments, I don't think you have any actual proof that any of this is happening in any of the code, including upstart, which is the other side of the coin in this particular article (as someone else already pointed out).

I will offer an alternative point of view here as to why there is resistance to systemd in Debian: because it is coming from Red Hat[*] and because it attempts to make the whole system more integrated (which is the Fedora way of doing the distro - the theory of it anyway).

[*] There seems to be some kind philosophical resistance to Red Hat among many open source folks, because they decided to turn open source into a profitable business. And although Red Hat open sourced pretty much everything they ever wrote, they are still seen as "evil" by some. I have no idea what that is about, but I'm pretty sure it's out there.

I'm pretty sure it's out there.

Posted Dec 31, 2013 11:23 UTC (Tue) by Wol (guest, #4433) [Link]

Or even people dislike Red Hat for the same reason as me ...

When I was first playing with distros, I settled on SuSE 5.4. I tried Red Hat (also at version 5, iirc, that's RH5, not RHEL5) and didn't like it. I probably was heavily influenced by the national character of the distros, too, SuSE was(is?) German and I'm Anglo-Deutsch.

Plus I tend to support the smaller guys, and so also avoid RH because they're the giant in the room.

Not particularly rational a stance, so I just tend to ignore RH (I'm definitely not anti), but I'm not "on their side".

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:59 UTC (Thu) by deconfliction (guest, #94407) [Link]

"In the end, all you have is FUD against Red Hat"

You've read my side of this argument, and that is what you believe?

Emphasis on "all", because you are correct, I do have FUD against RedHat. But it's not all I have, and I also don't think it is intellectually unjustified.

FUD. Fear, Uncertainty, and Doubt. 1 year ago, it was almost always the case that you could throw that label around as a negative. Today, I think Fear, Uncertainty, and Doubt are some of the healthiest feelings to have towards the foundations of our internetworked computational security.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 13:00 UTC (Tue) by misc (subscriber, #73730) [Link]

So if the point is "we have too complex solution and this cause bugs and help people to hide security problem", then I guess the solution is to simplify and drop all alternatives.

But then, some will likely say "diversity is needed, becuase having 1 single code is causing risk since it is easier to attack, so that would cause security problem".

In short, whatever happen, people can just argue that this was done to help the spooks, because whatever we do, this is a trade-of. And so as any trade-of, there is always something being improved, so whatever the choice is, something will be made easier, and this something can be turned in "easier for the spies".

So if a conclusion can be reached whatever the choice made before, then there is no correlation between the choice and the conclusion.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 20:58 UTC (Tue) by j1mc (subscriber, #56848) [Link]

In Jacob Applebaum's recent talk, "To Protect And Infect, Part 2 [30c3]", he mentioned how a malware-infected mouse would keep the screen from going to sleep when the infected mouse was attached to the computer.

Mention of this was passed along to systemd developers who implemented something in systemd that would lock the screen when such a mouse was attached to the computer.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 22:35 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

Not exactly. He mentioned that certain agencies use ”mouse wigglers” – USB devices simulating mouse movements. It is done to prevent screensaver kicking-in, it is useful when the computer is confiscated.

The 71-seat.rules files in distributed with systemd containg following rule:

SUBSYSTEM=="input", ATTR{name}=="Wiebetech LLC Wiebetech", RUN+="/usr/bin/loginctl lock-sessions"

Upon pluging in ”the wiggler”, above rule will activate screensaver imediately. Exactly what the wiggler is supposed to prevent.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:28 UTC (Mon) by shmerl (guest, #65921) [Link]

I think Canonical employees had to be excluded from any voting on this. It's a simple rule, even if they are trustworthy, but any potential conflict of interest should invalidate participation by default, regardless the trust. It's a pity Debian can't handle this properly.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 17:43 UTC (Mon) by drag (subscriber, #31333) [Link]

I don't see why Canonical employees should be excluded.

They work with Debian, they care about Debian, and they have a vested interest in the direction Debian goes. Why should they be excluded? How many other people in the technical committee use Debian for their own projects professionally and would be impacted by this choice.. do they need to be excluded also because they may have conflicted interests?

Far from it. It's the people that have a vested interest in the outcome are exactly the sort of people you want as part of a discussion.

Debian just takes forever to decide these sorts of things. That's the only reason it seems so bad. In any discussion with lots of people there are going to be a multitude of different interests, people bringing up red herrings and deeply flawed technical analysis.. it's just part of the process.

Positions forming in the Debian init system discussion

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

There's a _conflict_ of interests. They are supposed to make a decision based on technical merits of the proposals, and their employment _will_ make them biased. Legal and medical professions have the similar rule (dating back to Hippocrates) - practitioners that have to remain neutral must not be biased by their employment or other forms of close association.

Now, that doesn't mean that they should be excluded from the _discusssion_. They certainly are the best people to answer technical questions.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 19:33 UTC (Mon) by smoogen (subscriber, #97) [Link]

Personally I would want Red Hat employees from being barred on voting for Fedora issues first as there is a lot more perceived conflict of interest there. Especially since the number of canonical developers who could vote on a Debian issue out of the number of possible votes is a lot less.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 19:46 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

The comparison is absurd though. Fedora was created by Red Hat directly and Red Hat continues to be a key sponsor of the project. Debian roots and Canonical's role in Debian is very much different.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 20:36 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

That's up to Fedora's steering committee. Their situation is different from Debian's.

Also, in any case it makes no sense to bar RedHat employees from ALL votes. The only questionable ones are those with blatant conflicts of interests.

For example, a vote on codename is not likely to involve any conflicts. A vote on inclusion of new package manager in the Fedora $NEXTVERSION might be.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:34 UTC (Tue) by jubal (subscriber, #67202) [Link]

If you feel that there is a conflict of interest, you're free to point this out to the general Debian community, raise the issue with the TC itself, if not satisfied still, raise the issue with the DPL and – ultimately – you can always propose a GR, find sponsors and see that it's voted by other Debian developers.

Hope that helps!

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 5:13 UTC (Tue) by shmerl (guest, #65921) [Link]

I think that issue was already raised, but dismissed on the basis that participants are trustworthy. I think however that this rule has many valid reasons to be applied in either case, regardless the trust, and it's a common practice in many other areas.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 12:50 UTC (Tue) by jubal (subscriber, #67202) [Link]

I know that the issue was raised and dismissed. I guess that Cyberax either doesn't care enough to get the GR proposed or perhaps he's not a DD. Well, tough luck.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 13:48 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm not a DD, but we have a couple of them in my company. I can't (and won't) ask them to raise this question, but I'm pretty confident that at least somebody is going to raise a GR request if upstart is selected (which seems likely right now).

As for me, I'll switch all our development to Fedora/CentOS if upstart is going to be used. I don't really fancy staying with a slow-moving quickly-obsoleting Ubuntu stack.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 13:54 UTC (Tue) by jubal (subscriber, #67202) [Link]

I always thought that slow-moving, in case of an init system, is more a feature than a bug.

(And anyway, centos 5 is using sysvinit, centos 6 is using upstart. That leaves RHEL betas or Fedora.)

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 14:04 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

No, it's not a feature than the alternatives are clearly superior.

> (And anyway, centos 5 is using sysvinit, centos 6 is using upstart. That leaves RHEL betas or Fedora.)
And SUSE, and Arch, and Mandriva (or WTH they are called now), and Gentoo (among other options). Anyway, it's pretty clear that most non-Debian distributions are going to switch to systemd in the near-future.

So there's going to be two camps: Ubuntu+Debian and everybody else. They are going to diverge more and more.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 16:42 UTC (Tue) by jubal (subscriber, #67202) [Link]

The distributions are diverging and converging in cycles, I wouldn't be too afraid of it.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 22:24 UTC (Tue) by Wol (guest, #4433) [Link]

Gentoo is openRC at the moment. Whether that's going to change, I don't know. I don't like the idea of switching to a non-default init system, but I also want to run my system multi-user (as in, two screens, two keyboards, two mice) and I gather that - unlike the others - systemd makes that easy.

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 14:33 UTC (Thu) by isilmendil (subscriber, #80522) [Link]

Suse Linux Enterprise is still firmly in SysV init land. I guess you meant OpenSUSE there…

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 14:37 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope. The upcoming SUSE Enterprise 12 is going to use systemd.

The current version (11) was released even before the start of systemd development.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 14:25 UTC (Tue) by dodocaptain (guest, #44818) [Link]

Centos 6 is still sysvinit, not Upstart.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 16:39 UTC (Tue) by jubal (subscriber, #67202) [Link]

Do tell? Have you checked what your init 1 is? ;-)

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:17 UTC (Wed) by juliank (subscriber, #45896) [Link]

Yes, of course, a GR will come if upstart is chosen.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:19 UTC (Wed) by dlang (subscriber, #313) [Link]

and there will probably be a GR if systemd is chosen.

and I wouldn't be surprised to see a GR if sysV is chosen...

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 2:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

From what I'm seeing, people really want systemd because of its technical advantages. And nobody argues (well, except for Canonical employees) that systemd is really more advanced.

And it looks like there's not anybody who wants to switch to upstart for the sake of upstart. Lots of people are simply _opposed_ to systemd or to its non-portability.

That tells something.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 6:26 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

So we will see if technical in the committee name really stands. Or will the decision be political.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 6:55 UTC (Thu) by dlang (subscriber, #313) [Link]

no matter what is decided, some people will claim the decision was political, not technical.

Positions forming in the Debian init system discussion

Posted Jan 21, 2014 17:48 UTC (Tue) by faheem (guest, #47574) [Link]

> And nobody argues (well, except for Canonical employees) that systemd is really more advanced.

Did you mean upstart here?

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:49 UTC (Tue) by josh (subscriber, #17465) [Link]

I'd have been willing to assume good faith on the part of the other TC members who work for Canonical, but I do find it disconcerting that the maintainer of upstart in Debian in particular is participating actively in the decision.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 21:35 UTC (Mon) by jmm (subscriber, #34596) [Link]

I've always disliked the technical commitee in Debian, since it creates a self-elected group of developers within in the Debian developer community.

In the past I've gruntingly accepted it to resolve petty conflicts like maintainers fighting whether package a or package b should provide /usr/bin/foo, but for strategic questions like the init question it is totally inappropriate.

Guillem Jover put it very well on debian-devel:
http://lists.debian.org/debian-devel/2013/10/msg00719.html

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 21:53 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Why didn't he just sponsor a GR if he feels so strongly about it?

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:22 UTC (Wed) by juliank (subscriber, #45896) [Link]

He can just wait for the result, and if he doesn't like it, he can still propose a GR. Why do the work now?

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 0:10 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

He is the one claiming TC shouldn't be discussing this decision at all. Then I don't see what he is wasting TC's time if he intends to override it with a GR anyway.

Positions forming in the Debian init system discussion

Posted Jan 8, 2014 17:15 UTC (Wed) by jwarnica (guest, #27492) [Link]

Knowing as little as possible about internal Debian politics, I would imagine it is still entirely reasonable for the TC to decide "This isn't a technical question, and/or also a strategic question which we are not qualified to even make a recommendation on"

Positions forming in the Debian init system discussion

Posted Jan 8, 2014 18:46 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

TC clearly believes (and references the constitution) that this is within their purview. Ian wrote key parts of that governance document and is in TC. So I see that as authoritative.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 18:29 UTC (Mon) by asdf1234 (guest, #94694) [Link]

It is nice to see some researched viewpoints on this subject. Some things I wanted to bring up on Russ' viewpoint:

1) Saying Redhat backed off from upstart is not a good argument for using systemd. Lennart and Kay are both Redhat employees so of course Redhat is going to use systemd. Now if he addressed the reasons Redhat went with systemd it would help his argument.

2) Saying (rough paraphrase) "just add systemd functionality to BSD/Hurd/etc." is a huge problem that is glossed over in Russ' argument. He's arguing that since they will have to port logind, cgroups, etc. over into these other platforms, you might as well port systemd too. I think it's very unlikely that the Debian developers will get the entire systemd stack accepted into BSD/Hurd/etc. Since systemd is much more than an init system now, that is a huge hurdle that is very unlikely to be met. Whereas with a smaller set of functionality like Upstart, you are much more likely to get accepted upstream. If they really want to see if either approach is viable they should be interacting with those communities and see if they are amenable to either approach. Otherwise, Debian's only choice may be to stick with sysvinit.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 18:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Upstart is NOT significantly smaller. It uses about the same set of Linux-specific functionality. The only major exception is cgroups.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 18:45 UTC (Mon) by asdf1234 (guest, #94694) [Link]

It seems that they need to find out if logind/journald/etc. will even be accepted by those communities before pursing either option since both options have this premise. Otherwise you have these choices:

1) Maintain a separate sysvinit Debian distro for BSD/Hurd/etc. This is a lot more work on your package maintainers.

2) Stick with sysvinit.

3) Use OpenRC.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:59 UTC (Mon) by Lovechild (guest, #3592) [Link]

Or option 4.

Seeing as kFreeBSD and Hurd are practically speaking unused and poorly, if at all, maintained. Drop them to an unsupported tier till such a time as they can support the APIs needed or drop them all together.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 13:14 UTC (Thu) by rvfh (subscriber, #31018) [Link]

Oh dear... I hope it's accepted by all now that there will be _one_ init system coming out of this and it will be either upstart or systemd!

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 18:56 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

The required ptrace is already available in latest FreeBSD kernel.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 18:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

So now you just need eventfd(), singlafd(), epoll(), udev and so on.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 1:05 UTC (Thu) by wahern (subscriber, #37304) [Link]

*BSD already has equivalents for epoll and signalfd. In fact, *BSDs signal events are infinitely more convenient. On Linux a signal can only be received by a _single_ listener. On *BSD the signal is delivered to all listeners.

Likewise, on Linux signalfd will not catch ignored or delivered signals (that is, signals with a handler). You have to block the signal in order to use signalfd to see it. This is not so on *BSD.

eventfd is nice, though. If you're using it as a true counting semaphore, there's no substitute. Most people usually use it in place of a signaling pipe, however, in which case it's trivial to just use a pipe.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 1:34 UTC (Thu) by wahern (subscriber, #37304) [Link]

Or if not a pipe, some kqueue implementations have a user event (e.g. EVFILT_USER on FreeBSD), or you can just install a 0 second timeout. That way you're only dealing with a single descriptor, just like eventfd.

Solaris, OTOH, has no signal listening primitive, which is really annoying. OTOH, it's O(1) polling primitive is always one-shot, which sounds less than optimal but is really very smart. They can optimize persistence behind the scenes while avoiding threading+event pitfalls that plague modern software.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 9:38 UTC (Thu) by smurf (subscriber, #17840) [Link]

So if you want to dispatch a single signal to multiple recipients in Linux, that's easy, just write ten lines of code to dispatch the signal information to the workers.

OTOH if you have a bundle of possible signal handlers in BSD (multiple worker threads for instance), that's easy too, just write a signal handler which triggers the next-available thread.

I cannot imagine a situation where sending a signal to both a traditional handler and signalfd would make sense. If warranted, the signalfd reader can call the traditional handler explicitly. But to have the kernel do that by default seems foolish to me.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:42 UTC (Thu) by wahern (subscriber, #37304) [Link]

Say you have a library (like my cqueues library) that provides a portable interface to non-blocking event management, including receiving signals. Say you have two separate tasks running inside the same process, mostly oblivious to each other (because they're black boxed, independent modules), and each wants to be signaled on SIGHUP so each can reset its internal configuration or state, but doesn't want to leak this abstraction to the hosting code.

On Linux you have to create a special-purposed centralized signal dispatcher in your library to do this. Not on BSD.

On Linux creating this centralized signal dispatcher forces you, as a library writer, to have to initialize and maintain a global state object. This is exceptionally ugly. I chose not to do that, because my library is meant to be embeddable (including trivially pluggable into any event loop) and guaranteed not to do crazy things behind the hosting application's back (that means no hidden mutexes, for example, which might complicate forking or create unnecessary dependencies).

So, I'm sorry, there's no excuse here. I understand why Linux did it--because it requires hacking up the signal dispatching code in the kernel to support multiple receivers. But *BSD put in the effort, and they have a better interface to show for it.

On the flip side, Linux has eventfd and *BSD doesn't. Linux has the better interface in this regard for pollable, counting semaphores. No excuses.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:38 UTC (Thu) by sionescu (subscriber, #59410) [Link]

Imagine two different pieces of code in the same process that spawned subprocesses and want to handle SIGCHLD but have no means of coöperating because they haven't been written with that concern in mind.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 21:57 UTC (Fri) by smurf (subscriber, #17840) [Link]

I'd assume that if one of the threads in question is in a syscall / blocking signals / whatever, the signal in question is consumed by the other one, leading to an interesting race condition.

In any case I consider a library's dependency on SIGCHLD delivery (or indeed the fact that it installs a SIGCHLD handler at all) to be a bug. There are more reliable methods to get notified when a process has gone away, e.g. when reading from its STDERR returns EOF.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 1:51 UTC (Sat) by wahern (subscriber, #37304) [Link]

What race condition? We're talking about the poor behavior of signalfd. This is the inconvenient behavior: if you create two separate signalfd descriptors, each listening for the same signal, only one of them will see it. With that kind of simple behavior, one could pretty much implement signalfd entirely in userspace, for all it's worth.

On BSD you could listen for SIGCHLD with kevent+EVFILT_SIGNAL on two seperate kqueue descriptors, reap with wait4 or waitpid, and there'd be no race whatsoever.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 12:32 UTC (Thu) by j1mc (subscriber, #56848) [Link]

For the record, Kay Sievers was employed by Novell when he began working on systemd.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 22:27 UTC (Mon) by torquay (guest, #92428) [Link]

    I think portability to non-Linux systems is important. It may be that our existing non-Linux ports are not very widely used, undermaintained, and/or not of production quality. However, I think it is important for us to keep those options open.

And this is a technical argument? Almost nobody uses the kFreeBSD and Hurd kernels [1], and yet the vast majority of Debian maintainers and users would in effect be forecefully prevented from using available features in the Linux kernel? Absurd.

systemd's use of cgroups and other Linux kernel features is clearly a major advantage over upstart, and yet we're in effect told that "no, sorry, you can't use those features, so systemd is not even going to be considered".

For upstart to achieve feature parity where it really counts, it will need to start using Linux kernel features. Otherwise there is no way around the fact that upstart is an inferior technical solution. Moreover, by adding in features to upstart that are already in systemd, the proverbial wheel is yet again reinvented, increasing the maintenance burden.

[1] According to Debian's popcon, the number of reported kFreeBSD and Hurd kernels is around 0.09% in comparison to Linux i386 and amd64 kernels. This percentage drops even lower when Linux kernels on other platforms are taken into account (eg. powerpc).

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:10 UTC (Mon) by dlang (subscriber, #313) [Link]

using the feature if it's available is not a problem

Saying that not having the feature is unsupported is a problem

Declaring that you are taking over more and more aspects of the system is a problem (I had missed the G+ post on October where it was declared that the kdbus implementation of dbus was going to be owned and controlled by systemd)

these land grabs and mandatory dependancies are the problem. It's a attitude problem more than a technical problem.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:24 UTC (Mon) by josh (subscriber, #17465) [Link]

> using the feature if it's available is not a problem
> Saying that not having the feature is unsupported is a problem

Doesn't work that way; that's a recipe for never being able to count on any useful new feature. The kernel has a requirement to keep supporting old userspace; userspace has no requirement to keep supporting old kernels. systemd intentionally provides quite a bit of Linux functionality to daemons and unit files, and relies on that functionality itself to implement core features. Some of those features were added to the Linux kernel specifically to make systemd better. What's the benefit of continuing to support systems without them? If you want to run an old kernel, run an old version of systemd to go with it.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:44 UTC (Mon) by dlang (subscriber, #313) [Link]

it's known as degrading gracefully, and it's not as fun as just working on new stuff, but it makes the resulting system much better.

> userspace has no requirement to keep supporting old kernels.

Many userspace programmers seem to think that they have no requirement to support anything other than the latest and greatest. That's a problem.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:11 UTC (Tue) by josh (subscriber, #17465) [Link]

You seem more than willing to speak in absolutes, such as "much better" and "That's a problem"; perhaps you'd like to explain those statements for people who don't already agree with you? You haven't actually said anything to help anyone else see your point of view.

For my part, I'd suggest that both portability to other kernels and portability to older kernels are tradeoffs, which should be made consciously but which need not always be made in favor of maximum portability. Sometimes it's OK to choose to use a feature that other systems don't have; otherwise, what's the point of having features other systems don't have?

I like that manpages always talk about the portability status of a feature; when I'm writing portable software I use features that run on the systems I have to care about, and when I'm writing software that need not be portable I take full advantage of the features my preferred target environment has.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:00 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I would also consider init to be in a different class of software than your average userspace application, in the same way that udev or iproute2 is tied to the underlying OS as it interfaces with platform specific kernel level services. If your init is going to expose Linux kernel features like cgroups or syscall filters or namespaces or SELinux then by definition it has a lot of platform-specific code. In the systemd case they made a conscious trade-off to make systemd as simple and straightforward as possible by not being afraid to use all the features that Linux provides, the same trade-off made with PulseAudio really, with some of the same effects in that they are exercising features that weren't well-used before which is driving bug-fix and refactoring in the kernel to make the features more robust, like Tejun Heo's work on cgroups.

It seems that many of the features that would be useful to an init, like containers and process management, are highly non-standardized across OS kernels making portability non-existant.

Positions forming in the Debian init system discussion

Posted Dec 30, 2013 23:41 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> these land grabs and mandatory dependancies are the problem. It's a attitude problem more than a technical problem.
That's an easy thing for you to say because you're not the one who would have to maintain the resulting ifdef-riddled code base.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:14 UTC (Tue) by misc (subscriber, #73730) [Link]

And having a attitude and refusing patches was never a issue on the lklm, and not even speaking of the colorful and vigorous style ( or verbal abuse, depending on your perspective ) of discussion on the list.

But for some reason, it seems the free software world suddenly discover that there is people opinionated outside of the kernel crowd. Why is this a problem for a core component like systemd, and not a problem for another core component like the kernel ?

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:43 UTC (Tue) by torquay (guest, #92428) [Link]

    Saying that not having the feature is unsupported is a problem

I agree that small non-core features can be considered as optional features. However, something major such as cgroups is a core feature. By deliberately staying in the past through not supporting current technology, projects end up behind left behind. Why deliberately cripple yourself by not taking advantage of a very useful advancement in technology? Why deliberately make your system less robust? Why deliberately make the maintenance burden higher?

In fact, why don't we all revert to transport by horse wagons? Better yet, how about we forget about the wheel entirely, and revert to hunting for food in large packs with spears?

    these land grabs and mandatory dependancies are the problem. It's a attitude problem more than a technical problem.

Land grabs? I see this more as progress. Making 50 bazillion implementations to achieve one functionality might be all fine and dandy in the name of "we're free to do that", but there's a hefty price to pay in terms of supporting the 50 bazillion implementations.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 0:54 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Land grabs? I see this more as progress. Making 50 bazillion implementations to achieve one functionality might be all fine and dandy in the name of "we're free to do that", but there's a hefty price to pay in terms of supporting the 50 bazillion implementations.

Gnome, KDE, Xfce, <insert other gazillion Linux desktops here>: please pay heed! Please!

PS. Thank you for this comment.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 1:04 UTC (Tue) by torquay (guest, #92428) [Link]

    Gnome, KDE, Xfce, <insert other gazillion Linux desktops here>: please pay heed! Please!
I agree that everybody has their preferences in terms of the UI. However, this is different than re-implementing something low-level like systemd, which has an influence on everything. Even the above-mentioned desktops share core parts of their infrastructure, through services such as dbus and others. The point is to differentiate where it makes sense, not to needlessly reinvent the wheel.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 2:44 UTC (Tue) by bojan (subscriber, #14302) [Link]

It is much more then just preferences. Much more.

The true desktop, statistically, is really just two things: Windows and Mac. Both of these followed just one line of desktop development and "unbelievably" were able to keep the vast majority of users. In spite of lack of choice of "UI preferences", apparently.

On the other hand, Linux has more desktop "choices" right now than both of these had version incarnations in their history (didn't count, to be honest, but would not be surprised). I mean, we have one written in JS, of all things - FFS!

No wonder Linux is just a rounding error when it comes to desktop...

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 17:23 UTC (Wed) by krake (subscriber, #55996) [Link]

But isn't the difference also in availability of choice on Windows and Mac?

I don't use either platform often enough to know about their options, but how easy is it to boot either into a different desktop and how many vendors provide such alternative desktops?

I remember that back in the days of Windows 3.11 I was in fact using an alternative deskop, but I can't remember its vendor.

Obviously only the existance of suitably developed alternatives not being used allows to conclude that the primary option is used by choice. The lack of alternatives obviously would not.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 22:31 UTC (Wed) by bojan (subscriber, #14302) [Link]

It is entirely irrelevant whether people use Windows and Mac because they made a conscious choice that this is the UI they prefer or because it is the only available thing for that type of computer. The fact remains, you can have _one_ line of desktop development per OS and have lots of users.

This whole wasted effort in Linux world where every man and his dog has a desktop is just that - a wasted effort.

The reasons for this waste a varied. The original Gnome/KDE thing was about the licence dispute. Later on, we had "desktop philosophy" wars - whatever that's supposed to mean.

Instead of having one system that can accommodate many by being flexible, we have a mess that no sane third party application developer can ever dream of targeting.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 22:54 UTC (Wed) by dlang (subscriber, #313) [Link]

> This whole wasted effort in Linux world where every man and his dog has a desktop is just that - a wasted effort.

so what?

it's effort that the people doing it think is worthwhile, who are you to judge that it's wasted?

Linux itself was termed 'wasted effort' by many people when it was started (for different reasons)

GNU's mission is considered 'wasted effort' by people who don't have any problems with proprietary code.

Open Source Development is not centrally planned and run. Getting someone to stop working on one project does not mean that they will work on another project that you think is better, it may just mean they stop contributing entirely.

while individual projects always wish they had more contributers, there is not a shortage overall, and we accept that a lot of effort is going to be wasted on things that eventually become dead ends. We let the market (our users) provide the feedback, but sometimes it's worth working on the project even is the userbase is one, the developer of the project.

And you have no right to tell any developer that they are wasting their time. You can point out other things that you think may address their needs, but if they don't agree, that's just fine.

David Lang

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:07 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

And you have no right to tell any developer that they are wasting their time.

Nonsense. One absolutely has the right to tell any developer that they are wasting their time. What one does not have (in the general case) is the right to be listened to when one does.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:39 UTC (Wed) by krake (subscriber, #55996) [Link]

Indeed!

If everyone would stop doing things that anyone would consider a waste we wouldn't do anything at all anymore other then bare survival.

We wouldn't even have this conversation because we, as a species, would have never developed written language, maybe not even a structure language at all.

People who think that learning, teaching, praticising and researing is a waste are a waste of bio resources.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 0:20 UTC (Thu) by bojan (subscriber, #14302) [Link]

> If everyone would stop doing things that anyone would consider a waste we wouldn't do anything at all anymore other then bare survival.

You are absolutely right. The first thing every Windows user does, as it is well known, is decide which window manager they want to run. Which from this list should they use?

http://en.wikipedia.org/wiki/Comparison_of_X_window_managers

I mean, unless they had all those choices, how on earth would they ever be able to do anything? And how would Windows as a platform every progress?

Seriously for a second. There is choice, change and progress. Then there is waste.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 0:33 UTC (Thu) by dlang (subscriber, #313) [Link]

you are right that it's a waste, but you are wrong to try and stop the waste.

It's also a waste to have more than one car manufacturer, and for that manufacturer to have more than just a couple models

having more than one R&D team wastes effort, they are trying wrong things, they are duplicating effort of other R&D teams.

and you know what? eliminating wasted effort like this has been tried, it takes a very strong government dedicated to central planning.

and it failed.

it turns out that wasting effort is neccessary.

It's also not a zero sum game, eliminating what you consider wasted effort doesn't result in that effort going to things that you consider worthwhile.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 1:20 UTC (Thu) by bojan (subscriber, #14302) [Link]

No, I agree with you that some duplication of effort is necessary. Linux desktop should duplicate the effort put in by Microsoft and Apple. Possibly even Google.

But, it should not be duplicating its own effort to such a degree that there is no product that can be targeted by third parties, identified by users etc. A desktop is a system that serves that kind of purpose.

Just consider these brief examples:

- how is one to run a useful extension made for Gnome Shell on XFCE/KDE?
- why does each Linux desktop have to have their own file manager?
- why do they all have to have their own window managers?
- why do they have different session managers?

And so on and so forth. Surely, all of the above are examples of unnecessary duplication. Caused by the fact that developers have "philosophical differences", use different toolkits, don't like moving panels, like moving panels, want 3D, don't want 3D etc. All artificially created barriers by communities themselves.

You know, if Linux desktop had large market penetration, I would say - sure, duplicate. But, in the state where it is just a rounding error? I don't think so. The end result is a lot of unfinished software, just in different states of unfinished.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 1:54 UTC (Thu) by mchapman (subscriber, #66589) [Link]

> Linux desktop should duplicate the effort put in by Microsoft and Apple. Possibly even Google.

You speak of "Linux desktop" as if it were a person. It isn't.

In reality, people work on what interests them. Who are you to decide what interests others?

If *you* think the various desktops should work more closely together, get on board and help them do that.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 2:18 UTC (Thu) by bojan (subscriber, #14302) [Link]

> You speak of "Linux desktop" as if it were a person. It isn't.

I have no idea what you are talking about here. It is a collection of software made by a group of people. Or should be, at least.

> In reality, people work on what interests them. Who are you to decide what interests others?

Why do you think I want to decide anything for anyone? I'm just saying that many years of effort still produced only a fragmented mess. If rounding errors are the level of market share that is aimed for here, then there is no problem.

> If *you* think the various desktops should work more closely together, get on board and help them do that.

Is your theory that if I get on board and help, Gnome/KDE/XFCE/<insert other gazillion desktops here> will merge? Thanks, but Superman is the dude in the cape. :-)

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 3:36 UTC (Thu) by mchapman (subscriber, #66589) [Link]

> If rounding errors are the level of market share that is aimed for here, then there is no problem.

I think few people are aiming for any particular level of market share. That these projects continue to exist despite such low market share demonstrates that it's not really a big concern.

> Is your theory that if I get on board and help, Gnome/KDE/XFCE/<insert other gazillion desktops here> will merge?

No, of course not. But it'd probably end up doing a lot more good than sitting here claiming that desktops "should" do X or "should" do Y.

Frankly, I don't see a problem with duplication of effort, even when it's "unnecessary". Sometimes good things can come out of re-exploring a well-trodden problem space: both systemd and Upstart arose because of it.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 4:08 UTC (Thu) by bojan (subscriber, #14302) [Link]

> I think few people are aiming for any particular level of market share.

Well, Red Hat (who don't care about desktop: http://bits.blogs.nytimes.com/2009/04/06/red-hat-opts-for...) and Canonical (who think they already won: https://bugs.launchpad.net/ubuntu/+bug/1) both agree with you, in a way. Which is probably the reason why there is no winner.

I am trying to imagine Google having the same attitude when it comes to Android/Chrome OS and it honestly does not compute. I really would not be surprised if Google ate Red Hat's and Canonical's cake in this space, although both of these had a massive first mover advantage (at different times).

If something like that were to happen, most of the projects that exist now in the "Linux desktop" space may simply become irrelevant.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 19:53 UTC (Thu) by krake (subscriber, #55996) [Link]

> I think few people are aiming for any particular level of market share.

Indeed!

My guess is that a lot of people have been conditioned to think in terms of "market" and "getting a piece of the cake" and so on and forget that not everything is gouverned by captialism, greed and the longing for more and more profit.

Actually even in the context of commerce, percentage in an arbitrary but unrelated context is often less relevant than other values.
Just consider the miniscule market share Ferrari has in the global car industry yet they continue to create cars that will never have any significant market percentage wise.

Or software created for a specific country or region, e.g. tax software. Those vendors often have a couple of thousand (or depending on country tens of thousands) customers, a tiny speckle in the global consumer software market, yet still considered very successful.

> No, of course not.

Mostly because the question was very clumsly phrased. It is not about "merging" at all, consolidation is more often about switching to a shared or third party solution for something in the next generation of ones products.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 3:54 UTC (Thu) by dlang (subscriber, #313) [Link]

by your logic there should only be one mail client, one database, one word processing program, anything more is a waste of effort

If duplication is such a waste, why should Linux duplicate the effort put in by Microsoft and Apple? what makes _any_ linux desktop worthwhile enough?

Yes, there is wasted effort. That's the way things work. We accept it and don't get upset by it. Continuing to rail against the wasted effort accomplishes little more than getting anything else that you say ignored as people start to filter you out.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 4:11 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> If duplication is such a waste, why should Linux duplicate the effort put in by Microsoft and Apple? what makes _any_ linux desktop worthwhile enough?
If Windows or Mac OS X were fully free then it probably wouldn't have made any sense to duplicate their functionality in Linux.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 4:30 UTC (Thu) by bojan (subscriber, #14302) [Link]

> by your logic there should only be one mail client, one database, one word processing program, anything more is a waste of effort

Never said anything like that. You are just twisting my words there.

We have multiple desktops, each with their own (sometimes non-interchangeable) components doing more or less the same stuff, being (to a degree) incompatible with each other as platform targets, having totally different look and feel etc. for no good reason.

Of course nobody sane is writing 3rd party stuff for this. Of course OEMs don't take it seriously. Of course users aren't going to pick any of that up.

You see, systemd is actually an excellent example of how it's done. Yes, some will get grumpy, but in the end a very good technical solution will win. Next round, maybe some other. But, at least it is something that everyone can target as a whole.

> If duplication is such a waste, why should Linux duplicate the effort put in by Microsoft and Apple? what makes _any_ linux desktop worthwhile enough?

I don't know - because we'd like an open source desktop to actually succeed? What is wrong with winning?

> Yes, there is wasted effort. That's the way things work.

On the other hand, _too_ _much_ wasted effort leads to fragmentation that we are seeing right now. It is sometimes hard to accept the hard truth, but it is always necessary in order to do better.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 19:57 UTC (Thu) by krake (subscriber, #55996) [Link]

> there should only be one mail client, one database, one word processing program, anything more is a waste of effort

What?! A mail client is totally wasted effort, it is just a word process on top of a remote database :-)

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 12:51 UTC (Thu) by paulj (subscriber, #341) [Link]

why does each Linux desktop have to have their own file manager?

The most recent case I can think of: Mint forked nautilus cause the GNOME people started stripping out features out of Nautilus, no?

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 19:35 UTC (Thu) by krake (subscriber, #55996) [Link]

> how is one to run a useful extension made for Gnome Shell on XFCE/KDE?

That's pretty non sensical, isn't it? "How do I run plugin for application X in application Y". How do I run a Windows shell extension on OS X?

> why does each Linux desktop have to have their own file manager?

If you mean vendors having a desktop product having a file manager product, then this is wrong. Only larger vendors have multiple products beside their desktop product and not all file manager vendors have desktop products.

> why do they all have to have their own window managers?

they don't. Some desktop product vendors have their own window manager component because that is often what they started with or they came from being a window manager vendor.
Other vendors might have recommendations for a specific other vendor's window manager component, but are still not restricted to that recommendation.

> why do they have different session managers?

The only good question in your list. Maybe because there is no vendor that has a stand alone session manager product? One could try to create that an see if there is any uptake. Maybe it is a very central piece of the machinery and other vendor's roadmaps are not in line with one's own?

Not that it matters there is after all only one session manager per definition and they all use the same protocol towards applications.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:15 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> That's pretty non sensical, isn't it? "How do I run plugin for application X in application Y". How do I run a Windows shell extension on OS X?
No, it's not nonsensical. On Mac OS X/Windows I can reasonably expect any software to work with the default shell (which is present on more than 99.999% of installations).

> If you mean vendors having a desktop product having a file manager product, then this is wrong. Only larger vendors have multiple products beside their desktop product and not all file manager vendors have desktop products.
No, he's talking about Thunar/Dolphin/whatever GNOME uses.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:42 UTC (Thu) by krake (subscriber, #55996) [Link]

> No, it's not nonsensical.

Yes it is. Almost no software category has a universal plugin API. Browsers do (NPAPI) and AFAIK audio effect plugins do.

And even for browsers that doesn't cover extensions. Chrome doesn't run Firefox extensions, IE doesn't run Chrome extensions and I don't even know if Safari even has extensions.

Moreover, there is no cross vendor desktop shell extension capability for propriertary desktop products either, so it is not only non-sensical, it is even hypocritical.

> No, he's talking about Thunar/Dolphin/whatever GNOME uses.

Which is what I said, right?

Large software vendors such as KDE, GNOME, Microsoft or Apple have a workspace shell product and application products, which in the case of KDE, GNOME, Microsoft and Apple does indeed include a file manager product.

However, there are other, often smaller vendors, which have only a workspace shell product or only application products, some of which might have a file manager among them.

I even heard rumors that some of the large vendors with workspace shell products even have their own web browser products!

We might have to brace ourselves for browser vendors to add workspace shells to their product lines

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:14 UTC (Thu) by bojan (subscriber, #14302) [Link]

Here is a hint: step back about a hundred paces, then look. You may see a bigger picture. :-)

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:25 UTC (Thu) by krake (subscriber, #55996) [Link]

Ah, more sarcasm?

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 15:57 UTC (Mon) by niner (subscriber, #26151) [Link]

So you can expect any Mac OS X software to work with the default Windows shell? No? Then why do you expect any Gnome software to work with the default KDE shell? Just because both happen to run on a common OS kernel?

It seems to me that you're just confusing different definitions of the term "operating system". You are using the original definition "abstraction of the hardware" with the nowadays common definition propagated by Microsoft and Apple that could be termed like "kernel and application software for supporting common use cases of a computer".

You are using the original definition for Linux and expect to get the same as with the modern definition. You can't. If you want to compare software at the same level, you have to take Gnome/Linux, KDE/Linux, Unity/Linux and whatever else there is. They are roughly comparable to common Windows or OS X desktops. And at this level, expecting Gnome/Linux software to work seamlessly on a KDE/Linux system is just as unreasonable as expecting OS X software to work on a Windows desktop. Except that very often it is indeed possible on Linux based systems because of standardization and effort put in by the developers of those systems.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 16:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> So you can expect any Mac OS X software to work with the default Windows shell? No? Then why do you expect any Gnome software to work with the default KDE shell? Just because both happen to run on a common OS kernel?
Yep. They run on the same kernel, use the same display server, they can run side-by-side.

As a user, I'd expect them to interoperate.

> You are using the original definition for Linux and expect to get the same as with the modern definition. You can't. If you want to compare software at the same level, you have to take Gnome/Linux, KDE/Linux, Unity/Linux and whatever else there is.

Yeah, it reminds me of the good old joke the describes the Linux desktop situation pretty succinctly:

> I was walking across a bridge one day, and I saw a man standing on the edge, about to jump off. So I ran over and said "Stop! don't do it!"
>"Why shouldn't I?" he said.
> I said, "Well, there's so much to live for!"
> He said, "Like what?"
> I said, "Well...are you religious or atheist?"
> He said, "Religious."
> I said, "Me too! Are you christian or buddhist?"
> He said, "Christian."
> I said, "Me too! Are you catholic or protestant?"
> He said, "Protestant."
> I said, "Me too! Are you episcopalian or baptist?"
> He said, "Baptist!"
> I said,"Wow! Me too! Are you baptist church of god or baptist church of the lord?"
> He said, "Baptist church of god!"
> I said, "Me too! Are you original baptist church of god, or are you reformed baptist church of god?"
> He said,"Reformed Baptist church of god!"
> I said, "Me too! Are you reformed baptist church of god, reformation of 1879, or reformed baptist church of god, reformation of 1915?"
> He said, "Reformed baptist church of god, reformation of 1915!"
> I said, "Die, heretic scum", and pushed him off.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 17:27 UTC (Mon) by dlang (subscriber, #313) [Link]

> Yep. They run on the same kernel, use the same display server, they can run side-by-side.

> As a user, I'd expect them to interoperate.

define "interoperate"

if you install two different windows apps, they will both run on windows, but the chances of them being able to use each other's data is low. It's only if they are interacting with remote services (such as LDAP/AD)

Even for something like picture managers, they may import pictures from the "My Pictures" directory, but they will each store their own metadata, edits, and everything else in incompatible ways.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 17:46 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I can install a nice weather tray application on Windows and it will work on Win 2000, Win XP, Windows Vista, Windows 7 and even Windows 8. That spans about 15 years.

I can't install a weather tray application from GNOME2 on GNOME3 Fallback mode. I can't install GNOME2 tray application on Xfce, and though they even both use GTK!

THIS is fragmentation. It's unnecessary, divisive and ultimately self-destructive.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 18:03 UTC (Mon) by dlang (subscriber, #313) [Link]

are you sure about this? you can use Gnome system tray apps with KDE for example.

So if you can't do this with Xfce it sounds like Xfce needs to update their system tray to support the freedesktop.org standard that has been worked out.

Now, this standard did not always exist, and at one time every window manager did their own thing, but then they started to coordinate and established a standard.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 18:14 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

I'm pretty sure. I tried to use GNOME's Power Manager applet in Xfce and failed.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 18:20 UTC (Mon) by dlang (subscriber, #313) [Link]

I wonder if the problem was related to the systemtray or if that applet depends on other power management tools that weren't available?

Power management is one of the areas where there is a lot of work going on, which translates into lots of experimentation and incompatibility.

Try some other applets.

As a Kubuntu user, I've run into quite a few cases where I end up running a Gnome applet in the systemtray.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 18:33 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Nope. It used the same power management daemon (upowerd?) as Xfce's native applet.

I couldn't make the applet to start without it trying to start the GNOME panel.

Positions forming in the Debian init system discussion

Posted Jan 6, 2014 16:59 UTC (Mon) by raven667 (subscriber, #5198) [Link]

That's pretty much a description of the problem as bojan stated it at the beginning of the thread. By fragmenting the GUI OS into incompatible silos without complete compatibility of the underlying layers we have prevented the gaining of any critical mass of application development in any one of those silos, and prevented a critical mass of infrastructure developers. They have worked hard to standardize parts of it, through ICCCM and freedesktop.org and others but it's not complete and comprehensive compatibility, there are plenty of rough edges that frustrate application development.

That's the essential complaint, that all of these silos are fundamentally working at cross purposes of each other because the fragmentation of the Linux Desktop OS marketplace weakens them all. A single arrow is weak and easy to break, a bundle of arrows is stronger and hard to break.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 17:03 UTC (Thu) by krake (subscriber, #55996) [Link]

> The first thing every Windows user does, as it is well known, is decide which window manager they want to run.

I haven't created new Windows user accounts lately, but that is new to me.
I didn't even know that Windows had window managers.
Interesting developments.

> Which from this list should they use?

I think you are confusing things. Microsoft Windows is not using the X Window system, so those Window managers that are nowadays seemingly offered to Windows users need to be different ones.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:07 UTC (Thu) by bojan (subscriber, #14302) [Link]

No, I think you missed my sarcasm.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:22 UTC (Thu) by krake (subscriber, #55996) [Link]

Must have.

That comment looked like total non sense to me. I tried my best to make any sense of it, but the extremely hard to believe claim followed by an seemingly misunderstood or misinterpreted meaning of the word window in X window manager just made it looks like some incoherent gibberish.

Are you referring to the first sentence?

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 2:58 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

That's all true, but from a perspective of a user, Linux most definitely doesn't need:

1) More 'regular' windows managers. Exotic window managers like ratpoison are fine - they were not designed for regular users.

2) More music players.

3) More Internet browsers that nobody uses.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 17:14 UTC (Thu) by krake (subscriber, #55996) [Link]

A single user is unlikely to change a lot.

Just like in any other product categeory, nothing special regarding computing in general or Linux specifically.

Sure, there are always users that like to evaluate the unknown, but then that is their prerogative.

Most people settle for a given product option and only reevaluate if that option no longer fits their needs, e.g. their needs changed or the product changed, etc.

However, the same person can apply different behavior to different kinds of product, e.g. changing car model every time but staying with the brand, or keeping the same product of shampoo even when the vendor changes, etc.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 17:43 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

>Just like in any other product categeory, nothing special regarding computing in general or Linux specifically.

Actually, there is. Linux in many cases Just Doesn't Work (tm) and consumers simply vote with their feet.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 19:22 UTC (Thu) by krake (subscriber, #55996) [Link]

> Actually, there is

No. Every product category has multiple options to chose from. Even when manufacturers have consolidated down to a handful worldwide.
For some kinds of products the availability of options is so important that single manufacturers even have "competing" products under different brand names.

> Linux in many cases Just Doesn't Work (tm)

Awww. You have to try better (tm). Nobody on lwn.net will fall for such primitive flamebait.

> consumers simply vote with their feet.

Exactly! Hence no need to artifically curb availability. A new music player will not gain any users if does not appeal to some. If it does they will, as you put it, vote with their feet and use it instead of whatever they used before.

A couple of years ago most music players were like WinAMP. Luckily there was no artifical ban on new music players so nowadays most use softwarethat is more like a music library.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 19:39 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I think you are comparing apples and oranges here by comparing end user applications, for which there is much competition, and infrastructure, where competition is less useful and standardization provides real benefits.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 19:57 UTC (Thu) by dlang (subscriber, #313) [Link]

And here we have the core of the disagreement.

Many of us think that competition is very useful in infrastructure and standardization provides real benefits in end user applications.

we are looking for standardization in file formats and APIs, not in limiting the number of possible options.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:26 UTC (Thu) by krake (subscriber, #55996) [Link]

Very good points!

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:32 UTC (Thu) by raven667 (subscriber, #5198) [Link]

Aren't you contradicting yourself when you say you are looking for standardization in APIs as aren't APIs the infrastructure we are talking about? The original complaint was that there are not standard APIs for applications to use because there are entire separate competitive stacks (KDE, GNOME, Unity, XFCE, etc.) between the kernel and the application that don't have standard APIs.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 21:26 UTC (Thu) by dlang (subscriber, #313) [Link]

the difference is that I don't see KDE and GNOME as the relevant APIs, or even GTK vs QT.

the API relevant to those applications is X11 for display. The fact that different apps use different toolkits to talk to that API is not a big deal (as long as the toolkits are willing to co-exist, which they are)

There are a lot of infrastructure components in *nix that have changed significantly over time (look at the capabilities of rsyslog v7 vs sysklogd for example), but the applications using them don't need to know about the differences between them if they don't want to.

similarly, the login process has changed radically since the early days, but because the APIs have been stable, the changes in details (from /etc/passwd to /etc/shadow to PAM) haven't required app changes.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 15:29 UTC (Fri) by torquay (guest, #92428) [Link]

    the API relevant to those applications is X11 for display. The fact that different apps use different toolkits to talk to that API is not a big deal (as long as the toolkits are willing to co-exist, which they are)

I'd argue that while having a low-level API like X11 is useful, it would be even more useful to have a standardised toolkit API, which exists at a higher level (ie. less verbose) and is hence easier to program in. One can of course change the look + etc, through re-implementing the API, but not breaking it. Standardisation at a higher level can be applied to many other parts of the stack.

The main point is to draw a line of standardisation (and hence stability) somewhere in the overall stack, in order to achieve a sweet spot between 2 factors: customisability and ease of use, both from the point of view of writing end user applications. End user applications and users are the entire reason operating systems exist in the first place -- many people in the open source world seem to forget this.

Right now the trade-off between the 2 factors is completely out of whack. The only thing that's standardised in the Linux world is the kernel, glibc and to a large extent the mess that's X11. In almost everywhere else though, we have lots of customisability along with associated costs of piss poor API stability. GTK is still a moving target (deprecating and adding APIs at an uncomfortable rate). Qt is a bit better, but it has gone through many major releases in a relatively short span.

Enough is enough. Any efforts to standardise low-level plumbing though software such as systemd are very welcome.

It is of course pertinent to note that there is already one Linux-based system which has taken stability seriously: Android. It's also relevant to note that the number of tablets and phones running Android easily eclipses the "traditional" Linux desktop.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 15:38 UTC (Sat) by krake (subscriber, #55996) [Link]

> I'd argue that while having a low-level API like X11 is useful, it would be even more useful to have a standardised toolkit API, which exists at a higher level (ie. less verbose) and is hence easier to program in.

Sure, but developers would most often still use the toolkit they prefer.

Motif was basically the standard toolkit for X11 based systems, yet most developers use GTK+ or Qt.

Speaking of Qt, a large portion of Qt developers use Qt on Windows, which presumably has a standard toolkit.

Even single vendor solutions need to change toolkits now and then, but just like on X11 the common low level API makes it possible to keep old and new API working in parallel.

Standardisation of APIs is unfortunately often also just wasted effort. Standardisation of protocols and data formats on the other hand are usually long lived and successful.

Positions forming in the Debian init system discussion

Posted Jan 4, 2014 23:23 UTC (Sat) by dlang (subscriber, #313) [Link]

> Standardisation of APIs is unfortunately often also just wasted effort. Standardisation of protocols and data formats on the other hand are usually long lived and successful.

actually, I'll disagree with this.

standardization of APIs can be extremely valuable

standardization of toolkits (and their APIS) is far less useful.

The Unix POSIX API standardization is an example of a very valuable API standard.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 20:25 UTC (Thu) by krake (subscriber, #55996) [Link]

I don't see where I make that comparison.

I mentioned music players as an example because that is one of the examples in the grand grand parent comment.

There is competition in this area, as you said, and it has been proven useful (change in needs of music players, avoiding IE-only stagnation, etc)

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:16 UTC (Wed) by bojan (subscriber, #14302) [Link]

> so what?

So, no users.

> it's effort that the people doing it think is worthwhile, who are you to judge that it's wasted?

I am not doing the judging - developers and users are. And they are voting with their feet, because, to be perfectly honest, there is no such thing as a Linux desktop.

Linux has been around for many years. One would expect that by now, things would settle on some desktop that everyone can target and use. No such thing happened. Instead, we have more fragmentation than ever before. What is the consequence of this? No Linux desktop, of course. Rinse, repeat...

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:32 UTC (Wed) by krake (subscriber, #55996) [Link]

> It is entirely irrelevant whether people use Windows and Mac because they made a conscious choice that this is the UI they prefer or because it is the only available thing for that type of computer

Well, it depends on what you are trying to imply from that.
If you are implying that users with no other choice will use the only thing they can use then of course that is obvious.

If you are implying that choice is not necessary then this can only be because there is choice and it is not being used or rejected.

Since the first one is a selffulfiling prophecy and thus without any content or relevance, I have to assume you were targetting the latter. In which case it should be possible to point to the alternatives offered to Windows and Mac users.

> The fact remains, you can have _one_ line of desktop development per OS and have lots of users.

Nobody is disbuting that. Canonical shows that with Unity on Ubuntu. The whole Ubuntu family also shows that one line of desktop environment per OS variation can have lots of users.

But it also shows that given a vendor given choice plus alternatives that the vendor chosen option will not automatically get all users, in the contrary.
Which makes it extremely hard to believe that Windows and Mac users have in fact alternatives available to chose from.

But, as I wrote before, I don't follow either platform's development close enough to rule the existence of alternative desktop options out.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 0:09 UTC (Thu) by bojan (subscriber, #14302) [Link]

There must be some miscommunication somewhere, I think. So, let me try to clarify.

These are the facts on the desktop (roughly speaking):

- Windows and Mac have users
- Linux does not

Now about the "UI choice" (or whatever you want to call it) with multiple desktops on Linux. This was supposed to be some kind of "better approach" in order to satisfy the needs of just about everyone, but supposedly targeting exactly what each group wanted. That is what we (the remaining, rusted-on Linux desktop users) have been told for years. I used to believe it. I used to preach it, FFS!

Compare that to facts. It didn't work. We were all wrong.

No serious third party application vendor can even identify what Linux desktop really is. Users don't know what it is, they cannot purchase or otherwise obtain it and neither would they want to. There are no labels on boxed software that say "Linux desktop compatible". There is no "Linux desktop application store" etc. There is no critical mass. It didn't happen.

That is what I'm implying.

In many ways, multiple Linux desktops have solved the competition problem for both Microsoft and Apple for now. They are the ones laughing all the way to the bank for quite some time now.

PS. Note, I did not count Android as a Linux desktop, mostly because it is not desktop ready and because isn't really a GNU/Linux system.

PPS. I have no idea why you are mentioning Canonical in this context at all. They are just another source of fragmentation, IMHO.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 16:53 UTC (Thu) by krake (subscriber, #55996) [Link]

> These are the facts on the desktop (roughly speaking):
> - Windows and Mac have users
> - Linux does not

Maybe you consider that covered under "roughly speaking", but all three operating systems have users. A lot.
We all know that Windows desktop users are the largest group, but given Earths enormous population even numbers magnitudes lower than Linux desktop's official share (which is way lower than the actual share in users) would a huge number of individuals.

> This was supposed to be some kind of "better approach" in order to satisfy the needs of just about everyone, but supposedly targeting exactly what each group wanted

Well, it is probably not targettting every possible group with an individual solution, but it seems to have settled on quite a nice range of solutions, each distinctly preferred by the people using it.

So while there might be better approaches to satisfy the inherent ndividual differences of people, it is definitely a viable one. Even systems that I would not be able to use have tens of thousands of users who would feel inhibited by any other solutions (otherwise they wouldn't be using their respective setup).

> Compare that to facts. It didn't work. We were all wrong.

I find it worked really well.
People who like be in control as much as possible have found developers catering to that needs.
At the same time people who like to have as much as possible automated have also found developers catering to that needs.

Or people who's mental model prefers instant application of setting changes vs people who's mental model prefers explicit acknowledgement.

Sure, along that line people could decide to use Mac or Windows respectively, but what if they like a different aspect of the other system?

Satisfying those combinational conflicts with only two options means making sacrifices. Those might be easily acceptable but can also be hardly bearable.

Given the capability to add new options, those in the latter category can often find a more suitable home. As evident by large numbers of users for each of the popular options :)

> I have no idea why you are mentioning Canonical in this context at all. They are just another source of fragmentation, IMHO.

I interpreted an earlier comment to say that a vendor chose solution will always be universally excepted even if alternatives exist.
Ubuntu would suggest that this is not true, because there is a primary vendor, Canonical, with a vendor chosen option, Unity, but several alternatives on the same base platform have significant numbers of uses as well.

It was just an example of at least one situation where availability of options also resulted in some those options being chosen.

I haven't read all new postings since then so somebody might have already provided examples of alternatives on Windows or Mac that did not get chosen, for the time being I had to assume that all those platforms' users were using the vendor provided option because there was no other to chose from.
Which of course would make them irrelevant as examples for discussing user preferences.

Positions forming in the Debian init system discussion

Posted Jan 2, 2014 23:08 UTC (Thu) by deconfliction (guest, #94407) [Link]

" The reasons for this waste a varied. The original Gnome/KDE thing was about the licence dispute. Later on, we had "desktop philosophy" wars - whatever that's supposed to mean.

Instead of having one system that can accommodate many by being flexible, we have a mess that no sane third party application developer can ever dream of targeting."

Umm... you managed to define one of the core "desktop philosophy wars" right after claiming you didn't know what the phrase meant. And in fact, gnome taking the route of removing flexibility, and being adverse to spending time making others lives easier that wanted flexibility, is pretty much precisely the argument I heard against systemd.

It's not waste. It's options, and it's evolution. Enjoy your confidence, it's a fun feeling to have.

Positions forming in the Debian init system discussion

Posted Jan 3, 2014 4:19 UTC (Fri) by raven667 (subscriber, #5198) [Link]

These are terrible arguments. I'm not sure how we are confusing GNOME's history of moving its more advanced config options from the Settings app to [gd]conf or gnome-tweak-tool, while still retaining many or most of the options with the fact that systemd exposes a plethora of options that the Linux kernel provides for starting and managing processes, that other systems would be years away from achieving, if they were trying at all. It's like this is the Slashdot version of "facts" which aren't really anchored in the technical realities, you "heard" an argument about GNOME or systemd but haven't done the research to see how relevant or factual this is, and aren't listening to the people who have done so, but are not afraid to repeat it.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 11:47 UTC (Tue) by Wol (guest, #4433) [Link]

And as I understand it, certain parts of KDE were broken by adopting (Gnome) dbus, despite KDE's version being better :-(

Although kdbus apparently is now fixing at least some of it.

The problem in some places, however, is that whether it's good or not, some software design decisions do not fit well with some wetware design decisions. And unfortunately the latter CAN'T be changed ... :-)

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 12:17 UTC (Tue) by BlueLightning (subscriber, #38978) [Link]

Er, would you care to elaborate? I've been a KDE user right through the DCOP->dbus transition and I noticed no such breakage (at least, not attributable to that particular transition.)

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 15:27 UTC (Tue) by mgraesslin (subscriber, #78959) [Link]

there are still users around who are unhappy that dbus is not network transparent which came for free with DCOP (AFAIU - never used DCOP as a developer). As we are at the state of transiting away from X11 I'm rather happy that we don't have an IPC which relies on X11.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 15:47 UTC (Tue) by richmoore (guest, #53133) [Link]

The only real thing that dbus lacked that dcop had was the deadlock protection when dealing with recursive calls. Code relying on that was probably something that needed a bit of redesign anyway. The only other thing was the lack of a tool like kdcop (a graphical viewer) and we now have qdbus which offers the same facilities.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 10:45 UTC (Wed) by paulj (subscriber, #341) [Link]

Re graphical viewer, was D-Feet not sufficient?

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 12:20 UTC (Wed) by richmoore (guest, #53133) [Link]

I don't think it existed back then. :-)

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 14:17 UTC (Tue) by daniels (subscriber, #16193) [Link]

D-Bus was designed equally by GNOME and KDE developers. Waldo (one of the primary DCOP designers), Harri (core Qt developer), and Zack were all involved from day one.

That it is/was some kind of GNOME project forced on KDE is a total myth. (And even if it was: why did KDE accept it?)

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 7:43 UTC (Sun) by JanC_ (guest, #34940) [Link]

> Almost nobody uses the kFreeBSD and Hurd kernels [1],

That's not really relevant or important.

The reason why some people want to keep them in Debian is that the fact that they are there helps to keep the possibility open (or at least make it easier) to add other kernels to Debian in the future. Probably kernels that don't even exist yet now.

Positions forming in the Debian init system discussion

Posted Jan 9, 2014 5:45 UTC (Thu) by torquay (guest, #92428) [Link]

    That's not really relevant or important.

I beg to differ. It is directly relevant. If kFreeBSD doesn't provide the necessary features now, who is going to write another kernel from scratch which will provide the features in the future? The Hurd kernel has been around for a long while, and yet its development pace is slower than the proverbial snail. And if more choice is good, why not modify Debian to allow the option of using the ReactOS kernel?

By leaving all the options open, all the manpower and effort will be put into maintaining the resultant mess, instead of being directed towards something more useful.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 6:15 UTC (Tue) by johannbg (subscriber, #65743) [Link]

If they choose the path of upstart ( forking all the bits and supporting them ) or the path of many init system both will result in added load to maintainers and service sub community ( QA/Triaging etc) in Debian which is a pretty heavy price to pay for "choice" alone in my books vs systemd where you can share units, documentations as well reduce the learning curve for users among systemd only distributions in the process.

We that are doing systemd distribution integration work have also been collaborating and sharing experience and knowledge among ourselves how the migration process is and has taken place as well we have been collectively sharing units across distributions Arch,Fedora,Gentoo,OpenSuse,Mageia etc and try to ensure they are upstreamed from day one.( there is also always room for more/better collaboration )

We also are trying to eliminated that pointless difference among our distributions so that those units can be better integrate and I think I can speak for everyone that has been involved in systemd distribution integration efforts that we would extend that collaboration effort to Debian community. I also think that unit files should exist for ca 70% of the total service/daemon base which probably makes it easier to migrate to the upstart.

Readers here can speculate why that collective collaboration effort among distribution did not happened with upstart and why the integration of kFreeBSD and Hurd with upstart has not already taken place or even if it will take place et all if it became the default init system.

How much is Canonical actually delivering back to Debian or Upstream for that matter? ( which in turn should shed light how much weight they hold in community wide decisions )

Now regarding Lennart, Kay and any other RH employee that currently is working on systemd and I have met thus far ( which I think is everybody ) ,I can say without a doubt that there is no corporate agenda taking place in systemd and being one of the more vocal individual against RH community mistreatment in the Fedora community and the person that stepped down from the ServerWG due to such things taking place, I can say without a shadow of doubt I'll vouch for them, their integrity, any place,anywhere, any day of the week, their all good people with good intention, with their heart in the right place and thinking about the GNU/Linux ecosystem in whole as well as the systemd community itself.

If RH was interfering or dictating anything ( networkd being the most recent sample that contradicts such things taking place in systemd by RH ) I would not be surprised if they simply walk away from the company.

In relation to this whole RH/NSA/Selinux/backdoor fud taking place here in the comment section , people need to realize as more of the plumbing layer gets closer to wholeness so will the multiple effects of collective collaboration and contribution take place ( since everybody would be focusing on a single stack instead of 10 100 or thousand ) with an end result which is far greater and securer for everybody in the GNU/Linux ecosystem and the only effective means we can start defending ourselves against NSA and other spy agency out there which cannot be achieve with endless fragmentation in that layer. ( more choices == more ways in )

Positions forming in the Debian init system discussion

Posted Jan 5, 2014 17:39 UTC (Sun) by marcH (subscriber, #57642) [Link]

> more choices == more ways in

Errr... not that simple. "more ways in", yes; but affecting less people.

Some level of competition is good; not just for security ("how much" has been argued here countless times already)

This is so sad.

Posted Dec 31, 2013 14:44 UTC (Tue) by exadon (subscriber, #5324) [Link]

I'm just a lurker who has been using Linux for 20 years (1.1.50, Slackware), but this kind of fighting makes me lose faith.

Redhat: We have the technically superior solution, and we don't care what others say.

Canonical: Redhat has the technically superior solution, but they are hostile, so we can't trust them and better do our own thing. We have the money.

Google: Redhat has the technically superior solution but they are using the license as a weapon, so we better do our own thing. We have the money.

Debian: Redhat has the technically superior solution, but using it would alienate our friends.

Microsoft: Nice show. No need to spread any more FUD about Linux, they take care of this themselves.

This is so sad.

Posted Dec 31, 2013 15:36 UTC (Tue) by luya (subscriber, #50741) [Link]

Systemd is a freedesktop.org community project while upstart is strictly Canonical. It would be nice to properly do a reseach before posting. Attacking Red Hat for the project the company haven't even hosted tells more about the reader.

This is so sad.

Posted Dec 31, 2013 16:26 UTC (Tue) by xnox (subscriber, #63320) [Link]

Huh?

Canonical: launchd has bad license, let's make upstart.

Google: upstart is cool, let's use that for ChromeOS

Redhat: upstart is cool, let's use it. (unknown internal arguments) we use systemd.

Debian: let's use upstart? (years ago) we need support for ports...

Is much closer to historic reality and funnier version of the comic =)))))

(unknown internal arguments)

Posted Dec 31, 2013 20:09 UTC (Tue) by Wol (guest, #4433) [Link]

May I suggest you read Systemd's history. Upstart did not do what was needed (as various other posts here have pointed out).

And Lennart has a history of "doing things right" - he decided Upstart couldn't be fixed (or maybe rather its design decisions couldn't be fixed) so he started again.

And while people curse his blunt teutonic way of doing things, the fact is *MOST* free/open software projects are pretty tyrannical in their structure, and Lennart has a following of people who trust him, so when he designed systemd it successfully took off.

Cheers,
Wol

This is so sad.

Posted Dec 31, 2013 20:29 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

" Canonical: launchd has bad license, let's make upstart."

What does upstart have to do with launchd license? systemd has a model similar to launchd. Your historic reality sounds like revisionism.

http://0pointer.de/blog/projects/systemd.html

"But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on MacOS the listening of the sockets is pulled out of all daemons and done by launchd. The services themselves hence can all start up in parallel and dependencies need not to be configured for them."

This is so sad.

Posted Jan 3, 2014 12:56 UTC (Fri) by sorpigal (subscriber, #36106) [Link]

The original upstart spec included a justification for not simply adopting launchd reasons for which included that its license was not palatable. I imagine this is what was being referenced. It's possible that if launchd had had a friendlier license upstart would never have existed, so yes they are related.

The vote isn't over yet

Posted Dec 31, 2013 18:11 UTC (Tue) by HelloWorld (guest, #56129) [Link]

The CTTE might yet come to the right conclusion. Of course it would be rather catastrophic for Debian and especially for the linux ecosystem as a whole if they didn't for the reason that you mentioned. But it hasn't come this far yet.

The vote isn't over yet

Posted Dec 31, 2013 18:21 UTC (Tue) by jubal (subscriber, #67202) [Link]

uh-uh, the end of the world is nigh. Calm down, man, whatever happens, the systems won't stop booting.

The vote isn't over yet

Posted Dec 31, 2013 19:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

The end of Debian, not world. And yeah, it's nigh.

The vote isn't over yet

Posted Jan 1, 2014 13:13 UTC (Wed) by jubal (subscriber, #67202) [Link]

Oh dear. Oh dear. Who could've thought.

The vote isn't over yet

Posted Jan 5, 2014 23:04 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> Calm down, man, whatever happens, the systems won't stop booting.
Oh, I assure you Debian won't be booting on my machines if they get this wrong.

The vote isn't over yet

Posted Jan 6, 2014 12:45 UTC (Mon) by jubal (subscriber, #67202) [Link]

It would have more impact, have you mentioned that you stomped your both feet, I guess.

The vote isn't over yet

Posted Jan 6, 2014 23:36 UTC (Mon) by HelloWorld (guest, #56129) [Link]

So you're saying that Debian shouldn't care what its users want and do?

The vote isn't over yet

Posted Jan 7, 2014 11:02 UTC (Tue) by jezuch (subscriber, #52988) [Link]

> So you're saying that Debian shouldn't care what its users want and do?

Which users? It's you against the users of Debian/kfreebsd. They are users too, you know. So you're saying that Debian shouldn't care what its users want and do?

(Disclosure: I'm a Debian user and I'm in favor of systemd. But your position is... dishonest.)

The vote isn't over yet

Posted Jan 7, 2014 17:06 UTC (Tue) by smurf (subscriber, #17840) [Link]

… except that the number of Debian/non-Linux users is … somewhat low … compared to those of /Linux.

The vote isn't over yet

Posted Jan 7, 2014 12:58 UTC (Tue) by jubal (subscriber, #67202) [Link]

What I am saying (in a rather unpleasant way, I agree) is that no matter which way the decision goes, Debian will end with a solution that's technically superior to the status quo.

Personally, I prefer upstart – but I won't scratch my disk drives with a bastard file if the tech-ctte decides to choose systemd.

The vote isn't over yet

Posted Jan 7, 2014 16:33 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> I won't scratch my disk drives with a bastard file

Is this a saying from somewhere? I'm not familiar with the idiom (if it is one); I can guess the connotation, but if there's some subtext… :) .

The vote isn't over yet

Posted Jan 7, 2014 18:01 UTC (Tue) by dlang (subscriber, #313) [Link]

The vote isn't over yet

Posted Jan 7, 2014 17:28 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> What I am saying (in a rather unpleasant way, I agree) is that no matter which way the decision goes, Debian will end with a solution that's technically superior to the status quo.
I just read a nice quote from some blog[1]: “improving on ‘terrible’ doesn’t necessarily mean the result is anywhere near ‘good’”.

[1] http://grundlefleck.github.io/2013/06/23/using-scala-will...

The vote isn't over yet

Posted Jan 8, 2014 15:59 UTC (Wed) by hummassa (subscriber, #307) [Link]

In your reference, what would be "terrible"?

The vote isn't over yet

Posted Jan 8, 2014 18:17 UTC (Wed) by HelloWorld (guest, #56129) [Link]

sysvinit is terrible, obviously.

The vote isn't over yet

Posted Jan 9, 2014 1:31 UTC (Thu) by The_Barbarian (subscriber, #48152) [Link]

I use Debian/Linux, and I currently have no plans to use hurd or kfreebsd. But I am against systemd due to hostility to portability (though I acknowledge that other than that it is clearly superior). I wish it was otherwise.

The vote isn't over yet

Posted Jan 9, 2014 3:23 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

All things being equal, portable code is indeed better but I don't really see much of a problem here. Characterizing systemd as hostile to portability seems off the mark to me since they are just being honest about the status. systemd is fairly low level and no other operating system is going to adopt it. It takes advantage of a ton of Linux specific features and porting in this case either means reimplementing it with the same interfaces or implementing the specific features that Linux has that other kernels lack.

The vote isn't over yet

Posted Jan 9, 2014 4:14 UTC (Thu) by The_Barbarian (subscriber, #48152) [Link]

>systemd is fairly low level and no other operating system is going to adopt it.

That may well be, if so, that is exactly why it should not be used for Debian. I have no objection to other distros using it.

The vote isn't over yet

Posted Jan 9, 2014 4:26 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

If that is your objection, what are you recommending for Debian? None of the other leading contenders are going to be adopted for anything else either. They might make a port available but other operating systems aren't going to use it by default. They all have their own systems.

The vote isn't over yet

Posted Jan 3, 2014 23:31 UTC (Fri) by dag- (subscriber, #30207) [Link]

At this point I really would like to see Debian just pick something other than systemd. Just to see how it would play out and what predictions would hold true.

As the decision won't impact me, I don't have any strong opinions on what Debian should be doing. However I hope it comes to a conclusion soon.

PS Why wasn't a "portable systemd" project never considered, much like the "portable openssh" project ? The situation seems quite similar, upstream's use-case vs portability.

The vote isn't over yet

Posted Jan 4, 2014 2:04 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> At this point I really would like to see Debian just pick something other than systemd. Just to see how it would play out and what predictions would hold true.
Yeah, it also would be interesting to do this with the nuclear war.

> PS Why wasn't a "portable systemd" project never considered, much like the "portable openssh" project ? The situation seems quite similar, upstream's use-case vs portability.
Systemd depends on a large number of Linux-specific functionality that simply doesn't exist on other systems.

The vote isn't over yet

Posted Jan 4, 2014 2:33 UTC (Sat) by dag- (subscriber, #30207) [Link]

> Yeah, it also would be interesting to do this with the nuclear war.

You're quite the pessimist :-)

The difference being that Debian wouldn't be destroyed by keeping the existing (or a better) init system, it may merely impact its pace and/or uptake. We don't know in what way, which makes it more interesting. Would a decision impact the userbase ? Would there be a large outcry ? A schism ? Would it increase ties with Ubuntu, alienate Debian derivatives ?

But I can say this because it won't impact me, unlike a nuclear war.

The vote isn't over yet

Posted Jan 4, 2014 12:55 UTC (Sat) by hummassa (subscriber, #307) [Link]

> Systemd depends on a large number of Linux-specific functionality that simply doesn't exist on other systems.

well, actually... ;)

there is no reason at all why the "linux-specific functionality" (not That large after all) couldn't be implemented in the other systems (IIRC someone is implementing cgroupfs for the Hurd, how hard can it be to implement it over FreeBSD?)

The vote isn't over yet

Posted Jan 4, 2014 13:32 UTC (Sat) by anselm (subscriber, #2796) [Link]

It's probably less of a technical problem than a social one; you would have to get it past the actual FreeBSD developers, who historically have been less than enthusiastic about taking on board stuff that originates from Linux.

The vote isn't over yet

Posted Jan 4, 2014 14:54 UTC (Sat) by hummassa (subscriber, #307) [Link]

Considering its purpose would be "to run Debian GNU/kFreeBSD", the patch/module to kFreeBSD could be maintained by Debian if upstream refused it...

The vote isn't over yet

Posted Jan 4, 2014 15:21 UTC (Sat) by anselm (subscriber, #2796) [Link]

That would also conveniently put the work where it belongs, namely onto the Debian GNU/kFreeBSD maintainers, who could then be scratching their own itch instead of forcing the rest of the project to scratch it for them by disconnecting Debian from where the rest of Linux seems to be going.

The vote isn't over yet

Posted Jan 6, 2014 7:10 UTC (Mon) by josh (subscriber, #17465) [Link]

> PS Why wasn't a "portable systemd" project never considered, much like the "portable openssh" project ? The situation seems quite similar, upstream's use-case vs portability.

Because the Portable OpenSSH project ports OpenSSH from OpenBSD to more popular target platforms, and OpenSSH doesn't use much in the way of OpenBSD-specific functionality to begin with. (In fact, arguably Portable OpenSSH uses more Linux-specific functionality than OpenSSH uses OpenBSD-specific functionality; notably, Portable OpenSSH can use seccomp.)

systemd already runs on Linux, uses quite a lot more Linux-specific functionality in ways that are not easily removed (since they're used to implement critical bits of functionality), and the combination of interest and resources just doesn't seem likely to exist to port it to less popular UNIXes.

If someone wanted to port systemd, a separate "Portable systemd" project would be the way to do it, though that project should start by trying to add the necessary features from Linux to the target platform rather than trying to hack systemd to remove the use of those features.

Positions forming in the Debian init system discussion

Posted Dec 31, 2013 15:48 UTC (Tue) by shruggy (subscriber, #94695) [Link]

It seems as nobody still posted the link to the Colin's position, so I'll do it:
http://lists.debian.org/debian-ctte/2013/12/msg00296.html

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 16:27 UTC (Wed) by Del- (guest, #72641) [Link]

Thanks for the link. At this point in time it seems clear that the only arguments against systemd that holds any water is portability. I hope Colin, Steve and Ian shows the ability to take in new knowledge and make the right decision. Being a devoted Debian and Ubuntu user for over a decade, it really does mean a lot to me. It does not make sense to pick a significantly inferior solution based on a portability argument, and yes, I do believe that practically everybody sees systemd as the superior solution from a technical point of view. Please, Colin, Steve and Ian, do the right thing.

Positions forming in the Debian init system discussion

Posted Jan 1, 2014 23:37 UTC (Wed) by juliank (subscriber, #45896) [Link]

Well, it seems like he prefers upstart only because he knows it better. So he is biased, and should not vote in favour of either option.

Bdale Garbee made up his mind

Posted Jan 2, 2014 19:49 UTC (Thu) by HelloWorld (guest, #56129) [Link]

https://lists.debian.org/debian-ctte/2014/01/msg00067.html

Quote:
> So, to summarize, I think systemd should be our choice for a new default
> init system for Debian GNU/Linux. Where I think we still need to focus
> attention is on how to manage the transition, and how to make *any* new
> init system default for Linux palatable for Debian's non-Linux ports.

Positions forming in the Debian init system discussion

Posted Jan 9, 2014 9:52 UTC (Thu) by oldtomas (guest, #72579) [Link]

After having witnessed (with some disbelief and some horror) this thread, I'm more convinced than ever that I don't want systemd near any of my computers.

Why, you ask?

The attitude of its more vocal proponents.

Positions forming in the Debian init system discussion

Posted Jan 9, 2014 10:31 UTC (Thu) by anselm (subscriber, #2796) [Link]

What about the attitude of its more vocal detractors?

Positions forming in the Debian init system discussion

Posted Jan 10, 2014 0:28 UTC (Fri) by Wol (guest, #4433) [Link]

:-)

WHAT vocal proponents?

All I can see in this thread is people pointing out the FACT that systemd takes advantage of all the facilities provided by linux - which is true!

As a result, it is clearly the best init system currently available on linux. But - as an equally obvious result - it will be a pig to implement *well* on any other kernel.

(Although I have seen a few comments where people have objected to systemd being mis-characterised. But what's wrong about objecting to misleading / false claims?)

Cheers,
Wol

Positions forming in the Debian init system discussion

Posted Jan 10, 2014 15:26 UTC (Fri) by raven667 (subscriber, #5198) [Link]

My take on it is that the behavior that is deemed most objectionable by systemd proponents is the lack of humility and the persistent characterization of systemd as superior, some people would prefer an apology or contrition and are skeptical of confidence.

Positions forming in the Debian init system discussion

Posted Jan 10, 2014 16:14 UTC (Fri) by anselm (subscriber, #2796) [Link]

One issue is that Lennart Poettering does not appear to suffer fools gladly. This is a trait that he shares with various other prominent people in our community – including, for example, Linus Torvalds – but also one which, for whatever reason, people are less forgiving of in his case than they are elsewhere, so they tend to be just as obnoxious in return. This does nothing to advance the level of the discussion on both sides.

So far in the Linux community there has been no need to »apologise« or show »contrition« for technical excellence. If systemd is persistently characterised as »superior« this may well be because by most criteria, as an init system for Linux it actually is superior to the alternatives, and by a fairly wide margin. In fact we do not need Lennart Poettering to tell us this (and frankly, what would you expect him to say?) if we have independent assessments such as that of Russ Allbery in the article at the root of this discussion. Well-founded opinions like Russ's are especially important given that many of the people who are very vocally against systemd do not actually appear to have looked at the issue in any kind of detail, and that shows in the type and quality of counterargument one tends to encounter.

Positions forming in the Debian init system discussion

Posted Jan 10, 2014 19:31 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

That may well be but the results are pretty amusing

http://mirror.linux.org.au/pub/linux.conf.au/2014/Monday/...

Positions forming in the Debian init system discussion

Posted Jan 13, 2014 8:37 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> behavior that is deemed most objectionable by systemd proponents is the lack of humility and the persistent characterization of systemd as superior

I think that's called "confidence in one's work". Frankly, characterizing this as "objectionable" is laughable.

Positions forming in the Debian init system discussion

Posted Jan 13, 2014 8:44 UTC (Mon) by anselm (subscriber, #2796) [Link]

This looks like the time-honoured recipe of »if you can't attack the work, attack the author«. Lennart Poettering could say that the sky is blue and the sun comes up in the morning and there would be people claiming the contrary as a matter of principle.

Positions forming in the Debian init system discussion

Posted Jan 13, 2014 9:56 UTC (Mon) by smurf (subscriber, #17840) [Link]

Well, Lennart did voice his opinion in language which can't in good conscience be described as "polite".

However: (a) systemd is not just Lennart's work, some major ideas (and code) are from other people, (b) this perception is from the early days of pulseaudio and, in all fairness, those days are long gone.

Of course, if somebody has a history of arrogant comments, pretty much anything they say will be perceived as more of the same even though the same comments would be regarded as perfectly harmless if voiced by somebody else.

To me, the attitude of the upstart proponents as I perceive it of "we can do everything systemd can do, it's just a Small Matter Of Programming … which we haven't done yet and don't have plans to do either, esp. since we have no idea how much work it'd actually be, but you STILL should choose our model" is far more grating.

Positions forming in the Debian init system discussion

Posted Jan 9, 2014 15:16 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> After having witnessed (with some disbelief and some horror) this thread, I'm more convinced than ever that I don't want systemd near any of my computers. Why, you ask? The attitude of its more vocal proponents.

Why, do processes start with the wrong color if they are exec'd by systemd? Will the attitude of some person on LWN who you disagree with cause RAM failure?

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 7:44 UTC (Thu) by oldtomas (guest, #72579) [Link]

> [Wol] it is clearly the best init system currently available on linux

> [raven667] some people would prefer an apology or contrition and are skeptical of confidence.

> [anselm] Lennart Poettering does not appear to suffer fools gladly

> [jezuch] "confidence in one's work" [...] characterizing this as "objectionable" is laughable

> [anselm] if you can't attack the work, attack the author

And so on and so forth. In a nutshell "if you don't share our opinion, you're an idiot, because We Are Right (TM)"

Thanks for making my point even more clearly that I could ever have made it.

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 8:33 UTC (Thu) by smurf (subscriber, #17840) [Link]

Which point would that be? This discussion is split about some minor advantages of using upstart, some major features of systemd which upstart doesn't have and won't get any time soon, and some non-technical problems which some upstart proponents have with systemd and/or one of its main authors.

One can only respond calmly to the latter sort of 'argument' a finite number of times before losing one's patience. That is not the problem, that's basic human nature.

The grandstanding of some upstart proponents on a "The systemd repository is taking over Linux! Run away!" platform is the problem. (I know you don't see it that way. But I do.)

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 16:18 UTC (Thu) by oldtomas (guest, #72579) [Link]

> Which point would that be?

That (for me, at least) there are several criteria beyond technical on which to decide which software I use and associate with. That while systemd has a couple of nifty ideas -- (x)inetd could rip off some of that socket association thing; yes, the PID file stuff was clumsy in SysV init from the very beginning (remember: BSDinit had it already right then). CGroups, DBus -- meh, for me (the CGroup thing becoming negative with the last developments in the kernel front). The mixing of lots of policy into a bunch of binary: negative.

But: as long as the community around systemd behaves the way it does, I won't touch it with a ten foot pole. That's the deal breaker for me.

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 17:08 UTC (Thu) by cortana (subscriber, #24596) [Link]

yes, the PID file stuff was clumsy in SysV init from the very beginning (remember: BSDinit had it already right then)

The process described in FreeBSD's init(8) sounds almost identical to Linux's sysvinit scheme (/etc/ttys : /etc/inittab and /etc/rc.d : /etc/rc?.d). Is this what you mean, or are you talking about something else?

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 17:42 UTC (Thu) by oldtomas (guest, #72579) [Link]

> The process described in FreeBSD's init(8) sounds almost identical to Linux's sysvinit scheme (/etc/ttys : /etc/inittab and /etc/rc.d : /etc/rc?.d). Is this what you mean, or are you talking about something else?

Yes and no. I was talking about this (cf. your reference):

> The init utility can also be used to keep arbitrary daemons running,
> automatically restarting them if they die. In this case, the first field
> in the ttys(5) file must not reference the path to a configured device
> node and will be passed to the daemon as the final argument on its com-
> mand line. This is similar to the facility offered in the AT&T System V
> UNIX /etc/inittab.

Of course, one could use inittab for daemons under Linux too, but the point is that it was customary in the mid-90's to shepherd system daemons this way, thus potentially controlling their run status and their stdin/stdout/stderr and reacting to their termination via signals.

This would have been a nice evolution path towards something interesting (and those are the things systemd gets right, IMHO)

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 18:24 UTC (Thu) by anselm (subscriber, #2796) [Link]

Of course, one could use inittab for daemons under Linux too, but the point is that it was customary in the mid-90's to shepherd system daemons this way, thus potentially controlling their run status and their stdin/stdout/stderr and reacting to their termination via signals.

The most obvious problems with this are that starting daemons via /etc/inittab doesn't give you service ordering even in the clumsy way SysV init does (so no making sure Apache only starts when syslogd and MySQL are already running), and that there is no provision on the part of init for actually dealing usefully with a daemon's stdin/stdout/stderr, which Unix-style daemons customarily close when they start, anyway (and that convention is older than the mid-90s). There's a reason why SysV init works like it does.

This of course completely disregards the fact that systemd does many other useful things even when it is simply starting service processes based on a »runlevel-like« target (leaving aside obvious nifty things like socket activation). All of this would have to be retrofitted into the SysV init infrastructure and would only make that more convoluted and non-standard.

Positions forming in the Debian init system discussion

Posted Jan 17, 2014 10:34 UTC (Fri) by oldtomas (guest, #72579) [Link]

> The most obvious problems with this are that starting daemons via /etc/inittab doesn't give you service ordering even in the clumsy way SysV init does [...]

Yep. That's why I talked about the mid-90ies (no, I wasn't trying to show off what an old fart I am ;-) and hand-waved about evolution path. I do know that when I first saw this SysV bunch-of-scripts I thought "oh, my! what happened to respawn?" (there were other thoughts about those brutal shell epics in HP/UX, but I disgress).

Anyway, this has taken us astray from the original intention of my post, and that was that beyond "technical excellence", which is, of itself not a well-defined thing anyway, there are other factors *for me* on which to judge whether I want to use/take part in some software. And systemd and its "environment" fail on those other accounts so much (I repeat: *for me*, probably not for you) that I refuse to even have a deeper look at it.

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 19:44 UTC (Thu) by smurf (subscriber, #17840) [Link]

> as long as the community around systemd behaves the way it does

Sorry, but I don't see a problem here. All I see are people who know what they're doing, whose software _works_, and has a ton of features certain other software does not have. In my book, that gives them some leniency in the "how much arrogance willl I put up with" department -- of which I don't see all that much in the first place.

I _have_ worked with people (and/or their software) who were so sure of themselves that there was absolutely no way to convince them to change a single bit in their source code.

The authors of systemd are not members of that set.

IMHO.

Positions forming in the Debian init system discussion

Posted Jan 16, 2014 8:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

The only problem is that they _are_ right.

I was initially against systemd, but then I actually tried to use it... It is really a brilliant piece of software.


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds