https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-re...
two years. that's how long one of these bugs has been in systemd. *via a remote network*. what the hell is an init system doing being accessible *via DNS queries*?
for anyone who still believes that systemd is okay to use and deploy, and that there exist "great advantages that outweigh the risks", are you *finally* getting the message now?
dozens of distros, millions of people, all affected by the irresponsible act of switching "en-masse" to a single over-reaching init system which is developed in a fashion that is not being properly managed or controlled. i do not understand why people do not understand this.
l.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-re...
two years. that's how long one of these bugs has been in systemd. *via a remote network*. what the hell is an init system doing being accessible *via DNS queries*?
If you read the summary of the article to the second line, you'll note that it is talking about 'systemd-resolved' -- so not the init at all.
Yes, I know that it was stupid to call all these disparate bits of the SystemD project systemd-$whatever, becuase it's just asking for people to do what you just did, but I really expect _you_ to understand that there is more than one executable involved in systemd, and that not all of them can possibly run as process 1, all at once.
On my fairly default stretch laptop, systemd-resolved is not running.
On free.hands.com, to which you have access, it is also not running.
So, to answer your qustion, well, it isn't ... obviously.
Might I ask in response: What the hell are you doing not fact checking this before repeating it? It's not as though this is the first time that an anti-systemd story has been spun to the point of becoming nonsense.
I'd imagine that this has managed to go undetected for so long because most people have no interest in running this program on anything but containers (which is what it's for AFAIK) and that anyone sensible is firewalling those containers to make sure that the only DNS server they talk to is the one they control that is running on the physical host.
Cheers, Phil.
On Mon, Jul 3, 2017 at 9:26 AM, Philip Hands phil@hands.com wrote:
Might I ask in response: What the hell are you doing not fact checking this before repeating it?
because in the scheme of programs-that-constitute-systemd it really doesn't matter, phil. the slashdot report also includes a link to this second discovered flaw:
https://ma.ttias.be/giving-perspective-systemds-usernames-start-digit-get-ro...
once those have been fixed, there will be more severe bugs discovered. and after those, yet more discovered. it's never going to end... and that's just the security aspect.
the situation before systemd was that we had quotes imperfect quotes disparate programs that were managed by completely different teams. the actual init system(s) that used those programs did not "develop" significantly because... basically they did not *need* actual development.
now we have the most dangerous situation where power is concentrated into the hands of a few *known* irresponsible developers who simply *do not know when to stop*.
i cannot think of anything more dangerous to the entire software libre eco-system than 98% of GNU/Linux distros having abdicated power and responsibility into the hands of lennart pottering and his team.
l.
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
On Mon, Jul 3, 2017 at 9:26 AM, Philip Hands phil@hands.com wrote:
Might I ask in response: What the hell are you doing not fact checking this before repeating it?
because in the scheme of programs-that-constitute-systemd it really doesn't matter, phil.
...
Are you aware of confirmation bias?
Might I recommend this book to you:
http://www.pinterandmartin.com/irrationality.html
(I see there's a new edition, which I've just ordered as the update is almost certainly as interesting as the original. So, thanks for giving me a reason for looking up the canonical URL -- I look forward to re-reading it :-) )
Cheers, Phil.
On Mon, Jul 3, 2017 at 10:06 AM, Philip Hands phil@hands.com wrote:
Are you aware of confirmation bias?
you're talking to a reverse-engineer, so you know that i am.
the problem is that there are so many different "signs" from so many different directions that it becomes completely overwhelming to enumerate them all, track them all down, and describe them all.
but, worse than that, if i *was* to enumerate them all there would be not a single person on the planet willing to read everything that i wrote.
more than that, it would take such a long time that i would run out of patience well before i completed any such "report".
this is a *systemic* problem, phil. the actual source code - and the flaws *in* that source code - are merely symptoms of an underlying "illness" within the software libre community that has absolutely nothing to do with technical mastery.
remember, you're talking to someone who notices far more than they can actually describe in words, who takes in sparse and disparate information from a huge array of sources (and draws correct conclusions that other people simply cannot achieve... or, unfortunately, accept). we can get hung up on the details if you like, but that will not help (at all).
l.
On Mon, Jul 3, 2017 at 4:40 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
the situation before systemd was that we had quotes imperfect quotes disparate programs that were managed by completely different teams. the actual init system(s) that used those programs did not "develop" significantly because... basically they did not *need* actual development.
now we have the most dangerous situation where power is concentrated into the hands of a few *known* irresponsible developers who simply *do not know when to stop*.
But we still have that situation. As Phil said, systemd-resolved is not used by default on (at least) Debian Stretch, and from the sound of things it's not used on most other distros either. The systemd developers wrote a local caching resolver daemon, and distros can either choose to use it, or not. You can still use dnsmasq, or not have a caching resolver at all, or... etc. There's nothing stopping you!
It's true that the systemd developers have also written replacements for existing software that *have* been widely adopted, notably systemd-logind in favor of ConsoleKit. But ConsoleKit's original developer(s) have stopped maintaining it, which I'd imagine is part of the reason distros started moving to logind. (There is the ConsoleKit2 fork, but I'm not sure how much traction that's gotten.)
On Mon, Jul 3, 2017 at 3:00 PM, Jonathan Frederickson silverskullpsu@gmail.com wrote:
It's true that the systemd developers have also written replacements for existing software that *have* been widely adopted, notably systemd-logind in favor of ConsoleKit. But ConsoleKit's original developer(s) have stopped maintaining it, which I'd imagine is part of the reason distros started moving to logind. (There is the ConsoleKit2 fork, but I'm not sure how much traction that's gotten.)
there's a misconception that software that does its job actually needs "development". good stable software that does a job and does it well (the unix philosophy) often simply needs "maintenance" only - keeping up-to-date with dependency changes, tool changes, 64-bit ports and architecture ports and so on. the problem is: maintenance is a really boring job. so after a few years, people... stop doing it. at that point the software is often considered "abandonware".
sadly it sounds like consolekit suffers (suffered) such abandonment... ironically by virtue of having become stable (and thus boring to work on). so i'm not really sure what to say, particularly as consolekit is something that is pretty damn necessary. it's a bizarre situation.
l.
On Mon, Jul 3, 2017 at 10:24 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
there's a misconception that software that does its job actually needs "development". good stable software that does a job and does it well (the unix philosophy) often simply needs "maintenance" only - keeping up-to-date with dependency changes, tool changes, 64-bit ports and architecture ports and so on. the problem is: maintenance is a really boring job. so after a few years, people... stop doing it. at that point the software is often considered "abandonware".
Right, and notably also security fixes.
But my point is I don't think it's useful to demonize the systemd developers for writing their own version of software for which the alternatives are no longer maintained. (Or even software which still has actively maintained alternatives, honestly!) systemd-resolved is just another caching resolver, systemd-logind is just another session manager, etc.
People have always done this, it's just that the systemd folks are writing their own versions of lots of different services. And that's okay! You're free to use them, or not, as you choose. (Granted in most cases it's the distro maintainer's choice, as it is for all the other default software in their distro.)
On Mon, Jul 3, 2017 at 3:38 PM, Jonathan Frederickson silverskullpsu@gmail.com wrote:
People have always done this, it's just that the systemd folks are writing their own versions of lots of different services. And that's okay! You're free to use them, or not, as you choose.
... actually... we (the users) are in no way "free". constraints such as time, effort, money and risk (which are usually offset by collaborative effort) all come into play and take precedence over whether the *source code* happens to be libre.
(Granted in most cases it's the distro maintainer's choice, as it is for all the other default software in their distro.)
... exactly. this is what particularly pisses me off about how systemd has been deployed: all possible alternatives across 98% of distros - particularly the major ones - have ripped up and burned pretty much all and any possibility of **CONVENIENT** choice.
for example, until i discovered that angband.pl actively maintains systemd-less debian packages for xorg, udev, pulseaudio and several critical pre-systemd packages (including consolekit), i was forced to make an extremely risky *MANUAL* removal of systemd. that included REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i also had to add a hundred entries into /etc/modules - some of which i could not determine so had to actually not have access to critical hardware for a considerable amount of time.
you *really* want to tell me that i am quotes free quotes to make such unbelievably risky decisions, on a live-running mission-critical system that has no regular backups?
this one example underscores that "freedom" - having access to the source - is no longer the only factor, meaning that we are heavily and critically deependent on decisions made by distro maintainers.
unfortunataly, many people who committed to a particular distro, and implicitly trusted the distro maintainers, have been betrayed. the choice (or expectation)? f*** off and find yourself another distro. except that too is a betrayal of trust: the amount of effor it takes to convert a live-running mission-critical system over to a completely new distro? that people would even consider suggesting that users should convert live-running systems is... words fail me.
l.
this one example underscores that "freedom" - having access to the source - is no longer the only factor, meaning that we are heavily and critically deependent on decisions made by distro maintainers.
Again, this has always been the case! Unless you're packaging things yourself, you're dependent on the distro maintainers (or sometimes the upstream developers) to package them for you, or you have to install them outside the package manager which carries its own set of risks.
The distro maintainers have to manage their (often limited and unpaid) time wisely. In Debian's case, choosing systemd as the init system means that package maintainers only have to write much shorter systemd service files instead of longer sysvinit-style startup scripts. As a developer, I can certainly understand that decision.
Perhaps software freedom alone is no longer enough, and in some cases I agree. But in this case, I don't think I can fault Debian (as a volunteer project) for not wanting to do work they don't have to.
Jonathan Frederickson silverskullpsu@gmail.com writes:
this one example underscores that "freedom" - having access to the source - is no longer the only factor, meaning that we are heavily and critically deependent on decisions made by distro maintainers.
Again, this has always been the case! Unless you're packaging things yourself, you're dependent on the distro maintainers (or sometimes the upstream developers) to package them for you, or you have to install them outside the package manager which carries its own set of risks.
The distro maintainers have to manage their (often limited and unpaid) time wisely. In Debian's case, choosing systemd as the init system means that package maintainers only have to write much shorter systemd service files instead of longer sysvinit-style startup scripts. As a developer, I can certainly understand that decision.
It's unfortunate that systemd is seen as necessary to get these shorter service files for service declaration. Or that sysvinit requires you to write long complicated init scripts.
Rather than replacing the init system, it would be possible to write a standalone tool to interpret service files that sysvinit can call.
This works because sysvinit and other early UNIX init systems are written as separate components, that interact by running other exectuables/commands. This is the opposite to how systemd is architected where it moves more functionality into the same executable, making it less flexible and extensible as a result.
On Mon, Jul 3, 2017 at 12:35 PM, Adam Van Ymeren adam@vany.ca wrote:
It's unfortunate that systemd is seen as necessary to get these shorter service files for service declaration. Or that sysvinit requires you to write long complicated init scripts.
Rather than replacing the init system, it would be possible to write a standalone tool to interpret service files that sysvinit can call.
This works because sysvinit and other early UNIX init systems are written as separate components, that interact by running other exectuables/commands. This is the opposite to how systemd is architected where it moves more functionality into the same executable, making it less flexible and extensible as a result.
Of course that's possible! It's just that (AFAIK) nobody has done it yet. I'm sure the users of non-systemd init systems would appreciate such a tool, given the increasing number of projects that ship with only systemd service files upstream.
The question remains: who's going to write it?
On 2017-07-03 at 11:34:29 -0400, Jonathan Frederickson wrote:
The distro maintainers have to manage their (often limited and unpaid) time wisely. In Debian's case, choosing systemd as the init system means that package maintainers only have to write much shorter systemd service files instead of longer sysvinit-style startup scripts. As a developer, I can certainly understand that decision.
for the sake of accuracy, I'd like to point out that Debian's developers are still adding sysvinit startup scripts, or at least maintaining the existing ones (altought "patches welcome" is very much the approach in the case of new ones).
sysvinit is still a supported init system in Debian (and still the default on the non-linux port, which are not release architectures but are still pretty maintained); the main reason why this may change in the future is if there is no longer anybody who cares about it enough to at least report bugs, but ideally also support the developementĀ¹.
what is not supported is having a system that is completely purged of any reference to the systemd libraries, even if they just point to shim code, because that would require distributing multiple binary packages for a lot of source packages, and that is not really suitable to the way debian works.
The main victim to debian choosing to default on systemd, up to now, has been upstrart, and that only because upstream (Canonical) stopped supporting it. However, from the point of view of independence from a single corporation that would have been even worse.
Perhaps software freedom alone is no longer enough, and in some cases I agree. But in this case, I don't think I can fault Debian (as a volunteer project) for not wanting to do work they don't have to.
Indeed, volunteer time is seriously limited, and there are things that are just beyond what can be expected from them.
E.g. if a mayor DE would start requiring systemd to work, Debian would not be in the position to fork it, but that doesn't mean that non-systemd users will be forced to migrate to systemd, just that they would have to use one of the many other DE available in Debian.
Ā¹ this is not that unlikely, however: there have been a number of calls for help because the numbers of complaints on the mailing list is much higher than the number of people actually giving even a tiny bit of help in ensuring that sysvinit continues to be tested and supported in Debian, and if nobody tests it, eventually it will bitrot and stop working.
Indeed, volunteer time is seriously limited, and there are things that are just beyond what can be expected from them.
E.g. if a mayor DE would start requiring systemd to work, Debian would not be in the position to fork it, but that doesn't mean that non-systemd users will be forced to migrate to systemd, just that they would have to use one of the many other DE available in Debian.
Ā¹ this is not that unlikely, however: there have been a number of calls for help because the numbers of complaints on the mailing list is much higher than the number of people actually giving even a tiny bit of help in ensuring that sysvinit continues to be tested and supported in Debian, and if nobody tests it, eventually it will bitrot and stop working.
That is why, runit and openrc are badly needed as options but no matter what, the developers of debian had no right to force all packages to require systemd if they are calling their distro "universally free or free software" because that is the opposite of how free software is supposed to work.
We really shouldn't put all are eggs in the same basket. Due to the number of holes that may exist. also, this makes it easier I am sure for the NSA and other corporate firms I am sure to hack into us. but meh go ahead and support a broken init especially the same one that many other distros use that if people figure a way out to hack in a specific way... has a domino effect... This may be hypothetical, but I am unnerved by this idea that's all. I may lack information but I am sure Luke knows far more terrifying details than I am suggesting...
That's my last thought on this hopefully for a while. ;)
TBH I'd remove systemd from my copy of Mint, but I'd be afraid to break it. No, not because of systemd itself -- because of me. Things tend to break when I tinker with them, lol, especially when they're as complicated as a modern OS is.
So I guess I'll live with it for now.
On Mon, Jul 03, 2017 at 06:32:00PM -0400, zap wrote:
Indeed, volunteer time is seriously limited, and there are things that are just beyond what can be expected from them.
E.g. if a mayor DE would start requiring systemd to work, Debian would not be in the position to fork it, but that doesn't mean that non-systemd users will be forced to migrate to systemd, just that they would have to use one of the many other DE available in Debian.
Ā¹ this is not that unlikely, however: there have been a number of calls for help because the numbers of complaints on the mailing list is much higher than the number of people actually giving even a tiny bit of help in ensuring that sysvinit continues to be tested and supported in Debian, and if nobody tests it, eventually it will bitrot and stop working.
That is why, runit and openrc are badly needed as options but no matter what, the developers of debian had no right to force all packages to require systemd if they are calling their distro "universally free or free software" because that is the opposite of how free software is supposed to work.
Openrc is included in Debian. If anybody asked me to add support for its configs for whatever packages I maintain, I guess the approach would likewise be "patches are wellcomed", but there are also no packaging tools for that, which makes the required patches larger, I believe.
I would probably also not be able to easily be able to debug those.
On Tue, Jul 4, 2017 at 7:55 AM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
Openrc is included in Debian.
that's new (and fantastic to hear) - it appears that openrc is interoperable with initscripts so in theeorryyy there shouldn't be any need to submit new configs (start/stop scripts for services).
l.
On 2017-07-04 at 10:04:03 +0100, Luke Kenneth Casson Leighton wrote:
On Tue, Jul 4, 2017 at 7:55 AM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
Openrc is included in Debian.
that's new (and fantastic to hear) - it appears that openrc is interoperable with initscripts so in theeorryyy there shouldn't be any need to submit new configs (start/stop scripts for services).
It was one of the candidates considered when deciding what init system to adopt, altought it had much less support than systemd or upstart (and I suspect it's even less tested than sysvinit).
But, most maintainers are going to be happy to receive patch to improve support for it (just like they are for sysvinit), even if they may not be interested in creating them themselves.
I've found that the first traces of it are in 2012:
https://lists.debian.org/debian-devel/2012/04/msg00547.html
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
Openrc is included in Debian.
It was one of the candidates considered when deciding what init system to adopt, altought it had much less support than systemd or upstart (and I suspect it's even less tested than sysvinit).
yeahh it was a pity it hadn't had as much mindshare: i've installed it by default on the parabola gnu/linux-libre eoma68-a20 images and, whilst it works well, it feels a little... odd. perhaps that's down to being unfamiliar with it, or that parabola / archlinux requires that if you install e.g. openssh you have to remember to install openssh-openrc and then also run a manual command to make sure it's enabled at boot time (pacman lacks the postinst functionality of dpkg, and archlinux itself seems to lack the concept of setting up "default configured behaviour" for services, leaving that to the user themself).
one good thing: i wasn't aware that openrc could be parallelised: it's as simple as adding rc_parallel="YES" to /etc/openrc.conf which i will try out very shortly.
back when the openmoko came out, you remember you bought one phil, and told me that it was terribly unresponsive? they used an ARM9 processor, which has a very poorly-designed 1st level cache. on the ARM9, thread/process context-switching results in COMPLETELY throwing away the contents of the 1st level cache.
so any context-switch - x11, d-bus, parallel startup, whatever - resulted in performance that was last seen when sysvinit was initially designed, because it *was* designed [N decades ago] to start services *in series* so that context-switching could be minimised as much as possible.
unfortunately, developers who primarily use x86/amd64 forget that it is only intel / AMD processors that have heavily-optimised context switching: hyperthreading, 4 or more cores / hardware-threads (usually, these days), 1st level cache that's often larger than the 2nd level cache of embedded processors and so on...
... so they design software that really only works well on x86. i remember around 2004 running opie / familiar on 600mhz Intel ARM PXA 270 processors (before PXA was sold to marvell) and the boot time was often in the *TWO MINUTE* range. god only knows what would happen if systemd was deployed on such processors.
systemd unfortunately makes heavy use of d-bus for message-passing. unlike most client-server RPC architectures, d-bus acts as an INTERMEDIARY. that makes for DOUBLE context-switching. client SWITCH d-bus-as-intermediary SWITCH server. for *each part of a round-trip*. that means *FOUR* context-switches for a simple "request-response" as opposed to just two for any other client-server RPC architecture.
the heavy usage of d-bus for the openmoko OS basically was part of what killed the project. it would not surprise me at all to find that d-bus is similarly slowing systemd down when compared to other init systems.
anyway i'll dig the parabola microsd card out again, switch to parallel openrc and boot it up. it might be a bit much for the A20 to handle, but we'll soon see.
l.
On Tue, Jul 4, 2017 at 11:44 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
anyway i'll dig the parabola microsd card out again, switch to parallel openrc and boot it up. it might be a bit much for the A20 to handle, but we'll soon see.
ok we're looking at a 21 second boot time to the lightdm login manager with rc_parallel="YES" in /etc/rc.conf and around 25-26 seconds without. to the serial console prompt is around 16 seconds with rc_parallel="YES" and around 20-21 without.
for a 1ghz dual-core embedded processor either isn't bad, and performance does appear to be improved. the amount of time spent by the 3.4.104 kernel in initialising hardware (and informing me about it) does seem to be considerable: around 5-8 seconds of the entire boot time!
l.
On Tue, Jul 04, 2017 at 11:44:33AM +0100, Luke Kenneth Casson Leighton wrote:
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
Openrc is included in Debian.
It was one of the candidates considered when deciding what init system to adopt, altought it had much less support than systemd or upstart (and I suspect it's even less tested than sysvinit).
yeahh it was a pity it hadn't had as much mindshare: i've installed it by default on the parabola gnu/linux-libre eoma68-a20 images and, whilst it works well, it feels a little... odd. perhaps that's down to being unfamiliar with it, or that parabola / archlinux requires that if you install e.g. openssh you have to remember to install openssh-openrc and then also run a manual command to make sure it's enabled at boot time (pacman lacks the postinst functionality of dpkg, and archlinux itself seems to lack the concept of setting up "default configured behaviour" for services, leaving that to the user themself).
one good thing: i wasn't aware that openrc could be parallelised: it's as simple as adding rc_parallel="YES" to /etc/openrc.conf which i will try out very shortly.
Likewise is Debian's variant of sysvinit (and systemd, of course).
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
...
the heavy usage of d-bus for the openmoko OS basically was part of what killed the project. it would not surprise me at all to find that d-bus is similarly slowing systemd down when compared to other init systems.
The way that d-bus was used in OpenMoko was astonishing, and is really not something one can use to criticise d-bus in general. Not that I'm trying to say that d-bus is particulalry lovely, but what you're doing here is like saying that micrometer screw guages are rubbish becuase you once saw someone using one as a hammer, and they hurt their thumb.
The program that ran most of OpenMoko was written on the assumption that it would be very soon replaced by separate components that would all pass messages around via d-bus (a stupid design, given the hardware), then time ran out and that prototype was what shipped.
The result being that if one got an incoming call, it would provoke a cascade of (IIRC 7) d-bus interactions that were all being answered by call-backs in the single program that was doing everything. Each one went via a kernel context switch (or two?), dumping the cache, and that meant that it would take at least 5 seconds for the ringer to start ringing after a call came in, a few more seconds to show you the screen with the answer button, a second or two for your mad tapping to be noticed, during which the accelerometer would realise that it needed to swap portrait for landscape (repainting the "cancel" button where the "answer" used to be) and then finally it would process your demented attempts to answer the sodding thing as a call rejection. Marvelous.
Enrico Zini worked all that out, and then knocked up a very short script that waited for calls, made the ringer ring, and looked out for a button press on the physical button -- that allowed it to behave quite like a phone with no fuss.
If anyone wants an OpenMoko, I have one going cheap :-/
Cheers, Phil.
On Wed, Jul 5, 2017 at 6:49 PM, Philip Hands phil@hands.com wrote:
The program that ran most of OpenMoko was written on the assumption that it would be very soon replaced by separate components that would all pass messages around via d-bus
ah! 12+ years i'm glad someone remembers. i got the trolltech greenphone, not an openmoko
The result being that if one got an incoming call, it would provoke a cascade of (IIRC 7) d-bus interactions that were all being answered by call-backs in the single program that was doing everything. Each one went via a kernel context switch (or two?), dumping the cache, and that meant that it would take at least 5 seconds for the ringer to start ringing after a call came in, a few more seconds to show you the screen with the answer button,
... which was painted with x11 so that meant many more more context-switches and cache-dumps because x11 is a client-server architecture...
a second or two for your mad tapping to be noticed, during which the accelerometer would realise that it needed to swap portrait for landscape (repainting the "cancel" button where the "answer" used to be) and then finally it would process your demented attempts to answer the sodding thing as a call rejection. Marvelous.
... didn't you have call-forwarding such that there wasn't enough time to actually answer the call anyway? :)
Enrico Zini worked all that out, and then knocked up a very short script that waited for calls, made the ringer ring, and looked out for a button press on the physical button -- that allowed it to behave quite like a phone with no fuss.
dang. *sigh* nokia's low-cost mobile phone OS (symbian?) at least was well-designed (or, designed for purpose).
If anyone wants an OpenMoko, I have one going cheap :-/
ah that would be good to use for the GTA04 motherboard replacement oh wait damnit that didn't go so well, they used a package-on-package TI SoC and DDR sandwich, where the processor was only designed for very specialist mass-volume manufacturing, was made too thin (to save cost) and warps under standard PCB assembly (ovens)... they got something like a SEVENTY SEVEN PERCENT failure rate during a pre-production manufacturing run.
http://laforge.gnumonks.org/blog/20170306-gta04-omap3_pop_soldering/
l.
zap calmstorm@posteo.de writes:
Indeed, volunteer time is seriously limited, and there are things that are just beyond what can be expected from them.
E.g. if a mayor DE would start requiring systemd to work, Debian would not be in the position to fork it, but that doesn't mean that non-systemd users will be forced to migrate to systemd, just that they would have to use one of the many other DE available in Debian.
Ā¹ this is not that unlikely, however: there have been a number of calls for help because the numbers of complaints on the mailing list is much higher than the number of people actually giving even a tiny bit of help in ensuring that sysvinit continues to be tested and supported in Debian, and if nobody tests it, eventually it will bitrot and stop working.
That is why, runit and openrc are badly needed as options but no matter what, the developers of debian had no right to force all packages to require systemd if they are calling their distro "universally free or free software" because that is the opposite of how free software is supposed to work.
WTAF?
There is no "forcing" or "requiring" involved, and people spouting this bullshit is getting _really_ old now.
If any such radical change had actually been enacted then:
a) well, we'd be in a different universe, where Debian was run by some sort of overlord who was prone to making snap decisions on a whim.
b) there would have been a mass bug filing for all these packages that did not require systemd, to somehow add that requirement.
c) there would have then been a vast wave of new package uploads with the new packages, encumbered with those requirements.
NONE OF THIS HAPPENED.
Debian didn't even make it so that other inits were somehow downgraded, except for the fact that sysvinit is no longer the default on those platforms where systemd actually exists (so on other platforms it's not even the default, and most packages happily build on _all_ platforms, so how does that sit in the same universe as one where systemd is "required"?)
In fact Debian instead made efforts (much of the effort being done by the Debian systemd maintainers) to make sure that is was actually rather easier to switch between inits. The systemd folk even wrote extra code to make sure that sysvinit and other inits could continue to support programs where the upstreams have decided that they want to depend on the services that systemd provides. That strikes me as above and beyond the call of duty.
What thanks do they get for it?
They get unending inchoate screaming about how they are part of some sort of global conspiracy, until they started burning out.
The result being that they no longer have time, and certainly have no inclination, to support systemd-shim, and the useless wankers that did all the screaming of course cannot be arsed to put any effort into it, so it's now rotting, and the chances of being able to continue using other inits in Debian are now beginning to diminish.
This is NOT because anyone forced anyone to do anything.
If people were to decide not to post another anti-systemd rant, and instead do something as trivial as reporting a single bug where non-systemd-as-init was causing a problem, then there would be some hope of making sure that other inits continue to work, but from what I can see that is not happening.
Instead people are spreading lies and scuttling off to the likes of Devuan (who are also not addressing the issues, because they are not improving application portability, because it's impossible to have Devuan _with_ systemd).
Also, note that Debian is still going to the effort of making choice possible -- other ditros that switched have made the rather more sensible choice of supporting only systemd, and thus saving themselves the effort of supporting the minority inits.
I imagine that's why people are still bothering to attack Debian on this since they imagine that there's a slim chance that we might switch again, but what you have now is definitely the best you're going to get.
As a parent of two small children I can tell you that screaming never gets rewarded, and my children if they scream long enough will either both lose the toy they are fighting over, or have something they like even less happen to them -- I think that's pretty much the mindset that most Debian Developers have adopted to people howling about systemd, so be warned:
Life can always get worse, and if you don't want that, stop screaming and put some effort into building the world as you'd like it to exist.
Cheers, Phil.
I think the driving point no one wants to argue about and therefore has been lapdancing around, is one way or another systemd is developed by a very ambitious company.
Not even speaking to the morals of said company or it's constitutents, it's sustainable existence depends on monopolizing volunteer support for subsystems that it finds to be marketable.
This isn't a conflict of interest, necessarily. However, people are Afraid there might be if there hasn't been already been underhanded tactics, exploiting their income to rapidly expand development for an ultra specific however most leverage-able component of the GNU/Linux system, implementing more features, faster, and with fewer bugs than can possibly be audited for by volunteers. If no one can replace systemd because they simply can't code as well as them nearly as fast as them, because they lack the income to survive doing so, it means that the strength of desire to advance humanity will soon no longer be the most significant force enabling the development of linux, as, regardless of the morals and vision the redhat team have, others will follow their example. At the end of the day, this is an improper means to get to goals that for all intensive purposes are simultaneously uncertain and hard to argue with. What happens when other organisations realize they can build leverage over the linux community by ultra-specializing, and massively accelerating the development of a very tiny component of the system with very rapid bug-free feature creeps, effectively making it bloatware that functions REALLY WELL and encouraging people to either expand it according to their vision or feel deprived of it. Right now, it's very difficult to say whether or not this is an intention of the redhat team and it would be very reasonable to call it unintentional, but their behavior is suggesting to others that this is an acceptable practice regardless of intentions.
I sincerely understand these are people trying to make the world a sweeter place albeit in a "ends are more important than means"-kinda-unintentional-way. These aren't super-villains like PR would have us believe, in fact quite likely very much the opposite.
This isn't really the poster-example of a healthy way of settling differences inside a community. Maybe the redhat team should have done more to trying reaching out to the most informed systemd critics, and maybe those critics should have done more to beat down the flames their words fanned. This whole debacle seems far from civil and I don't understand why, fully yet.
Hope, I'm helping with perspective :d
On Tue, Jul 4, 2017 at 12:20 PM, Jean Flamelle eaterjolly@gmail.com wrote:
I think the driving point no one wants to argue about and therefore has been lapdancing around, is one way or another systemd is developed by a very ambitious company.
this reminds me: when kde received $10m in EU funding, what they developed was a copy of the worst ever variant of windows [vista] and it shocked a lot of people. plasma took years to develop, was more complex and really didn't do anything better than what the existing python bindings to KDE's underlying architecture already did.
the point being: when money gets involved, people can drop whatever they were doing and can focus full-time on "coding". but the downside of that is that they *do* focus full-time on "coding"... and less time on thinking, talking, relaxing, designing, communicating and creativity.
i've seen it happen so many times: when the pace of development is slower - because it's done part-time - naturally what results is... better code. why? because people spent more of their down-time *actually thinking* and mulling things over.
the rapid pace of the projects funded by redhat are near-consistently causing grief and aggravation. one of the ones _not_ causing grief [from redhat-funded developers] is the linux kernel project and that is a huge exception because it has so many contributors that it has a totally different development track.
i thought this might help as i don't believe that redhat is *deliberately* intending to piss people off by rushing ahead, but that's what's happening as a direct result of redhat trying to justify its existence in a commercial world.
I sincerely understand these are people trying to make the world a sweeter place albeit in a "ends are more important than means"-kinda-unintentional-way.
i'm reminded of bob podolski's words (actually probably john david garcia's): ethical ends can *never* be achieved by unethical means....
Hope, I'm helping with perspective :d
always. thank you jean.
l.
Sorry but I have to challenge you on this, it isn't right for systemd to be the only init that can be used on debian by default.
There is no "forcing" or "requiring" involved, and people spouting this bullshit is getting _really_ old now.
If any such radical change had actually been enacted then:
a) well, we'd be in a different universe, where Debian was run by some sort of overlord who was prone to making snap decisions on a whim.
b) there would have been a mass bug filing for all these packages that did not require systemd, to somehow add that requirement.
c) there would have then been a vast wave of new package uploads with the new packages, encumbered with those requirements.
NONE OF THIS HAPPENED.
Incorrect sorry but I am not sure where you get your info from.
Debian didn't even make it so that other inits were somehow downgraded, except for the fact that sysvinit is no longer the default on those platforms where systemd actually exists (so on other platforms it's not even the default, and most packages happily build on _all_ platforms, so how does that sit in the same universe as one where systemd is "required"?)
In fact Debian instead made efforts (much of the effort being done by the Debian systemd maintainers) to make sure that is was actually rather easier to switch between inits. The systemd folk even wrote extra code to make sure that sysvinit and other inits could continue to support programs where the upstreams have decided that they want to depend on the services that systemd provides. That strikes me as above and beyond the call of duty.
What thanks do they get for it?
They get unending inchoate screaming about how they are part of some sort of global conspiracy, until they started burning out.
The result being that they no longer have time, and certainly have no inclination, to support systemd-shim, and the useless wankers that did all the screaming of course cannot be arsed to put any effort into it, so it's now rotting, and the chances of being able to continue using other inits in Debian are now beginning to diminish.
This is NOT because anyone forced anyone to do anything.
If people were to decide not to post another anti-systemd rant, and instead do something as trivial as reporting a single bug where non-systemd-as-init was causing a problem, then there would be some hope of making sure that other inits continue to work, but from what I can see that is not happening.
Instead people are spreading lies and scuttling off to the likes of Devuan (who are also not addressing the issues, because they are not improving application portability, because it's impossible to have Devuan _with_ systemd).
Also, note that Debian is still going to the effort of making choice possible -- other ditros that switched have made the rather more sensible choice of supporting only systemd, and thus saving themselves the effort of supporting the minority inits.
I really would like to see evidence of that. I tried to remove systemd on debian like three months ago for openrc and it dragged every bit of software off. So your thoughts are invalid sadly.
I imagine that's why people are still bothering to attack Debian on this since they imagine that there's a slim chance that we might switch again, but what you have now is definitely the best you're going to get.
As a parent of two small children I can tell you that screaming never gets rewarded, and my children if they scream long enough will either both lose the toy they are fighting over, or have something they like even less happen to them -- I think that's pretty much the mindset that most Debian Developers have adopted to people howling about systemd, so be warned:
Life can always get worse, and if you don't want that, stop screaming and put some effort into building the world as you'd like it to exist.
Cheers, Phil. From your response, you seem to think I am anti systemd, and that anyone
who disagrees with systemd is a child. That is an invalid argument. I don't want systemd to be my only option that's all.
I will say it again, I have only known about systemd controversy for a few months, but I will tell you this, it seems like a dangerous idea for all distros to use the same init in case something goes wrong. and the code is taken advantage of. Aka, one distro gets hacked because of it, a domino effect if you would will happen.
By the way, I can feel your anger from your response. I am quite calm right now. Just relax, you use what you want, we will use what we want. That is the code of open source and even more so, free software.
On Tue, Jul 4, 2017 at 7:28 PM, zap calmstorm@posteo.de wrote:
Sorry but I have to challenge you on this, it isn't right for systemd to be the only init that can be used on debian by default.
This doesn't make any sense. The default is what it is, a single option from a set of options that is the default one. There can only be one default. Not all sets of options can be selected on setup otherwise installing Debian would take longer than compiling gentoo. Systemd is apparently just the default option. And my problem is, people like you seem to believe that debian is some sort of organization that decides for the shake of their users. Wrong. Debian is a community first, if users want something, they can add it. There are alternative inits available but apparently nobody cares enough to maintain and script them. Which begs the question, why are systemd haters so vocal but do nothing about it ? It seems like those who actually did the work scripting for inits chose to work for systemd only, and now it's just a bunch of people who demand stuff without offering anything in return( i.e. work).
On 07/04/2017 01:01 PM, Bill Kontos wrote:
On Tue, Jul 4, 2017 at 7:28 PM, zap calmstorm@posteo.de wrote:
Sorry but I have to challenge you on this, it isn't right for systemd to be the only init that can be used on debian by default.
This doesn't make any sense. The default is what it is, a single option from a set of options that is the default one. There can only be one default. Not all sets of options can be selected on setup otherwise installing Debian would take longer than compiling gentoo.
Yes that didn't make sense my bad. I meant it shouldn't be the only one usable on debian.
Systemd is apparently just the default option. And my problem is, people like you seem to believe that debian is some sort of organization that decides for the shake of their users. Wrong. Debian is a community first, if users want something, they can add it. There are alternative inits available but apparently nobody cares enough to maintain and script them. Which begs the question, why are systemd haters so vocal but do nothing about it ? It seems like those who actually did the work scripting for inits chose to work for systemd only, and now it's just a bunch of people who demand stuff without offering anything in return( i.e. work).
Openrc and Runit are better. In my humble opinion. again I am not anti-systemd I am for choice.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
With all due respect, some people can't code. Do they not deserve a voice?
To clarify... by "some people can't code" -- I not only mean the people who, in a literal sense, cannot write or read any programming language and therefore are unable to contribute, but also people like me who are truly awful at it and honestly should, for the sake of sanity in those who can program well, stay well away from anything even vaguely resembling a programming language.
My, er, crowning achievement is an eight-room text adventure *that has no parser* -- it compares entire input strings without attempting to manipulate them. I wrote it in MS QuickBASIC PDS 7.1 on a 486 Toshiba about three or four years ago... mostly to see if I could actually do it. It took me *multiple weeks* to get it completely written and debugged, and it kind of pushed the envelope of what I could do with programming. If anyone actually wants the source code for it, I'll gladly put it up on PasteBin or any other suggested similar place, although I'll warn you, it'll probably give you hives.
So, Mr Kontos *et al.*, what would you have me maintain, other than my distance from any mission-critical chunk of code...? ;)
On Tue, Jul 4, 2017 at 8:29 PM, Christopher Havel laserhawk64@gmail.com wrote:
So, Mr Kontos *et al.*, what would you have me maintain, other than my distance from any mission-critical chunk of code...? ;)
I'm in the same boat as you. Money. Something that you want to happen isn't happening, ask around gouge interest and invest in development of the alternatives you like.
Money? I ain't got that. Somebody else wants to pay, that's different... but me, well... let's just say that the moth in my wallet up and died.
On Tue, Jul 4, 2017 at 1:07 PM, Christopher Havel laserhawk64@gmail.com wrote:
With all due respect, some people can't code. Do they not deserve a voice?
As far as Linux is concerned, no, they usually don't get a voice in how the software is written. Why would they? Volunteer programmers usually work on what *they* want, not what *others* want. If others find it useful, then great, and if they find bugs, then even better. But I don't think that very many loner programmers writing FOSS software these days are doing user studies and UX whiteboarding and all that. They're the exception, not the rule.
Linux has always been a "my way or the highway (to look for another OSS alternative / distro)" type thing. In the past this worked pretty great, if people didn't like distro A it lost popularity to distro B, and life was good.
I think the problem is that the ecosystem has gotten so big and so corporate that there's a bigger inequality between distros and software that have corporate support, and those that don't. That's a wild-ass generalization, but stop to think for a second at how many of the most popular distros right now are corporately backed or are using important bits of corporately backed software.
Then look at how many Linux users are loading binary blobs like video drivers, wifi drivers, etc. I'd bet that the no-programming-experience end-user is MORE likely to load binary blobs, and they're MORE likely to run systemd without even knowing what the fuck a systemd is. Look at the Raspberry Pi as a primary example. I've got senior level principle engineers at my job that think that the Raspberry Pi is 100% open source, PCB's and all. Obviously not true but they've not even looked. They're living in a false reality, but that's OK for them, as long as they can use it as a Kodi server they're happy. These aren't dumb people. These are just people with a different set of priorities in life.
So tl;dr, 'no-programming-experience' users don't get a voice in what gets written, but do get a voice in what software they run. But most don't really care, they just want free software that works, and aren't really in it for the philosophy that others espouse. ymmv. herding cats and all that.
I think you and I will have to respectfully disagree. *Everyone* should have a voice. I may not be able to code, but I can still contribute in some way. Here's my other crowning achievement (IMO) -- a bug report where I got something major repaired. Partially I was lucky, because it was one of those 'this is boring' situations (faulty code was accepted without being properly examined, leading to a break in support), except someone stepped in externally, because they could, and sort of took over things and fixed them.
https://bugs.freedesktop.org/show_bug.cgi?id=91966
Oh, right, length warning there. It took multiple *months* to get that thing untangled and working. Oh -- and, much to my chagrin, it still hasn't been picked up *to this day* by Debian, Ubuntu, and derivatives -- the very OSes it affects. Anything from about 2014 on has the defective version. (Last known-good config was Ubuntu Precise Pangolin!) It's been a year or two, you'd think they'd've gotten around to it by now... oh well, it's for a very particular set of rather-unpopular species of 32bit gear, so it probably won't matter much longer... support for 32bit gear is dropping like flies in a winter barn...
On Jul 4, 2017 1:53 PM, "Christopher Havel" laserhawk64@gmail.com wrote:
I think you and I will have to respectfully disagree. *Everyone* should have a voice.
I never said whether those people "deserve" to have a voice or not. All I tried to explain was whether they actually have had one, matter of fact factly. And I don't think that I'm the least bit wrong in what I wrote. I have no business guessing what people "deserve", that's completey subjective.
In philosophy, there's a huge difference between an "ought" and an "is", and objective reality will almost always end up leaning towards the latter.
Fair enough... although it seems to me that, as (I would hope) good-natured humans, we should all endeavor to bring the "is" at least a little closer to the "ought"...
On 2017-07-04 at 13:07:33 -0400, Christopher Havel wrote:
With all due respect, some people can't code. Do they not deserve a voice?
In the past, the FLOSS community was pretty bad at only valuing contributions that involved writing code, and ignoring pretty much everything else.
Nowadays, it depends a lot on which community you are involved with: some are still of the idea that only code matters, but many more recognise that software alone has limited usefulness, and that many other kinds of contributions are just as important.
Debian these days is one such community (see e.g. https://www.debian.org/intro/diversity and https://contributors.debian.org/ and http://www.enricozini.org/blog/2012/debian/more-diversity-in-skills/ for some background on the latter), and while being somewhat technically minded is helpful in finding something to contribute on, actual writing of code is a minority of the available tasks.
One think that is *very* helpful is testing stuff, especially when using rare configurations, and opening bugs when something isn't working as expected. It is true that does not always mean that they are going to be fixed, but it is still useful.
* if there is no open bug on the bugtracker you can be 99% that it won't be fixed, opening the bug significantly raises the chances for a fix, even if it's not a guantee. * by opening the bug you are showing that somebody is actually using that program/feature: sometimes minor stuff that the maintainers don't really care about are taking lots of their effort, and if they don't even know if anybody cares about it they are much more likely to just drop worrying about it. * Not just the package maintainers see the bugs on their packages: sometimes other people notice them and may get involved and provide a patch, even if they are not the bug opener themselves.
While doing so, remember that (in the case of Debian) you're probably requesting somebody to do something in their spare time, so they may not answer immediately (or in the next week), and maybe the answer will be that they can't fix the bug unless somebody else comes with a patch, but being nice in the request usually leads to receiving nice answers.
I agree that it's not a task suitable to anybody as it does require at least a bit of proficiency in using linux systems and the ability to follow instructions (probably involving the command line) to provide more data if needed, but the set of people being able to to so should be much bigger than the set of people who are able to succefully patch some random code.
On Tue, Jul 04, 2017 at 08:01:54PM +0300, Bill Kontos wrote:
It seems like those who actually did the work scripting for inits chose to work for systemd only, and now it's just a bunch of people who demand stuff without offering anything in return( i.e. work).
As I heard it, the disputes about systemd on the Debian mailing lists got so vicious that those who didn't want systemd left and went elsewhere to contribute.
--- hendrik
On 2017-07-04 at 14:39:17 -0400, Hendrik Boom wrote:
On Tue, Jul 04, 2017 at 08:01:54PM +0300, Bill Kontos wrote:
It seems like those who actually did the work scripting for inits chose to work for systemd only, and now it's just a bunch of people who demand stuff without offering anything in return( i.e. work).
As I heard it, the disputes about systemd on the Debian mailing lists got so vicious that those who didn't want systemd left and went elsewhere to contribute.
well, the disputes got vicious, and I admit that I skipped reading most of it for my own sanity.
At least on IRC, however, most of the viciousness seemed to come from the non-systemd camp; it can be true that they alienated the people who may have wanted to help supporting other systems, but making them not want to be on the same side of those people, but blaming the systemd-supporting debian community for their actions doesn't sound right.
I say seemed, however, because at least in the worst cases the pattern of behaviour were more suggestive of a troll trying to stir up controversy for its own sake (or for some other reason) rather than somebody honestly concerned with systemd, and that surely helped muddle things further.
On Tue, Jul 4, 2017 at 9:03 PM, Elena ``of Valhalla'' valhalla-l@trueelena.org wrote:
I say seemed, however, because at least in the worst cases the pattern of behaviour were more suggestive of a troll trying to stir up controversy for its own sake (or for some other reason) rather than somebody honestly concerned with systemd, and that surely helped muddle things further.
yyeah this is the most unfortunate / fortunate aspect of what happened. a massive proportion of people in the software libre community (particularly debian) knew that something felt... wrong... but were completely ill-equipped to *both* identify it *and* express it.
where the primary focus was on engineering, where you *absolutely must* be capable of expressing precisely and exactly what is wrong, a "this doesn't feel right" feeling would *of course* be outright rejected with "please provide evidence / proof".
not only that but people would have felt totally uncomfortable expressing their true views and feelings (even if they truly had a way to express them without causing upset / offense / whatever). "i feel totally betrayed by your democratic majority-vote-style decision [which e.g. forces me to spend hundreds of hours converting live-running systems to a new distro]" is not something that can be bug-fixed.
so yes, the end-result, elena, would have been what you witnessed.
why describe this as "fortunate"? because it identifies a flaw within the software libre community that, one might hope, everyone can learn from.
l.
zap calmstorm@posteo.de writes:
Sorry but I have to challenge you on this, it isn't right for systemd to be the only init that can be used on debian by default.
There is no "forcing" or "requiring" involved, and people spouting this bullshit is getting _really_ old now.
If any such radical change had actually been enacted then:
a) well, we'd be in a different universe, where Debian was run by some sort of overlord who was prone to making snap decisions on a whim.
b) there would have been a mass bug filing for all these packages that did not require systemd, to somehow add that requirement.
c) there would have then been a vast wave of new package uploads with the new packages, encumbered with those requirements.
NONE OF THIS HAPPENED.
Incorrect sorry but I am not sure where you get your info from.
I'm not sure what you're expecting me to say.
I pay attention to the uploads.
I've been a Debian Developer for over 2 decades.
I was there since before all this started on the mailing lists.
I'm vaguely aware of the extent to which things depend on things.
Actually, let's try a very rough estimate on "stretch" (the new release):
for p in systemd libsystemd0 libselinux1 libc6 ; \ do apt-cache rdepends \ --no-suggests --no-conflicts --no-breaks --no-replaces $p \ | grep '^ ' | sort -u | wc -l ; \ done 34 144 133 19816
Note that libselinux1 (which is pretty much equivalent to libsystemd0 in its purpose) is almost as widely depended upon as libsystemd0, and that they are both two orders of magnitude less depended upon than libc6.
_That_ is why I reacted badly to your "forced to require" assertion.
I'll admit that there are recursive dependencies that spread that net quite a lot wider, but also those numbers include the likes of sogo where the dependency is:
Depends: libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.14.0), libgnustep-base1.24 (>= 1.24.7), libgnutls30 (>= 3.5.0), liblasso3 (>= 2.5.0), libmemcached11, libobjc4 (>= 4.6), libsbjson2.3, libsope1 (>= 3.2.6), init-system-helpers (>= 1.18~), tmpreaper | systemd, sogo-common (= 3.2.6-2), adduser, zip, lsb-base (>= 3.0-6)
so here systemd is depended upon only as an alternative to tmpreaper.
If you want better numbers, feel free to work them out yourself, but I'd hope that you'll manage to understand from this that there has not been a policy change to "force" packages to "require" (or as we'd call it "depend") upon systemd, or even libsystemd0.
Oh, and not that it matters, as I wasn't there when the Debian Technical Committee made its decision to choose systemd as the default, but I would have made the same decision if I had been on the committee then, and these days I am:
https://www.debian.org/intro/organization#tech-ctte
so, if that doesn't qualify me to comment on happenings in Debian in your eyes, I'm not quite sure what would.
Cheers, Phil.
I'm not sure what you're expecting me to say.
I pay attention to the uploads.
I've been a Debian Developer for over 2 decades.
I was there since before all this started on the mailing lists.
I'm vaguely aware of the extent to which things depend on things.
Actually, let's try a very rough estimate on "stretch" (the new release):
for p in systemd libsystemd0 libselinux1 libc6 ; \ do apt-cache rdepends \ --no-suggests --no-conflicts --no-breaks --no-replaces $p \ | grep '^ ' | sort -u | wc -l ; \ done 34 144 133 19816
Note that libselinux1 (which is pretty much equivalent to libsystemd0 in its purpose) is almost as widely depended upon as libsystemd0, and that they are both two orders of magnitude less depended upon than libc6.
_That_ is why I reacted badly to your "forced to require" assertion.
I'll admit that there are recursive dependencies that spread that net quite a lot wider, but also those numbers include the likes of sogo where the dependency is:
Depends: libc6 (>= 2.14), libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.14.0), libgnustep-base1.24 (>= 1.24.7), libgnutls30 (>= 3.5.0), liblasso3 (>= 2.5.0), libmemcached11, libobjc4 (>= 4.6), libsbjson2.3, libsope1 (>= 3.2.6), init-system-helpers (>= 1.18~), tmpreaper | systemd, sogo-common (= 3.2.6-2), adduser, zip, lsb-base (>= 3.0-6)
so here systemd is depended upon only as an alternative to tmpreaper.
If you want better numbers, feel free to work them out yourself, but I'd hope that you'll manage to understand from this that there has not been a policy change to "force" packages to "require" (or as we'd call it "depend") upon systemd, or even libsystemd0.
Oh, and not that it matters, as I wasn't there when the Debian Technical Committee made its decision to choose systemd as the default, but I would have made the same decision if I had been on the committee then, and these days I am:
https://www.debian.org/intro/organization#tech-ctte
so, if that doesn't qualify me to comment on happenings in Debian in your eyes, I'm not quite sure what would.
Cheers, Phil.
Well, it least you were more civil about it. I do think that openrc or runit should have at least been on the table for a vote. Although, I am curious why you think that runit-init is no longer a package on debian. I am curious to why that package was taken down. I will stick to devuan though and you I am sure will stick to debian. That's about it.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jul 5, 2017 at 1:43 AM, zap calmstorm@posteo.de wrote:
Well, it least you were more civil about it.
zap, phil, et al: i must apologise, the less-than-civil tone is my fault. i began this thread from a position of frustration and pissed-off-ness.
slowly over time however these discussions are helping me to be able to both understand and vocalise things without the frustration and pissed-off-ness.
so i apologise, and at the same time am extremely grateful for everyone's participation.
l.
On 07/05/2017 01:37 AM, Luke Kenneth Casson Leighton wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jul 5, 2017 at 1:43 AM, zap calmstorm@posteo.de wrote:
Well, it least you were more civil about it.
zap, phil, et al: i must apologise, the less-than-civil tone is my fault. i began this thread from a position of frustration and pissed-off-ness.
slowly over time however these discussions are helping me to be able to both understand and vocalise things without the frustration and pissed-off-ness.
so i apologise, and at the same time am extremely grateful for everyone's participation.
l.
Well, I wasn't talking about you that time, but yeah we all need to just calm down and look carefully at what is going on here without eyes of hate. If possible I mean.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Jul 4, 2017 at 10:50 PM, Philip Hands phil@hands.com wrote:
zap calmstorm@posteo.de writes:
Sorry but I have to challenge you on this, it isn't right for systemd to be the only init that can be used on debian by default.
There is no "forcing" or "requiring" involved, and people spouting this bullshit is getting _really_ old now.
If any such radical change had actually been enacted then:
a) well, we'd be in a different universe, where Debian was run by some sort of overlord who was prone to making snap decisions on a whim.
b) there would have been a mass bug filing for all these packages that did not require systemd, to somehow add that requirement.
c) there would have then been a vast wave of new package uploads with the new packages, encumbered with those requirements.
NONE OF THIS HAPPENED.
Incorrect sorry but I am not sure where you get your info from.
I'm not sure what you're expecting me to say.
I pay attention to the uploads.
I've been a Debian Developer for over 2 decades.
I was there since before all this started on the mailing lists.
I'm vaguely aware of the extent to which things depend on things.
Actually, let's try a very rough estimate on "stretch" (the new release):
for p in systemd libsystemd0 libselinux1 libc6 ; \ do apt-cache rdepends \ --no-suggests --no-conflicts --no-breaks --no-replaces $p \ | grep '^ ' | sort -u | wc -l ; \ done 34 144 133 19816
Note that libselinux1 (which is pretty much equivalent to libsystemd0 in its purpose) is almost as widely depended upon as libsystemd0, and that they are both two orders of magnitude less depended upon than libc6.
i've mentioned it a number of times: the difference between libsystemd0 and libselinux1 (both of which remain "dormant" if not actually utilised) is that selinux is developed under the auspices of the NSA's guidance according to an extremely stable and trustworthy process. by complete contrast systemd is *literally* developed under the complete and total opposite ethos in *every* single way conceivable [only one aspect of which is the actual resultant "code"].
i believe it's safe to say that the NSA can actually be trusted in its core area of expertise: security. they began by sponsoring a university research initiative, which came up with the FLASK model. a roadmap and a series of papers were developed long before any code was written, allowing interested people with a particular interest in high security to comment and contribute. the scope of the project was well-defined right from the beginning and *has not changed*. any extensions that are added (such as the xorg extensions) are done so in a non-intrusive and optional fashion.
more than that: the developers who are involved in it are sensible, highly competent, respectful, respect-worthy and, from the evidence of their ongoing behaviour, clearly trust-worthy people. manoj srivastava and stephen smalley are just two that, with my vague memory being what it is, that i can remember their names after never having spoken to them for over ten years should underscore how much of a lasting impression just those two peoples' competence has made on me.
now, for everything in that paragraph above, write something in your own mind that takes every positive statement and replace it with the total opposite. then substitute "pottering" for "NSA". i won't do it for you, because i don't wish to be the one writing what could easily be interpreted as utter hateful vitriol.
*this* is why people do not wish to have code written by and being actively developed by pottering on their systems. i keep emphasising: it's not actually about the code: it's about much, much more than that. and that's why (phil) when you say things along the lines of "give me one good reason why..." and it involves an *actual specific code-related issue*, i feel compelled to point out that it's the wrong question to be asking / wrong approach to be taking.
so this is why people - who do not have sufficient expertise to "code their way out of the problem", and/or do not have the expertise to package alternative init-systems and/or who do not have the time/resources to risk converting to a totally new distro - still want to be able to *completely* remove systemd i.e do "apt-get --purge remove libsystemd0" and still retain a fully-functional *debian* system [not a devuan system] because of all the advantages, cost-savings and so on of doing so.
this is so hard to explain succinctly.
l.
I'm not going to join this pro/anti systemd discussion as it is pointless at this point, but,
On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote:
for example, until i discovered that angband.pl actively maintains systemd-less debian packages for xorg, udev, pulseaudio and several critical pre-systemd packages (including consolekit), i was forced to make an extremely risky *MANUAL* removal of systemd. that included REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i also had to add a hundred entries into /etc/modules - some of which i could not determine so had to actually not have access to critical hardware for a considerable amount of time.
Hang on, is this for the images for the EOMA68? I figure you don't have systemd there because the kernel is < 3.12. But no udev? Or is this for an unrelated system?
On 07/03/2017 01:12 PM, Tzafrir Cohen wrote:
I'm not going to join this pro/anti systemd discussion as it is pointless at this point, but,
For the most part I agree with you, but I must admit I trust someone with as much experience like Luke far more than systemd. But you are free to avoid this conversation altogether if you wish. meh...
On Mon, Jul 3, 2017 at 6:12 PM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
Hang on, is this for the images for the EOMA68?
no.
I figure you don't have systemd there because the kernel is < 3.12. But no udev? Or is this for an unrelated system?
correct. my main laptop.
On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote:
for example, until i discovered that angband.pl actively maintains systemd-less debian packages for xorg, udev, pulseaudio and several critical pre-systemd packages (including consolekit), i was forced to make an extremely risky *MANUAL* removal of systemd. that included REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i also had to add a hundred entries into /etc/modules - some of which i could not determine so had to actually not have access to critical hardware for a considerable amount of time.
For the record, I feel called on to point out that Devuan has done most of that for you, but I suspect that you already know that, and it wasn't ready at the time.
So you other guys: If you're removing systemd from Debian, just use Devuan instead -- it's already (mostly) been done for you!
Why do I say mostly? There are a few vestigial traces in the system -- such as libsystemd0, which provides a few systemd interfaces in a form that just reports that systemd is not present. I think that package should really be called something like nosystemd.
-- hendrik
On Tue, Jul 4, 2017 at 2:41 AM, Hendrik Boom hendrik@topoi.pooq.com wrote:
For the record, I feel called on to point out that Devuan has done most of that for you, but I suspect that you already know that, and it wasn't ready at the time.
i do - that's not quite it. i have such a high dependency on debian that i can't take the risk of converting. instead i've deployed anganbd.pl's packages and they _do_ get rid - entirely - of libsystemd1. the reason that they do that is to test packages that are ostensibly listed as not depending on sytemd actually *really* do not depend on systemd.
angband.pl's approach means that i can stay on debian, and there's no risk of jeapordising this project.
l.
On Mon, Jul 03, 2017 at 09:41:07PM -0400, Hendrik Boom wrote:
On Mon, Jul 03, 2017 at 04:02:23PM +0100, Luke Kenneth Casson Leighton wrote:
for example, until i discovered that angband.pl actively maintains systemd-less debian packages for xorg, udev, pulseaudio and several critical pre-systemd packages (including consolekit), i was forced to make an extremely risky *MANUAL* removal of systemd. that included REMOVING udev entirely and MANUALLY maintaining entries in /dev (!) i also had to add a hundred entries into /etc/modules - some of which i could not determine so had to actually not have access to critical hardware for a considerable amount of time.
For the record, I feel called on to point out that Devuan has done most of that for you, but I suspect that you already know that, and it wasn't ready at the time.
So you other guys: If you're removing systemd from Debian, just use Devuan instead -- it's already (mostly) been done for you!
In another thread someone mentioned trusting people. I trust the maintainer of angband.pl generally more than maintainers of Devuan, from observed behavior.
On Tue, Jul 4, 2017 at 8:17 AM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
In another thread someone mentioned trusting people. I trust the maintainer of angband.pl generally more than maintainers of Devuan, from observed behavior.
*sigh* i love what the devuan team have done: they've achieved a hell of a lot. the only thing is: their stated mission statement is "to give people free choice over their init service". and... err... the lack of support for systemd makes that mission statement a false statement.
devuan is therefore a backlash *against* systemd. if they were true to their mission statement they would add the option to include it.
what would be really *really* handy is if someone modified angband.pl's packaging so that it compiled *both* systemd *and* systemd-less packages, making the systemd-less variants e.g. of udev as "udev-nosystemd" and using "Provides: udev" (or whatever appropriate debian control magic is necessary).
the reason for that would be that the angband.pl variants could then actually be proposed for inclusion in debian.
l.
On Tue, Jul 04, 2017 at 10:09:45AM +0100, Luke Kenneth Casson Leighton wrote:
On Tue, Jul 4, 2017 at 8:17 AM, Tzafrir Cohen tzafrir@cohens.org.il wrote:
In another thread someone mentioned trusting people. I trust the maintainer of angband.pl generally more than maintainers of Devuan, from observed behavior.
*sigh* i love what the devuan team have done: they've achieved a hell of a lot. the only thing is: their stated mission statement is "to give people free choice over their init service". and... err... the lack of support for systemd makes that mission statement a false statement.
devuan is therefore a backlash *against* systemd. if they were true to their mission statement they would add the option to include it.
The official line is that, if you want Devuan with systemd you should simply install Debian, which *is* Devuan with systemd. Thus you have choice, which you wouldn't have with Debian alone.
It doesn't enable you to simply boot with systemd on even-numbered days and without it on odd-numbered days, but it is a reasonable compromise, given their lack of resources.
-- hendrik
P.S. Technically, Debian itself does make it possible to have a system without systemd, but you have to install with systemd and then replace it. And there are a lot of packages that depend on systemd, but don't in Devuan, so the option isn't as viable as it is presented.
what would be really *really* handy is if someone modified angband.pl's packaging so that it compiled *both* systemd *and* systemd-less packages, making the systemd-less variants e.g. of udev as "udev-nosystemd" and using "Provides: udev" (or whatever appropriate debian control magic is necessary).
the reason for that would be that the angband.pl variants could then actually be proposed for inclusion in debian.
It would have been good of Debian to have adopted a policy like that. Instead they didn't even make systemd a choice at installation time.
-- hendrik
their stated mission statement is "to give people free choice over > their init service". and... err... the lack of support for systemd >
makes that mission statement a false statement.
I wondered about this, so I am going to try a comprehensive analysis of their website (irrelevant analysis is cut)
Main page mentions the "Exodus declaration in 2014"
The original declaration says "produce a reliable and minimalist base distribution that stays away from the... lock-in promoted by systemd." The original goal was to prevent lock-in, huh?
Also: "Among the priorities are: enable diversity... for the existing Debian downstream *willing to preserve Init Freedom*."
That implies systemd is not part of "Init Freedom," since, according to that, if downstream stayed with Debian (and systemd) they would not be preserving Init Freedom
The main page mentions "the right to Init Freedom" and has a link...
"Init Freedom is about restoring a sane approach to PID1, **one that respects diversity and freedom of choice**." The rest of the page is irrelevant.
I wish they would define "Init freedom." The closest thing to a definition is the last quote (above)
So it seems that systemd is explicitly excluded from Init Freedom (which is *defined* as respecting freedom of choice) and therefore I cannot disagree with your statement
if they were true to their mission statement they would add the > option to include it.
Unfortunately, I have to agree
Here is a question: Is a false (in any way) mission statement enough to totally dismiss something? Even if their actions (providing a reasonable alternative) are seemingly good?
From what I have observed, you seem to have two "codes" that you live
by, your ethics and your intuition. Your ethics seems to mostly involve your influence over others, so what does your intuition say about Devuan?
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jul 5, 2017 at 5:48 AM, James L james6.28318530@gmail.com wrote:
if they were true to their mission statement they would add the option to include it.
Unfortunately, I have to agree
i spoke to one of the people in devuan, who turned out to be an amazingly wise person, and i was able to point out this discrepancy to them without over-reaction. i suggested to them that it might be a good idea to properly honour the mission statement by including systemd in devuan.
their response was that in their opinion it simply would never happen, ever. devuan was *geniunely* born out of a back-lash reaction *against* systemd.. *not* out of a desire to genuinely honour their mission statement.
Here is a question: Is a false (in any way) mission statement enough to totally dismiss something? Even if their actions (providing a reasonable alternative) are seemingly good?
*sigh* i love what they've done, but the best way to illustrate it is with a story from mother theresa. she was invited to an anti-war rally, once. she declined... and told them that if they ever wanted to hold a *peace* rally, she would be delighted to attend.
that really says it all, i think.
From what I have observed, you seem to have two "codes" that you live by, your ethics and your intuition.
ha. to clarify: i use my intuition to identify those things which are ethical [and then follow up with as much rational / logical reasoning as i can stand]. where i really didn't even have a definition of what is actually ethical until i encountered bob podolski, only last year. ironic or what... :)
Your ethics seems to mostly involve your influence over others, so what does your intuition say about Devuan?
jury's still out. i'm hopeful that one day they'll be able to resolve the conflict and truly honour their mission statement. for myself i... i simply cannot bring myself to endorse or support things where there exists a huge cognitive dissonance. call it an ISO9001 "fail" if you will.
l.
On Wed, 5 Jul 2017 06:48:08 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Wed, Jul 5, 2017 at 5:48 AM, James L james6.28318530@gmail.com wrote:
if they were true to their mission statement they would add the option to include it.
Unfortunately, I have to agree
i spoke to one of the people in devuan, who turned out to be an amazingly wise person, and i was able to point out this discrepancy to them without over-reaction. i suggested to them that it might be a good idea to properly honour the mission statement by including systemd in devuan.
their response was that in their opinion it simply would never happen, ever. devuan was *geniunely* born out of a back-lash reaction *against* systemd.. *not* out of a desire to genuinely honour their mission statement.
Here is a question: Is a false (in any way) mission statement enough to totally dismiss something? Even if their actions (providing a reasonable alternative) are seemingly good?
*sigh* i love what they've done, but the best way to illustrate it is with a story from mother theresa. she was invited to an anti-war rally, once. she declined... and told them that if they ever wanted to hold a *peace* rally, she would be delighted to attend.
that really says it all, i think.
From what I have observed, you seem to have two "codes" that you live by, your ethics and your intuition.
ha. to clarify: i use my intuition to identify those things which are ethical [and then follow up with as much rational / logical reasoning as i can stand]. where i really didn't even have a definition of what is actually ethical until i encountered bob podolski, only last year. ironic or what... :)
Your ethics seems to mostly involve your influence over others, so what does your intuition say about Devuan?
jury's still out. i'm hopeful that one day they'll be able to resolve the conflict and truly honour their mission statement. for myself i... i simply cannot bring myself to endorse or support things where there exists a huge cognitive dissonance. call it an ISO9001 "fail" if you will.
l.
Luke I became involved about three weeks after the project started. I'm still on the ML but had no time to keep up or contribute much. I saw some of the most cordial behaviour that I have had the privilege to witness on a mailing list from most of (all?) the members! I really believe that they will meet with success in their toiling. Not to justify by pointing to lesser examples, but contrast it with the behaviour of Mr. Pottering. Insta-bug-close. Taking every available short cut. No Portability to clang/bsd/etc. I really think that Devuan is just taking an obvious short cut in the above case. That is to say, if devuan and debian devs got together to merge then devuan would get support for system and debian would support other inits. I do not and did not see any resentment to debian on the list by the devuan devs.
Sincerely, David
On Fri, Jul 7, 2017 at 11:35 PM, David Niklas doark@mail.com wrote:
Luke I became involved about three weeks after the project started. I'm still on the ML but had no time to keep up or contribute much.
not a problem.
I saw some of the most cordial behaviour that I have had the privilege to witness on a mailing list from most of (all?) the members!
huh. despite quite a lot of "venting", that's really appreciated to hear.
I really believe that they will meet with success in their toiling. Not to justify by pointing to lesser examples, but contrast it with the behaviour of Mr. Pottering. Insta-bug-close. Taking every available short cut. No Portability to clang/bsd/etc.
*cringes*... i see you noticed his behaviour.
I really think that Devuan is just taking an obvious short cut in the above case. That is to say, if devuan and debian devs got together to merge then devuan would get support for system and debian would support other inits. I do not and did not see any resentment to debian on the list by the devuan devs.
the devuan team have a really nice team spirit, and their work is of significant interest beyond just debian/devuan. the technique of HTTP-redirect-cloning distros has useful implications for other libre (e.g. FSF-Endorseable) distros that wish to remove certain packages but do not wish to host a hundred gigabytes worth of tens of thousands of files to do so, not least because it would be insanely impractical to do so, just for the purposes of e.g. removing nonfree firmware or trademarked images and words.
l.
I'm replying very late because I needed to find the right words and they were not coming to me, till now. Feel free to return the favour (:
On Sat, 8 Jul 2017 15:24:23 +0100 Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Fri, Jul 7, 2017 at 11:35 PM, David Niklas doark@mail.com wrote:
<snip>
I saw some of the most cordial behaviour that I have had the privilege to witness on a mailing list from most of (all?) the members!
huh. despite quite a lot of "venting", that's really appreciated to hear.
What I am about to write aught to be interpreted with respect to my understanding of people and myself and I make no guarantee that my understanding is correct; only that I believe it is correct. "Venting", when not directed against a person is an expression of disgust with a situation. A constructive use "Venting" is the writing about a problem, whether someone actually notices or the situation improves helps the person by expressing there thoughts and feelings on the matter instead of keeping it bottled up inside of them. A person "vents" because a situation would have to be important to them, not because it necessarily is (consider gov. spying or proprietary hardware, how many people "Vent" against those vs. say, protecting the environment). Typically just not contradicting a "venting" person will leave them calmer than when they started. Therefore, I did not and do not consider "Venting" in and of itself an evil, rather as a means to and end.
And there were times when those on the Devuan mailing list would seem to head towards the "I hate Poettering" side, but we would all engage them (except, maybe me because I would miss most of the discussion), to thinking about the enemy we were fighting, which was systemd, not Poettering, and it would work 100% of the time, at least as far as I remember. To be fair, I don't think anyone on the list would want to hire him or be his best friend, but that is personal preference or disgust, not hate.
I really believe that they will meet with success in their toiling. Not to justify by pointing to lesser examples, but contrast it with the behaviour of Mr. Pottering. Insta-bug-close. Taking every available short cut. No Portability to clang/bsd/etc.
*cringes*... i see you noticed his behaviour.
<snip>
I only wish I understood why. If you read Mr. Poettering's blog on systemd[1], he points out several technical merits. One of the biggest arguments against portability is made by telling people that daemons can't be trusted to stop and must, therefore be tracked by the init system so that they don't misbehave. He then goes on with how to write a daemon that utilizes systemd more effectively, thus daemons which were behaving under other init's stop working properly and function only on systemd unless they are written and tested on both systemd and not systemd init systems, thus doubling the work that needs to be done by the developers. Why must systemd do what it does the way it does? That is to say, if systemd must have unusual access to the kernel why not use a modular design so that BSD support could be implemented? Or even add a switch to the kernel to tell it to track a certain process so that it does not misbehave. That would work for both systemd and not systemd inits. The same could be done for socket activation. Have the daemon itself tell the kernel that it wants the socket to be opened with the expectation that another process will attach later.
The incompatibility with clang seems to be mostly an attempt at not wanting to do memory management, why not use rust?
Or sh ...... (:
Sincerely, David
On Fri, Jul 28, 2017 at 10:37:22AM -0400, doark@mail.com wrote:
And there were times when those on the Devuan mailing list would seem to head towards the "I hate Poettering" side, but we would all engage them (except, maybe me because I would miss most of the discussion), to thinking about the enemy we were fighting, which was systemd, not Poettering, and it would work 100% of the time, at least as far as I remember.
I thought you were out to write a good system, and not up against another software.
On Tue, Aug 01, 2017 at 09:14:11PM +0200, Tzafrir Cohen wrote:
On Fri, Jul 28, 2017 at 10:37:22AM -0400, doark@mail.com wrote:
And there were times when those on the Devuan mailing list would seem to head towards the "I hate Poettering" side, but we would all engage them (except, maybe me because I would miss most of the discussion), to thinking about the enemy we were fighting, which was systemd, not Poettering, and it would work 100% of the time, at least as far as I remember.
I thought you were out to write a good system, and not up against another software.
The other software was the immediate reason the system wasn't good.
-- hendrik
On Tue, 1 Aug 2017 21:14:11 +0200 Tzafrir Cohen tzafrir@cohens.org.il wrote:
On Fri, Jul 28, 2017 at 10:37:22AM -0400, doark@mail.com wrote:
And there were times when those on the Devuan mailing list would seem to head towards the "I hate Poettering" side, but we would all engage them (except, maybe me because I would miss most of the discussion), to thinking about the enemy we were fighting, which was systemd, not Poettering, and it would work 100% of the time, at least as far as I remember.
I thought you were out to write a good system, and not up against another software.
I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system. So nobody was out to write a system, rather to utilize others that they deemed was more suitable for their purposes.
Sincerely, David
On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark@mail.com wrote:
I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system.
I disagree. The majority of people on this list (2000+) stayed silent on this particular topic. Many ordered their Computer Card with Debian.
kind regards Pablo
Hello,
On Tue, Aug 8, 2017 at 11:57 AM, Pablo Rath pablo@parobalth.org wrote:
On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark@mail.com wrote:
I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system.
I disagree. The majority of people on this list (2000+) stayed silent on this particular topic. Many ordered their Computer Card with Debian.
I disagree, being silent about this topic is not endorsing any particular option. Neither is choosing a specific computer card.
At least in my case...
I disagree, being silent about this topic is not endorsing any particular option. Neither is choosing a specific computer card.
At least in my case...
I second this notion. I have been silent for a long time but because I didn't see this topic till today. I trust Luke's judgment on systemd. If he says it is insecure and has 20+ background of experience, then why should we disagree with him?
Personally, I will be getting devuan when I decide whether it is up to my standards or not. Though I still wonder when rk3388 is coming out. ;)
On Tue, Aug 8, 2017 at 4:21 PM, zap calmstorm@posteo.de wrote:
I trust Luke's judgment on systemd. If he says it is insecure and has 20+ background of experience, then why should we disagree with him?
because you've thought it through or yourself, weighed the balance of factors *you* are comfortable with, and come to your own conclusion. which may or may not happen to be the same.
i'm comfortable with a parallel-factors "fuzzy" approach to decision-making: it's part of reverse-engineering to consider factors that you really genuinely have no clue on, really, as to whether they're black-and-white "true" or not. but when you take 5, 10, 20, 50 or even more such "no-clue" samples and they *all* agree, that's as good an indication that the hypothesis is statistically valid as any.
and it can be a lot faster and a lot less hassle.
*but*...
you try to explain this approach to people... dang it can get ugly *real* fast. the usual sign of trouble is when people ask the question "Give Me One Good Reason". with the analysis approach that i take on "nebulous" topics, to give ONE reason is not only flat-out impossible, it's completely and utterly misleading to do so. the multi-factor signs - the entire package - *is* the "reason"... but that is not something that many people can cope with. they consider the entire approach to be deeply flawed... because there is no "rational" single factor that says black and white yes or no.
l.
because you've thought it through or yourself, weighed the balance of factors *you* are comfortable with, and come to your own conclusion. which may or may not happen to be the same.
i'm comfortable with a parallel-factors "fuzzy" approach to decision-making: it's part of reverse-engineering to consider factors that you really genuinely have no clue on, really, as to whether they're black-and-white "true" or not. but when you take 5, 10, 20, 50 or even more such "no-clue" samples and they *all* agree, that's as good an indication that the hypothesis is statistically valid as any.
and it can be a lot faster and a lot less hassle.
*but*...
you try to explain this approach to people... dang it can get ugly *real* fast. the usual sign of trouble is when people ask the question "Give Me One Good Reason". with the analysis approach that i take on "nebulous" topics, to give ONE reason is not only flat-out impossible, it's completely and utterly misleading to do so. the multi-factor signs - the entire package - *is* the "reason"... but that is not something that many people can cope with. they consider the entire approach to be deeply flawed... because there is no "rational" single factor that says black and white yes or no.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
My bad,I was just trying to say that we should trust your 20+ years of experience, considering your ethical standards in general, I thought this was a good analysis.
I see part of your point though, there are a lot more reasons... Linus at one point after all said systemd's design scope was insanely complex.
So yes, I did read up a bit on it a while ago. Should I have mentioned that? probably... but oh well too late now.
On Tue, Aug 8, 2017 at 9:12 PM, zap calmstorm@posteo.de wrote:
because you've thought it through or yourself, weighed the balance of factors *you* are comfortable with, and come to your own conclusion. which may or may not happen to be the same.
My bad,I was just trying to say that we should trust your 20+ years of experience, considering your ethical standards in general, I thought this was a good analysis.
i'd be much more comfortable with you taking responsibility for your own decision-making (and rationale) not least, you can double-check mine.
btw PLEASE zap, i believe i've had to tell you four or five times now, please TRIM UNNECESSARY CONTEXT. i set some rules and have one person still in moderation, i can't just arbitrarily ignore those rules.
do you see what i did above? i cut out everything that wasn't relevant. PLEASE DO THE SAME.
l.
i'd be much more comfortable with you taking responsibility for your own decision-making (and rationale) not least, you can double-check mine.
I don't really understand completely, I guess
btw PLEASE zap, i believe i've had to tell you four or five times now, please TRIM UNNECESSARY CONTEXT. i set some rules and have one person still in moderation, i can't just arbitrarily ignore those rules.
do you see what i did above? i cut out everything that wasn't relevant. PLEASE DO THE SAME.
Trim like this? To be honest, I thought I did trim it enough. my bad.
On Wed, Aug 9, 2017 at 11:34 AM, zap calmstorm@posteo.de wrote:
btw PLEASE zap, i believe i've had to tell you four or five times now, please TRIM UNNECESSARY CONTEXT.
do you see what i did above? i cut out everything that wasn't relevant. PLEASE DO THE SAME.
Trim like this? To be honest, I thought I did trim it enough. my bad.
LGTM
A good exercice, is to try reading web archives of a ML, you'll easily understand why this is so important (at least to some of us).
On Wed, Aug 9, 2017 at 10:34 AM, zap calmstorm@posteo.de wrote:
i'd be much more comfortable with you taking responsibility for your own decision-making (and rationale) not least, you can double-check mine.
I don't really understand completely, I guess
well you did ok here. you're posting inline so that's great (you've been good at doing that).
btw PLEASE zap, i believe i've had to tell you four or five times now, please TRIM UNNECESSARY CONTEXT. i set some rules and have one person still in moderation, i can't just arbitrarily ignore those rules.
do you see what i did above? i cut out everything that wasn't relevant. PLEASE DO THE SAME.
Trim like this?
this time you took out the "to unsubscribe blah blah" bit... so yes.
To be honest, I thought I did trim it enough. my bad.
previous message you did, you left in about 3 paragraphs written by me which was *not* related in any way to what *you* were saying, and you left in the "to unsubscribe blah blah" notice.
imagine that this is a real conversation. whilst it's good practice to repeat a "summary" of what the other person has said, in order to indicate that you understand what they've said, if you repeated EVERY SINGLE WORD they'd get f*****d-off with you pretty quickly.
basically you have to get inside the other person (or people's) head(s), and think, "okay, if i saw this, how much time would it take to read, is everything in it *absolutely* necessary, but also is it long enough (*enough* context) so that they'll understand where the conversation left off?"
that's what it's all about.
l.
On Tue, Aug 08, 2017 at 11:57:44AM +0200, Pablo Rath wrote:
On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark@mail.com wrote:
I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system.
I disagree. The majority of people on this list (2000+) stayed silent on this particular topic. Many ordered their Computer Card with Debian.
Debian is well-known to be upgradable to Devuan with just a dist-upgrade after editing /etc/apt/sources.list.
If I wanted Devuan I would have ordered Debian too.
-- hendrik
On 17.8.8 3:57, Pablo Rath wrote:
On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark@mail.com wrote:
I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system.
I disagree. The majority of people on this list (2000+) stayed silent on this particular topic. Many ordered their Computer Card with Debian.
I am nearly sure, from the context, that with the words 'those on the list', he was referring to "Devuan's" mailing-list, NOT this mailing-list.
On Fri, Aug 11, 2017 at 03:07:37PM -0600, chadvellacott@sasktel.net wrote:
On 17.8.8 3:57, Pablo Rath wrote:
On Sat, Aug 05, 2017 at 09:56:23PM -0400, doark@mail.com wrote:
I aught to have been more clear, almost all of those on the list found systemd a bad choice for them vs. another init system.
I disagree. The majority of people on this list (2000+) stayed silent on this particular topic. Many ordered their Computer Card with Debian.
I am nearly sure, from the context, that with the words 'those on the list', he was referring to "Devuan's" mailing-list, NOT this mailing-list.
Yes, now that you pointed it out I can see it too. I should have focused more on the context but my brain jumped to the wrong conclusion too quickly. Thank you Chad for pointing this out. This makes my reply to David above meaningless.
kind regards Pablo
This is a late response, but persons seem to keep confusing the two mailing-lists.
On 17.7.8 8:24, Luke Kenneth Casson Leighton wrote:
On Fri, Jul 7, 2017 at 11:35 PM, David Niklas doark@mail.com wrote:
Luke I became involved about three weeks after the project started. I'm still on the ML but had no time to keep up or contribute much.
not a problem.
At first, I too thought that he was referring to THIS mailing-list, "Arm-netbook". But considering that David's message (as retained below) ends up obviously focusing on Devuan and Debian, it seems that he is, even at the start of his message, talking of a mailing-list for Devuan.
I saw some of the most cordial behaviour that I have had the privilege to witness on a mailing list from most of (all?) the members!
huh. despite quite a lot of "venting", that's really appreciated to hear.
(My comment above, fits here too.)
I really believe that they will meet with success in their toiling.
~~~
I really think that Devuan is just taking an obvious short cut in the above case. That is to say, if devuan and debian devs got together to merge then devuan would get support for system and debian would support other inits. I do not and did not see any resentment to debian on the list by the devuan devs.
the devuan team have a really nice team spirit,
~~~
l.
On Fri, Aug 11, 2017 at 10:07 PM, chadvellacott@sasktel.net wrote:
This is a late response, but persons seem to keep confusing the two mailing-lists.
yeah me included. thanks for pointing this out chad.
On Wed, Jul 05, 2017 at 06:48:08AM +0100, Luke Kenneth Casson Leighton wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Jul 5, 2017 at 5:48 AM, James L james6.28318530@gmail.com wrote:
if they were true to their mission statement they would add the option to include it.
Unfortunately, I have to agree
i spoke to one of the people in devuan, who turned out to be an amazingly wise person, and i was able to point out this discrepancy to them without over-reaction. i suggested to them that it might be a good idea to properly honour the mission statement by including systemd in devuan.
their response was that in their opinion it simply would never happen, ever. devuan was *geniunely* born out of a back-lash reaction *against* systemd.. *not* out of a desire to genuinely honour their mission statement.
The mission statement came later. But they do mean it's about choice. That said, they do have practial limitations as to what alternatives they can offer themselves, and they have focussed on important alternatives that are not provided by Debian. This is how they provide choice. I don't see how this si oncompatible with their mission statement, though I can see how it may appear so.
They also care that system owners be in control of their own systems. Choice is a means to this end. But some subsystems make this kind of control difficult, and it's reasonable not to spend effort in this direction. Especially when there's a well-known and reasonably compatible distro that already does that.
-- hendrik
Here is a question: Is a false (in any way) mission statement enough to totally dismiss something? Even if their actions (providing a reasonable alternative) are seemingly good?
*sigh* i love what they've done, but the best way to illustrate it is with a story from mother theresa. she was invited to an anti-war rally, once. she declined... and told them that if they ever wanted to hold a *peace* rally, she would be delighted to attend.
that really says it all, i think.
From what I have observed, you seem to have two "codes" that you live by, your ethics and your intuition.
ha. to clarify: i use my intuition to identify those things which are ethical [and then follow up with as much rational / logical reasoning as i can stand]. where i really didn't even have a definition of what is actually ethical until i encountered bob podolski, only last year. ironic or what... :)
Your ethics seems to mostly involve your influence over others, so what does your intuition say about Devuan?
jury's still out. i'm hopeful that one day they'll be able to resolve the conflict and truly honour their mission statement. for myself i... i simply cannot bring myself to endorse or support things where there exists a huge cognitive dissonance. call it an ISO9001 "fail" if you will.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Jul 9, 2017 at 2:53 AM, Hendrik Boom hendrik@topoi.pooq.com wrote:
The mission statement came later. But they do mean it's about choice. That said, they do have practial limitations as to what alternatives they can offer themselves, and they have focussed on important alternatives that are not provided by Debian. This is how they provide choice. I don't see how this si oncompatible with their mission statement, though I can see how it may appear so.
because i've spoken directly with them (privately), and received an emphatic opinion that their state of mind is so firmly in the "anti-systemd" camp that to even *contemplate* the mere *suggestion* - in an open fashion - that systemd really should be included in order to properly honour their mission statement would be outright rejected.
the sad thing is that if they actually did make it possible to choose to use systemd in devuan, the means and method by which that needs to be done would most likely result in the possibility of a complete merge between devuan and debian some in the future.
l.
Hi,
On Mon, Jul 03, 2017 at 10:26:51AM +0200, Philip Hands wrote:
Luke Kenneth Casson Leighton lkcl@lkcl.net writes:
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-re...
two years. that's how long one of these bugs has been in systemd. *via a remote network*. what the hell is an init system doing being accessible *via DNS queries*?
If you read the summary of the article to the second line, you'll note that it is talking about 'systemd-resolved' -- so not the init at all.
Yes, I know that it was stupid to call all these disparate bits of the SystemD project systemd-$whatever, becuase it's just asking for people to do what you just did, but I really expect _you_ to understand that there is more than one executable involved in systemd, and that not all of them can possibly run as process 1, all at once.
An init system comprises many processes. System V init e.g. uses shell scripts to start services. The whole system is called System V init.
Systemd is supposed to replace the complete init system, not just the process with PID 1. In addition, it adds lots of other functionality (DNS resolver, DCHP client, network configuration, desktop session management, ...), all of which existed and worked before the systemd replacements.
Thanks, Erik
On Mon, Jul 3, 2017 at 11:00 AM, Erik Auerswald auerswal@unix-ag.uni-kl.de wrote:
Systemd is supposed to replace the complete init system, not just the process with PID 1. In addition, it adds lots of other functionality (DNS resolver, DCHP client, network configuration, desktop session management, ...), all of which existed and worked before the systemd replacements.
.. and which have now been replaced by a monoculture which is focussed specifically on one OS (GNU/Linux), on one GNU/Linux distro (redhat), on one *type* of distro (redhat desktops), on one *desktop* (redhat gnome desktop), with *ZERO* wider consultation with other teams as to what they might want or need.
there has even been talk that FreeBSD and so on *MUST* convert over to systemd and associated fascist-developed support infrastructure "because that's how it's done, now". and if they do not, then, well, to hell with them: they can go bit-rot in hell as far as the supporters of systemd are concerned.
all of which illustrates that it's not about the code, it's not about the quality of the code, it's the entire attitude and the over-concentration of power into the hands of such a small and highly irresponsible team. and the fact that the distros are either complicit with this or are completely blind to how dangerous this situation really is to the health of the software libre community as a whole.
l.
On Mon, Jul 3, 2017 at 10:52 AM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
for anyone who still believes that systemd is okay to use and deploy, and that there exist "great advantages that outweigh the risks", are you *finally* getting the message now?
Because the only distro that uses systemd-resolved by default is ubuntu. Nobody else has been affected by this. Have you ever wondered why we see the kernel everywhere but every other part of the desktop stack is irrelevant outside the desktop users ? Because there is too much variance. And yet people keep breaking abis and support the idea of multiple inits that do the same thing in slightly different ways requiring the maintenance of multiple init scripts over and over again.
On Mon, Jul 3, 2017 at 9:47 AM, Bill Kontos vkontogpls@gmail.com wrote:
much variance. And yet people keep breaking abis and support the idea of multiple inits that do the same thing in slightly different ways requiring the maintenance of multiple init scripts over and over again.
when i was looking at taking over maintenance of depinit one of the first tasks was to add full automated compatibility for initscripts. signiicant advantages of depinit were lost in the process but there was no loss when compared to sysvinit itself. individual initscripts could then be replaced to provide a much better way of handling services (safe_mysqld for example could be dispensed with entirely).
even with that in mind i see no down-side to the additional workload that you refer to when you consider the upside that diversity brings. no monoculture, no centralised control, and a need for people managing *different* projects - the components that systemd has [irresponsibly] made quotes redundant quotes - to communicate, discuss and agree interoperable standards.
the abdication of responsibility by all distros has taken away the opportunity for diverse and disparate teams to work together, shunting aside all the safeguards that are normally in place and allowing lennart pottering and his team to arbitrarily and unilaterally decide how GNU/Linux should work.
this, then, primarily is what i do not understand that people do not understand.
l.
On Mon, Jul 3, 2017 at 12:06 PM, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
even with that in mind i see no down-side to the additional workload that you refer to when you consider the upside that diversity brings. no monoculture, no centralised control, and a need for people managing *different* projects - the components that systemd has [irresponsibly] made quotes redundant quotes - to communicate, discuss and agree interoperable standards.
Because it adds cost technical debt blah blah blah and it is one of the many reasons as to why applications in gnu/linux systems break all the time when the maintainer drops them. But I completely disagree with the idea that adding more people to the mix when they are not needed is a good thing. It is the fate of everything IT related to eventually be automated or made redundant and for people to move on to the next thing. That's just how it is. It used to be office suits being ported to multiple architectures in the 80s, it's init systems now. The problem I see with those criticizing systemd is that the vast majority of them do not even try to make something better that retains the features that make systemd valuable. Instead they just make a distro where they purge anything that has systemd in it's name even when it's a dummy package so packages who expect systemd but can't find it will work.
Also I don't consider going from a variety of options each with it's disadvantages to a single option essentially standardizing it a bad thing. It's just a lost opportunity to make a real standard for sure, but I don't think that's monoculture.
On Mon, Jul 3, 2017 at 10:19 AM, Bill Kontos vkontogpls@gmail.com wrote:
Also I don't consider going from a variety of options each with it's disadvantages to a single option essentially standardizing it a bad thing. It's just a lost opportunity to make a real standard for sure, but I don't think that's monoculture.
it's the very definition of a monoculture, bill.
a standard has multiple implementations: full documentation, stable APIs, a reference design plus alternative implementations (and/or people willing *to* implement alternative implementations).
where is the standard fully documented?
where is the definition of the stable APIs which have been set as "gold" and not subject to change for the next 10-20 years?
where is the reference design (with associated proper documentation)?
where are the alternative implementations?
l.
On Mon, Jul 03, 2017 at 12:05:59PM +0100, Luke Kenneth Casson Leighton wrote:
On Mon, Jul 3, 2017 at 10:19 AM, Bill Kontos vkontogpls@gmail.com wrote:
Also I don't consider going from a variety of options each with it's disadvantages to a single option essentially standardizing it a bad thing. It's just a lost opportunity to make a real standard for sure, but I don't think that's monoculture.
it's the very definition of a monoculture, bill.
a standard has multiple implementations: full documentation, stable APIs, a reference design plus alternative implementations (and/or people willing *to* implement alternative implementations).
where is the standard fully documented?
where is the definition of the stable APIs which have been set as "gold" and not subject to change for the next 10-20 years?
where is the reference design (with associated proper documentation)?
where are the alternative implementations?
Gee, it's as if you're talking about bitcoin-core....
Developing all this stuff you speak of takes resources and time to develop, test, deploy, support, maintain.
Do you have time to do it, or, at some point, do you have to take work that pays? So if you want to monoculture problem, then start figuring out how to build a **business model** based on a diverse ecosystem.
My first suggestion would be start accepting something like http://grantcoin.org as payment for your work, and for hardware, for at least if that works, we might have developers that can sign up for a basic income guarantee and work on whatever they feel like working on, rather than code that will get them paid.
Or sell me a piece of libre-hardware that's pre-installed **and QA tested** with a stack of libre-software that includes all the designs so I can go down to my local silicon fab and PCB house and have them make a derivative work.
On Mon, Jul 3, 2017 at 3:43 PM, Troy Benjegerdes hozer@hozed.org wrote:
Gee, it's as if you're talking about bitcoin-core....
bitcoin-core is not a critical and essential dependency which has been forced onto 98% of GNU/Linux users without their informed consent.
l.
when i was looking at taking over maintenance of depinit one of the first tasks was to add full automated compatibility for initscripts. signiicant advantages of depinit were lost in the process but there was no loss when compared to sysvinit itself. individual initscripts could then be replaced to provide a much better way of handling services (safe_mysqld for example could be dispensed with entirely).
even with that in mind i see no down-side to the additional workload that you refer to when you consider the upside that diversity brings. no monoculture, no centralised control, and a need for people managing *different* projects - the components that systemd has [irresponsibly] made quotes redundant quotes - to communicate, discuss and agree interoperable standards.
the abdication of responsibility by all distros has taken away the opportunity for diverse and disparate teams to work together, shunting aside all the safeguards that are normally in place and allowing lennart pottering and his team to arbitrarily and unilaterally decide how GNU/Linux should work.
this, then, primarily is what i do not understand that people do not understand.
l.
You absolutely have a point. we shouldn't be putting all our eggs into the same basket. What will happen if that basket gets holes in it?
This is the case of systemd.
I prefer not to trust systemd for this, security issues, stability issues and also my laptop runs slower with it.
I compared the difference between debian and devuan and I was sorely dissapointed by debian.
On 07/03/2017 03:52 AM, Luke Kenneth Casson Leighton wrote:
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-re...
two years. that's how long one of these bugs has been in systemd. *via a remote network*. what the hell is an init system doing being accessible *via DNS queries*?
for anyone who still believes that systemd is okay to use and deploy, and that there exist "great advantages that outweigh the risks", are you *finally* getting the message now?
dozens of distros, millions of people, all affected by the irresponsible act of switching "en-masse" to a single over-reaching init system which is developed in a fashion that is not being properly managed or controlled. i do not understand why people do not understand this.
l.
I got your message a while ago, and thank you for bringing this up, because systemd actually is not only less secure, but it is slower (for me anyways) and the people who made that software are hostile to people wanting to remove systemd. I use devuan ascii with openrc and I quite enjoy devuan. Just know, your words on systemd got me off of debian and onto devuan. So thank you!
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
arm-netbook@lists.phcomp.co.uk
-
Adam Van Ymeren -
Bill Kontos -
chadvellacottļ¼ sasktel.net -
Christopher Havel -
David Niklas -
doarkļ¼ mail.com
-
Elena ``of Valhalla'' -
Erik Auerswald -
Hendrik Boom -
James L -
Jean Flamelle -
Jonathan Frederickson -
Luke Kenneth Casson Leighton -
Neil Jansen -
Pablo Rath -
Philip Hands -
Troy Benjegerdes -
Tzafrir Cohen -
Vincent Legoll -
zap