Re: Debianization

[Didier Kryn]

Le 21/04/2018 à 18:19, Guillaume Perréal a écrit :

Le 21/04/2018 à 12:28, Didier Kryn a écrit :
    May I humbly ask why you don't start with Devuan (which is Debian 
stripped out of systemd)? Of course it is less challenging than doing 
the job on Debian, but it would be wholehartedly applauded and tested 
by the Devuan community, while you shouldn't expect much recognition 
from Debian.


            Didier
I have tried to boot an Alpine Linux with s6-init and the set of of 
the services I wanted and it is quite a lot a work. I think writing a 
full replacement with shims and "translators" is an order of magnitude 
higher.


Guillaume.


    I'm a follower of musl and a supporter of static 
linking. I started to build my own musl-based Linux before Alpine was 
available and eventually achieved to build a functional native 
development platform. But it is too much work and I plan to try Alpine 
pretty soon :-)


    Whether starting from Alpine or Devuan, at least you don't have to 
fight against Systemd which has put metastases pretty much everywhere in 
the system. You start from sysvinit and just replace the rc scripts even 
with keeping sysv's init proper, at the beginning. A big part of the 
work is packaging and transitionning flawlessly from one system to the 
other when installing/removing the packages.


        Didier

Re: Debianization

[Didier Kryn]

Le 20/04/2018 à 07:48, SZÉPE Viktor a écrit :

Idézem/Quoting Colin Booth :


On Thu, Apr 19, 2018 at 11:10:33PM +, Laurent Bercot wrote:

> Have any started (thinking about) packaging skalibs, execline and s6
> the Debian policy-obeying way?

 What does that mean? If it's just FHS, skarnet.org follows FHS by
default, so there's no problem here. Are there other constraints
restricting what a Debian package can do?

It's technically a pile of things:
libs/skalibs (the .so)
lib-devel/skalivs-dev (the .a for compiling against
lang/execline
lib/libexecline (the .so)
lib-devel/libexecline-dev (the .a again)
and so on. I have sort-of complaint packages that I used to get my build
chain working for a project at work, but correctly separating stuff isa
chunk of work. Doable, just obnoxious.


In a previous message:


... into both .deb's and .rpm's using fpm without much fuss.


That much fuss includes 859 lintian tags e.g. gcc hardening, rc 
scripts for essential Debian packages, a systemd->s6 migration utility 
etc.

https://lintian.debian.org/tags.html

So basically I type apt-get install s6 and it makes systemd disappear, 
and all these basic services work after reboot:


cgroupfs-mount
console-setup.sh
cron
dbus
hwclock.sh
keyboard-setup.sh
kmod
networking
procps
rsync
rsyslog
ssh
udev

Is there a documentation how to turn e.g. 'networking' into an s6 rc?


SZÉPE Viktor, honlap üzemeltetés / Running your application
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md



    May I humbly ask why you don't start with Devuan (which is Debian 
stripped out of systemd)? Of course it is less challenging than doing 
the job on Debian, but it would be wholehartedly applauded and tested by 
the Devuan community, while you shouldn't expect much recognition from 
Debian.


            Didier

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Didier Kryn]

Le 16/11/2017 à 12:31, Laurent Bercot a écrit :

   I fully understand that this list is focused on good programming
practice and libudev is considered something disgusting in that
respect. My question was triggered by the frustration, probably
shared by many, of not being able to replace Udev by Mdev or Mdevd,
only because Xorg autoconfig has become a must.


 And do you think it's fair to direct that frustration at people who have
nothing to do with its causes and cannot do anything about it, instead of
the people in charge?

 The issue is not a technical one: it's a political one. I can provide
technical solutions to technical problems, but if you want to tackle
political problems, you will need someone with more political power
and more willingness to do politics.



Using the same API as libudev isn't necessary, because Xorg might be
patched to use a different one, but what is needed is to hide the
unstability of sysfs by some run-time abstraction layer.

   Replacing systemd-udev by something simpler and well done, like
mdev or mdevd is not only a technical, but also a crucial political
issue for software freedom. So hopping somebody with the skills will
come out with a good idea


 Apparently I was not clear enough, so let me repeat: replacing udev with
something simpler and well done is, AFAICT, impossible as long as you
stick to the notion of "hide the unstability of sysfs by some run-time
abstraction layer". The run-time abstraction layer is exactly what
libudev is; if you start with the same concepts as udev and implement
from
there, you *will* end up with udev, there's no way around it.

 Maybe an alternative implementation of libudev would be better; it
probably would, because given freedesktop.org's (and especially Kay
Sievers') history, chances are the current implementation of libudev is
terrible. But a new implementation *would not solve the underlying
issue*. Any gains would only be marginal; a new API could be somewhat
different,
but not different enough from libudev's API to be worth it. At the end
of the day, it would just split up the software ecosystem and incur
maintenance costs, for what? the satisfaction of not having GKH and KS
control uevent management in Xorg, knowing full well that the alternative
does the exact same thing as libudev with the exact same issues,
minus some minor implementation ones?

 When I look at libudev, I see a bunch of bloaty wrappers and generic
functionality put in a nice package and enforced on people. I don't
like it any more than you do, but the real fix is to do away with the
need for that bloat in the first place; it definitely is not to go NIH
and say "ok, we'll do our own libudev, which will be just as useless, but
at least it won't be yours, nyah nyah nyah".

 I'm interested in writing code that does real things, not in writing
bloaty wrappers, even if I know that MY bloaty wrappers would be the
best bloaty wrappers ever.

 Tell you what, I do have an idea for a libudev alternative: in your
application, you write your code *exactly* as you would if you were
accessing the files in sysfs directly, except you don't access files
under /sys, you access files under /definitelynotsys instead. And
you defer the responsibility of the /sys to /definitelynotsys mapping
to a third-party layer; I can even be that third party, if you want.
Nobody can blame you: you're not accessing sysfs, you're just using
my API. And it's nobody's business if a common implementation of my API
is making /definitelynotsys a symlink to /sys.

--
 Laurent


Dear Laurent.

Excuse me for insisting so long and off-topic. For my excuse let me 
say my only will was to use mdevd *and* Xorg. I'm not fond of politics 
more than you. Let's put an end to this thread.


Didier

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Didier Kryn]

Le 16/11/2017 à 10:25, Casper Ti. Vector a écrit :

On Wed, Nov 15, 2017 at 02:53:21PM +, Laurent Bercot wrote:

  Is it really the only place in Xorg that depends on libudev?
I'd think it would be much, much more entangled with libudev than
this.

Unfortunately, just as noted by Guillermo, libudev is also, in more
complicated ways, needed by quite a few x11 drivers and (perhaps most
importantly) xserver itself.  I apologise for (again) not thoroughly
investigating the issues before replying :(


  So, yeah. If you want a patch for xf86-input-evdev that will
make it stop depend on libudev, I can write one in an hour. But
that patch will likely never go upstream, because it goes against
policy; and complying with the policy would basically amount to
rewriting libudev and making a new udevd. Which I believe I'm quite
able to do, and better than the existing ones, but it would still be
bad software design, and I have no interest in contributing to the
problem.

(Again, I am not someone fluent in low level programming, so please feel
free to correct me if I make stupid mistakes in the following.)

 From my cursory glance at the x11 code that use libudev, and the libudev
documentation, the main functionalities of libudev seem to fall into two
almost orthogonal categories: those that abstract the sysfs interface,
and those that handle the udev event queue.  I have not come up with a
good idea on how to provide the latter in a vender-neutral way, but a
neutral design of the former seems obvious: if sysfs was really never
intended to be a stable interface at all, at least make a minimalist
library outside udev that provide the necessary functionalities.

However, as you noted, "sysfs has not changed interfaces to the point of
breaking stuff in 12 years and counting", so the intended instability is
not really an excuse; and even if we pretend that sysfs is so unstable,
stating that sysfs is "a private export only to be consumed by udev" [1]
(ie. not mdev, nldev, vdev, etc.) has no technical basis.  But noticing
that the actors in the drama include GKH and KS, this is unsurprising;
this is also the reason I refered to the conspiracy theory again.

[1] 

I agree that there is a conspiracy. The mails exchanged by Rob 
Landley are very explicit.


I don't think Linus Torvalds would tolerate on the long term that a 
group of people develop a private kernel interface for the purpose of 
forcing systemd to all Linux users. In fact I guess he is aware of this, 
and even sensitive to the bad quality of their code, but he will not 
move because only one person complains.


Rob Landley would have a stronger argument if a large number of 
users had their desktops running mdev and undocumented changes in sysfs 
breaks it.


Didier

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Didier Kryn]

Le 15/11/2017 à 19:27, Laurent Bercot a écrit :

   "Applications should not access sysfs" doesn't mean there should
be only one version of the intermediate library. There's already
Systemd-Udev and Eudev versions, at least. For the case of Xorg, it
just means sysfs access should not be hard-coded in the source of
Xorg, but there should be some library in between, so that it is not
necessary to recompile Xorg for every version of the kernel. So any
replacement for the needed subset of libudev would do it.


 Yes, but that's the whole point: the needed information is available
as is in sysfs, and putting a library in-between is 100% bloat. It's
just about testing something in the device path, and the device path
is just that - a path in sysfs. The way libudev proceeds to get
that information is entirely more complex than necessary - it even adds
operations that can fail, such as memory allocation, when it is
entirely useless here; but with the way the libudev architecture is
designed, it is the only way, and there's no escaping the bloat,
added SPOF, added failure points.

 There is _no good way_ to implement the interesting parts of
EvdevDeviceIsVirtual() without directly accessing sysfs. It's either
sysfs, or libudev, or a libudev replacement that would, by design,
necessarily be just as bad as libudev.

--
 Laurent

I fully understand that this list is focused on good programming 
practice and libudev is considered something disgusting in that respect. 
My question was triggered by the frustration, probably shared by many, 
of not being able to replace Udev by Mdev or Mdevd, only because Xorg 
autoconfig has become a must. Using the same API as libudev isn't 
necessary, because Xorg might be patched to use a different one, but 
what is needed is to hide the unstability of sysfs by some run-time 
abstraction layer.


Replacing systemd-udev by something simpler and well done, like 
mdev or mdevd is not only a technical, but also a crucial political 
issue for software freedom. So hopping somebody with the skills will 
come out with a good idea :-)


Didier

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Didier Kryn]

Le 15/11/2017 à 15:53, Laurent Bercot a écrit :

Linus has said, multiple times, that sysfs wasn't supposed to be a
stable interface, so applications should just not access sysfs.


"Applications should not access sysfs" doesn't mean there should be 
only one version of the intermediate library. There's already 
Systemd-Udev and Eudev versions, at least. For the case of Xorg, it just 
means sysfs access should not be hard-coded in the source of Xorg, but 
there should be some library in between, so that it is not necessary to 
recompile Xorg for every version of the kernel. So any replacement for 
the needed subset of libudev would do it.


I don't know what evdev is (I guess some virtual device) and what's 
its place in the big Xorg picture, but I think some of you guys know it. 
Any usefull link?


Didier

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Didier Kryn]

Le 12/11/2017 à 20:24, Laurent Bercot a écrit :

Will there be a plan to add something roughly isomorphic to libudev?


 Not in the short or medium term. The problem of libudev, and this
is shared by everything from freedesktop.org as well as systemd, is
that its design and structure cannot be achieved without a monolithic
implementation, and are a stealthy way to enforce vendor lock-in.

 In other words: if you try to implement something like libudev, you
necessarily end up writing your own udevd, which is a useless pursuit -
and there is no way to make it more modular.



A most desired addition to mdev would be to provide a means for 
Xorg to autoconfigure, which it does now, IIUC, with the help of 
libudev. This doesn't means using the same API as libudev because I bet 
Xorg people would be open to an alternative.


Not saying this is easy, but it's not the same thing as pursuing 
the whole udev...


Didier