DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Before I address your specific points, I should point out that the people who wrote the documents you quoted do not speak English natively. Some subtleties may have been lost in translation. I should also point out that this post reflects only my views. I'm not a member of the VUA--I don't speak for them.
Quote:
Quote:
and to avoid any lock-in in the most important parts of the systems by avoiding things that are trying to hijack the GNU part of the system, like systemd is doing right now in many distros and also in our lovely debian.
Quote:
preserving users and sysadmins to be forced to abandon the GNU, KISS and UNIX philosophy and losing control,
and I have to ask, which part of systemd do you perceive is taking away something from GNU and which part of GNU is taken away?
The ideas behind these specific points are that in large-scale Free Software projects, Freedom 0 begins to take on an additional meaning for us. The freedom to run programs as you wish for any purpose becomes conditioned on how open the surrounding ecosystem and developer community is towards interoperating with those programs and their use-cases. For example, Linux and the kernel community go to great lengths to preserve compatibility with userspace. In doing so, they preserve the user's freedom to run a wide variety of software on top of it for a wide variety of purposes. Contrast this to a hypothetical world where the kernel API changed frequently--in this scenario, Freedom 0 is reduced, since continuous compatibility breakage would limit the selection and usability of software to only those that were compatible with the latest changes.
Devuan strives to be a distro that maximizes Freedom 0 for as many users as possible, under this interpretation of it. It does so by making interoperability a first-class design goal. Devuan strives to help users run whatever combination of programs they want, without forcing them to become full-time developers and packagers to do so. The means doing things like keeping cross-component dependencies and baked-in policies to a minimum, and developing software designed with interoperability in mind. While this often gets reduced to adhering to the UNIX philosophy, it's important to emphasize that the intent of doing so is to preserve Freedom 0 for users.
Some might argue that making the source code available under the GPL is sufficient to preserve Freedom 0--if users are unhappy with the code, they can maintain their own patches against it. We believe this is disingenuous thinking when applied to large-scale software systems, since doing so would require one or more people to commit to it full-time. Running software you don't like because the alternative is throwing away your livelihood is neither an endorsement of the software, nor is choosing to run it a freely-made choice.
That said, we believe that Debian's adoption of systemd represents a net reduction of Freedom 0. I say "reduction" because it's well-known that various components of systemd have historically been implemented by separate, independent programs. Adopting systemd means moving from a world where I can mix and match various daemons independently of one another (and in most cases independently of the underling OS kernel and overlying UI) to a world where my choices are to use Linux+glibc+systemd+dbus to get a functional Free Software desktop, to go without the desktop (or use second-class shims) to use my preferred alternatives. My ability to run whatever programs I want for whatever reason--as Debian had historically prided itself on offering to users--is diminished by adopting systemd. This is an undesirable development for us, so we're doing something about it.
Quote:
Quote:
2.2 protect freedom of choice of users and developers
An universal OS must protect freedom of choice, trying to provide all the alternatives to adapt to any use case, from a common home user to a developer and/or a sysadmin, and avoiding to force minoritarian users to work in the way the majority follow, as any minority has usually good reasons for doing thing in different way.
I don't quite get how you can claim that you want to provide freedom of choice and at the same time dismiss the inclusion of systemd, by now the most used init system (and more) in your repositories, maybe you can explain that a bit.
This gets brought up periodically on both the mailing list and IRC. We're not opposed in principle to offering systemd in Devuan. If we had the manpower to support it as an init alternative, we would. The reason why we don't right now is because systemd's architecture makes it difficult to let users run systemd alongside their preferred alternatives to systemd's subordinate daemons. What we are doing for now is packaging systemd-shim and cgmanager to help users run parts of systemd without systemd-PID-1, and setting up the packages we imported from Debian to build without pulling in optional systemd dependencies.
You don't see systemd in our package repository because of the way our mirroring system works. Devuan implements an APT proxy that overlays Devuan packages on top of Debian's mirrors. You can apt-get install systemd in Devuan, and the APT proxy will redirect you to the Debian mirrors for it.
Quote:
Sidenote: When I saw this
Quote:
We consider ourselves the real debian history continuity path, and the actual debian like a fork from us, or a derivate from devuan with bloatware added.
My first thought was that this would be the first time I know off that the derivative (Debian, is there a specific reason that you write it lowercase?) provides the repositories for the the main distro and not the other way around.
No reason for the lower-case (it's a typo). The passage you quote is trying to say that Devuan strives to uphold Debian's founding principles--i.e. to be the Universal OS. Recent events suggest that Debian does not intend to adhere to these principles in the ways that we have come to appreciate them. I would love to be wrong about this, though--in fact, I intend to submit patches and packages to Debian to help increase the degree to which it offers Freedom 0.
Last edited by judecnelson; 04-29-2015 at 02:17 PM.
Contrast this to a hypothetical world where the kernel API changed frequently--in this scenario, Freedom 0 is reduced, since continuous compatibility breakage would limit the selection and usability of software to only those that were compatible with the latest changes.
Devuan strives to be a distro that maximizes Freedom 0 for as many users as possible, under this interpretation of it. It does so by making interoperability a first-class design goal. Devuan strives to help users run whatever combination of programs they want, without forcing them to become full-time developers and packagers to do so.
Let's not look at the kernel, but at the glibc instead. There are several cases of a software that will not run on older glibc versions. Steam and Debian 7 are a prominent example of this case, where you have to tweak the distro in non-trivial ways. When I follow your logic, and if I understand it correctly, Devuan should be opposed to using the glibc also, since it also diminishes your choice, but I can't see that mentioned anywhere. Not to mention that glibc provides options that are not offered by other libc implementations, like musl, and that there is software using those options, effectively creating the same lock-in people claim for systemd.
Quote:
That said, we believe that systemd's architecture poses a net reduction of Freedom 0. I say "reduction" because it's well-known that various components of systemd have historically been implemented by separate, independent programs. Adopting systemd means moving from a world where I can mix and match various daemons independently of one another (and in most cases independently of the underling OS kernel and overlying UI) to a world where my choices are to use Linux+glibc+systemd+dbus to get a functional Free Software desktop, to go without the desktop (or use second-class shims) to use my preferred alternatives. My ability to run whatever programs I want for whatever reason--as Debian had historically prided itself on offering to users--is diminished by adopting systemd. This is an undesirable development for us, so we're doing something about it.
Sorry, but I think you got that backwards. systemd is not forcing anyone to use the components they offer, it is the projects that make themselves dependent on certain parts of systemd that are doing what you perceive as a diminishing of your freedom. Developers are still free to use whatever they want as dependencies for their projects and if a project decides to use systemd components as a dependency then it is their freedom to do so. The same way as in the glibc example above glibc is not responsible for software using its extended functionality, it is the software that is actually using that extended functionality. It also seems to me that you have that common misconception that once you use systemd as PID 1 you actually have to use all its components also, which is not true. Projects like uselessd even prove that it is viable for a single developer to fork systemd and patch the hell out of it until it works like that person want it to work.
Quote:
This gets brought up periodically on both the mailing list and IRC. We're not opposed in principle to offering systemd in Devuan. If we had the manpower to support it as an init alternative, we would. The reason why we don't right now is because systemd's architecture makes it difficult to let users run systemd alongside their preferred alternatives to systemd's subordinate daemons.
Would you please be more specific on that? What are those difficulties? I have to ask, because I have no problems to replace systemd components with stand-alone alternatives, obviously except journald, which can not trivially be replaced (though it is possible), but can be used to feed other logging daemons (and even extend their functionality this way).
Quote:
No reason for the lower-case (it's a typo). The passage you quote is trying to say that Devuan strives to uphold Debian's founding principles--i.e. to be the Universal OS. Recent events suggest that Debian does not intend to adhere to these principles in the ways that we have come to appreciate them.
Even amongst Debian developers and users there where debates what the "universal" in "universal OS" actually means.
Anyways, and please correct me if I am wrong, but I think you actually refer to article 4 of the Social Contract and feel that making systemd the default init system somehow is an act against this article, that it somehow is an act against "We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.". But as I said above, it seems that somehow the "and the free software community" part has been lost by people that claim that Debian is not an OS that is guided by the needs of their users anymore, while all the time it wasn't an OS solely guided by the needs of their users, but an OS guided by "the needs of our users and the free software community". Many parts in the free software community have decided that for their projects using systemd is a viable option, especially when those parts of the community that objected to systemd failed to maintain the alternatives. When such a large project as Debian is today tries to cater to developers and users there inevitably will come the point where decisions have to be made that one of the parties will perceive to be against their interests. Devuan quite obviously perceives the decision for systemd as default as an act against the Debian user's interest, but also quite obviously dismisses the part where it says "and the free software community".
Just to clarify: Don't get me wrong, I am all for the freedom to let you choose which software you use and if you feel that there is something wrong with Debian then by all means, fork it and adapt it as you see fit, especially when you really have the manpower to do that and the resulting projects, like vdev and loginkit, are suitable for other distributions that aim to be systemd free (or, in the case of Gentoo and Void, let you choose), too. It is just that it seems to me that the reasons for the fork you cite are more or less a disguise for what actually is a simple "we don't like systemd and don't want it in our distro", which in my opinion is a totally valid statement and there is no need to hide it.
Let's not look at the kernel, but at the glibc instead. There are several cases of a software that will not run on older glibc versions. Steam and Debian 7 are a prominent example of this case, where you have to tweak the distro in non-trivial ways. When I follow your logic, and if I understand it correctly, Devuan should be opposed to using the glibc also, since it also diminishes your choice, but I can't see that mentioned anywhere. Not to mention that glibc provides options that are not offered by other libc implementations, like musl, and that there is software using those options, effectively creating the same lock-in people claim for systemd.
That's an apples-to-oranges comparison. It's entirely possible to have multiple libc's installed, and unlike init, it's entirely possible to run programs with different libc's concurrently. Moreover, if you install one libc, it doesn't require the removal of the other. I accept that some packages may pull in separate libc's, but that's fine--it doesn't affect the architecture or administration of other programs (since they won't be using it), nor does it preclude the installation of other libc's or programs that depend on them.
I'd be willing to help make multi-libc as painless as possible in Devuan, if there is sufficient interest.
Quote:
Sorry, but I think you got that backwards. systemd is not forcing anyone to use the components they offer, it is the projects that make themselves dependent on certain parts of systemd that are doing what you perceive as a diminishing of your freedom. Developers are still free to use whatever they want as dependencies for their projects and if a project decides to use systemd components as a dependency then it is their freedom to do so. The same way as in the glibc example above glibc is not responsible for software using its extended functionality, it is the software that is actually using that extended functionality. It also seems to me that you have that common misconception that once you use systemd as PID 1 you actually have to use all its components also, which is not true.
It seems that I updated my comment as you were posting this. We are in agreement in that it's ultimately the distro (not systemd) that diminished freedom.
Quote:
Projects like uselessd even prove that it is viable for a single developer to fork systemd and patch the hell out of it until it works like that person want it to work.
You may be interested to know that the original uselessd developer has given up (link: https://forums.darknedgy.net/viewtopic.php?id=4963). The first sentence is reproduced below, to illustrate the long-term "viability" of forking systemd:
Quote:
After mangling systemd into something a bit saner turned out to be frustrating and seemingly more of a fool's errand to me, with no enjoyment out of it, I made the decision to turn over development and ownership of the project to a guy named Manuel Bachmann (alias Tarnyko) of http://www.tarnyko.net/, who is a packager for Tizen, among other things.
I'm looking forward to seeing what Mr. Bachmann does with it. However, if you take a look at his site's announcement (http://www.tarnyko.net/en/?q=node/52), you'll see that the current uselessd is still derived from systemd 208 (so it's already somewhat behind Debian's systemd), and does not appear to have received any public updates since January.
Quote:
Would you please be more specific on that? What are those difficulties? I have to ask, because I have no problems to replace systemd components with stand-alone alternatives, obviously except journald, which can not trivially be replaced (though it is possible), but can be used to feed other logging daemons (and even extend their functionality this way).
I was thinking in the opposite direction--how do you run systemd daemons without systemd-PID-1? That's not easy; in fact, it will probably only get harder if kdbus gets accepted. The shims are a near-term solution, but they'll always be second-class citizens since the API between the systemd daemons and systemd-PID-1 is not guaranteed to be stable (if you want, you can ask the loginkit developer Dima Krasner about all the undocumented unstable API cruft he had to wade through to get GDM to start with it).
Quote:
Even amongst Debian developers and users there where debates what the "universal" in "universal OS" actually means.
Anyways, and please correct me if I am wrong, but I think you actually refer to article 4 of the Social Contract and feel that making systemd the default init system somehow is an act against this article, that it somehow is an act against "We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.". But as I said above, it seems that somehow the "and the free software community" part has been lost by people that claim that Debian is not an OS that is guided by the needs of their users anymore, while all the time it wasn't an OS solely guided by the needs of their users, but an OS guided by "the needs of our users and the free software community". Many parts in the free software community have decided that for their projects using systemd is a viable option, especially when those parts of the community that objected to systemd failed to maintain the alternatives. When such a large project as Debian is today tries to cater to developers and users there inevitably will come the point where decisions have to be made that one of the parties will perceive to be against their interests. Devuan quite obviously perceives the decision for systemd as default as an act against the Debian user's interest, but also quite obviously dismisses the part where it says "and the free software community".
Like Debian, Devuan is also guided by the needs of its users and the Free Software community. The difference is that the Devuan community has different opinions on how Freedom 0 applies to the OS's architecture and the organization that develops it. It's not a popularity contest. Also, as I said above, we're not opposed to maintaining systemd as an option; it's just that we lack the manpower to do so right this minute.
It's not that the alternatives want for maintenance--Devuan, Slackware, Gentoo, and others are already doing so and will continue to do so. It's that most other distros supported only one init in the first place, and they decided one-by-one to switch to systemd. It may make the maintainers' lives easier, but it doesn't always work to the users' benefit. You may recall the fall-out when Arch decided to switch to systemd, for example.
What ultimately pushed me and others away from Debian was the lack of a guarantee that we would be able to choose init separately from other unrelated programs in the future, as had largely been the case prior to systemd. A critical consequence of the outcome of Ian's GR is that it leaves DDs free to ignore patches to preserve compatibility with inits other than systemd, and there would be no remedy for this short of either maintaining a forked package in a separate repository or asking the CTTE to intervene in each case.
This is a very tenuous situation to be in if you prefer something other than systemd. On the one hand, Debian cannot (and should not) compel DDs to do things they don't want to do. On the other hand, a single DD can easily and severely undermine whatever work we would do to preserve support for an alternative init. It's not that I doubt that such DDs are acting in good faith; it's that they have a different vision of what a Universal OS should look like (as you point out), and when push comes to shove, the DDs will get their way. And no one wants to be the thorn in everyone's side by asking the CTTE to intervene again and again, especially since there are still so many raw nerves and hard feelings.
Given this political climate, I'm of the opinion that a "copy-on-write" fork in the style of Devuan is the best option for everyone. We'll be able to keep as much in common with Debian as possible, while also providing continuity to Wheezy users who do not want systemd, and providing a proving ground for evolving, testing, and integrating alternatives that for whatever reason don't get included in Debian.
Please explain why you believe that our actions are dismissive of the needs of the Free Software community. It seems to me that between Devuan and Debian, we're collectively serving more people's needs than either group could do on its own.
Quote:
Just to clarify: Don't get me wrong, I am all for the freedom to let you choose which software you use and if you feel that there is something wrong with Debian then by all means, fork it and adapt it as you see fit, especially when you really have the manpower to do that and the resulting projects, like vdev and loginkit, are suitable for other distributions that aim to be systemd free (or, in the case of Gentoo and Void, let you choose), too. It is just that it seems to me that the reasons for the fork you cite are more or less a disguise for what actually is a simple "we don't like systemd and don't want it in our distro", which in my opinion is a totally valid statement and there is no need to hide it.
Except that it isn't a disguise. It's pretty clear that we want Init Freedom. Ask on the mailing list or IRC what everyone's favorite init system is, if you don't believe me. I doubt you'll get a unanimous answer. I won't deny that a lot of people came to Devuan because their distro of choice went with systemd, but the reason they came to Devuan is because we intend to support running the init systems they prefer (like Epoch, OpenRC, and file-rc) alongside anything else they want.
It's not just init systems, either--we want the freedom to run whatever desktop apps we want, whatever DEs we want, whatever editors we want, etc. In fact, one long-term goal of mine for vdev is to support using whatever device management strategy you want--even a static /dev. To enable this, I'm making an ABI-compatible libudev that doesn't need udevd.
Last edited by judecnelson; 04-29-2015 at 07:18 PM.
That's an apples-to-oranges comparison. It's entirely possible to have multiple libc's installed, and unlike init, it's entirely possible to run programs with different libc's concurrently. Moreover, if you install one libc, it doesn't require the removal of the other. I accept that some packages may pull in separate libc's, but that's fine--it doesn't affect the architecture or administration of other programs (since they won't be using it), nor does it preclude the installation of other libc's or programs that depend on them.
I'd be willing to help make multi-libc as painless as possible in Devuan, if there is sufficient interest.
I think you missed my point. Debian does not provide newer glibc versions without a complete upgrade away from the Stable branch, yet the glibc interface can change in newer versions, so that programs that rely on the newer interfaces might not work on Debian (again, as happened for example with Steam and Debian 7), effectively providing the same lock-in that people complain about with systemd. Of course you could install a newer glibc to a custom location and use certain binaries with custom library paths, but that is trickery that is not officially supported. So there is your freedom diminished by glibc, you can't just run any software you want in any configuration you want, yet I have never seen the VUA (or anyone else) complain about that.
Quote:
It seems that I updated my comment as you were posting this. We are in agreement in that it's ultimately the distro (not systemd) that diminished freedom.
I would go even further and say that it is not the distro, but upstream developers and ultimately the community itself. See for example Upower, at some point they have decided that they remove Consolekit support, because Consolekit went unmaintained for years, despite the outcry of people in the community, which also went on for years, how systemd somehow forcefully deprecated Consolekit with abandoning it. One can see Kickstarter/GoFundMe/whatever campaigns for all sorts of weird stuff, but in all these years nobody went ahead to start a campaign for further maintenance of Consolekit and in all these years nobody (not even the VUA) went ahead and said "we need it, we will maintain it". It needed the already understaffed XFCE team to go ahead and fork it. At least the Devuan developers, including you, started to do something about it, and I appreciate that, because that is the true spirit of open source, doing, not crying and demanding. But I think at could have happened much earlier and having those alternatives available earlier could have made the situation in Debian much easier when it came to decide for an init system and how to support different init systems.
Quote:
You may be interested to know that the original uselessd developer has given up (link: https://forums.darknedgy.net/viewtopic.php?id=4963). The first sentence is reproduced below, to illustrate the long-term "viability" of forking systemd:
Quote:
After mangling systemd into something a bit saner turned out to be frustrating and seemingly more of a fool's errand to me, with no enjoyment out of it, I made the decision to turn over development and ownership of the project to a guy named Manuel Bachmann (alias Tarnyko) of http://www.tarnyko.net/, who is a packager for Tizen, among other things.
I'm looking forward to seeing what Mr. Bachmann does with it. However, if you take a look at his site's announcement (http://www.tarnyko.net/en/?q=node/52), you'll see that the current uselessd is still derived from systemd 208 (so it's already somewhat behind Debian's systemd), and does not appear to have received any public updates since January.
OK, then it might not feasible for a single developer, but that shows a different interesting point: It seems that nobody was really interested in uselessd, otherwise other people would have joined the effort. I seriously doubt that, while Mr. Bachmann is a Tizen developer, he took that project over in behalf of the Tizen team, they would have joined earlier if it would have been their intention to make use of uselessd.
Quote:
I was thinking in the opposite direction--how do you run systemd daemons without systemd-PID-1? That's not easy; in fact, it will probably only get harder if kdbus gets accepted. The shims are a near-term solution, but they'll always be second-class citizens since the API between the systemd daemons and systemd-PID-1 is not guaranteed to be stable (if you want, you can ask the loginkit developer Dima Krasner about all the undocumented unstable API cruft he had to wade through to get GDM to start with it).
I will give you that, it might be difficult to run systemd components without systemd as PID 1 (I don't know, I am not a developer, I will take your word for it), but I am not quite sure why you would even try that. As I said, I am not a developer, so I have to ask for a better understanding: If you want to have something that can replace systemd components for systems not running systemd as PID 1, why bother with systemd internals? Why not just provide the interfaces that systemd presents to the outside? Isn't that the approach that the systembsd people have chosen?
Quote:
It's not that the alternatives want for maintenance--Devuan, Slackware, Gentoo, and others are already doing so and will continue to do so.
I think you misunderstood me. When I talked about failed maintenance I meant rather individual projects, not entire distros. Prominent example, again, Consolekit.
Quote:
It's not that the alternatives want for maintenance--Devuan, Slackware, Gentoo, and others are already doing so and will continue to do so. It's that most other distros supported only one init in the first place, and they decided one-by-one to switch to systemd. It may make the maintainers' lives easier, but it doesn't always work to the users' benefit. You may recall the fall-out when Arch decided to switch to systemd, for example.
Whenever there is a major switch in a distro you will have people that cry about the switch, has happened many times in all distros and will happen in the future. That is not in any way related to systemd. You will, for example, see the same when Wayland starts to get adopted as default by the major distros (except Ubuntu, of course).
Quote:
What ultimately pushed me and others away from Debian was the lack of a guarantee that we would be able to choose init separately from other unrelated programs in the future, as had largely been the case prior to systemd. A critical consequence of the outcome of Ian's GR is that it leaves DDs free to ignore patches to preserve compatibility with inits other than systemd, and there would be no remedy for this short of either maintaining a forked package in a separate repository or asking the CTTE to intervene in each case.
This is a very tenuous situation to be in if you prefer something other than systemd. On the one hand, Debian cannot (and should not) compel DDs to do things they don't want to do. On the other hand, a single DD can easily and severely undermine whatever work we would do to preserve support for an alternative init. It's not that I doubt that such DDs are acting in good faith; it's that they have a different vision of what a Universal OS should look like (as you point out), and when push comes to shove, the DDs will get their way. And no one wants to be the thorn in everyone's side by asking the CTTE to intervene again and again, especially since there are still so many raw nerves and hard feelings.
And here we come to a point I don't get. For every package that would need such a patch you will have to have a package maintainer in Devuan. Assuming good faith of the Debian developers, what would have stopped the Devuan package maintainers to join forces with Debian developers and take care of those patches directly in Debian? I can understand when a Debian developer says "Well, I can't accept that patch, I don't use [insert alternative init system] and therefore can't test it", but I doubt that a Debian developer would have problems with a Devuan developer joining forces with him to provide and test those patches.
Quote:
Please explain why you believe that our actions are dismissive of the needs of the Free Software community. It seems to me that between Devuan and Debian, we're collectively serving more people's needs than either group could do on its own.
As I said, projects as large as Debian that want to cater users and developers will have at some point in time have to make a decision that will be perceived by one of the groups as against their interests. For systemd, it seems that a part of the users perceived it that way, though all the problems that may arise (like a package maintainer possibly rejecting a patch) are merely theoretical and could be avoided by joining the Debian team. It is very clear that the largest part of software projects in the Linux ecosystem is in favor of systemd. The KWin maintainer has clearly stated that he won't support non-systemd for the Wayland port because supporting non-systemd is already a mess for them (he also made clear that he will be fine with other developers providing that support). Other KDE developers have also made statements why they want systemd (or for that matter, rather a consolidated base system, the systemd guys were just the first to actually do that). The opinion of the GNOME guys should be clear.
So those packages in Devuan would also have to be patched, while the better option would have been to join those teams and provide those patches upstream instead, distro independent (we all know how submitting distro specific patches to many of those projects work out). So, as I see it, with putting the user of the developer instead of joining the developers a disservice is done to the community at whole, with both, splitting the Debian community and not joining upstream where needed for your purposes. This disservice is of course somewhat diminished with your work on vdev and Loginkit, but I still think that joining upstream would have had better effects.
Quote:
Except that it isn't a disguise. It's pretty clear that we want Init Freedom. Ask on the mailing list or IRC what everyone's favorite init system is, if you don't believe me. I doubt you'll get a unanimous answer. I won't deny that a lot of people came to Devuan because their distro of choice went with systemd, but the reason they came to Devuan is because we intend to support running the init systems they prefer (like Epoch, OpenRC, and file-rc) alongside anything else they want.
It was very clear from the beginning that the VUA came into life not because Debian has abandoned other init systems (it simply has not), but because they are opposed to systemd. This becomes even more clear when you keep in mind that for OpenRC they weren't even packages in Debian before the init system discussion began (and Epoch still doesn't have a Debian package at all). If those people would have been so eager to run [insert favorite init system] in Debian then there would have been packages for those init systems in Debian for a long time already. They made it even more clear with posting links on the debianfork website to FUD spreading sites like the boycottsystemd website and the threat to fork Debian when they don't get their will, instead of getting involved in Debian (funnily, with the reasoning that they don't have the time to join Debian, while they now have the time to manage an entire distribution). So, my position on this still stands, to me it is clear that at least the VUA, those people that started the project, didn't want a more open Debian, they wanted a systemd-free Debian. I guess we can only wait and see how in the future (if the manpower becomes available) a possible integration of systemd into Devuan will be handled.
I think you missed my point. Debian does not provide newer glibc versions without a complete upgrade away from the Stable branch, yet the glibc interface can change in newer versions, so that programs that rely on the newer interfaces might not work on Debian (again, as happened for example with Steam and Debian 7), effectively providing the same lock-in that people complain about with systemd. Of course you could install a newer glibc to a custom location and use certain binaries with custom library paths, but that is trickery that is not officially supported. So there is your freedom diminished by glibc, you can't just run any software you want in any configuration you want, yet I have never seen the VUA (or anyone else) complain about that.
You've answered your own question. If program A uses libc-A and program B uses libc-B, I can install A, B, libc-A, and libc-B, and run A and B at the same time. There is no reduction in freedom, and thus nothing to complain about.
This is not the case with dependency on init. If program A needs init-A but program B needs init-B, then I can install only A or B but not both, since I cannot install (let alone run) init-A and init-B at the same time. The only ways to install A and B at the same time are to either design A and B to depend on the same init, or to design them to not depend on any init at all.
Quote:
I would go even further and say that it is not the distro, but upstream developers and ultimately the community itself. See for example Upower, at some point they have decided that they remove Consolekit support, because Consolekit went unmaintained for years, despite the outcry of people in the community, which also went on for years, how systemd somehow forcefully deprecated Consolekit with abandoning it. One can see Kickstarter/GoFundMe/whatever campaigns for all sorts of weird stuff, but in all these years nobody went ahead to start a campaign for further maintenance of Consolekit and in all these years nobody (not even the VUA) went ahead and said "we need it, we will maintain it". It needed the already understaffed XFCE team to go ahead and fork it. At least the Devuan developers, including you, started to do something about it, and I appreciate that, because that is the true spirit of open source, doing, not crying and demanding. But I think at could have happened much earlier and having those alternatives available earlier could have made the situation in Debian much easier when it came to decide for an init system and how to support different init systems.
It's not my place to tell the UPower developers what to do with their project.
However, the fact that ConsoleKit went unmaintained for years does not mean that it's intrinsically unusable. Software is not machinery--it doesn't rust, nor does it need periodic oiling or tune-ups. The downside risk to using unmaintained software is that if you encounter bugs, or if incompatibilities with the its surrounding environment are introduced, then it's up to you to deal with them. This means that it's not that big a deal if ConsoleKit has no maintainer, as long as it works. That's why there was no outcry at the lack of maintenance, but there was when other programs stopped using it in favor of systemd (since ConsoleKit was the alternative to logind).
Nevertheless, we agree with upstream that ConsoleKit represents an architectural dead-end. However, we believe that the way forward is to remove the need for it altogether, instead of swapping it out for systemd. We wouldn't prevent users from installing and running it, of course, but we'd strive to offer the option to go without it as well.
Quote:
OK, then it might not feasible for a single developer, but that shows a different interesting point: It seems that nobody was really interested in uselessd, otherwise other people would have joined the effort. I seriously doubt that, while Mr. Bachmann is a Tizen developer, he took that project over in behalf of the Tizen team, they would have joined earlier if it would have been their intention to make use of uselessd.
This is basically the reason why non-systemd users don't fork systemd. Because systemd doesn't offer any compelling features for them in the first place, there's no point in sinking effort into making systemd usable to them--they get along just fine without it.
However...
Quote:
I will give you that, it might be difficult to run systemd components without systemd as PID 1 (I don't know, I am not a developer, I will take your word for it), but I am not quite sure why you would even try that. As I said, I am not a developer, so I have to ask for a better understanding: If you want to have something that can replace systemd components for systems not running systemd as PID 1, why bother with systemd internals? Why not just provide the interfaces that systemd presents to the outside? Isn't that the approach that the systembsd people have chosen?
...The reason to try hacking on systemd's subordinate daemons at all is that they are needed to run certain upstream popular software (i.e. GNOME and soon KDE). They just have the unfortunate side-effect of depending on systemd-PID-1 to be running. Systembsd seeks to implement just enough of the interface that the OpenBSD port of GNOME can work on OpenBSD. Dima Krasner's LoginKit is an effort to implement the logind interface without pulling in systemd-PID-1.
I think systembsd is a from-scratch effort due to licensing considerations. Dima started from logind because there's no point to re-inventing the wheel if it can be avoided.
Quote:
I think you misunderstood me. When I talked about failed maintenance I meant rather individual projects, not entire distros. Prominent example, again, Consolekit.
Whenever there is a major switch in a distro you will have people that cry about the switch, has happened many times in all distros and will happen in the future. That is not in any way related to systemd. You will, for example, see the same when Wayland starts to get adopted as default by the major distros (except Ubuntu, of course).
With efforts like XWayland and Xweston, it should be possible to install and use both with no loss of freedom. If I can run both Wayland and an X server, and run both Wayland clients and X clients at the same time, then there's no problem.
Quote:
And here we come to a point I don't get. For every package that would need such a patch you will have to have a package maintainer in Devuan. Assuming good faith of the Debian developers, what would have stopped the Devuan package maintainers to join forces with Debian developers and take care of those patches directly in Debian? I can understand when a Debian developer says "Well, I can't accept that patch, I don't use [insert alternative init system] and therefore can't test it", but I doubt that a Debian developer would have problems with a Devuan developer joining forces with him to provide and test those patches.
Maintaining a friendly relationship with upstream distros and developers is in our constitution--we'd be happy to send patches, if they're wanted. Once vdev is tested and ready, I'll be sending some patches along that will decrease Debian's reliance on udev. Similarly, nothing stops Debian from pulling patches directly from us, since our code is publicly visible.
However...
Quote:
As I said, projects as large as Debian that want to cater users and developers will have at some point in time have to make a decision that will be perceived by one of the groups as against their interests. For systemd, it seems that a part of the users perceived it that way, though all the problems that may arise (like a package maintainer possibly rejecting a patch) are merely theoretical and could be avoided by joining the Debian team.
...Debian isn't the right place to be sending patches. As you point out, the coupling between GNOME and logind is GNOME's doing, not Debian's, and the coupling between logind and systemd-PID-1 is Lennart Poettering's doing, not GNOME's. Joining Debian isn't going to fix upstream's decision to mandate a particular init. Replacing the parts of the init system that they depend on (i.e. with loginkit and vdev) will. Moreover, working in an environment that promotes interoperability and values your contributions towards that goal means a lot to me. I'm not feeling that from Debian these days.
Quote:
It is very clear that the largest part of software projects in the Linux ecosystem is in favor of systemd. The KWin maintainer has clearly stated that he won't support non-systemd for the Wayland port because supporting non-systemd is already a mess for them (he also made clear that he will be fine with other developers providing that support). Other KDE developers have also made statements why they want systemd (or for that matter, rather a consolidated base system, the systemd guys were just the first to actually do that). The opinion of the GNOME guys should be clear.
It really sucks to be you if aren't going to use systemd but you rely on these programs, doesn't it?
It's not my place to tell GNOME or KDE developers how to do their jobs. However, I don't buy their arguments for hard-depending on logind either. The central problems that logind solves for GUIs are:
* ensuring that for computers that run multiple sessions, only processes in the active session can access certain hardware.
* ensuring that processes in a session only access hardware assigned to the seat in which the session is running.
* granting unprivileged users the ability to issue a few privileged session-related commands, like suspending or shutting down.
The first two points only apply if your computer will be shared between multiple people--either by taking turns and locking/unlocking different sessions, or running a multiseat setup. As more and more people own their computers, this is less and less of a problem. They aren't that hard to solve either--I'm doing it with vdev and a few shell scripts in my spare time, and I'm doing it in a way that is both portable and not coupled to init.
The last point is trivially solved with proper use of sudo and/or setuid/setgid wrappers that run the privileged operation.
I might be misremembering, but I'm pretty sure the GNOME and KDE developers made those comments in the context of how annoying it was to solve these problems with ConsoleKit (which tries to the same kinds of things).
Quote:
So those packages in Devuan would also have to be patched, while the better option would have been to join those teams and provide those patches upstream instead, distro independent (we all know how submitting distro specific patches to many of those projects work out). So, as I see it, with putting the user of the developer instead of joining the developers a disservice is done to the community at whole, with both, splitting the Debian community and not joining upstream where needed for your purposes. This disservice is of course somewhat diminished with your work on vdev and Loginkit, but I still think that joining upstream would have had better effects.
I don't follow you at all.
You seem to be assuming that by forking Debian, both the Debian and Devuan communities suffer from diminished manpower. This is patently false, for several reasons.
First, a developer in one community is a developer in the other--Debian's derivatives borrow code from Debian at no cost to Debian, and Debian borrows from their derivatives at no cost to the derivative (see how Ubuntu and Debian share patches and bug trackers, for example). There is no reduction in manpower.
Second, the existence of two different user communities that share a common core attracts more users than either could alone. Again, look at how many people use Debian derivatives--that's mostly Debian's code they're using, and that's mostly Debian's code they're submitting bug reports and patches for. But it wasn't Debian that attracted them--it was the derivative. All Debian has to do is watch their derivatives' repositories and merge code that they didn't have to write themselves (and sometimes, the derivative will even do the merging for them). Debian even has a process for interfacing with its derivatives for this very purpose: https://wiki.debian.org/DEX.
Third, the existence of two different developer communities with different design goals attracts more developers than either could alone. Even though it has different design goals, Devuan shares a lot of DNA with Debian, and you can bet that code that works on one will be easy to port to the other. I would not be writing vdev if it weren't for Devuan, but Debian gets to benefit as well. Same goes for the rest of Devuan's projects, and for all other derivative-created projects--Debian is made stronger because more developers are working on it.
It's not like derivatives exist in a vacuum, walled off from one another. We all share code and bug reports. The whole "forks divide communities and make both projects worse off" meme seriously needs to die, especially now that there is empirical evidence that the most common results of forks are either that one branch dies out (i.e. no long-term division of the community) or they both succeed in their own rights (i.e. the fork needed to happen). See http://flosshub.org/sites/flosshub.o...es/paper_0.pdf.
Quote:
It was very clear from the beginning that the VUA came into life not because Debian has abandoned other init systems (it simply has not), but because they are opposed to systemd. This becomes even more clear when you keep in mind that for OpenRC they weren't even packages in Debian before the init system discussion began (and Epoch still doesn't have a Debian package at all). If those people would have been so eager to run [insert favorite init system] in Debian then there would have been packages for those init systems in Debian for a long time already. They made it even more clear with posting links on the debianfork website to FUD spreading sites like the boycottsystemd website and the threat to fork Debian when they don't get their will, instead of getting involved in Debian (funnily, with the reasoning that they don't have the time to join Debian, while they now have the time to manage an entire distribution). So, my position on this still stands, to me it is clear that at least the VUA, those people that started the project, didn't want a more open Debian, they wanted a systemd-free Debian. I guess we can only wait and see how in the future (if the manpower becomes available) a possible integration of systemd into Devuan will be handled.
Ask yourself this--if all we cared about was getting away from systemd, why would we be spending so much time building a Debian derivative instead of switching to Slackware or Void or Gentoo or whatever? As I said earlier, it's because our goal is to preserve the user's freedom to run the programs they want to run. You don't have to take my word for it--go to our ML and post something like "Hey VUA, what is Devuan's mission? Does it exist because you're opposed to systemd, because you care about freedom like this rando judecnelson said on LinuxQuestions, or something else entirely?" and get a direct answer from them.
Technically, we are working with Debian on this--Debian gets to take our work and use it for their own purposes, just like how they can do so with all their other derivatives. You don't have to be a Debian Developer to get code into Debian. Moreover, Devuan's approach is a much less risky proposition for Debian--they don't have to trust us with developer keys, and they get to take only the bits they want. So regardless of Devuan's fate, Debian is no worse off but stands to gain. What better position to be in than that?
Last edited by judecnelson; 05-01-2015 at 12:26 AM.
The old question of "when it's ready" will be on a lot of people's minds, but all anyone can respond with is have patience.
As far as logind's full replacement, loginkit and ConsoleKit2 have replaced a majority of that functionality, as has systemd-shim to some extent, however, removing systemd-shim would probably be more favorable to use a more independent package rather than a toolkit aiming at two or three layers of functionality (systemd-api, systemd-cgroups, and systemd-logind). So far loginkit only supplicants one of the missing functions from ConsoleKit2 that logind has.
LoginKit so far implements "Inhibit()" which is not yet added to ConsoleKit2. The only difference between logind and ConsoleKit2 is the session seat manager "ListSessions()" vs. "GetSessions()" which have near equal functionality. This is why LoginKit has a backend for ConsoleKit2 to pass those functions off to ConsoleKit2.
You can read this document to get a better understand that my talking:
Devuan may be a new project, but give it time to mature and get going. To be frank, it is a redevelopment of Debian.
I seriously do hope the developers of Devuan do keep in mind that it might be best to forgo having a bunch of committees running things because various interests can be brought in that may not reflect well, as was the case with the Debian Technical Committee as we all saw. In essence, Devuan could use a more simplified leadership system (though I'd wonder how well a single point leadership like Slackware has with a BDFL would fair).
However, I am hoping all the ventures Devuan is promoting and progressing, such as vdev, loginkit, and others, can bring sanity back to Linux and even bring more sanity to the whole of UNIX as well.
You've answered your own question. If program A uses libc-A and program B uses libc-B, I can install A, B, libc-A, and libc-B, and run A and B at the same time. There is no reduction in freedom, and thus nothing to complain about.
This is not the case with dependency on init. If program A needs init-A but program B needs init-B, then I can install only A or B but not both, since I cannot install (let alone run) init-A and init-B at the same time. The only ways to install A and B at the same time are to either design A and B to depend on the same init, or to design them to not depend on any init at all.
It's not my place to tell the UPower developers what to do with their project.
However, the fact that ConsoleKit went unmaintained for years does not mean that it's intrinsically unusable. Software is not machinery--it doesn't rust, nor does it need periodic oiling or tune-ups. The downside risk to using unmaintained software is that if you encounter bugs, or if incompatibilities with the its surrounding environment are introduced, then it's up to you to deal with them. This means that it's not that big a deal if ConsoleKit has no maintainer, as long as it works. That's why there was no outcry at the lack of maintenance, but there was when other programs stopped using it in favor of systemd (since ConsoleKit was the alternative to logind).
Nevertheless, we agree with upstream that ConsoleKit represents an architectural dead-end. However, we believe that the way forward is to remove the need for it altogether, instead of swapping it out for systemd. We wouldn't prevent users from installing and running it, of course, but we'd strive to offer the option to go without it as well.
This is basically the reason why non-systemd users don't fork systemd. Because systemd doesn't offer any compelling features for them in the first place, there's no point in sinking effort into making systemd usable to them--they get along just fine without it.
However...
...The reason to try hacking on systemd's subordinate daemons at all is that they are needed to run certain upstream popular software (i.e. GNOME and soon KDE). They just have the unfortunate side-effect of depending on systemd-PID-1 to be running. Systembsd seeks to implement just enough of the interface that the OpenBSD port of GNOME can work on OpenBSD. Dima Krasner's LoginKit is an effort to implement the logind interface without pulling in systemd-PID-1.
I think systembsd is a from-scratch effort due to licensing considerations. Dima started from logind because there's no point to re-inventing the wheel if it can be avoided.
With efforts like XWayland and Xweston, it should be possible to install and use both with no loss of freedom. If I can run both Wayland and an X server, and run both Wayland clients and X clients at the same time, then there's no problem.
Maintaining a friendly relationship with upstream distros and developers is in our constitution--we'd be happy to send patches, if they're wanted. Once vdev is tested and ready, I'll be sending some patches along that will decrease Debian's reliance on udev. Similarly, nothing stops Debian from pulling patches directly from us, since our code is publicly visible.
However...
...Debian isn't the right place to be sending patches. As you point out, the coupling between GNOME and logind is GNOME's doing, not Debian's, and the coupling between logind and systemd-PID-1 is Lennart Poettering's doing, not GNOME's. Joining Debian isn't going to fix upstream's decision to mandate a particular init. Replacing the parts of the init system that they depend on (i.e. with loginkit and vdev) will. Moreover, working in an environment that promotes interoperability and values your contributions towards that goal means a lot to me. I'm not feeling that from Debian these days.
It really sucks to be you if aren't going to use systemd but you rely on these programs, doesn't it?
It's not my place to tell GNOME or KDE developers how to do their jobs. However, I don't buy their arguments for hard-depending on logind either. The central problems that logind solves for GUIs are:
* ensuring that for computers that run multiple sessions, only processes in the active session can access certain hardware.
* ensuring that processes in a session only access hardware assigned to the seat in which the session is running.
* granting unprivileged users the ability to issue a few privileged session-related commands, like suspending or shutting down.
The first two points only apply if your computer will be shared between multiple people--either by taking turns and locking/unlocking different sessions, or running a multiseat setup. As more and more people own their computers, this is less and less of a problem. They aren't that hard to solve either--I'm doing it with vdev and a few shell scripts in my spare time, and I'm doing it in a way that is both portable and not coupled to init.
The last point is trivially solved with proper use of sudo and/or setuid/setgid wrappers that run the privileged operation.
I might be misremembering, but I'm pretty sure the GNOME and KDE developers made those comments in the context of how annoying it was to solve these problems with ConsoleKit (which tries to the same kinds of things).
I don't follow you at all.
You seem to be assuming that by forking Debian, both the Debian and Devuan communities suffer from diminished manpower. This is patently false, for several reasons.
First, a developer in one community is a developer in the other--Debian's derivatives borrow code from Debian at no cost to Debian, and Debian borrows from their derivatives at no cost to the derivative (see how Ubuntu and Debian share patches and bug trackers, for example). There is no reduction in manpower.
Second, the existence of two different user communities that share a common core attracts more users than either could alone. Again, look at how many people use Debian derivatives--that's mostly Debian's code they're using, and that's mostly Debian's code they're submitting bug reports and patches for. But it wasn't Debian that attracted them--it was the derivative. All Debian has to do is watch their derivatives' repositories and merge code that they didn't have to write themselves (and sometimes, the derivative will even do the merging for them). Debian even has a process for interfacing with its derivatives for this very purpose: https://wiki.debian.org/DEX.
Third, the existence of two different developer communities with different design goals attracts more developers than either could alone. Even though it has different design goals, Devuan shares a lot of DNA with Debian, and you can bet that code that works on one will be easy to port to the other. I would not be writing vdev if it weren't for Devuan, but Debian gets to benefit as well. Same goes for the rest of Devuan's projects, and for all other derivative-created projects--Debian is made stronger because more developers are working on it.
It's not like derivatives exist in a vacuum, walled off from one another. We all share code and bug reports. The whole "forks divide communities and make both projects worse off" meme seriously needs to die, especially now that there is empirical evidence that the most common results of forks are either that one branch dies out (i.e. no long-term division of the community) or they both succeed in their own rights (i.e. the fork needed to happen). See http://flosshub.org/sites/flosshub.o...es/paper_0.pdf.
Ask yourself this--if all we cared about was getting away from systemd, why would we be spending so much time building a Debian derivative instead of switching to Slackware or Void or Gentoo or whatever? As I said earlier, it's because our goal is to preserve the user's freedom to run the programs they want to run. You don't have to take my word for it--go to our ML and post something like "Hey VUA, what is Devuan's mission? Does it exist because you're opposed to systemd, because you care about freedom like this rando judecnelson said on LinuxQuestions, or something else entirely?" and get a direct answer from them.
Technically, we are working with Debian on this--Debian gets to take our work and use it for their own purposes, just like how they can do so with all their other derivatives. You don't have to be a Debian Developer to get code into Debian. Moreover, Devuan's approach is a much less risky proposition for Debian--they don't have to trust us with developer keys, and they get to take only the bits they want. So regardless of Devuan's fate, Debian is no worse off but stands to gain. What better position to be in than that?
Honestly, as long as this anti-debian crap exists, you'll never have a discussion.
Biggest question:
Do you wish to contribute or replace/retaliate ... ?
I do thank you for your honesty and being public (your fellow devs should follow this).
PS: ... your blog post on systemd didn't help either.
systemd is turning linux into a dysfunctional and useless operating system
-> we have to remove it.
I know it will take a crap ton of work to remove systemd from debian (and
linux in general), but systemd is terminal. If you don't, there is no
future for you.
So what?
Any moron can post on any public list.
You're not helping your cause in making this yet an other stupid anti-systemd topic.
I'd love to see an alternative.
If you're capable, please do.
Don't add silly (and aggressive) doomdumps. I do take those serious.
Honestly, as long as this anti-debian crap exists, you'll never have a discussion.
Not sure I know what you mean? We *love* Debian--that's why we're building off of it. AFAIK most of the VUA are Debian users. I've personally been using it for the last 9 years.
Quote:
Biggest question:
Do you wish to contribute or replace/retaliate ... ?
Not sure what you mean here either. You seem to be suggesting that creating a derivative distro falls on a "contribute-versus-replace/retaliate" continuum, which makes no sense to me. First, "replace" and "retaliate" are not even close to the same thing in my eyes; maybe you can clarify? There certainly isn't any malice intended by our actions. Second, we're not eagerly replacing packages left and right--we're only concerning ourselves with creating/altering packages to remove what we consider to be needless dependencies (example: our dbus package does not depend on libsystemd0). It's not limited to systemd, either--dependency minimization is a means to maximizing the user's ability to exercise Freedom 0. Moreover, our APT server only serves the packages that differ from Debian, and redirects the HTTP GET requests for unmodified Debian packages to Debian's mirrors (this is the case for over 90% of the archive). I guess that means we're contributing?
Quote:
I do thank you for your honesty and being public (your fellow devs should follow this).
Admittedly, our website is pretty minimal. However, most of us prefer to interact via mailing lists anyway, so that's where most of the activity is.
Quote:
PS: ... your blog post on systemd didn't help either.
Are you referring to this one: http://judecnelson.blogspot.com/2014...fallacies.html? If so, I've done my best to be as factual and straight-forward as possible. If you've found errors, or find parts to be ambiguous, misleading, or otherwise unclear, please feel free to email me (or comment directly on the blog) so we can talk about it. I'm open to making improvements--the intent of the blog post is to be informative. In fact, I'd love to see a similar blog post detailing all the invalid anti-systemd arguments that keep coming up. I'd even link to it.
Last edited by judecnelson; 05-02-2015 at 01:45 AM.
I seriously do hope the developers of Devuan do keep in mind that it might be best to forgo having a bunch of committees running things because various interests can be brought in that may not reflect well, as was the case with the Debian Technical Committee as we all saw. In essence, Devuan could use a more simplified leadership system (though I'd wonder how well a single point leadership like Slackware has with a BDFL would fair).
There's a bit more info on the project goals and organization here: https://git.devuan.org/devuan/devuan-project/wikis/home. The information is tentative and subject to change--the precise details are still being worked out--but they should give an overview of the underlying principles that guide the project's organizational evolution.
A couple key differences between us and Debian:
* In addition to Devuan developers, there are three additional designated roles: the VUA (who run the distro), the operators (who run and maintain infrastructure), and registered users.
* We have a weighted voting system for project-wide decisions in which everyone, including registered users, can cast a vote.
...The reason to try hacking on systemd's subordinate daemons at all is that they are needed to run certain upstream popular software (i.e. GNOME and soon KDE). They just have the unfortunate side-effect of depending on systemd-PID-1 to be running. Systembsd seeks to implement just enough of the interface that the OpenBSD port of GNOME can work on OpenBSD. Dima Krasner's LoginKit is an effort to implement the logind interface without pulling in systemd-PID-1.
Still, my questions remain: GNOME/KDE/whatever do not rely on systemd components, they rely on the interfaces provided by these components. The internal working of systemd, AFAIK, shouldn't have any influence on how the interfaces work that are published to the outside. So I still don't get why internal interface instabilities are a problem.
Quote:
...Debian isn't the right place to be sending patches. As you point out, the coupling between GNOME and logind is GNOME's doing, not Debian's, and the coupling between logind and systemd-PID-1 is Lennart Poettering's doing, not GNOME's. Joining Debian isn't going to fix upstream's decision to mandate a particular init. Replacing the parts of the init system that they depend on (i.e. with loginkit and vdev) will. Moreover, working in an environment that promotes interoperability and values your contributions towards that goal means a lot to me. I'm not feeling that from Debian these days.
The point made was that Debian developers might reject patches that enable their packages to work with other init system. The countermeasure would have been to work together with those developers to get those patches into the packages and test them properly. For this kind of patches only Debian is the right place.
Quote:
It really sucks to be you if aren't going to use systemd but you rely on these programs, doesn't it?
Only if one just demands that software has to work the way one wants without joining upstream and working on it. That is the whole point I wanted to make. Isn't that one of the reasons that in the first place started the whole open source movement? The "hey, we don't want to maintain this anymore, but the code is free, so if you still want it work on it" thing? As I see it, there are three options:
1. The not desirable option: simply don't use what doesn't work as you like.
2. Fork it. Not really an option for larger projects, like KDE or GNOME, unless you have a whole bunch of developers at hand.
3. Most feasible option, IMHO: Join upstream to maintain that stuff that you need yourself.
Which is the point I wanted to make here:
Quote:
I don't follow you at all.
You seem to be assuming that by forking Debian, both the Debian and Devuan communities suffer from diminished manpower. This is patently false, for several reasons.
First, a developer in one community is a developer in the other--Debian's derivatives borrow code from Debian at no cost to Debian, and Debian borrows from their derivatives at no cost to the derivative (see how Ubuntu and Debian share patches and bug trackers, for example). There is no reduction in manpower.
Second, the existence of two different user communities that share a common core attracts more users than either could alone. Again, look at how many people use Debian derivatives--that's mostly Debian's code they're using, and that's mostly Debian's code they're submitting bug reports and patches for. But it wasn't Debian that attracted them--it was the derivative. All Debian has to do is watch their derivatives' repositories and merge code that they didn't have to write themselves (and sometimes, the derivative will even do the merging for them). Debian even has a process for interfacing with its derivatives for this very purpose: https://wiki.debian.org/DEX.
Third, the existence of two different developer communities with different design goals attracts more developers than either could alone. Even though it has different design goals, Devuan shares a lot of DNA with Debian, and you can bet that code that works on one will be easy to port to the other. I would not be writing vdev if it weren't for Devuan, but Debian gets to benefit as well. Same goes for the rest of Devuan's projects, and for all other derivative-created projects--Debian is made stronger because more developers are working on it.
It's not like derivatives exist in a vacuum, walled off from one another. We all share code and bug reports. The whole "forks divide communities and make both projects worse off" meme seriously needs to die, especially now that there is empirical evidence that the most common results of forks are either that one branch dies out (i.e. no long-term division of the community) or they both succeed in their own rights (i.e. the fork needed to happen). See http://flosshub.org/sites/flosshub.o...es/paper_0.pdf.
If Devuan people want a version of Debian that provides the choices they want, then the obvious course of action would be to join Debian and make that happen, not to fork away from it, claiming that you are the true Debian and Debian is now your downstream.
Quote:
Ask yourself this--if all we cared about was getting away from systemd, why would we be spending so much time building a Debian derivative instead of switching to Slackware or Void or Gentoo or whatever?
Because those people like Debian, they just don't like systemd. That is the only reason I see at all for Devuan to exist, the only reason why for Devuan people a fork is the better option instead of getting involved with Debian to shape it more like they would like to see it.
Just to make that clear: I am not opposed to the Devuan project. If you guys think that a fork is the only way to get a Debian that gives you what you want, then by all means, do it. I just don't think that it is a good idea and that the manpower now involved in developing Devuan would be better and more effective spent to make Debian the Debian you want.
Still, my questions remain: GNOME/KDE/whatever do not rely on systemd components, they rely on the interfaces provided by these components. The internal working of systemd, AFAIK, shouldn't have any influence on how the interfaces work that are published to the outside. So I still don't get why internal interface instabilities are a problem.
Any implementation of an API will be subject to the structural and semantic constraints it imposes. This is true for all software systems, not just systemd. Depending on what these constraints are, the interface to an application can effectively mandate that a re-implementation does not stray far from the reference implementation. The logind API makes sufficiently many semantic constraints that it mandates either logind itself, or something that works pretty much identically to logind (making it logind in all but name).
GetSession() may be used to get the session object path for the session with the specified ID. Similar, GetUser() and GetSeat() get the user resp. seat objects. GetSessionByPID() and GetUserByPID() get the session/user object the specified PID belongs to if there is any.
So, in order to implement this method correctly, a logind re-implementation must:
* have at least an opaque notion of what a "session object" is (i.e. "there is such a thing as a session object, and I know how to tell instances of them apart")
* be able to assign and query individual session objects by an opaque ID, such that each ID is assigned to at most one session object but each session object has exactly one ID
* maintain a binding between each session object and the PID of the process with which it is associated
* maintain a binding between each session object and the path to it
* provide a subsystem to keep track of a session object's lifetime, since PIDs and paths come and go
But, this is pretty much what logind itself already does. And these are the constraints on the implementation imposed by a simple getter method. Take a look at the other methods and the "session object" definition, and you'll find yourself with an even more constrained implementation that looks, feels, smells, tastes, and sounds like logind.
My point is, to say that "GNOME/KDE don't depend on logind, they just depend on something that implements its interface" is to make a distinction without a difference. It's the same as saying "$PROGRAM does not depend on UNIX, it just needs something that implements POSIX" while ignoring the fact that if an OS implements POSIX, it's certifiable as UNIX.
Internal interface instability is a problem if you want a long-term solution to using logind without systemd-PID-1 (i.e. cgmanager and systemd-shim will need to implement the unstable interface). It's part of the reason we're going with LoginKit for non-systemd users, since LoginKit needs neither cgmanager nor systemd-shim nor systemd-PID-1.
Quote:
The point made was that Debian developers might reject patches that enable their packages to work with other init system. The countermeasure would have been to work together with those developers to get those patches into the packages and test them properly. For this kind of patches only Debian is the right place.
Except Devuan is "getting those patches into the packages and testing them properly" as well--our packages are derived from Debian's, but with the patches applied. We're making sure they integrate well with the rest of Debian as a consequence of the fact that Devuan is identical to Debian in all other aspects. To this end, it doesn't matter which distro integrates the patches--the other one can port them with minimal effort, if desired.
At the time of this writing, it's trivial to disable the systemd dependency for a lot of packages--usually it can be done via a compile-time switch. For example, dbus in Debian depends on libsystemd0, but the need for it can be removed by compiling dbus without the systemd dependency. The dbus maintainer in Debian knows this, and yet keeps this dependency. The one in Devuan does not have this dependency. Other than this, our dbus packages are the same.
The reason we're maintaining forked packages is because "depend vs do not depend on systemd" is usually manifest as a packaging problem, not a code problem. A package can either depend on at least one part of systemd, or not depend on any part of systemd. It cannot do both at the same time. This means that regardless of how easy or hard it is to remove systemd dependencies from individual packages, removing chains of dependencies at the distro scale remains a difficult task. To support both dbus and dbus-nosystemd, Debian will need to either (1) get every package that depends on dbus to depend on dbus-nosystemd as an alternative, or (2) rename dbus to dbus-systemd and create a metapackage called "dbus" that depends on either dbus-systemd or dbus-nosystemd. This would need to be done for every single package that depends on some part of systemd.
This is where the problem becomes politically intractable. In order for Debian to incorporate the changes we want (i.e. change the dependency graph to allow for our non-systemd packages to be used in place of the systemd ones), we'd need the consent of every Debian Developer that has a package that depends on a package that depends on systemd through a chain of dependencies. Specifically, if a DD maintains package A, and A depends on B, and there exists a list of packages C[1]...C[N] such that B depends in C[1], C[i] depends on C[i+1], and C[N] depends on part of systemd, then we'd need the DD to allow A to depend on either B or B', where B' is our package that is built such that there is no such chain C[1]...C[N] in the archive. Even if we do all the work to make this happen, it only takes one DD to reject our changes for the task to be all for naught. For example, if a GNOME package maintainer decides for his/her package to not accept dbus-nosystemd in place of dbus, then all packages that depend on that GNOME package will pull in parts of systemd. I'd be willing to bet lots of money that at least one DD would be able to find a reason to keep at least one dependency chain in place, even while acting in good faith.
This brings me back to what I said in my previous post. Creating the fork is the best outcome for everyone. Debian don't have to deal with us, but they've lost no manpower and, through our efforts, have gained a larger audience (recall that Devuan includes users from outside of Debian) as well as code they can later incorporate at their leisure (in fact, this is already happening--see below). At the same time, we can do whatever we deem necessary without stepping on anyone's toes. Forking is the least-costly path to everyone getting their way.
Quote:
Only if one just demands that software has to work the way one wants without joining upstream and working on it. That is the whole point I wanted to make. Isn't that one of the reasons that in the first place started the whole open source movement? The "hey, we don't want to maintain this anymore, but the code is free, so if you still want it work on it" thing? As I see it, there are three options:
1. The not desirable option: simply don't use what doesn't work as you like.
2. Fork it. Not really an option for larger projects, like KDE or GNOME, unless you have a whole bunch of developers at hand.
3. Most feasible option, IMHO: Join upstream to maintain that stuff that you need yourself.
Option (3) is not feasible if upstream disagrees with the direction in which you want to take the project. If your ideas differ enough, they'll tell you to fork it or find an alternative if you don't like their decisions. Debian had a GR about this--they chose not to require DDs to accept patches for alternative inits, leading to the infeasible packaging situation I described above.
That brings us to option (2), which is where we are at today.
Quote:
Which is the point I wanted to make here:
If Devuan people want a version of Debian that provides the choices they want, then the obvious course of action would be to join Debian and make that happen, not to fork away from it, claiming that you are the true Debian and Debian is now your downstream.
We are trying to work with Debian--like I said earlier, Debian derivatives aren't isolated from one another or from Debian. For example, I just learned a few hours ago that the jenkins-debian-glue maintainer has accepted patches from us (see https://github.com/mika/jenkins-debi...bian/changelog, commits 74712ff and 3dd4a13).
Quote:
Because those people like Debian, they just don't like systemd. That is the only reason I see at all for Devuan to exist, the only reason why for Devuan people a fork is the better option instead of getting involved with Debian to shape it more like they would like to see it.
Just to make that clear: I am not opposed to the Devuan project. If you guys think that a fork is the only way to get a Debian that gives you what you want, then by all means, do it. I just don't think that it is a good idea and that the manpower now involved in developing Devuan would be better and more effective spent to make Debian the Debian you want.
Like I said earlier (and you can confirm on our ML), what fundamentally drives Devuan is the desire to preserve the user's freedom to install run whatever programs they want, however they want. While the increase in systemd dependency chains in Debian motivated us to get started, our goal is orthogonal to how any individual may feel about systemd itself. After all, Devuan wouldn't need to exist if our users' ex-distros offered systemd in such a way that they could uninstall it and install their init system of choice without breaking a bunch of other packages in the process.
Last edited by judecnelson; 05-03-2015 at 10:04 PM.
Any implementation of an API will be subject to the structural and semantic constraints it imposes. This is true for all software systems, not just systemd. Depending on what these constraints are, the interface to an application can effectively mandate that a re-implementation does not stray far from the reference implementation. The logind API makes sufficiently many semantic constraints that it mandates either logind itself, or something that works pretty much identically to logind (making it logind in all but name).
So, in order to implement this method correctly, a logind re-implementation must:
* have at least an opaque notion of what a "session object" is (i.e. "there is such a thing as a session object, and I know how to tell instances of them apart")
* be able to assign and query individual session objects by an opaque ID, such that each ID is assigned to at most one session object but each session object has exactly one ID
* maintain a binding between each session object and the PID of the process with which it is associated
* maintain a binding between each session object and the path to it
* provide a subsystem to keep track of a session object's lifetime, since PIDs and paths come and go
But, this is pretty much what logind itself already does. And these are the constraints on the implementation imposed by a simple getter method. Take a look at the other methods and the "session object" definition, and you'll find yourself with an even more constrained implementation that looks, feels, smells, tastes, and sounds like logind.
My point is, to say that "GNOME/KDE don't depend on logind, they just depend on something that implements its interface" is to make a distinction without a difference. It's the same as saying "$PROGRAM does not depend on UNIX, it just needs something that implements POSIX" while ignoring the fact that if an OS implements POSIX, it's certifiable as UNIX.
Internal interface instability is a problem if you want a long-term solution to using logind without systemd-PID-1 (i.e. cgmanager and systemd-shim will need to implement the unstable interface). It's part of the reason we're going with LoginKit for non-systemd users, since LoginKit needs neither cgmanager nor systemd-shim nor systemd-PID-1.
Thanks for the explanation, that makes sense to me.
Quote:
Except Devuan is "getting those patches into the packages and testing them properly" as well--our packages are derived from Debian's, but with the patches applied. We're making sure they integrate well with the rest of Debian as a consequence of the fact that Devuan is identical to Debian in all other aspects. To this end, it doesn't matter which distro integrates the patches--the other one can port them with minimal effort, if desired.
At the time of this writing, it's trivial to disable the systemd dependency for a lot of packages--usually it can be done via a compile-time switch. For example, dbus in Debian depends on libsystemd0, but the need for it can be removed by compiling dbus without the systemd dependency. The dbus maintainer in Debian knows this, and yet keeps this dependency. The one in Devuan does not have this dependency. Other than this, our dbus packages are the same.
The reason we're maintaining forked packages is because "depend vs do not depend on systemd" is usually manifest as a packaging problem, not a code problem. A package can either depend on at least one part of systemd, or not depend on any part of systemd. It cannot do both at the same time. This means that regardless of how easy or hard it is to remove systemd dependencies from individual packages, removing chains of dependencies at the distro scale remains a difficult task. To support both dbus and dbus-nosystemd, Debian will need to either (1) get every package that depends on dbus to depend on dbus-nosystemd as an alternative, or (2) rename dbus to dbus-systemd and create a metapackage called "dbus" that depends on either dbus-systemd or dbus-nosystemd. This would need to be done for every single package that depends on some part of systemd.
This is where the problem becomes politically intractable. In order for Debian to incorporate the changes we want (i.e. change the dependency graph to allow for our non-systemd packages to be used in place of the systemd ones), we'd need the consent of every Debian Developer that has a package that depends on a package that depends on systemd through a chain of dependencies. Specifically, if a DD maintains package A, and A depends on B, and there exists a list of packages C[1]...C[N] such that B depends in C[1], C[i] depends on C[i+1], and C[N] depends on part of systemd, then we'd need the DD to allow A to depend on either B or B', where B' is our package that is built such that there is no such chain C[1]...C[N] in the archive. Even if we do all the work to make this happen, it only takes one DD to reject our changes for the task to be all for naught. For example, if a GNOME package maintainer decides for his/her package to not accept dbus-nosystemd in place of dbus, then all packages that depend on that GNOME package will pull in parts of systemd. I'd be willing to bet lots of money that at least one DD would be able to find a reason to keep at least one dependency chain in place, even while acting in good faith.
I don't buy this. You are merely pushing the problem back, but are not solving it. This exact problem will come to bite you in the back once you have found the manpower to incorporate systemd into the Devuan repositories (after all, its all about choice, so sooner or later systemd has to be available in Devuan if you want to live up to those claims), and you will find, assuming the same good faith for Devuan developers that is assumed for the Debian developers, that there will be a developer who refuses to compile a package with systemd support or changing a dependency chain. So instead of solving that problem, you are recreating it in your project and pretending it doesn't exist because you simply have postponed it to a later date, while now, directly after the Jessie release, would be the best time to get the needed changes you rightfully pointed out off the ground in Debian.
Quote:
Like I said earlier (and you can confirm on our ML), what fundamentally drives Devuan is the desire to preserve the user's freedom to install run whatever programs they want, however they want. While the increase in systemd dependency chains in Debian motivated us to get started, our goal is orthogonal to how any individual may feel about systemd itself. After all, Devuan wouldn't need to exist if our users' ex-distros offered systemd in such a way that they could uninstall it and install their init system of choice without breaking a bunch of other packages in the process.
I tend to not believe that, until proven wrong by seeing a proper and fully fledged implementation of systemd in the Devuan repositories. Debian didn't even have packages for systems like OpenRC or Epoch (which has still no package), so they couldn't be used before systemd as default either, unless you hand-rolled them into Debian, so I don't believe the "systemd does prevent other init systems in Debian and we want to make it open to all" either, to me it seems to be just an excuse so that people don't have to say "I just don't like systemd" (which is in some circles a very unpopular opinion, though I think it is a totally valid one). FWIW, some anecdotal stuff, a few days ago I tested Debian 8 (LXDE version) with systemd and sysvinit to determine differences in memory usage and found not a little thing broken because of replacing systemd with sysvinit.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
Also, you may be pleased to know that our mailing list archive and development IRC logs are both public, as is our Git server:
