Maintainerless Debian?
Maintainerless Debian?
Posted Dec 8, 2016 12:30 UTC (Thu) by mgb (guest, #3226)In reply to: Maintainerless Debian? by farnz
Parent article: Maintainerless Debian?
For-profit Redhat has chosen a path. Groupthink Debian has copied it. Devuan and others have chosen a different path.
It was unfortunate that the universal operating system threw away working solutions for one path but Devuan has rebuilt what was lost, just as TDE rebuilt a KDE3 path after it was forced out of Debian.
Posted Dec 8, 2016 12:58 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (28 responses)
So far Debian hasn't thrown SysV init away (it is still supported in Jessie, it's just no longer the default). Obviously, the Debian project can't force Debian maintainers to tie themselves in knots in order to fix problems in SysV init scripts. This doesn't mean that they can't do it out of general altruism if they want to, or that third parties aren't allowed to contribute patches to fix issues that they have found with a package's SysV init support. Incidentally, this is another argument in favour of group maintainership; if the original maintainer of a package in Debian doesn't care for SysV init support, they could take on board someone who keeps just that aspect of the package on track. Since all the pertinent packages already come with SysV support for legacy reasons, that shouldn't be a huge task.
IOW, the people who insist on SysV init get to scratch their own itches rather than have them scratched by others, and it would be perfectly possible to do that under the auspices of Debian. If they prefer to fork the distribution instead then that is of course their privilege, but doing it within Debian would probably be a lot less work.
Posted Dec 8, 2016 19:05 UTC (Thu)
by mgb (guest, #3226)
[Link] (27 responses)
The Devuan devs have generously provided a solution to this problem, while software developers and Debian packagers continue to supply solutions to many other problems.
You are not prohibited from using either path, nor are you forced to use either path. Why does Devuan concern you?
Posted Dec 8, 2016 19:08 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (24 responses)
Because it's a bug in Debian, per current policy, if sysvinit does not work in Debian Jessie. Right now, Debian claims that this is a supported configuration - if that's false, Debian should find out sooner rather than later so that it can either fix its bugs, or declare this configuration unsupported (thus pushing people who want sysvinit and Debian onto Devuan).
Posted Dec 9, 2016 16:39 UTC (Fri)
by zlynx (guest, #2285)
[Link] (23 responses)
Personally I think they're crazy, but eh.
Posted Dec 9, 2016 18:45 UTC (Fri)
by mgb (guest, #3226)
[Link] (20 responses)
Code is for the most part written upstream, not in Debian. Most of that code runs in many different operating systems, not just Linux. The code doesn't need systemd but a small number of Debian devs have aggressively added unnecessary systemd dependencies making the universal operating system much less so.
So a significant fraction of what the Devuan devs have done is simply removing gratuitous systemd dependencies. And the reason that this is important is that when something better than systemd comes along those who want to experiment or adopt the new idea can do so freely. That's F/LOSS.
Posted Dec 9, 2016 18:55 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Dec 9, 2016 19:15 UTC (Fri)
by pizza (subscriber, #46)
[Link] (18 responses)
It seems to me that contributing upstream by writing and maintaining non-systemd code paths would be a far more productive use of everyone's time than the effort of forking an entire distro to merely purge libsystemd.so from one's hard disk. ConsoleKit is a great example of something that has bitrotten into an unusable state.
But hey, far be it for me to tell someone else how to spend their free time. I spend mine reverse-engineering printers, after all.
Posted Dec 9, 2016 19:59 UTC (Fri)
by mgb (guest, #3226)
[Link] (17 responses)
It is a few Debian devs who have added the gratuitous dependencies on systemd.
This is unfortunate for the ex-universal operating system but fortunately the Devuan devs have restored users' ability to try interesting new software whenever it is appears.
Posted Dec 9, 2016 20:23 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
On a system that doesn't actually run systemd, libsystemd does nothing, so having it installed isn't really much of a problem. If upstream includes it, you probably create more potential trouble by ripping it out than you do by leaving it in.
IOW, there is no pressing need to fork a whole distribution simply to get rid of libsystemd, unless you're on a crusade against anything that has “systemd” in its name. But hey, whatever floats your boat.
Posted Dec 9, 2016 21:15 UTC (Fri)
by pizza (subscriber, #46)
[Link] (15 responses)
Again, every single bit of software that truly depends on systemd at runtime (be it through a hard requirement or an optional compile-time feature) was done so by its upstream, not some unnamed Debian developers that you continue to disparage (while at the same time, taking advantage of their hard work).
Posted Dec 9, 2016 22:12 UTC (Fri)
by mgb (guest, #3226)
[Link] (14 responses)
Posted Dec 9, 2016 22:51 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Software in Debian is supposed to work well with systemd, since systemd is the default init system on Debian. This means that a Debian developer will generally add the “--with-systemd” configuration switch (or omit the “--without-systemd” switch) when packaging an upstream package that includes such a switch. A dependency on libsystemd has no severe impact on systems that run other init systems because on such systems, libsystemd does nothing. It certainly does not restrict people's “flexibility and freedom” any more than any other library dependency (like on, say, libreadline) would.
It would be a disservice to Debian's users not to build a Debian package such that it takes advantage of systemd's features on those Debian machines that do run systemd, if the package offers that option. Having said that, I don't think that Debian developers actively add libsystemd support to packages that don't already include such support (optional or not) in the upstream version, such that the Devuan people feel obliged to take that support out again. Do you have any specific examples of such packages?
Posted Dec 10, 2016 1:30 UTC (Sat)
by pizza (subscriber, #46)
[Link] (3 responses)
Thank you for the compliment, but it's not about being clever -- I try to be precise and consistent in my statements. It is also a necessary skill when writing deeply embedded code that Must. Not. Fail.
(And I note that you completely sidestepped what I wrote)
> Systemd is one of a very few pieces of UNIX-ish software which does not run on non-Linux.
Nobody (least of all the systemd authors) has claimed otherwise.
> Converting an optional feature to a hard dependency is trivial but tedious work which the Devuan devs have to reverse in order to remove the unnecessary dependencies.
I'm sorry, who (and to what) are you claiming has done this "trivial but tedious conversion to a hard dependency" that needs must be reversed? Please cite a specific example.
> Devuan devs remove gratuitous dependencies to give users like me more flexibility and freedom and for this I am grateful. I fail to see why a few Debian devs are so intent on removing flexibility and freedom, particularly as it hinders the future evolution of F/LOSS.
You are arguing that adding a feature/option hinders your flexibility and freedom, while removing feature/option adds to your flexibility and freedom. It's an odd position to take, given that it directly contradicts the dictionary definitions of those words.
Posted Dec 10, 2016 2:59 UTC (Sat)
by mgb (guest, #3226)
[Link] (2 responses)
Not so. If one adds the option locked_in_a_small_box to pizza, pizza's flexibility and freedom is limited. Systemd's broad scope and excessive coupling hinders the development of new and better F/LOSS.
We disagree, but why does it concern you? I was unhappy when Debian started restricting my freedom. Devuan devs have kindly worked around that problem saving me the effort and I am happy again. I believe Devuan provides more flexibility for the future evolution of F/LOSS.
But why do you care about Devuan, whether I am right or wrong? You have Debian. I have Devuan. Is there some reason you need to use systemd in Devuan?
Posted Dec 10, 2016 9:57 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
Wrong. That's only if you *force* the pizza to be locked in a small box. Adding an option never limited anything.
Also, systemd is neither small nor a lock-in. You can always do your own thing, systemd or not.
> Systemd's broad scope and excessive coupling hinders the development of new and better F/LOSS.
That has been demonstrated to be wrong. What hindered the development of new+better, in the past, was the fact that all previous solutions only solved part of the problem, thus switching to them never was attractive enough to actually happen, so most developers didn't bother.
The sole exception to this was Canonical's Upstart, but that had a different set of problems (some technical, some political) which eventually prevented it from getting adopted more widely.
The mere existence of systemd doesn't hinder anything. It just raises the bar. A lot.
> I was unhappy when Debian started restricting my freedom.
You never had the "freedom" to compel a Debian developer to not include a particular feature or to not require a library in their package in the first place.
Posted Dec 10, 2016 10:11 UTC (Sat)
by zdzichu (subscriber, #17118)
[Link]
Posted Dec 10, 2016 1:48 UTC (Sat)
by pizza (subscriber, #46)
[Link] (8 responses)
Oh, I should point out that the 'sysvinit' package is Linux-specific and non-portable. Indeed, each UNIX (and BSD) has its own unique, non-portable init whose implementation is closely tied to its underlying kernel.
(And at a higher level, only the most trivial of "init scripts" were portable to different Linuxes, to say nothing about different UNIX-ish systems)
Posted Dec 11, 2016 16:21 UTC (Sun)
by guillemj (subscriber, #49706)
[Link] (7 responses)
That's not correct. I would know because I've been involved in its porting many years ago. It also did not require many changes to make it build and work on non-Linux systems. In Debian it works on all of GNU/Linux, GNU/kFreeBSD and GNU/Hurd. Also start-stop-daemon (provided by dpkg), which is the foundation most init scripts in Debian are based on, works also on any of the BSDs, Mac OS X, AIX and should work on Solaris and HP-UX too.
Posted Dec 11, 2016 17:35 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
That doesn't detract from the fact that Linux was pretty much the only Unix-like system that actually still used System-V init. Virtually all the other Unixes had come up with their own alternatives to System-V init years earlier
Systemd is actually pretty late to the party, which in a way is an advantage because the systemd developers had the opportunity to look at many of the other systems in order to identify their strengths and weaknesses, and use that information in the design of systemd.
Posted Dec 12, 2016 11:15 UTC (Mon)
by jaromil (guest, #97970)
[Link] (4 responses)
Overall this whole thread is reassuring to read: on the systemd camp are always the same people. Yet I hoped this discussion could stay on topic about the maintainer issue raised by this good article, a topic which concerns very much Devuan well beyond the init diatribe.
What a pity for LWN that these hooligans are always around to sabotage the conversation.
Posted Dec 12, 2016 11:26 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
So as a matter of interest, how many people are actively contributing to Devuan and how do you handle the issue of who maintains which packages? Does Devuan encourage co-maintainership or “maintainerlessness” to a greater degree than Debian does today? What could Debian learn from Devuan as far as organising package maintainership is concerned?
Posted Dec 12, 2016 15:20 UTC (Mon)
by corbet (editor, #1)
[Link] (1 responses)
I do hope that we can stop rehashing the systemd discussion now?
Posted Dec 12, 2016 15:34 UTC (Mon)
by jaromil (guest, #97970)
[Link]
Posted Dec 12, 2016 16:35 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
> h/t. Cleverly argued. You could have been a lawyer.
do not exactly help keeping a discussion civil and on-topic either, and
> these hooligans
is far less civil in tone, if not meaning, than anything the sytemd proponents have posted here.
Incidentally, nobody has yet even tried to explain why removing libsystemd.so from Devuan helps its cause.
Posted Dec 12, 2016 12:35 UTC (Mon)
by pizza (subscriber, #46)
[Link]
"did not require many changes" rather undermisnes the argument that it is universal. (it uses all sorts of kernel-, libc-, and even compiler-specific bits)
But thanks for the correction.
> Also start-stop-daemon (provided by dpkg), which is the foundation most init scripts in Debian are based on, works also on any of the BSDs, Mac OS X, AIX and should work on Solaris and HP-UX too.
Speaking for AIX, OSX and Solaris specifically (I can't comment on the BSDs or HPUX), start-stop-daemon may technically run but will clash with their native tools (src, launchd and smf, respectively).
Also, even on the pure Linux side of things, start-stop-daemon is only guaranteed to exist (and be remotely up-to-date) on Debian and its derivatives.
Posted Dec 10, 2016 9:13 UTC (Sat)
by farnz (subscriber, #17727)
[Link] (1 responses)
Can we at least try to keep this productive? The question I'm asking is whether there is a bug or other technical reason that prevents people from using Debian Jessie with sysvinit, or whether it's just the well-known dislike of the systemd package name.
If Debian is buggy, and neither works when booted with sysvinit, nor accepts patches to fix it, then there's a very, very clear justification for Devuan. If it's relatively simple to switch a Debian systemd boot to a Debian Linux-specific sysvinit boot, then the justification is less clear.
Posted Dec 10, 2016 13:22 UTC (Sat)
by pizza (subscriber, #46)
[Link]
However, there are specific packages within Debian that effectively require systemd due to *upstream* dependencies. GNOME is the most prominent, as it relies on systemd-logind. That said, there are alternative implementations of the logind API with varying degrees of functionality. I do not know if Debian packages/integrates any of them.
Part of the big bruhaha over Debian switching over to systemd by default is that some folks were (IMO rightly) concerned it would lead to bitrot in non-default paths. However, the way the eventually-rejected GRs were worded, Debian packagers could be forced (as a matter of policy) to maintain and possibly even create code paths for all bundled init systems (including kFreeBSD's) in all packages, even when that meant effectively forking upstream.
Posted Dec 9, 2016 1:07 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (1 responses)
Let me get this straight. You seem to feel that systemd will eventually cause “stagnation”. This is an interesting POV given that in Linux, we have essentially had 30+ years of stagnation on the init-system scene before Upstart and, later, systemd came along (remember that System-V init predates Linux). So you want to avoid possible future stagnation by relying on a piece of software that has been around longer than virtually anything else in Linux and hasn't changed noticeably during that time? Way to go.
Posted Dec 9, 2016 2:04 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
However, this shows that it's still not a good idea to start a (or rather: yet another) discussion about the appropriateness of systemd.
Thus: Please don't.
Maintainerless Debian?
It was unfortunate that the universal operating system threw away working solutions for one path but Devuan has rebuilt what was lost
Maintainerless Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
In another words: "a crusade against libsystemd".
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
h/t. Cleverly argued. You could have been a lawyer.
Why should people care about Debian?
Discounting software that runs on self-contained language runtimes (eg Python, Perl, PHP, NodeJS, or Java) that "run everywhere" their runtime has been ported, the overwhelming majority of the upstream code in Debian does *not* run on non-Linux (okay, non-UNIXish) operating systems.
Systemd is one of a very few pieces of UNIX-ish software which does not run on non-Linux.
Again, every single bit of software that truly depends on systemd at runtime (be it through a hard requirement or an optional compile-time feature) was done so by its upstream, not some unnamed Debian developers that you continue to disparage (while at the same time, taking advantage of their hard work).
Converting an optional feature to a hard dependency is trivial but tedious work which the Devuan devs have to reverse in order to remove the unnecessary dependencies. Devuan devs remove gratuitous dependencies to give users like me more flexibility and freedom and for this I am grateful. I fail to see why a few Debian devs are so intent on removing flexibility and freedom, particularly as it hinders the future evolution of F/LOSS.
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
I hoped this discussion could stay on topic about the maintainer issue raised by this good article, a topic which concerns very much Devuan well beyond the init diatribe.
If you wanted the comment thread to stay on topic, then maybe you shouldn't have posted a top-level comment pitching the Devuan beta? I'm sorry, but the diversion here started at the top.
Hooligans
Hooligans
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Why should people care about Debian?
Maintainerless Debian?
Decades of experience tell us that excessive coupling as in systemd plumbing tends to stagnate a software ecosystem. To us working around systemd is essential to the long-term health of F/LOSS. Debian devs disagree.
Maintainerless Debian?