Positions forming in the Debian init system discussion

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.

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.

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.

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?

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

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.

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

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.

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

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.

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.

http://www.reference.com/motif/reference/why-is-it-called...

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.