an offer to create a non-systemd trisquel variant
- Anmelden oder Registrieren um Kommentare zu schreiben
Threads like this[1] pop up periodically, and have got me thinking: If I put some time into it I'm pretty sure I could create a non-systemd variant of Trisquel. I've gotten Debian working without systemd, and although an Ubuntu-derivative like Trisquel might be more difficult due to Canonical's tendency to make use of systemd-specific features in Ubuntu-specific software, it should be feasible. However, such a thing would not be of much use to me personally, and I not sure how many other people would use it either, since most users on this forum seem happy with systemd, and many of the ones who dislike systemd have found other distros that they prefer.
So I'll tell you what: If enough people (1) confirm that they would actually use a non-systemd Trisquel variant and (2) are willing to each donate some money to help cover my time and expenses, I will create a non-systemd version of Trisquel 9. Here would be the roadmap:
(1) Create a custom repository containing any additional/modified packages needed to use Trisquel without systemd, and a recipe for adding this repository to a fresh netinstall of Trisquel 9 and migrating to SysVinit.
(2) Create a graphical ISO that can run a live session only.
(3) Add a working text mode netinstaller to the ISO.
(4) Add a graphical installer to the ISO. This would probably be Calamares rather than Ubiquity (Trisquel's default installer), because I know from experience that I can get Calamares working without systemd with very minimal tweaking. If anyone has a strong preference for Ubiquity, I can look into it.
(5?) If my changes seem like they would make sense to include in Trisquel proper, I'll submit a merge request. Whether or not the changes would be accepted is out of my control.
I'd rent a VPS for the build system and to host the repository and ISO. 10 USD/month should cover this cost, which would be ongoing unless/until the changes were eventually accepted into Trisquel proper and separate infrastructure was no longer necessary. In addition, I'd ask for some additional donations to help compensate me for my time, as I'm not currently in a position to work on something like this completely gratis. This will also help determine whether or not this is worthwhile. If not enough people want this badly enough to donate, then it may not be worth doing. There are already three FSF-endorsed distros with non-systemd support (Parabola, Hyperbola, and Guix), so I'm only going to go out of my way to add a fourth if it would actually be useful to people.
If anyone is interested in this idea, let me know.
[1] https://trisquel.info/en/forum/systemd-free-trisquel-variant
Thank you very much for your selfless offering.
Basically there are two options for a systemd-free version, namely SysV init and OpenRC.
There's another question. What is the relationship between this systemd-free variation and the upstream Debian/Devuan?
> Basically there are two options for a systemd-free version, namely SysV init and OpenRC.
SysVinit is what I would usehere, because I've gotten Debian working with SysVinit and would want to reuse that experience. I have nothing against OpenRC, but I have less experience with it.
> What is the relationship between this systemd-free variation and the upstream Debian/Devuan?
This would involve porting certain Devuan and Debian packages to Trisquel, for example:
* Trisquel's MATE edition uses indicator applets, several of which depend on systemd, as well as some Ubuntu-specific packages to system libs. Debian's repositories includes packages from the Ayatana[1] project, which aims to create cross-distro versions of Ubuntu's indicator applets. Ubuntu-specific patches are not a problem for Trisquel, as long as they do not introduce freedom issues, but since Ayatana indicators appear to be less tied to systemd, they are likely to be more compatible with a non-systemd Trisquel version. For example, Ubuntu Bionic's indicator-datetime[2] could be replaced by Debian Bullseye's ayatana-indicator-datetime[3].
* As of version 241, libelogind0 is ABI compatible with libsystemd0, meaning it can be used as a drop-in replacement to support packages that have been compiled against libsystemd0. However, Debian stable currently has elogind 239 (and Ubuntu/Trisquel does not have elogind at all), so to have a stable version of libelogind0 that is ABI compatible with libsystemd0 I would probably use Devuan Beowulf's v241 package.
These packages would be compiled against Trisquel/Ubuntu's system libs, but kept up-to-date with Debian/Devuan for bug fixes and security updates.
[1] https://wiki.ubuntu.com/Ayatana
[2] https://packages.ubuntu.com/bionic/indicator-datetime
[3] https://packages.debian.org/bullseye/ayatana-indicator-datetime
I would be willing to donate a minimum of $10 a month if you could accept Paypal or setup a Liberapay; Patreon; etc. Possibly more if I am able to but a minimum of $10 USD. For me there really isn't much of an option for a systemd less variant. Parabola and Hyperbola are a pain to get installed and going in comparison to Trisquel. I gave up an hour of my only day off last week trying to get them installed but failed. I tried GUIX and while the install is easy, the day to day use of it is way too terminal focussed for my liking. I think a Trisquel version would still would be a worthwhile project.
In an ideal world, each distribution would come with as many variants as there are init system candidates.
This is such an unexpected proposal that I'd rather take some time to ponder over it, the main reason being that the real world not being ideal, trade-offs need to be made:
1) Trisquel being by far the most family ready libre OS to date, I have no doubt that this is the place where improvements of this kind should be applied.
2) Libre software thrives because of its peculiar mix of diversity and compatibility, so any attempt to steer clear from technological monopolies of any kind is welcome. I am not sure whether the current init system is the most problematic component of our daily computing activities in that regard. It might still be the most readily acted upon though.
3) I have the same question as nadebula.1984 about Devuan.
4) I have not myself, as a user, be suffering from systemd. In fact it feels that it solved many glitches which were previously plaguing some GNU/Linux distros. Maybe this is an optical illusion and these were solved not by systemd itself but simply by the continuous debugging applied to any init system in use in large parts of the ecosystem. However, I cannot help fearing this could be an attempt to fix something which is not broken.
5) I would be willing to commit to a monthly $10 to $20 to such a project, provided the above points can be cleared.
Thank you anyway for taking this into your own hands and making this proposal.
> 1) Trisquel being by far the most family ready libre OS to date, I have no doubt that this is the place where improvements of this kind should be applied.
I think the best place to apply such improvements is generally as far upstream as possible, so that it works its way down to all downstream distro, and Debian has indeed made some efforts toward SysVinit compatiblity. However, for some reason Ubuntu appears to have rejected these changes. Debian Bullseye and later has a version of libelogind0 that can replace libsystemd0, and yet for some reason Ubuntu does not have libelogind0 in its repositories at all. A non-systemd Trisquel will need to port some packages from Debian/Devuan in order to bypass Ubuntu's decisions.
> 2) Libre software thrives because of its peculiar mix of diversity and compatibility, so any attempt to steer clear from technological monopolies of any kind is welcome. I am not sure whether the current init system is the most problematic component of our daily computing activities in that regard.
I don't think init systems are the biggest problem either, but it's something that a few people have asked about, and something that is not otherwise on Trisquel's roadmap, so I thought I'd check and see who's interested.
> 4) I have not myself, as a user, be suffering from systemd. In fact it feels that it solved many glitches which were previously plaguing some GNU/Linux distros.
Trisquel works perfectly fine as-is. I am not trying to convince people who like systemd to stop liking it. I'm only proposing an alternative for those who want one.
Thanks, I'll be off pondering now.
EDIT: I am currently trying Devuan Beowulf. As much as I appreciate Trisquel, I would not like to be pushing for yet another "fork" for the sake of an alternative init system if some popular DFSG compliant distro already ships with it.
EDIT: I have made up my mind. I would personally rather keep using Trisquel with systemd than switch to a "liberated" Devuan. So it would be giving you the wrong incentives and in my humble opinion also wasting your time and energy to ask you to implement the proposed modified version of Trisquel. I meant that Trisquel would be the right place to implement such a change in comparison to other, less turnkey FSF approved distros which have already implemented it, but I agree that upstream is where the init system change should be done. This will happen if some day it is decided to base Trisquel on Devuan. If I was adamant about using SysVinit I would switch to Devuan and do what needs to be done to keep it free and blobless. People who care about their init system are more than capable of doing that themselves.
I am keeping my "+" vote on your OP because otherwise I would be voting it down as there is no cancel button, while I still think it is a good idea to improve diversity at all levels.
Hello
I don't like systemd. But not only.
I like Ubuntu and Trisquel approach to make life easier for users, not for hackers.
Thank you very much @chaosmonk for your offer, but I prefer to migrate in the future to a distro like Hyperbola.
I like Hyperbola philosophy and steps for the future, they don't like to depend on decisions "above".
I would like more an Hyperbola for users.
First, thanks chaosmonk for the offer. I think you are one of the most important/capable/useful people on the community around here.
Second, I am not knowledgeable enough about the difference between init systems to really make a call here. I do know a lot of people didn't like systemd (as I understand because it integrates things into one single system, being anti-KISS, is that right?), but I can't say I noticed any difference and don't mind using Trisquel as it is.
Finally, I think I would prefer to have a man of your abilities and energy and good will focused on other matters, which may prove more important in the near future.
Again, thanks for all your hard work, you set an example for people on this community, and I am lucky to be able to be a part of the same said community.
I support this idea.
Since Debian-base is more compatible for conversion into sysV system than Ubuntu-one, does this mean that there is a chance that for example Trisqel 11 will be based on Debian?
I'd be willing to throw some cashola into a project like this. More than that, if you'd teach me how to help you I'd like to be involved in getting it off the ground. I've been doing some packaging lately for a sysvinit distro, using sbuild and pbuilder. I need someone to mentor me in Debianizing source code.
You have my email address, chaosmonk - email me when you have time.
I would love this, I'm using Devuan because of this. It would be also nice once Trisquel 10 has support for a systemD-less system, it would be nice if we can get Dotnet 5 (It's MIT licensed) compiled for Trisquel. I tried to compile a GPL licensed application that depends on a version of DotNET Core that I don't have of which is dependent on a version of LLVM that I don't have and can't compile.
While DotNET is MIT licensed, I'm not trusting M$' pre-compiled binaries or the security holes in Flatpack and Snap that can mess with my BASHrc and gain root that way.
There would also be software patent liabilities in my country, but that would be a transitional thing like MP3 and Jpeg, I would say those standards are still relevant today and will be relevant for the foreseeable future and h264's patents will be in public domain in 5 years and it will still be relevant. Sometimes proprietary standards stay relevant even after their monopolization ended. I would say a lot of people would call themselves "minimalists", but have different minimal standards. Emerging technologies of the next 10 years would be so efficient, I would imagine they would still be relevant in 2050 as Huffman coding is today.
- Anmelden oder Registrieren um Kommentare zu schreiben