There was an interesting paper recently that looked at first time contributors to open source projects. They found that their first few patches are way more likely to introduce vulnerabilities when the code base is in C++ compared to Rust. The difference gets smaller the longer the contributor is around but never vanishes.

Maybe the devs are not bad, maybe it's you setting them up for failure?

https://cypherpunks.ca/~iang/p...

Quote from the conclusion ofnthenpaper:

> Namely, while it may still be true that Rust may feel like a more difficult language to learn, in at least some ways, new contributors actually benefit from its adoption, with their first contributions being less than 2% as likely to introduce vulnerabilities as C++,

So you avoid RAII since I gives a false sense of security? It also removes a class of bugs you can have without it.

> If the compiler barks you should be really careful about that unsafe block over there because memory but hey this block over here which results in melted steel when not done in the correct sequence is not marked for safety by the language and therefore does not deserve attention according to the language, what is the implication from a psychology perspective?

It absolutely would bark at "this melts metal when done wrong". Any sane rust dev would make that a unsafe function, so you would need to call that in an unsafe block.

Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?

I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem slow.

I also think that maintainers would not have gone for systemd if they did not think it had benefits for their users. Contrary to what you think maintainers do care for having people use their distribution. The fact that systemd had convinced developers did also factor into the maintainers decisions. So did advantages for the packagers: Getting rid of init scripts was a big part of that. There were lots of factors considered at Debian, check the CTTE discussion you liked to earlier for more.

I do not think it matters whether software depends on an init system. Software depends on other software all the time and will adapt once some better option comes along.

Actually I find it reassuring that things start to depend on systemd: It means that it is reasonably simple to interact with the system and that it provides something worth the effort to talk to it. Never seen that before on Linux.

Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.

How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.

Yes, POSIX is important. But as with any standard it defines the least common denominator. Couple that with the fact that POSIX was not updated in years and you have to address the least common denominator from more that 5 years ago (I think even longer...). That is an eternity in IT. A standard is fine, but it should not stop you from playing to your strength.

Systemd argues that an init system is closely related to the Kernel and should make all the fancy kernel features available to user space. There is enough precedence for this in commercial unix variants by the way: Many come with init systems tailored to their specific strength of their kernels. I do not see that as a bad thing. So far I am not aware of anybody in the BSD camp even wanting to port systemd. At least the FreeBSD developers said they wanted a modern init system, too, but they are going for something that plays to the strength of their own kernel. So why should systemd bother about being portable to OSes that want to come up with their own solution?

That BSDs require some compatibility layer is nothing new, either. There is support for Linux style /proc and IIRC even /sys in some of the BSDs! DBus, polkit and whatnot were ported over to the BSDs, too. So how is systemd any different than those projects? You will need to implement a couple of DBus interfaces and make sure those will do the right thing. Nothing new, nothing special.

There are projects on the BSDs as well, that are non-portable: LibreSSL and openSSH from openBSD spring to mind here. Those use interfaces from the BSD kernel. There a separate porting projects that bring those code bases over to Linux. They actually introduced a new kernel API due to libreSSL into the Linux kernel.

I see nothing bad in targetting specific platforms whatsoever. Yes, I do think POSIX is important: If you can do something with POSIX, then use that. If not, then use something else. And when in doubt target one platform and let people that care for other platforms port the stuff if they care.

It was not possible with consolekit, great that there was progress with consolekit2.

There is no way to refute conspiration theorists. It is a self-contained believe system, that functions outside of the real world. I won't bother to argue with that.

What got vdev/udev to do with running xorg as non-root? Yes, that does initial setup of device nodes, but all the rest is handled by systemd-logind.

You are brandishing the wing stick:-)

That person is bitching that everybody and their dog start to depends on systemd. That is your evidence right there.

Of course you have to do the dating assumption that devs do whatever they like... It kind of crumples if you assume that there are systemd hitmen traveling the world, forcing developers to depend on systemd.

That consultation mongering in that link is indeed laughable.

The absense of CVEs can mean the absense of people looking, and with the x11 being a quagmire of protocols, often contradicting each other as new stuff gets added over the decades, there are very few people that can even understand the code. One guy started to look last a while back and he is finding appalling bugs, check the recent CVEs and his presentation at last years chaos communication congress (30C3).

Making this swamp a bit dryer by not having it have root priviledgea is something that was work in progress ever since xfree started to run on Linux.

Now you come here and tell me that this sour spot for the last thirty years is better to keep around than having a much smaller, much cleaner codebase where almost all parts run in their own security context -- usually with privileges way lower than those you have as a user. Right.

Mid term devuan has just one chance: Make it easy for developers to provide solutions that work with multiple int systems. Systemd does bring quite a few improvements for developers. That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.

If devuan wants to keep a manageable distribution they need to make it similarly easy to tackle issues in a convenient and reliable way when using multiple init systems. If they manage that, then I am pretty sure developers will support their interfaces in favor of systemd. No developer wants needless ties.

Unfortunately it is much harder to provide generic solutions than it is to provide a specific one. So devuan is in a very challenging position to make things easier for developers.

Is they blow this, then they will have more and more software that depends on systemd-only interfaces and more and more work to remove those dependencies.