Discussion:
[Arm-netbook] severe systemd bugs (two of them)
Luke Kenneth Casson Leighton
2017-07-03 07:52:59 UTC
Permalink
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years

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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large att
Philip Hands
2017-07-03 08:26:51 UTC
Permalink
Post by Luke Kenneth Casson Leighton
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
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.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
S
Luke Kenneth Casson Leighton
2017-07-03 08:40:06 UTC
Permalink
Post by Philip Hands
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-root-privileges-bug/

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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Philip Hands
2017-07-03 09:06:31 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Philip Hands
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.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom
Luke Kenneth Casson Leighton
2017-07-03 09:17:53 UTC
Permalink
Post by Philip Hands
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac
Jonathan Frederickson
2017-07-03 14:00:41 UTC
Permalink
On Mon, Jul 3, 2017 at 4:40 AM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
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.)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments
Luke Kenneth Casson Leighton
2017-07-03 14:24:53 UTC
Permalink
On Mon, Jul 3, 2017 at 3:00 PM, Jonathan Frederickson
Post by Jonathan Frederickson
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send l
Jonathan Frederickson
2017-07-03 14:38:46 UTC
Permalink
On Mon, Jul 3, 2017 at 10:24 AM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
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.)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@f
Luke Kenneth Casson Leighton
2017-07-03 15:02:23 UTC
Permalink
On Mon, Jul 3, 2017 at 3:38 PM, Jonathan Frederickson
Post by Jonathan Frederickson
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.
Post by Jonathan Frederickson
(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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph
Jonathan Frederickson
2017-07-03 15:34:29 UTC
Permalink
Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large att
Adam Van Ymeren
2017-07-03 16:35:00 UTC
Permalink
Post by Jonathan Frederickson
Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large
Jonathan Frederickson
2017-07-03 17:14:48 UTC
Permalink
Post by Adam Van Ymeren
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?

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta
Elena ``of Valhalla''
2017-07-03 18:45:28 UTC
Permalink
Post by Jonathan Frederickson
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.
Post by Jonathan Frederickson
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.
--
Elena ``of Valhalla''

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook@
zap
2017-07-03 22:32:00 UTC
Permalink
Post by Elena ``of Valhalla''
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. ;)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netb
Christopher Havel
2017-07-03 22:35:01 UTC
Permalink
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.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment
Tzafrir Cohen
2017-07-04 06:55:41 UTC
Permalink
Post by zap
Post by Elena ``of Valhalla''
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.
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.p
Luke Kenneth Casson Leighton
2017-07-04 09:04:03 UTC
Permalink
Post by Tzafrir Cohen
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil
Elena ``of Valhalla''
2017-07-04 09:42:37 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Tzafrir Cohen
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
--
Elena ``of Valhalla''

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large
Luke Kenneth Casson Leighton
2017-07-04 10:44:33 UTC
Permalink
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
Post by Elena ``of Valhalla''
Post by Tzafrir Cohen
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Luke Kenneth Casson Leighton
2017-07-04 11:15:23 UTC
Permalink
On Tue, Jul 4, 2017 at 11:44 AM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments t
Tzafrir Cohen
2017-07-04 12:08:03 UTC
Permalink
Post by Luke Kenneth Casson Leighton
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
Post by Elena ``of Valhalla''
Post by Tzafrir Cohen
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).
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).
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-net
Philip Hands
2017-07-05 17:49:11 UTC
Permalink
Post by Luke Kenneth Casson Leighton
On Tue, Jul 4, 2017 at 10:42 AM, Elena ``of Valhalla''
...
Post by Luke Kenneth Casson Leighton
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.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachm
Luke Kenneth Casson Leighton
2017-07-06 05:21:50 UTC
Permalink
Post by Philip Hands
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
Post by Philip Hands
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...
Post by Philip Hands
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? :)
Post by Philip Hands
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).
Post by Philip Hands
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to
Philip Hands
2017-07-04 07:51:54 UTC
Permalink
Post by zap
Post by Elena ``of Valhalla''
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.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
Jean Flamelle
2017-07-04 11:20:22 UTC
Permalink
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm
Luke Kenneth Casson Leighton
2017-07-04 14:05:07 UTC
Permalink
Post by Jean Flamelle
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.
Post by Jean Flamelle
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....
Post by Jean Flamelle
Hope, I'm helping with perspective :d
always. thank you jean.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attach
zap
2017-07-04 16:28:00 UTC
Permalink
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.
Post by Philip Hands
There is no "forcing" or "requiring" involved, and people spouting this
bullshit is getting _really_ old now.
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.
Post by Philip Hands
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.
Post by Philip Hands
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
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.



_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
Bill Kontos
2017-07-04 17:01:54 UTC
Permalink
Post by zap
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).

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@f
zap
2017-07-04 17:06:46 UTC
Permalink
Post by Bill Kontos
Post by zap
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.
Post by Bill Kontos
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.
Post by Bill Kontos
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Sen
Christopher Havel
2017-07-04 17:07:33 UTC
Permalink
With all due respect, some people can't code. Do they not deserve a voice?
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Christopher Havel
2017-07-04 17:29:18 UTC
Permalink
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...? ;)
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
Bill Kontos
2017-07-04 18:20:43 UTC
Permalink
Post by Christopher Havel
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments t
Christopher Havel
2017-07-04 18:23:33 UTC
Permalink
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.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@f
Neil Jansen
2017-07-04 17:43:11 UTC
Permalink
Post by Christopher Havel
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.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phc
Christopher Havel
2017-07-04 17:53:36 UTC
Permalink
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...
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta
Neil Jansen
2017-07-04 18:14:59 UTC
Permalink
On Jul 4, 2017 1:53 PM, "Christopher Havel" <***@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.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to a
Christopher Havel
2017-07-04 18:20:24 UTC
Permalink
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"...
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta
Elena ``of Valhalla''
2017-07-04 18:36:37 UTC
Permalink
Post by Christopher Havel
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.
--
Elena ``of Valhalla''

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment
Hendrik Boom
2017-07-04 18:39:17 UTC
Permalink
Post by Bill Kontos
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments
Elena ``of Valhalla''
2017-07-04 20:03:34 UTC
Permalink
Post by Hendrik Boom
Post by Bill Kontos
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.
--
Elena ``of Valhalla''

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
Luke Kenneth Casson Leighton
2017-07-05 05:00:39 UTC
Permalink
On Tue, Jul 4, 2017 at 9:03 PM, Elena ``of Valhalla''
Post by Elena ``of Valhalla''
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send lar
Philip Hands
2017-07-04 21:50:34 UTC
Permalink
Post by zap
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.
Post by Philip Hands
There is no "forcing" or "requiring" involved, and people spouting this
bullshit is getting _really_ old now.
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.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/ http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-
zap
2017-07-05 00:43:12 UTC
Permalink
Post by Philip Hands
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.
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
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,
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
Luke Kenneth Casson Leighton
2017-07-05 05:37:39 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by zap
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom
zap
2017-07-05 11:50:50 UTC
Permalink
Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by zap
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.


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta
Luke Kenneth Casson Leighton
2017-07-05 05:35:06 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Philip Hands
Post by zap
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.
Post by Philip Hands
There is no "forcing" or "requiring" involved, and people spouting this
bullshit is getting _really_ old now.
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.
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachm
Tzafrir Cohen
2017-07-03 17:12:18 UTC
Permalink
I'm not going to join this pro/anti systemd discussion as it is
pointless at this point, but,
Post by Luke Kenneth Casson Leighton
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?
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
zap
2017-07-03 18:26:20 UTC
Permalink
Post by Tzafrir Cohen
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...

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la
Luke Kenneth Casson Leighton
2017-07-04 01:57:22 UTC
Permalink
Post by Tzafrir Cohen
Hang on, is this for the images for the EOMA68?
no.
Post by Tzafrir Cohen
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large
Hendrik Boom
2017-07-04 01:41:07 UTC
Permalink
Post by Luke Kenneth Casson Leighton
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


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send larg
Luke Kenneth Casson Leighton
2017-07-04 01:55:09 UTC
Permalink
Post by Hendrik Boom
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
Tzafrir Cohen
2017-07-04 07:17:00 UTC
Permalink
Post by Hendrik Boom
Post by Luke Kenneth Casson Leighton
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.
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.
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph
Luke Kenneth Casson Leighton
2017-07-04 09:09:45 UTC
Permalink
Post by Tzafrir Cohen
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send
Hendrik Boom
2017-07-04 14:29:47 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Tzafrir Cohen
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.
Post by Luke Kenneth Casson Leighton
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
James L
2017-07-05 04:48:31 UTC
Permalink
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?
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook
Luke Kenneth Casson Leighton
2017-07-05 05:48:08 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by James L
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.
Post by James L
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.
Post by James L
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... :)
Post by James L
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-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large att
David Niklas
2017-07-07 22:35:16 UTC
Permalink
On Wed, 5 Jul 2017 06:48:08 +0100
Post by Luke Kenneth Casson Leighton
Post by James L
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.
Post by James L
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.
Post by James L
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... :)
Post by James L
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachm
Luke Kenneth Casson Leighton
2017-07-08 14:24:23 UTC
Permalink
Post by David Niklas
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.
Post by David Niklas
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.
Post by David Niklas
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.
Post by David Niklas
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta
Tzafrir Cohen
2017-08-01 19:14:11 UTC
Permalink
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.
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachme
Hendrik Boom
2017-08-01 22:40:36 UTC
Permalink
Post by Tzafrir Cohen
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large
d***@mail.com
2017-08-06 01:56:23 UTC
Permalink
On Tue, 1 Aug 2017 21:14:11 +0200
Post by Tzafrir Cohen
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
Pablo Rath
2017-08-08 09:57:44 UTC
Permalink
Post by d***@mail.com
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Vincent Legoll
2017-08-08 11:45:39 UTC
Permalink
Hello,
Post by Pablo Rath
Post by d***@mail.com
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...
--
Vincent Legoll

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
zap
2017-08-08 15:21:44 UTC
Permalink
Post by Vincent Legoll
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. ;)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar
Luke Kenneth Casson Leighton
2017-08-08 15:45:50 UTC
Permalink
Post by zap
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar
zap
2017-08-08 20:12:44 UTC
Permalink
Post by Luke Kenneth Casson Leighton
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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
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.


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phco
Luke Kenneth Casson Leighton
2017-08-09 04:36:50 UTC
Permalink
Post by zap
Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
zap
2017-08-09 09:34:00 UTC
Permalink
Post by Luke Kenneth Casson Leighton
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
Post by Luke Kenneth Casson Leighton
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.


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcom
Vincent Legoll
2017-08-09 09:43:38 UTC
Permalink
Post by zap
Post by Luke Kenneth Casson Leighton
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).
--
Vincent Legoll

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send lar
Luke Kenneth Casson Leighton
2017-08-09 10:46:39 UTC
Permalink
Post by zap
Post by Luke Kenneth Casson Leighton
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).
Post by zap
Post by Luke Kenneth Casson Leighton
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.
Post by zap
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-ne
Hendrik Boom
2017-08-08 13:58:05 UTC
Permalink
Post by Pablo Rath
Post by d***@mail.com
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phco
c***@sasktel.net
2017-08-11 21:07:37 UTC
Permalink
Post by Pablo Rath
Post by d***@mail.com
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phc
Pablo Rath
2017-08-12 09:43:22 UTC
Permalink
Post by c***@sasktel.net
Post by Pablo Rath
Post by d***@mail.com
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

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@file

c***@sasktel.net
2017-08-11 21:07:56 UTC
Permalink
This is a late response, but persons seem to keep confusing the two mailing-lists.
Post by Luke Kenneth Casson Leighton
Post by David Niklas
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.
Post by Luke Kenneth Casson Leighton
Post by David Niklas
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.)
Post by Luke Kenneth Casson Leighton
Post by David Niklas
I really believe that they
will meet with success in their toiling.
~~~
Post by Luke Kenneth Casson Leighton
Post by David Niklas
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,
~~~
Post by Luke Kenneth Casson Leighton
l.
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo
Luke Kenneth Casson Leighton
2017-08-11 21:12:00 UTC
Permalink
Post by c***@sasktel.net
This is a late response, but persons seem to keep confusing the two mailing-lists.
yeah me included. thanks for pointing this out chad.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments
Hendrik Boom
2017-07-09 01:53:55 UTC
Permalink
Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by James L
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
Post by Luke Kenneth Casson Leighton
Post by James L
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.
Post by James L
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... :)
Post by James L
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.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large atta
Luke Kenneth Casson Leighton
2017-07-09 04:15:04 UTC
Permalink
Post by Hendrik Boom
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send la
Erik Auerswald
2017-07-03 10:00:48 UTC
Permalink
Hi,
Post by Philip Hands
Post by Luke Kenneth Casson Leighton
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
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
--
If it ain't broke, don't fix it.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
Luke Kenneth Casson Leighton
2017-07-03 11:02:45 UTC
Permalink
On Mon, Jul 3, 2017 at 11:00 AM, Erik Auerswald
Post by Erik Auerswald
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar
Bill Kontos
2017-07-03 08:47:32 UTC
Permalink
On Mon, Jul 3, 2017 at 10:52 AM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.
Luke Kenneth Casson Leighton
2017-07-03 09:06:06 UTC
Permalink
Post by Bill Kontos
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar
Bill Kontos
2017-07-03 09:19:49 UTC
Permalink
On Mon, Jul 3, 2017 at 12:06 PM, Luke Kenneth Casson Leighton
Post by Luke Kenneth Casson Leighton
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@f
Luke Kenneth Casson Leighton
2017-07-03 11:05:59 UTC
Permalink
Post by Bill Kontos
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Troy Benjegerdes
2017-07-03 14:43:31 UTC
Permalink
Post by Luke Kenneth Casson Leighton
Post by Bill Kontos
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files
Luke Kenneth Casson Leighton
2017-07-03 17:27:33 UTC
Permalink
Post by Troy Benjegerdes
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.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment
zap
2017-07-03 15:37:52 UTC
Permalink
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.


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.
zap
2017-07-03 15:33:23 UTC
Permalink
Post by Luke Kenneth Casson Leighton
https://it.slashdot.org/story/17/07/03/0343258/severe-systemd-bug-allowed-remote-code-execution-for-two-years
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!
Post by Luke Kenneth Casson Leighton
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.
Loading...