how hard is it to change init... automatically remixing trisquel live
since debian changed the default in version 8, the whole thing is over how hard it is to change init.
lets say there are 3 classes of systemd dependencies:
1. it doesnt need systemd (per se) but if you install the package it gets pulled in
2. it doenst need systemd (per se) but you have to recompile (not just repackage) the package to avoid it
3. it might run without systemd, though the dependency is in the code and you have to edit the code (not just recompile) to avoid it
most of the things that people say "require systemd" are in the first two classes of "dependency." on another distro it might not be needed, but in debian (and most derivs) it will be listed as a dep or compiled with the option to use it.
some packages can be compiled to not use it, but are compiled to use it. this is what ive read, at least.
so when i talk about automatically remixing trisquel live (thats what ive worked on for the past 2 days at least-- not all day) im talking about:
1. download iso
2. open iso
3. delete stuff
4. download add packages
5. create new bootable iso
and this is a process automated in fig (python 2, but you could also use pypy) so once youve done a little setup (create a couple folders, make certain things like unsquashfs tools and syslinux are available) then it goes to work creating the new bootable hybrid iso.
normally i do this with distros that have already worked around systemd. so this will show how trivial it is to have trisquel (live) without systemd, though i think the odds are good that libsystemd wont be so easy to get away from.
there are probably better ways to remaster trisquel specifically, i appreciate that. and ive used this method to remix a range of distros, some debian-based and some devuan-based and some not based on debian or devuan at all.
it does other things too-- it gets the new iso down to 1.3 by removing a lot of stuff that some users want but not every user wants on a live iso-- and instead of booting into mate it boots into icewm.
each feature is a pretty obvious group of lines of code, so suppose you dont want it to replace mate with icewm-- you just dont run that part. it can be commented out (or more classy, it can go in a conditional.)
if i get another init working (partly) i will update and ultimately share the code. if i dont get the init working, theres not a lot of point. but either way, changing inits will break some stuff no matter what.
so right off, the trisquel package relies on gnome-bluetooth which relies on systemd-related things that conflict with upstart being installed.
so this is the class 1 problem-- theres no reason trisquel should need gnome-bluetooth, if gnome-bluetooth depends on systemd being installed. effectively, the trisquel package has to be removed to install a different init. but alright, lets remove the trisquel package then.
we are also losing udisks2, gvfs (there goes mate) policykit-1 (printing, power-manager network-manager update-manager, ubiquity-- no installer, these all depend on policykit-1) oh, aptdaemon, language-selector-gnome
all this stuff depends on things that freedesktop (or debian, depending on which package) has tied to systemd. pulseaudio (of course) so no sound for firefox (recent versions of which require pa) and we still have 25 removals to go...
brasero, gnome-system-tools, caja, mate-applets, oh-- there goes mate-panel
aaaaaaand, we have resolved dependencies.
now if we also removed libsystemd0, we lose (for starters)
bsdutils util-linux cups-daemon dbus! inputattach libaccountservice0 libdbus-1-3 libpolkit-backend-1-0 libpolkit-backend-gobject-0 libprocps4 libpulse0 mate-system-monitor ofono openvpn rsyslog!
so rsyslog depends on libsystemd0 (in trisquel, in trisquel. probably in most debian-based distros. possibly not in devuan.) might as well make the kernel depend on it, too.
well, lets remove the pre-libsystemd0 dependencies (perhaps now you know why devuan was able to remove libsystemd in 1.0 but not in 2.0) and find out if it still boots.
(this could take a while. i can probably do it from the package manager in a chroot but i havent automated this yet. ive never selected upstart as an init either.)
the log from the modified live running from qemu: https://ptpb.pw/naS1
> theres no reason trisquel should need gnome-bluetooth
The 'trisquel' package is not for the base system. It's for the default desktop environment, which needs a bluetooth utility. This part isn't so strange to me.
> gnome-bluetooth depends on systemd being installed
This part is a little strange to me. the gnome-bluetooth package is present in GuixSD, which does not include systemd (GNU Shepherd is the init system) so I don't see why systemd needs to be a dependency.
Unnecessary dependencies can be removed from the deb package.
$ apt download [package]
$ tar x [package]*.deb
$ tar -xzf control.tar.gz
(edit 'control' and remove the dependency)
$ tar -cvzf control.tar.gz control
$ ar rcs newpackage.deb debian-binary control.tar.gz data.tar.xz
$ sudo dpkg -i newpackage.deb
I've used this to install packages without a particular dependency. However, without understanding exactly how your remixing works I don't know if this helps with your current situation.
> pulseaudio (of course) so no sound for firefox
I really wish Mozilla had not made the decision to require pulseaudio for sound. I understand their reasoning, which is that most people use pulseaudio and that the decision reduces work for Mozilla developers. However, pulseaudio is not suitable for audio production, and musicians (admittedly a minority of GNU/Linux users) require JACK instead. This creates problems, since JACK and pulseaudio cannot use the same soundcard simultaneously.
The workarounds I'm aware of are
- bridging pulseaudio and JACK with pulseaudio-module-jack
- running Firefox with apulse
But it's rather inconvenient to have to do these things when Firefox is the only program most people use that requires pulseaudio.
"The 'trisquel' package is not for the base system. It's for the default desktop environment, which needs a bluetooth utility. This part isn't so strange to me."
it is strange to me that that the desktop "needs" a bluetooth utility, to the point where removing the utility breaks the desktop. to me, that seems like an obvious call for a recommend... but maybe the updates might not work reliably then. (and why isnt trisquel called trisquel-desktop? except there is a package called trisquel-desktop-something i think.)
either way, i only mentioned it first since its the first thing that broke when i tried to change inits. remove systemd? immediately "trisquel" (desktop) is broken because gnome-bluetooth needs systemd.
i did state that these are "class 1" (simple) deps because theyre at the package level. i mean other than the package level, removing systemd wouldnt break "the desktop" imo. so im not trying to make this sound like a bigger deal than it is. im actually trying to quantify it.
_
"This part is a little strange to me. the gnome-bluetooth package is present in GuixSD, which does not include systemd (GNU Shepherd is the init system)"
thats why i bring classes into it. guix doesnt use apt of course, and you dont have any class 1 dependencies from debian in it. so the fact that it works in guix probably only helps prove that this is a class 1 or class 2 dependency. but it actually just leans that way.
_
"Unnecessary dependencies can be removed from the deb package."
$ apt download [package]
$ tar x [package]*.deb
$ tar -xzf control.tar.gz
(edit 'control' and remove the dependency)
AWESOME. i did not know how to do this, already this thread has advanced something. i also thought you needed ar to open a .deb package. i didnt know tar was up to it.
_
$ tar -cvzf control.tar.gz control
$ ar rcs newpackage.deb debian-binary control.tar.gz data.tar.xz
oh, there it is.
very cool though! thanks very much.
_
"I've used this to install packages without a particular dependency. However, without understanding exactly how your remixing works I don't know if this helps with your current situation."
potentially by leaps and bounds. not that most of my remixing doesnt get this far into packages because i usually starts with systemd-free distros. but if i choose to work on this part of it, this is what i would need, thank you.
_
"The workarounds I'm aware of are
- bridging pulseaudio and JACK with pulseaudio-module-jack
- running Firefox with apulse"
"But it's rather inconvenient to have to do these things when Firefox is the only program most people use that requires pulseaudio."
good ideas. i have to reiterate in the event i was misunderstood, there are 3 potential levels of "depends on" regarding systemd.
so there are things ive listed as "breaking" when you remove systemd, and im using the word "depend" at least in the packaging sense. i created the original post by running aptitude and trying to install upstart-sysv instead of systemd, and simply noting what had to be removed in order to proceed.
so im not trying to say that any example here actually "requires" systemd in any other way than that. some examples probably do require it-- especially when we get into libsystemd0. devuan has gone backwards with removing that from 1.0 to 2.0 (last i checked.)
but for a lot of these dependencies it is as "simple" as repackaging or recompiling. i definitely didnt say or imply otherwise.
and thanks again, some awesome stuff in there.
it is strange to me that that the desktop "needs" a bluetooth utility, to the point where removing the utility breaks the desktop.
Trying to remove both "gnome-bluetooth" and "libgnome-bluetooth13" does not trigger the removal of any MATE component on my system. So, I am not sure what you mean by "breaks the desktop".
why isnt trisquel called trisquel-desktop? except there is a package called trisquel-desktop-something i think.
It is called "trisquel-desktop-common". As the name suggest, "trisquel", "trisquel-mini" and "triskel" depend on it. The other desktop environment do not use GNOME Bluetooth. That is why "gnome-bluetooth" is a dependence of "trisquel", which defines, along with "trisquel-recommended", the default (MATE) edition of Trisquel.
i did state that these are "class 1" (simple) deps because theyre at the package level.
What do you mean by "package level"? Package maintainers do not add useless dependencies. If systemd is a dependency, then either GNOME Bluetooth or one of its dependencies (or a dependency of a dependency, etc.) uses some feature that systemd provides. It is possible that a precompilation option or a configuration flag allows to recompile without that reliance on systemd and a new package could be built. That certainly means losing features though.
Trying to remove both "gnome-bluetooth" and "libgnome-bluetooth13" does not trigger the removal of any MATE component on my system. So, I am not sure what you mean by "breaks the desktop".
originally i said (because this is exactly what happens) that if you remove systemd it breaks the gnome-bluetooth package. it does-- run aptitude and select upstart-sysv and select it instead of systemd and gnome-bluetooth will break.
it also breaks the trisquel package. i call it "the trisquel package" because it is a package, named simply "trisquel." i was told this is the desktop, not trisquel base, but i have no horse in that race. "why not call it 'trisquel-desktop' then?" i figured its because there is at least one other package with that name/namespace.
_
"It is called "trisquel-desktop-common". As the name suggest, "trisquel", "trisquel-mini" and "triskel" depend on it."
yeah, i get all of that. its an aside from my original two posts, and latches on to a response i made to someone telling me what the trisquel package is. it really doesnt matter a whole lot what the "trisquel" package is, actually. but most likely, it just makes it easier to pull in updates.
its a very very minor part of what i was talking about, and only in the context of what someone else claimed.
_
"Package maintainers do not add useless dependencies. If systemd is a dependency, then either GNOME Bluetooth or one of its dependencies (or a dependency of a dependency, etc.) uses some feature that systemd provides."
if you are suggesting that there are zero dependency issues that can be resolved simply by repackaging unmodified binaries, i believe the devuan team has done exactly this on occasion.
besides, even if there are no "useless dependencies" there are nonetheless "unwanted dependencies," and there are varyind degrees of how vital those dependencies are.
for example-- firefox requires pulseaudio which requires libsystemd0. so perhaps its not unreasonable to make a firefox package that requires the pulseaudio package. then you pull in libsystemd0 every time you install a browser.
since there are other ways to get sound from firefox (and since most websites work without sound, for that matter) i would consider pulseaudio optional in more ways than one.
some of these decisions come down to the convenience and opinion of the maintainer, not down to a flawless hierarchy of requirements. firefox may or may not be a good example.
i was not attempting to prove any of this, however. i was simply trying to categorise the 3 levels of dependency that already exist.
_
"It is possible that a precompilation option or a configuration flag allows to recompile without that reliance on systemd and a new package could be built. That certainly means losing features though."
yeah, one feature it would lose is systemd. i hear its doable, ive used several distros over the past few years that demonstrate this.
dont forget, that individuals are often happy to give up a feature they dont need, to get rid of a feature they dont want. traditionally, debian-based distros have done a really fine job of supporting that.
ian jackson (with debian since its first year in 1994) is still fighting in the mailing lists for that support to continue. this probably has only minor implications for trisquel, though i was already aware of what init trisquel would likely be using next, before the switch.
the goal here is to find out how much trisquel is still capable of once you remove systemd. that has implications for how much actually "requires" systemd, but without covering certain specifics even that idea (what actually requires systemd-- and in what way or to what extent is it required) is meaningless.
imo the best way to demonstrate the answer is by removing the easiest-to-remove parts of systemd, and then document whats still working. in the process, a bootable version of trisquel is possibly created that to varying degress, does not require systemd. at least thats what im working on at the moment.
it also breaks the trisquel package. i call it "the trisquel package" because it is a package, named simply "trisquel."
The package named "trisquel" is a meta-package. Same thing for "trisquel-recommended", "trisquel-base", "trisquel-base-recommended", "trisquel-desktop-common", "trisquel-desktop-common-recommended", "trisquel-codecs", "trisquel-minimal", "trisquel-print-system", etc.
Being a meta-package means only existing to ease the installation of a bunch of packages: the dependencies of the meta-package. In other words, a meta-package does not install anything by itself (except for a "changelog" file and a "copyright" file in /usr/share/doc). That is why removing a meta-package makes no difference. It does not "break" anything. At all. It only means you do not have Trisquel's related default set of packages installed. Removing *any* package in the default system will trigger the removal of "trisquel" (or only "trisquel-recommended").
if you are suggesting that there are zero dependency issues that can be resolved simply by repackaging unmodified binaries, i believe the devuan team has done exactly this on occasion.
Do you have any reference?
the goal here is to find out how much trisquel is still capable of once you remove systemd.
Given that you consider the removal of the "trisquel" package as "breaking trisquel" (what shows you do not understand the concept of meta-package), you will conclude that systemd breaks Trisquel... and you would conclude the same with any package in the default system.
Given that you consider the removal of the "trisquel" package as "breaking trisquel" (what shows you do not understand the concept of meta-package), you will conclude that systemd breaks Trisquel... and you would conclude the same with any package in the default system.
this is exactly where i thought you were going with this.
i didnt "conclude" that "systemd breaks trisquel (the distro)". i described the trisquel package as breaking (package dependency-wise, which it absolutely does, and ive already invited you to go see for yourself by opening an application and checking it) when you replace the systemd package (by selecting upstarts sysv)
youre trying to twist complete facts into false conclusions i havent made, and the goal is obviously to try to cast a dubious light on what im saying. however-- what youre saying has so little to do with anything im saying, that youre only making things complicated and getting far away from any point i was making.
your post suggests that im making some kind of sophomoric beginners mistake that you can correct, but it addresses something i didnt say-- your previous post was a warm up to the same.
maybe youre not trying to be condescending, but if youre truly married to the idea that im that naive, youre unlikely to get what im saying anyway. lets not not waste my time or yours on that line of "debate" where its 99% distractions about semantics and irrelevant minutiae and 1% substance.
and ive known what a meta-package is for years. but why are we even talking about that?
youre building a straw man based on taking words ive said and putting them in slightly different contexts they werent said in so you can "prove" what someone else doesnt know.
why this is sneaky: you can then deny that was your intention in the first place, "i really didnt understand, you should be more clear!" and im "just taking it personally"
but whats changed in this thread is weve gone completely from me talking how im remixing trisquel and what my experience is to you challenging me to prove i even know what a meta-package is.
thats not an accidental trajectory, and please knock it off. i have no desire to prove anything to someone who goes out of their way to insist i dont know the basics, because someone invested in that isnt going to admit when a point is made-- i debate with people that are intellectually honest, this is just a game to you-- go troll someone else.
"Do you have any reference?"
no double standards, here-- these posts are based entirely on experience and recent experimentation, i am outlining the experience so far. so far youve provided zero references yourself and from the beginning this thread was about an experiment, while you are picking endlessly with the most minor points made and demanding references now? im not interested.
"hey guys, im working on this thing."
"YOURE WRONG AND YOU DONT KNOW WHAT YOURE DOING!"
"um, what?"
i will just get back to it then, and report when ive done more. if and when the live version doesnt have systemd as init i will post the code that creates it under a free license.
i didnt "conclude" that "systemd breaks trisquel (the distro)". i described the trisquel package as breaking (package dependency-wise, which it absolutely does, and ive already invited you to go see for yourself by opening an application and checking it) when you replace the systemd package (by selecting upstarts sysv)
Of course it does. Removing *any* package that is part of the default edition of Trisquel removes "trisquel" and/or "trisquel-recommended". Those meta-packages *define* the default system. If you really understand that, why do you even mention it?
If you really understand that, why do you even mention it?
because, very simply-- i was describing what happens when you try to remove systemd.
and although its hardly a huge deal, that is one of the things that happens when you do that. i listed quite a few other things that happen as well. short answer: "for completeness."
i really must point out that each time you and i have interacted-- not only today or in this thread-- you have put more and more effort into trying to challenge the most unimportant aspects of what ive said. none of the things youve challenged are that key to what im doing, none of the things youve tried to point out are real revelations (closer to repeated attempts to condescend) and none of the questions-- for clarification or elaboration or citation, moved in any direction other than farther from the topic.
youre just challenging me for the sake of doing so, and its becoming increasingly obvious and silly. when i start ignoring your responses entirely-- very very soon, at this rate-- that will be the reason why. from what youve said so far, you must think i just picked up ubuntu yesterday, rather than 13 years and several dozen distros ago. go right ahead with that. good luck. i would say let me know when you have a real question-- you havent had one yet, and youre not going to either.
The reason for this is because of the "Depends: udev" line here:
$ apt-cache depends gnome-bluetooth
gnome-bluetooth
Depends: bluez
Depends: bluez-obexd
Depends: udev
Depends: libpam-systemd
Depends: libc6
Depends: libglib2.0-0
Depends: libgnome-bluetooth13
Depends: libgtk-3-0
Conflicts:
Breaks: gnome-shell
Recommends: gvfs-backends
|Recommends: unity-control-center
Recommends: gnome-control-center
Recommends: gnome-user-share
From a purely technical perspective I don't think it's necessary to remove gnome-blueooth at all to achieve your goal of avoiding a dependency on systemd.
What gnome-bluetooth depends on is udev. udev existed on its own for many years before becoming part of systemd.
Simply packaging eudev (which is a fork of udev without systemd) would be enough, and then either change the gnome-bluetooth bluetooth dependency from udev to eudev, or have the eudev listed as "providing" udev. Either method should satisfy the dependency and allow keeping gnome-bluetooth without systemd and the associated dependency breakage. The latter is probably easier because it would keep editing packages to a minimum.
This should also fix dependency breakage caused by other packages that need udev too.
So really all that you've discovered is that part of replacing the init system means you'll need eudev instead of systemd. This should not be news. Programs have needed udev for years, even before systemd was even a twinkle in Lennart Poettering's eye. You can't just rip out their dependency and say that they're broken without trying to replace it. Well, I guess you can because you did. :)
So if your goal was to show that you can introduce package breakage by removing dependencies and then not replacing them you have succeeded. Congratulations. Next: I wonder how much breakage really happens if you try to replace Trisquel's init system *correctly*. :) My theory is that there should be very little. Part of moving to a different init system correctly means you will need to package up some additional programs (like eudev) in order to avoid the breakage you have been causing.
Even the Guix people got GNOME to work without systemd by providing their own version of logind, called elogind. That was enough to avoid depending on systemd:
https://savannah.gnu.org/forum/forum.php?forum_id=8491
So, depending on where you want to go with your modified version of Trisquel, you may need that too in order to avoid breakage as you move to a different init system. And possibly others.
"So really all that you've discovered is that part of replacing the init system means you'll need eudev instead of systemd. This should not be news."
its definitely not news! ive used devuan since a month after a bootable iso was available, also gnuinos and refracta and miyo (not to mention my own fig os.)
all of which replace the init (revert to pre-systemd) and eudev was either used (i think) or proposed at one point. in fact the eudev "author" (maintainer) joined the project. there were even hopes and dreams of "vdev" (a completely indepedent udev replacement, which eudev was/is not) but i dont think those were ever realised, at least in devuan.
_
"Programs have needed udev for years"
which i dont dispute-- in fact im not really disputing much of anything youve said here-- although i do think its key that udev is now folded into systemd. to say "it needs udev but not systemd" is almost inaccurate except as we both know, theres eudev (and vdev.)
its really about context. in everything ive said about systemd on the trisquel forum-- is not about systemd universally (nor am i trying to paint it as such) but just systemd wrt to trisquel live and out of the box.
having used devuan, i know it is different there. having read about the status of gnome with bsd and/or gentoo, i know it is different there.
its even different with debian, because they dont use upstart. so the method of "getting rid of" systemd in debian and trisquel differs (but is similar.)
_
"So if your goal was to show that you can introduce package breakage by removing dependencies and then not replacing them you have succeeded. Congratulations."
oh, come on... my goal was clearly stated: to create a live trisquel version/deriv/toy/whatever that removes as much of systemd as reasonably possible. if that wasnt clear, it should be now.
when i responded to one person here, magic latched onto our exchange and started taking my responses to one person out of context. i responded to what someone else said, then magic responded as though it were my comment originally (he should have ideally addressed the person that actually made the comment.)
now youre (albeit more politely, thank you) taking my responses to magic out of context in a similar fashion. let me remind you what i just said the goal was. i think it was very clear what i was doing before people started jumping into the thread the middle.
_
"Part of moving to a different init system correctly means you will need to package up some additional programs (like eudev) in order to avoid the breakage you have been causing."
theres no point in telling me how to do this "correctly," im already content with the results of my effort so far. feel free to tell the trisquel devs how to do this correctly, so far they arent doing it at all. (well? wheres the version of trisquel that has eudev packaged as the alternative? ok, so thats a fair statement-- if far from the point i was making.)
i didnt cause the breakage, jx, apt did. unless by "cause" you mean "selecting ONE (1) package to install." then yes, file the bug report with yours truly. i selected upstart-sysv. note that i dont actually put the blame on the trisquel devs for this breakage either. so dont instigate something there.
_
"Even the Guix people got GNOME to work without systemd by providing their own version of logind, called elogind"
elogind ive heard of-- guix using it i have not. so when i thank you for letting me know this, it is sincere (i thought elogind was a bsd or gentoo fork, albeit of a systemd component, but im glad guix can use this.)
"So, depending on where you want to go with your modified version of Trisquel, you may need that too in order to avoid breakage"
since my approach is to do the simplest/easiest things first (and document the effects) then what i intend to do first is just change which packages are installed-- the step where you blamed me for breaking something.
all i did was select a single package in the repo to install and resolve the broken dependencies. i believe the word "broken" is the vocabulary used by apt, let me check:
"The following packages conflict with upstart-sysv and will be broken by its installation."
why i have to be tied the whipping post for reporting things neither of us consider news (but it is context/relevant, and thats why i said it) in the language that trisquels own software uses, i can only imagine is your idea of fun-- i would like to know why thats even considered okay.
(and before you even go there-- YES! i know trisquel didnt invent apt! for one, i used apt before trisquel existed...)
i am still in the process of automating the change in packages in the live iso. because i have a way of doing this that relies on practically zero debian/trisquel-specific packages, i am going with doing it that way.
however, one thing i want to point out to you is-- regardless of whether aptitude says the packages will be "broken" by installing upstart-sysv, you and banana both tried to make that into me claiming was some kind of "big deal" or "news."
hopefully this post resolves that once and for all. if not, then i really dont know what to tell you. but thank you for the note about guix. good old elogind...
systemd: "if you think just trying to work around it is a tiring, ongoing barrage of labyrinthine minutiae-- try posting about the progress on a forum!"
You knew that things like eudev and elogind weren't in the Trisquel repositories when you started right? So why not try adding them during the step #4 of your process?
1. download iso
2. open iso
3. delete stuff
4. download add packages
5. create new bootable iso
Because otherwise your method was doomed to fail from the start since there's no udev replacement. I guess what I'm saying is that your remix *could* have been successful if stuff like that had been done.
If you're interested, try to get eudev and elogind and etc. into the official Trisquel repositories. Or, make your own third party repo and put it them there (until/unless it gets into Trisquel.) It should make your life of living in a systemd-free world easier. Since things like this are not currently available in Trisquel, I suspect that methods such as yours to remove systemd are guaranteed to result in breakage since there isn't anything else (like eudev) there to replace the functionality. Unless one somehow limits themselves to programs that don't need udev. Perhaps it would be easier to remove the upstart package from Trisquel until/unless this stuff becomes available. Perhaps there's a bug report in all of this this: To do one of those things.
"Try to get eudev and elogind and etc. into the official Trisquel repositories."
a very good idea and indisputably constructive. definitely not what i was planning, but worth considering.
"Or, make your own third party repo and put it them there (until/unless it gets into Trisquel.) It should make your life of living in a systemd-free world easier."
not really the goal-- i am honestly perfectly happy with the systemd-free choices that exist at the moment. i am very much toying with creating a different one. while the debate is a bit tiring, im happy with the technical effort (and results) so far.
_
"Since things like this are not currently available in Trisquel, I suspect that any attempt to remove systemd is guaranteed to result in breakage since there isn't anything else (like eudev) there to replace the functionality."
sure, but as was explained to me a while ago, if you remove something that is depended on by something else-- voila, it is broken (in one sense or another.) i mean we do all get that, theres no one here that doesnt get that.
on the other hand-- i also think its probably possible to use trisquel without systemd. i have not once said otherwise, but i have had a few words either put in my mouth or placed in contexts that change the implication.
and i would like to demonstrate the possibilities there-- ranging from at least the very simple (booting without it) and probably not devuan-level repackaging and recompiling (im not likely to fork trisquel or become a full-time maintainer. this is just a fun project.)
_
"Perhaps it would be easier to remove the upstart package from Trisquel until/unless this stuff becomes available."
that would certainly stop people from toying around and trying to have options in trisquel, other than that i cant imagine what what the advantage would be-- the only confusion caused so far by the existence of the upstart package (that im aware of) is the confusion you and magic appeared to express when you considered the implications of things i said taken out of context.
i like to think the trisquel maintainers have got better things to do than resolve needless disputes by killing off legitimate trisquel packages that might even be useful to someone.
_
"Perhaps there's a bug report in all of this this: To do one of those things."
i think youre bluffing, but lets find out how far youre willing to go. file the report, i assume youll be asked to explain the reason. i look forward to reading it.
for all the nonsense that debian has gone through over this, even they havent deleted the alternative packages that trigger the removal of systemd. at least not 3 or more years since. lets find out if youre actually serious about going one step further than debian did, just to make a point.
besides, id be eager to find out the devs reaction to that report. let it be noted i still have some faith in the devs there.
just to save you a trip to your bookmarks: https://devel.trisquel.info/groups/trisquel/-/issues
you can be sure of this much-- if applying upstart-sysv to my software setup actually results in a bug report to remove it so that i cant install it-- other people are going to hear about it and have a better laugh at trisquel than youre having on me right now. so let me call your bluff.
on the other hand if the goal is to help trisquel, id agree wholly with your suggestion about eudev or elogind. that would certainly be an accomplishment for this thread, and i would have to hand it to you for a great idea proposed and executed.
"id agree wholly with your suggestion about eudev or elogind. that would certainly be an accomplishment for this thread, and i would have to hand it to you for a great idea proposed and executed."
It's 24979.
I'll also be seeing Rubén next month when he goes to SeaGL. I'll try to remember to mention it but no promises. I'm not sure what he thinks about the whole topic.
https://trisquel.info/en/issues/24979
utterly brilliant, thank you.
"no promises."
no worries.
i would note this has no immediate impact (possibly none whatsoever) on what im doing, but im not saying that to be negative-- on the contrary, if your bug report does more than my project (and it may well do) i will be just as pleased with your bug report as i am with my project.
"Because otherwise your method was doomed to fail from the start since there's no udev replacement. I guess what I'm saying is that your remix *could* have been successful if stuff like that had been done."
its hardly doomed to fail, so far it has accomplished everything ive set out to do with it. (it could be days, even a week.) im very close to finding out if it the first objective will be achieved. ive pointed out where the problems are, but theyre really not that bad in my opinion. if you install gnome-bluetooth, it will most likely undo what ive done. thats not my concern or my problem.
as for getting farther into removing things like libsystemd0, thats where these extras could be useful. but thats different than "doomed to fail." more like "doomed to get more complicated in ways that i would have come to expect after 3 or 4 years of experience with distros that remove systemd." doomed to that? sure. without a huge and unexpected bit of luck, yes. my goal wasnt necessarily to get that far into the removal. after all-- even devuan 2.0 (last i checked) is keeping libsystemd0 and doesnt have gnome either. so why would i ever try to do more than their entire cluster, with a tiny little remaster script?
I am a translator!
that would certainly stop people from toying around and trying to have options in trisquel, other than that i cant imagine what what the advantage would be-- the only confusion caused so far by the existence of the upstart package (that im aware of) is the confusion you and magic appeared to express when you considered the implications of things i said taken out of context.
I think the issue is that it isn't packaged correctly as it's missing essential components (such as eudev) and of course it is in conflict with Systemd which Trisquel has chosen to use (just like Hyperbola removes anything that depends on Systemd and replaces them with OpenRC versions and thus doesn't let Hyperbola users mess around with Systemd if they only use the official repos).
cant believe i got downvoted for saying im working on a project to remix trisquel.
i thought maybe the second post would get one for the snippy comment about the kernel, but not the one where i simply outlined the project.
tough crowd! everything else i said was just facts. how do you downvote facts? i did put this in the troll section because i figured it would only cause trouble somewhere else. i honestly wanted to minimise that. but this is trisquel, and this is software freedom-- and this is how software freedom works-- downvote that!
you guys go to all this trouble so that everyone has:
"The freedom to run the program As You Wish, for any purpose (freedom 0)." https://i.imgur.com/IOVgFBQ.jpg
"The freedom to study how the program works, and change it so it does your computing As You Wish (freedom 1)."
but here is someone is actually using that freedom, not asking you for anything at all-- only now thats a problem (for some mysterious undisclosed reason...)
whats up?
The purpose of downvoting is community self-moderation. Since your comment did not violate any community guidelines[1] it was improperly downvoted. I've cancelled out the improper downvote, which is what upvoting is for.
I've suggested before that up/down votes be replaced with a "flag as inappropriate" button that then prompts the user to specify which community guidelines was broken, which can be cancelled out by other users with an "improperly flagged" button. After the forum is redesigned, I'll submit a feature request if the issue is not already addressed.
If someone disagrees with a post that respects the community guidelines, a downvote is not a very helpful way to express that disagreement.
systemd is indeed controversial, but one improper downvote is not something to take personally or judge the entire community by. I've seen plenty of downvotes that were for no discernible cause. Sometimes it's just trolling.
[1] https://trisquel.info/en/wiki/trisquel-community-guidelines
"systemd is indeed controversial, but one improper downvote is not something to take personally or judge the entire community by."
oh, dont worry about that. i just saw it as an opportunity to make a few more points. after all, i was hoping for a real response, more like yours. i thought id written at least 99% of what i did in a way that earned it (subject to opinion of course.) since we agree it wasnt the best response, i simply used it as an opportunity to comment on freedom. "tough crowd!" was just tongue in cheek, its not like i was dogpiled or anything.
"I've seen plenty of downvotes that were for no discernible cause. Sometimes it's just trolling."
thats too bad. rest assured that i do not judge the entire community by one persons actions-- i only speak in broad terms because many of us (myself also) like to frame things in "principles" here when we can.
science is sort of like that too: "start with things that are expected to be common across the known universe, and work down from there." it would be nice if that automatically made us right too, but its more like a first step on the way to figuring something out.
I am a translator!
freemedia, good luck on your attempt to free Trisquel of systemd.
I don't think I'll use Trisquel though regardless of Systemd as Ubuntu LTS releases (on which new Trisquel releases are based) are very insecure by design (as the universe user community repo does not generally receive any updates). Of course Trisuqel could probably be used with universe disabled and by compiling all non-main repo packages from source (or adding random PPAs) but in this case it's probably better to just use a different distro. Ubuntu short term releases are better from a security standpoint since you never run very old versions of software packages, but Trisquel no longer releases versions based on them (they stopped in version 5.5).
this concept of newer=better security isnt something im familiar with.
updated for security fixes yes, newer=better security, no. any feature can introduce a security vulnerability, only security fixes actually improve security.
so what you really want is (slightly) older versions a la debian stable, plus security fixes. newer ubuntu versions could actually be less secure, but they have more new features. someone with a security background please refute if im mistaken. otherwise, debian should base their server releases on ubuntu because theyre newer. that doesnt ring true, though.
"good luck"
thank you. i hope you realise im not so concerned if youre wrong, but i thought it was worth defending trisquel on this one, since i think theyre probably doing the right thing there (or at least, doing no wrong there.)
I am a translator!
If you are going to run software without any updates at all (which is usually the case for the universe repository) then it's better to use short term service releases as even if the packages in the short term releases contain security vulnerabilities malware exploiting these vulnerabilities might not exist yet (but if your software is old enough then the likelihood of such malware existing is much higher).
so what you really want is (slightly) older versions a la debian stable, plus security fixes.
This is what Hyperbola does and yes it is better than running newer releases without getting security updates. If you needed to rank these three in security order (old software without updates, new software without updates, old software with security updates) then the ranking from most to least secure would usually be as follows:
old software with security updates
new software without updates
old software without updates
fair enough, but thats actually making three compromises to security in the name of security:
1. by running newer versions of free software that could introduce new problems and have undergone less testing.
2. by running the universe repo, which is full of untrusted software, right?
3. by not running updates that include security fixes (though i was hesitant to add this as it might not apply to your edge case, or it might only be an exception where it is irrelevant.)
i would guess that most trisquel users avoid all of these compromises, so even if youre right it would be a triply-irresponsible decision for trisquel from a security standpoint... better security for an edge case, worse overall. but i may have missed something in your reply. apologies if so.
edit:
"the ranking from most to least secure would usually be as follows:
old software with security updates
new software without updates
old software without updates"
hmm, alright. when you put it that way, sure. but just so we are clear-- you were saying you dont prefer trisquel for an edge case, where they have actually made the right security choices for most uses, right? if so, i misunderstood what you were saying originally.
I am a translator!
Trisquel does not usually update software in the universe repository which has most of the software people use such as VLC, Mplayer, AQEMU (QEMU GUI), FBReader, Liferea feed reader, MusicBrainz Picard, subtitleeditor, SimpleScreenRecorder and FileZilla. Users of that repository might expose themselves to security risks which become higher if they run the old software for longer periods of time.
would it be fair and/or accurate to say that most of those applications would rely on libraries that are not in universe but main-- and that updating them would not address most vulnerabilities, since most vulnerabilities would actually be in the dynamic libraries found in the main part of the trisquel repo?
my background is not in security, and this not an entirely rhetorical question.
I am a translator!
I think it depends on the programme.
VLC, Mplayer and simplescreenrecorder depend on ffmpeg which is part of universe as well, Picard includes acoustic fingerprinting support via libchromaprint-tools which is also part of universe.
Software such as axel and aria2 (download accelerators) only depends on main libraries but some command line programmes like mediainfo and subtitleeditor include universe dependencies (e.g. ZenLib and C++ interface to the GNOME XML library respectively). The file splitter and joiner lxsplit and the nfo viewer nfoview depend only on (very few) main packages.
Also AQEMU only depends on main packages (qemu is in main).
As regards the other packages I mentioned: FileZilla depends on on wxWidgets Cross-platform C++ GUI toolkit from universe, Liferea seems to only depend on main packages and FBReader depends on ZLibrary packages from universe.
The main repository receives security updates, so if you install a universe package depending only on main packages then you should be mostly secure regardless of whether the package receives updates.
Note that some popular libraries are also part of universe, such as par2.
A quick search shows almost every package I can think of is in universe: xchat, polari, gajim, foxtrotgps, goldendict, grsync, handbrake, dillo, links, elinks, epiphany-browser, gnome-hearts, kodi, linphone, mkvtoolnix, pan, transmission, guvcview, mpv, gtk-recordmydesktop, wireshark(??), xsane(??) (to be fair simple-scan is in main), ufraw, gthumb, firmware-ath9k-htc(??), audacious, tanglet, tali, neverball, neverputt, fotoxx, supertux, extremetuxracer, xournal...
?? - expresses my amazement at the package being in universe.
yeah for starters, anything that gets run as root the ideal would definitely be to get it out of universe, right?
I am a translator!
Yes - you can find threads online discussing the lack of security updates for universe packages such as these:
https://www.reddit.com/r/debian/comments/3mxzmr/is_debian_really_more_stable_than_ubuntu_for/
https://www.reddit.com/r/linux/comments/4pjevd/debian_better_security_than_ubuntu/
https://www.reddit.com/r/Ubuntu/comments/gph7n/dont_use_universe_repo_if_you_care_about_security/
unless this is an overstated problem-- which i would be willing to hear arguments for, it seems like this calls for a better free repo that trisquel could access.
since universe is basically just a repo of free software. also seems like room for something like snap to work-- not snap as done by ubuntu, but snap as done by the free software community.
i know there is resistance to this idea. im not talking about that at the moment, this is in the context of what youre telling me. any thoughts on that?