SoylentNews is people
SoylentNews
The Debian project has suffered from a long string of negative events recently, ranging from severe discontent over the inclusion of systemd, to talk of forking the project, to a grave bug affecting the important 'wine' package, to the resignation and reduced involvement of long time contributors.
The latest strife affecting Debian revolves around a request for a Debian package of the GPC-Slots 2 software. This request has been rejected with little more than an ad hominem attack against the software's author.
In response to the request, Stephen Gran wrote,
This is code by someone who routinely trolls Debian. I doubt we want any more poisonous upstreams in Debian, so I at least would prefer this never get packaged.
Jonathan Wiltshire proceeded to mark the request as 'wontfix', and closed it.
While Debian does strive to maintain high standards regarding the software it packages, the negative and personal nature of this rejection, without any apparent technical or licensing concerns, appears to conflict with Debian's own Code of Conduct. Such a personal attack could be seen as contradictory to the Code of Conduct's mandate that Debian participants "Be respectful", "Be collaborative", and most importantly, "Assume good faith".
Given its recent troubles as of late, many of them concerning the poor treatment of Debian developers and users alike, can Debian really afford to get embroiled in yet another negative incident?
(Score: 4, Interesting) by rleigh on Sunday November 23 2014, @11:56PM
It's unbelievable even for many Debian developers such as myself. However, as I'm sure you're aware of if you've been reading the mailing lists and news sites I think it's fair to say that it's essentially impossible to have any constructive discussion on the issue. Back when this started to be pushed, maybe three years or so back I did bring up the downsides, as did others. It doesn't bring me any pleasure to have been right about many of these things. But I stopped participating in the discussion about 18 months back, and ended unsubscribing from the lists about 9 months back. There's only so much of this you can take before your motivation is completely sapped, and when the discussion is entirely unproductive it's not like your contribution to the discussion will result in any positive change.
The ironic part is that if systemd had stuck to just simply replacing init, and integrating well with existing systems rather than trying to take over the world, it wouldn't have been controversial at all. After all, it's quite clear that while sysvinit is venerable and well tested, it isn't perfect and there are improvements to be made. For example, initscripts could have been replaced with openrc; start-stop-daemon could have got cgroups support. These could have all been done with zero impact; we already transitioned to dependency-based parallelised initscripts without too much trouble. If systemd had replaced this and no more, it would have been just fine.
The "failing to boot" bugs are IMO the absolute worst part. Any failure to boot should be a critical bug, and previously would have been a critical bug. Now the systemd people and their associated fans argue that failing to boot when an fstab entry can't be mounted is in fact not only desirable but essential, to prevent the system running without the configuration being "correct". Maybe from a certain perfectionist standpoint that's OK. But in the real world most people I suspect would rather their system booted successfully with a warning rather than not booting at all. It's not perfect, but then the world isn't a perfect place and doing the best you can in the fact of non-ideal conditions might be in fact preferable. Even this can't be discussed rationally; I've been told that not failing hard is unconditionally wrong, but what's so awful about different people having different perspectives and priorities? While the initscripts might have provided certain default policies we never dictated such fundamental stuff; if you wanted to do things differently, go right ahead and do so with our blessing, and the number of tweakable defaults shows how accommodating maintainers were to differing requirements. Another bad failure is when the system fails to start because it gets stuck, due to the massively overcomplicated dependencies and/or races and bugs. In the old world, insserv/startpar would order things according to the LSB headers. But if the metadata was inconsistent it would tell you before adjusting things, and if it was wrong at boot time at worst you'd have some services fail to start, but it would still attempt to start as much as possible. The system would still boot and bring itself up to a usable state unless things were seriously wrong in rcS. But we always tested those prior to every upload (I personally would test in a VM in various configurations, then on amd64 bare metal and on powerpc bare metal, and also on kFreeBSD).
Regards,
Roger
(Score: 2) by Nerdfest on Monday November 24 2014, @03:52AM
It's sad. I think we may very well be seeing the end of Linux as a viable OS. I really can't help thinking there's external elements trying to kill it.