Re: [Dng] [dng] vdev status updates

[KatolaZ]

On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
> On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
> > They decided to put them on the second disk which contained user data 
> > and was therefore mounted at /usr
> AFAIK that's "Unix System Resources" or somesuch, not "User"
> /j


Well, in the first few versions of Research Unix (and I believe at
least until Version 7, in 1979) /usr was the folder where user home
directories lived. /home came much later, AFAIK...

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] acpi and systemd

[James Powell]

Having watched other systems transitioning to systemd, I wouldn't be surprised 
if they did, or the projects get pushed into forced deprecation as ConsoleKit 
did before it was revived.
 
-Jim
 
> Date: Wed, 29 Apr 2015 08:19:25 -0400
> From: hend...@topoi.pooq.com
> To: dng@lists.dyne.org
> Subject: Re: [Dng] acpi and systemd
> 
> On Sun, Apr 26, 2015 at 12:31:16AM +0200, Franco Lanza wrote:
> > On Sat, Apr 25, 2015 at 05:16:42PM -0400, Hendrik Boom wrote:
> > > 
> > > acpid and acpi-support-base have already been removed from tasksel.
> > 
> > 
> > We already forked tasksel, so, it should not be an issue for us as long
> > as those two packages are maintained, or we will need to fork both acpid
> > and acpi-support-base too.
> 
> Indeed.  Is there a mechanism in place to watch for this kind of thing?  
> Should there be?
> 
> There might be a lot of packages dropped if Debian decides that systemd 
> supplants or conflicts with them,
> 
> -- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Dr. Nikolaus Klepp]

From the FreeBSD point of view:

https://www.freebsd.org/doc/en/books/handbook/dirstructure.html

Anyway, symlinking /bin to /usr/bin is quite strange.

Nik

Am Donnerstag, 30. April 2015 schrieb James Powell:
> From my personal knowledge, having built LFS a few times, though this doesn't 
> compare with other distributions as the purposes of /(root), /usr, /opt, and 
> /usr/local have changed over the years:
>  
> /(root) is where boot-time software is to be installed that must be readily 
> available when the system is brought up and init is sent into action.
>  
> /usr is where admin system and networked system services are installed. In 
> Linux terms, just about all software is installed here including local system 
> applications and add-on software. in BSD terms, this is where all 
> administrative tools to the OS are installed that do not have the same 
> priority as those needed at boot-time in /(root).
>  
> /usr/local is where user installed local packages are installed and ran from. 
> In Linux terms, this directory is rarely used nowadays, but is still part of 
> the FHS guidelines because you can use this directory. In BSD terms any 
> packages from the ports collection are installed here to segregate user 
> installed local applications and packages from the main BSD system.
>  
> /opt is where single purpose software that usually is self-contained, such as 
> LibreOffice, Mozilla Firefox, and specialized libraries like QT are kept.
>  
> /home was developed to separate non-root user accounts from /root and the 
> core of the system. Usually this is a separate partition usually using a long 
> term storage file system like BtrFS, ZFS, JFS, ReiserFS, etc.
>  
> Now this may not be 100% accurate but it is a rough estimate of what these 
> were purposed for.
>  
> I could be wrong... but I have been wrong from time to time.
>  
> -Jim
>  
> > Date: Thu, 30 Apr 2015 08:48:10 +0100
> > From: kato...@freaknet.org
> > To: reisenwe...@web.de
> > CC: dng@lists.dyne.org
> > Subject: Re: [Dng] [dng] vdev status updates
> > 
> > On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
> > > On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
> > > > They decided to put them on the second disk which contained user data 
> > > > and was therefore mounted at /usr
> > > AFAIK that's "Unix System Resources" or somesuch, not "User"
> > > /j
> > 
> > 
> > Well, in the first few versions of Research Unix (and I believe at
> > least until Version 7, in 1979) /usr was the folder where user home
> > directories lived. /home came much later, AFAIK...
> > 
> > My2Cents
> > 
> > KatolaZ
> > 
> > -- 
> > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[James Powell]

>From my personal knowledge, having built LFS a few times, though this doesn't 
>compare with other distributions as the purposes of /(root), /usr, /opt, and 
>/usr/local have changed over the years:
 
/(root) is where boot-time software is to be installed that must be readily 
available when the system is brought up and init is sent into action.
 
/usr is where admin system and networked system services are installed. In 
Linux terms, just about all software is installed here including local system 
applications and add-on software. in BSD terms, this is where all 
administrative tools to the OS are installed that do not have the same priority 
as those needed at boot-time in /(root).
 
/usr/local is where user installed local packages are installed and ran from. 
In Linux terms, this directory is rarely used nowadays, but is still part of 
the FHS guidelines because you can use this directory. In BSD terms any 
packages from the ports collection are installed here to segregate user 
installed local applications and packages from the main BSD system.
 
/opt is where single purpose software that usually is self-contained, such as 
LibreOffice, Mozilla Firefox, and specialized libraries like QT are kept.
 
/home was developed to separate non-root user accounts from /root and the core 
of the system. Usually this is a separate partition usually using a long term 
storage file system like BtrFS, ZFS, JFS, ReiserFS, etc.
 
Now this may not be 100% accurate but it is a rough estimate of what these were 
purposed for.
 
I could be wrong... but I have been wrong from time to time.
 
-Jim
 
> Date: Thu, 30 Apr 2015 08:48:10 +0100
> From: kato...@freaknet.org
> To: reisenwe...@web.de
> CC: dng@lists.dyne.org
> Subject: Re: [Dng] [dng] vdev status updates
> 
> On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
> > On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
> > > They decided to put them on the second disk which contained user data 
> > > and was therefore mounted at /usr
> > AFAIK that's "Unix System Resources" or somesuch, not "User"
> > /j
> 
> 
> Well, in the first few versions of Research Unix (and I believe at
> least until Version 7, in 1979) /usr was the folder where user home
> directories lived. /home came much later, AFAIK...
> 
> My2Cents
> 
> KatolaZ
> 
> -- 
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] About (k)dbus in LKML

[James Powell]

The discussion has not been favorable towards the adoption from current reading 
on LKML. Past tests have not proven reliability, nor any significant increase 
of speed of messaging across the IPC. Linus seems to be of no love for it.
 
IMO from the collective discussion, kdbus doesn't seem to be really well 
designed, fast, or reliable compared to traditional D-Bus and only has a small 
if minimal gain over traditional D-Bus near negligible. In short, one could 
wonder if this effort was a complete waste of time, or a convoluted effort to 
introduce a proprietary IPC in the kernel that can only be used by system so 
they can kill off netlink support in udev in favor of kdbus. My pick is the 
latter as we all know how the systemd kabal thinks, and we all can make an 
educated guess as to where Greg Kroah-Hartman's true loyalties lie.
 
The native IPC for Linux has been reliable, though it's not exactly fast by all 
means, but in terms of working, it works, does it's job well, and has a proven 
track record. All it needs are new protocols worked in to help it out by 
introducing new methods of using the IPC while maintaining legacy pathways. 
Oddly enough another IPC, Plumper from 9P has been available for some time now, 
but has never been attempted at a port.
 
I, and possibly others, can only hope Linus actually and ultimately says "no" 
to kdbus and sees the purpose behind kdbus not being a successor to D-Bus but a 
proprietary IPC that can be used by system for udev, and only for that purpose.
 
Though should it become part of the mainline, we all know Lennart will waste no 
time in dropping netlink support in udev just to get his way. If that becomes 
the case, eudev can hopefully make an effort to keep netlink alive in a 
separate tree while backporting code in from system-udev, but who knows how 
long that will last. However, Linus did make a stern warning that if they did 
anything to break the userspace (and breaking netlink in udev would do just 
that), they could have any number of penalties from more developers from 
systemd banned from kernel developments, to as well as possibly code excised 
from the kernel.
 
My 2 cents,
-Jim
 
Date: Tue, 28 Apr 2015 23:00:55 +1000
From: ad_u...@runbox.com
To: dng@lists.dyne.org
Subject: [Dng] About (k)dbus in LKML

https://news.ycombinator.com/item?id=9450806
 
Hot discussion about merging kdbus in kernel.
 
TL;DR: The people who talk about how kdbus improves performance are just
full of sh*t. (c) Linus
 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng  
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[James Powell]

Symlinking /bin to /usr/bin only seems like they are trying for a unified tree 
approach which is an ill design. If that's the case they should just install 
everything in /opt in it's own micro-tree/branch. Yes, it doesn't make sense 
because you have to use an initramfs if you use a separated /usr partition.
 
-Jim
 
> From: dr.kl...@gmx.at
> To: dng@lists.dyne.org
> Date: Thu, 30 Apr 2015 10:12:30 +0200
> Subject: Re: [Dng] [dng] vdev status updates
> 
> From the FreeBSD point of view:
> 
> https://www.freebsd.org/doc/en/books/handbook/dirstructure.html
> 
> Anyway, symlinking /bin to /usr/bin is quite strange.
> 
> Nik
> 
> Am Donnerstag, 30. April 2015 schrieb James Powell:
> > From my personal knowledge, having built LFS a few times, though this 
> > doesn't compare with other distributions as the purposes of /(root), /usr, 
> > /opt, and /usr/local have changed over the years:
> >  
> > /(root) is where boot-time software is to be installed that must be readily 
> > available when the system is brought up and init is sent into action.
> >  
> > /usr is where admin system and networked system services are installed. In 
> > Linux terms, just about all software is installed here including local 
> > system applications and add-on software. in BSD terms, this is where all 
> > administrative tools to the OS are installed that do not have the same 
> > priority as those needed at boot-time in /(root).
> >  
> > /usr/local is where user installed local packages are installed and ran 
> > from. In Linux terms, this directory is rarely used nowadays, but is still 
> > part of the FHS guidelines because you can use this directory. In BSD terms 
> > any packages from the ports collection are installed here to segregate user 
> > installed local applications and packages from the main BSD system.
> >  
> > /opt is where single purpose software that usually is self-contained, such 
> > as LibreOffice, Mozilla Firefox, and specialized libraries like QT are kept.
> >  
> > /home was developed to separate non-root user accounts from /root and the 
> > core of the system. Usually this is a separate partition usually using a 
> > long term storage file system like BtrFS, ZFS, JFS, ReiserFS, etc.
> >  
> > Now this may not be 100% accurate but it is a rough estimate of what these 
> > were purposed for.
> >  
> > I could be wrong... but I have been wrong from time to time.
> >  
> > -Jim
> >  
> > > Date: Thu, 30 Apr 2015 08:48:10 +0100
> > > From: kato...@freaknet.org
> > > To: reisenwe...@web.de
> > > CC: dng@lists.dyne.org
> > > Subject: Re: [Dng] [dng] vdev status updates
> > > 
> > > On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
> > > > On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
> > > > > They decided to put them on the second disk which contained user data 
> > > > > and was therefore mounted at /usr
> > > > AFAIK that's "Unix System Resources" or somesuch, not "User"
> > > > /j
> > > 
> > > 
> > > Well, in the first few versions of Research Unix (and I believe at
> > > least until Version 7, in 1979) /usr was the folder where user home
> > > directories lived. /home came much later, AFAIK...
> > > 
> > > My2Cents
> > > 
> > > KatolaZ
> > > 
> > > -- 
> > > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> > > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> > > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> > > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> > > ___
> > > Dng mailing list
> > > Dng@lists.dyne.org
> > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >   
> 
> 
> 
> -- 
> Please do not email me anything that you are not comfortable also sharing 
> with the NSA.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
  ___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 30/04/2015 01:27, Joerg Reisenweber a écrit :

On Wed 29 April 2015 23:46:51 Didier Kryn wrote:

>They decided to put them on the second disk which contained user data
>and was therefore mounted at /usr

AFAIK that's "Unix System Resources" or somesuch, not "User"
Maybe it's true, but it sounds like an afterthought, mostly for the 
reason it is inacurate, because the most important Unix System Resources 
are NOT in this directory but in /bin, /sbin, /lib and /etc.


I'm not saying it is illegitimate to try to give sense. People are 
now finding advantages in this configuration, which were not the 
original reason; why not also forge an acronym to give a sensible 
meaning to the name, different of the original meaning?


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] About (k)dbus in LKML

[Brad Campbell]

On 28/04/15 21:00, Alex 'AdUser' Z wrote:

https://news.ycombinator.com/item?id=9450806

Hot discussion about merging kdbus in kernel.

TL;DR: The people who talk about how kdbus improves performance are just
full of sh*t. (c) Linus


It is certainly a deep and wide ranging thread. When looked at from the 
10,000 foot view it does look like the dbus/systemd people have painted 
themselves into a corner and are trying to push an ill-conceived and 
incomplete hack into the kernel to try and work around it. It seems to 
have very little tangible benefit and lots of warts all over the place.


Hopefully it does not get legs and people spend some time coming up with 
a well thought out alternative solution that works for more than systemd 
lock in. I don't hold a _lot_ of hope however.


Regardless, Devuan is a step in the right direction.

Regards,
Brad
--
Dolphins are so intelligent that within a few weeks they can
train Americans to stand at the edge of the pool and throw them
fish.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Thu 30 April 2015 10:12:30 Dr. Nikolaus Klepp wrote:
> From the FreeBSD point of view:
> 
> https://www.freebsd.org/doc/en/books/handbook/dirstructure.html

and here is more (sorry to link to the obvious):  
http://www.pathname.com/fhs/pub/fhs-2.3.html (possibly outdated, I didn't 
check for a long time)

let me quote a quite old factoid of IRC infobot about what they did to /usr 
and /opt in maemo:
 optification is a inventive duct tape workaround to reclaim space in 
fs root, done due to the fact the systeminit *and* partitioning is FUBAR,  
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs,
 
or ""OMG - I wish they looked into FHS and moved /usr to eMMC"", 
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 bullet1,2 and 
fhs-2.3.html#PURPOSE16 dot3"

Maemo is also a nice example of a system that's absolutely incompatible with 
that systemd avalanche

/j


> 
> Anyway, symlinking /bin to /usr/bin is quite strange.
> 
> Nik
> 
> Am Donnerstag, 30. April 2015 schrieb James Powell:
> > From my personal knowledge, having built LFS a few times, though this
> > doesn't compare with other distributions as the purposes of /(root),
> > /usr, /opt, and /usr/local have changed over the years:
> > 
> > /(root) is where boot-time software is to be installed that must be
> > readily available when the system is brought up and init is sent into
> > action.
> > 
> > /usr is where admin system and networked system services are installed. In
> > Linux terms, just about all software is installed here including local
> > system applications and add-on software. in BSD terms, this is where all
> > administrative tools to the OS are installed that do not have the same
> > priority as those needed at boot-time in /(root).
> > 
> > /usr/local is where user installed local packages are installed and ran
> > from. In Linux terms, this directory is rarely used nowadays, but is
> > still part of the FHS guidelines because you can use this directory. In
> > BSD terms any packages from the ports collection are installed here to
> > segregate user installed local applications and packages from the main
> > BSD system.
> > 
> > /opt is where single purpose software that usually is self-contained, such
> > as LibreOffice, Mozilla Firefox, and specialized libraries like QT are
> > kept.
> > 
> > /home was developed to separate non-root user accounts from /root and the
> > core of the system. Usually this is a separate partition usually using a
> > long term storage file system like BtrFS, ZFS, JFS, ReiserFS, etc.
> > 
> > Now this may not be 100% accurate but it is a rough estimate of what these
> > were purposed for.
> > 
> > I could be wrong... but I have been wrong from time to time.
> > 
> > -Jim
> > 
> > > Date: Thu, 30 Apr 2015 08:48:10 +0100
> > > From: kato...@freaknet.org
> > > To: reisenwe...@web.de
> > > CC: dng@lists.dyne.org
> > > Subject: Re: [Dng] [dng] vdev status updates
> > > 
> > > On Thu, Apr 30, 2015 at 01:27:48AM +0200, Joerg Reisenweber wrote:
> > > > On Wed 29 April 2015 23:46:51 Didier Kryn wrote:
> > > > > They decided to put them on the second disk which contained user
> > > > > data
> > > > > and was therefore mounted at /usr
> > > > 
> > > > AFAIK that's "Unix System Resources" or somesuch, not "User"
> > > > /j
> > > 
> > > Well, in the first few versions of Research Unix (and I believe at
> > > least until Version 7, in 1979) /usr was the folder where user home
> > > directories lived. /home came much later, AFAIK...
> > > 
> > > My2Cents
> > > 
> > > KatolaZ


signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 30/04/2015 13:21, Joerg Reisenweber a écrit :

and here is more (sorry to link to the obvious):
http://www.pathname.com/fhs/pub/fhs-2.3.html  (possibly outdated, I didn't
check for a long time)

Thanks Joerg, for recalling the link.

This FHS is nothing more than a summary of current practice; it 
does not contain any sound rationale. Adhering to this standard just 
means freezing forever an unsatisfactory file hierarchy which is like it 
is for historical reasons.


I don't want to make war against the FHS. I'm just considering that 
the FHS has little value and I don't care if Debian violates it and 
Devuan follows. They will do it in a way which is compatible with the 
expectation of applications.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Thu 30 April 2015 15:30:06 Didier Kryn wrote:
>  This FHS is nothing more than a summary of current practice; it 
> does not contain any sound rationale
I beg to differ on that, to me it seems it has all the sound rationale it 
needs, to for example understand why /bin should have commands that are needed 
during early boot, before /usr gets mounted.

Thus FHS is not only a summary of current practice but also a guide to 
understand why that practice got adopted, what been the rationale, and what 
are the impacts when you deliberately ignore and deviate from such practice, 
by for example symlinking /s?bin/ to /usr/s?bin or not keeping commands needed 
during early boot in /s?bin

Poettering clearly understood the implications and outright rejected the 
rationale, by claiming nowadays it wasn't modern anymore to have a small root-
fs and a separate partition for /usr

/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Hendrik Boom]

On Wed, Apr 29, 2015 at 12:33:52AM -0400, Jude Nelson wrote:

> (i.e. a device file
> that shows up in devtmpfs from the kernel does not generate an inotify
> event).

I wonder if that's a bug or a feature.

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Laurent Bercot]

On 30/04/2015 15:58, Joerg Reisenweber wrote:

I beg to differ on that, to me it seems it has all the sound rationale it
needs, to for example understand why /bin should have commands that are needed
during early boot, before /usr gets mounted.

Thus FHS is not only a summary of current practice but also a guide to
understand why that practice got adopted, what been the rationale, and what
are the impacts when you deliberately ignore and deviate from such practice


 As Didier says, FHS is mostly an officialization of historical practices -
with a little bit added about current practices. It addresses some problems
correctly, addresses other problems incorrectly (that's what you get when
you try to cram modern uses into a historical frame that's ill-adapted to
them), and ignores yet other problems completely.

 Some of the original design decisions for the Unix directory structure,
that you still find in the FHS today, never made sense. Most of them made
sense at the time, but are obsoleted by today's needs. And some of them
still make sense today.

 Here are a few examples:

 - Never made sense: /var/mail. User mailboxes in a separate location, shared
between all users, are a horrible design. User mailboxes should reside in
users' home directory, it's the only sensible choice - for instance, it makes
quota management natural. Modern MTAs all deliver mail to mailboxes in the
user's home directory, and /var/mail should be relegated to the museum of
horrors, not be officialized in
  http://www.pathname.com/fhs/pub/fhs-2.3.html#VARMAILUSERMAILBOXFILES
with a weak-willed "(optional)" instead of the necessary "(for the sake of
all that's holy, NEVER FUCKING USE THIS)"

 - Made sense at the time, doesn't make sense today: the separation between
administrator commands (/sbin, /usr/sbin) and user commands (/bin, /usr/bin).
Back then, filesystems were slow and scaled badly, caches were small, and it
was costly (time-wise for lookups) to have too many binaries in a single
location. Segregating admin-only binaries in a separate location avoided
clogging /bin and /usr/bin, and was a simple solution to gain a factor of 2
or so, which apparently was enough. There certainly were other reasons for
that choice, but this is the only one that stands examination.

 Today, we have filesystems that can instantly lookup an entry in a directory
that has a million of entries. There's no more reason to separate /sbin from
/bin, except historical practice. /sbin/route is not inherently better than
/bin/route; we are just used to /sbin/route and inertia does the rest - but
it would actually be *simpler* to just move everything to /bin and /usr/bin
and be rid of /sbin and /usr/sbin altogether. It would also shorten PATHs,
which would be a definite blessing on some systems.

 What if we don't want users to run /bin/route ? Well, system calls is
where Unix security is at. route will make system calls that non-root
users cannot make, and that will fail, and report EPERM errors. There's no
reason to forbid a user to run "route", it just won't work. But if we
absolutely want to enforce the interdiction, it's possible to set 0700 rights
at installation, so that non-root users can't run the binary. (Note that
binaries in /sbin usually don't do that, and non-root users can run them.)

 - Made sense at the time, and still does today: the separation between /
and /usr.
 / was a base system that was guaranteed to boot and make a console usable.
/usr was the big, full-fledged system. In some installations, /usr was a
NFS mount. It was a perfectly reasonable way of setting up a machine.

 Today, the reasons for keeping the separation have changed, but the
separation is still useful. No matter what a few dim-witted so-called
engineers may say, it is *always* useful to have a guaranteed bootable
minimal system that at least gives access to a console, that does not
depend on the main filesystem (which is often big, mounted read-write,
and exposed to various corruptions).

 My point is that the FHS is not good per se. It's insufficient, and
very little work has been put into it; it's not the result of long
design discussions with top-of-the-cream Unix engineers, it's just a
mixed bag description of what's out there with the word "standard"
stamped onto it. (Like Single Unix, in a way, but at least Single Unix
is slowly evolving and is trying to weed out brainless legacy and
standardize good APIs.)

 I haven't even mentioned the things that FHS does not standardize or is
bad at, and there are a lot of those.

 However, what is happening here is that the systemd people, in all
their short-sighted hubris, are rejecting one of the few parts of the FHS
that are *actually good*.

 Beats me how those people can be so wrong and still managed to make it
to the grown-up stage and even get a diploma. That's some serious parenting
and school system fail.



Poettering clearly understood the implications and outright rejected the
rationale, by claiming nowadays i

Re: [Dng] [dng] vdev status updates

[John Morris]

On Thu, 2015-04-30 at 15:58 +0200, Joerg Reisenweber wrote:

> Poettering clearly understood the implications and outright rejected the 
> rationale, by claiming nowadays it wasn't modern anymore to have a small root-
> fs and a separate partition for /usr

He is correct on this point.  One should always obey the rules until you
understand why the rule was made and the consequences of breaking it.
Once upon a time the rule was that / should have everything needed to
complete the booting of the system and to get a rescue shell.  But Linux
already violates that rule in that a naked kernel often can't access or
mount / itself, which is why an initrd is usually used to start things
off.

Once that is accepted as something unavoidable, and it is unavoidable in
a world of lvm, multiple software RAID implementations, wide variety of
filesystems and such, the idea of / having the tools for mounting
everything else is impractical.  It made sense when / was on a fixed
disk with driver support baked into the kernel and there was only one or
two filesystems available.

Now as for other assertions in this thread that the FHS itself is
obsolete and violations of it should not be considered a bad thing, just
no.  No.  As I said above, first read and understand it so you
understand when it is ok to violate it and when it should be updated.
The FHS was carefully designed to accomodate things like NFS root,
readonly NFS mounting of parts of the system, mandating things like
*/share/ to only contain arch neutral data, etc.  A lot of work is there
to encode existing and historical practice in a lot more use cases than
any one developer will likely be familiar with.


signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Laurent Bercot]

On 30/04/2015 20:16, John Morris wrote:

He is correct on this point.  One should always obey the rules until you
understand why the rule was made and the consequences of breaking it.


 Except that the rule we're talking about just shouldn't be violated.



Once upon a time the rule was that / should have everything needed to
complete the booting of the system and to get a rescue shell.  But Linux
already violates that rule in that a naked kernel often can't access or
mount / itself, which is why an initrd is usually used to start things
off.

Once that is accepted as something unavoidable, and it is unavoidable in
a world of lvm, multiple software RAID implementations, wide variety of
filesystems and such, the idea of / having the tools for mounting
everything else is impractical.  It made sense when / was on a fixed
disk with driver support baked into the kernel and there was only one or
two filesystems available.


 You are committing the same error as the systemd people here, i.e.
you are assuming that it is always the case and there's nothing else than
general-purpose distro kernels with lvm, RAID and the kitchen sink,
provided by mainstream distributions for the desktop world or the server
world.
 This is not the case, and this is not even the common case. The majority
of Linux systems today is embedded devices.

 Breaking the embedded world to perform a very minor optimization (what is
the benefit of joining /bin and /usr/bin again ?) on desktop or server PCs
simply isn't reasonable engineering.



Now as for other assertions in this thread that the FHS itself is
obsolete and violations of it should not be considered a bad thing, just
no.


 I don't think anyone said that.



The FHS was carefully designed


 Stopped reading there.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[James Powell]

I respectfully like the aspect of the FHS. While parts of it are dated and 
could use a recasting, the core logic of separating kernel, admin, and user 
tools, libraries, and having them available in stages.

It shouldn't be scrapped by any means, or unified. Tools as certain stages need 
to be made available for specific purposes. It doesn't matter if you want to 
strictly follow FHS, Dan Bernstein's design, Microsoft's bastardized /opt 
design, or Lennart's unified /usr + initramfs... you need logical tools at 
certain points regardless, and if you don't have them, bad things happen.

-Jim

Sent from my Windows Phone

From: Laurent Bercot
Sent: ‎4/‎30/‎2015 12:16 PM
To: dng@lists.dyne.org
Subject: Re: [Dng] [dng] vdev status updates

On 30/04/2015 20:16, John Morris wrote:
> He is correct on this point.  One should always obey the rules until you
> understand why the rule was made and the consequences of breaking it.

  Except that the rule we're talking about just shouldn't be violated.


> Once upon a time the rule was that / should have everything needed to
> complete the booting of the system and to get a rescue shell.  But Linux
> already violates that rule in that a naked kernel often can't access or
> mount / itself, which is why an initrd is usually used to start things
> off.
>
> Once that is accepted as something unavoidable, and it is unavoidable in
> a world of lvm, multiple software RAID implementations, wide variety of
> filesystems and such, the idea of / having the tools for mounting
> everything else is impractical.  It made sense when / was on a fixed
> disk with driver support baked into the kernel and there was only one or
> two filesystems available.

  You are committing the same error as the systemd people here, i.e.
you are assuming that it is always the case and there's nothing else than
general-purpose distro kernels with lvm, RAID and the kitchen sink,
provided by mainstream distributions for the desktop world or the server
world.
  This is not the case, and this is not even the common case. The majority
of Linux systems today is embedded devices.

  Breaking the embedded world to perform a very minor optimization (what is
the benefit of joining /bin and /usr/bin again ?) on desktop or server PCs
simply isn't reasonable engineering.


> Now as for other assertions in this thread that the FHS itself is
> obsolete and violations of it should not be considered a bad thing, just
> no.

  I don't think anyone said that.


> The FHS was carefully designed

  Stopped reading there.

--
  Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
>   - Made sense at the time, doesn't make sense today: the separation between
> administrator commands (/sbin, /usr/sbin) and user commands (/bin,
> /usr/bin). Back then, filesystems were slow and scaled badly, caches were
> small, and it was costly (time-wise for lookups) to have too many binaries
> in a single location. Segregating admin-only binaries in a separate
> location avoided clogging /bin and /usr/bin, and was a simple solution to
> gain a factor of 2 or so, which apparently was enough. There certainly were
> other reasons for that choice, but this is the only one that stands
> examination

quote from most recent OpenSuse (yes, with dang systemd :-S ):

jr@saturn:~> ntpdate
Absolute path to 'ntpdate' is '/usr/sbin/ntpdate', so running it may require 
superuser privileges (eg. root).

/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
> /sbin/route is not inherently better than
> /bin/route; we are just used to /sbin/route and inertia does the rest - but
> it would actually be *simpler* to just move everything to /bin and /usr/bin
> and be rid of /sbin and /usr/sbin altogether. It would also shorten PATHs,
> which would be a definite blessing on some systems.

exactly this PATH issue is what I expect and appreciate here: I do NOT expect 
command autocompletion of normal user to get confused by command names that 
are not supposed to even be in user's PATH

/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[KatolaZ]

On Thu, Apr 30, 2015 at 10:32:54PM +0200, Joerg Reisenweber wrote:
> On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
> >   - Made sense at the time, doesn't make sense today: the separation between
> > administrator commands (/sbin, /usr/sbin) and user commands (/bin,
> > /usr/bin). Back then, filesystems were slow and scaled badly, caches were
> > small, and it was costly (time-wise for lookups) to have too many binaries
> > in a single location. Segregating admin-only binaries in a separate
> > location avoided clogging /bin and /usr/bin, and was a simple solution to
> > gain a factor of 2 or so, which apparently was enough. There certainly were
> > other reasons for that choice, but this is the only one that stands
> > examination
> 
> quote from most recent OpenSuse (yes, with dang systemd :-S ):
> 
> jr@saturn:~> ntpdate
> Absolute path to 'ntpdate' is '/usr/sbin/ntpdate', so running it may require 
> superuser privileges (eg. root).
> 

If I can add my 2 cents to the discussion, I would point out that in
the whole history of unix and unix-like systems there has never been a
common "standard" in terms of filesystem hierarchy. Apart from some
basics "common sense" usages (e.g. having all the essentials for boot
in /bin and the configuration filed in /etc), the hierarchy of any
unix and unix-like fs has always varied a lot across platforms and
time.

And also FHS is no more that a union of a bunch of common practices in
different unix-like systems, and in particular in different GNU/Linux
distributions. It is sufficient to run "man hier" in three or four
different distros (and even in different versions of the same distro)
to reckon that FHS is not carved in stone and, as a matter of fact,
does not represent a standard at all (look for instance at the
definition given by FHS for /sys and have a good laugh...)

I personaly believe that the motivations behind some of the
"classical" choices in terms of fs hierarchy made a lot of sense and
still make sense today (e.g., having the essential boot tools in
/bin), if we take into account that unix-like systems cover a wide
veriety of applications, from embedded systems to control washing
machines to internet routers.

What I don't understand is making "changes" to an existing hierarchy
by having in mind just one or a few possible use cases (e.g., "Linux
desktops" or "Linux mobile users", whatever these locutions might mean
to you). This is truly and essentially anti-unix, since it goes
towards forcing unnecessarily restricting policies. And this is
definitely alien to the unix philosophy

My2cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Joerg Reisenweber]

On Thu 30 April 2015 19:02:54 Laurent Bercot wrote:
> It would also shorten PATHs,
> which would be a definite blessing on some systems.
I guess - just like you said, and according to RFC2119 "SHOULD (NOT)" - you 
could simply symlink /sbin to /bin on your system when there's a good reason 
for doing so (I can't see where a shorter content of $PATH would be such 
"blessing", but whatever) and you *know what you're doing*.

I completely agree on most you said, FHS is no STANDARD, it's just a best 
practice. And best practice in all unix usually was to follow best practice 
unless you have sound reasons to not do.
Probably discussing how much common sense is in FHS X.Y is fun but not really 
helping. 
What's however obvious is the systemd cabal not giving an flying F* about FHS 
or best practice or sound rationale or anything, they simply push their own 
concept as long as it promises to strengthen lock-in to their idea of future 
linux.

/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Didier Kryn]

Le 30/04/2015 20:16, John Morris a écrit :

The FHS was carefully designed to accomodate things like NFS root,
readonly NFS mounting of parts of the system, mandating things like
*/share/  to only contain arch neutral data, etc.


The whole FH can be shared by NFS root, except /var, which cannot 
be shared entirely and /run (formerly /var/run) which cannot be shared 
at all - talking about Debian's FH.


The problem is /var/lib which must be carefully separated in two 
parts to distinguish applications which keep common data (eg apt) and 
applications which keep hardware-related data (eg ntpd). Then a few 
dirty tricks are necessary to make the two categories look like they are 
all in /var/lib.


I don't know if the question of sharing the FH through NFS is 
seriously addressed by the FHS; but, if it is, it fails.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] [dng] vdev status updates

[Laurent Bercot]

On 30/04/2015 22:35, Joerg Reisenweber wrote:

exactly this PATH issue is what I expect and appreciate here: I do NOT expect
command autocompletion of normal user to get confused by command names that
are not supposed to even be in user's PATH


 0700 for root-only binaries would hide them from your shell's autocompletion.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] acpi and systemd

[Jaromil]

On April 29, 2015 1:19:25 PM GMT+01:00, Hendrik Boom  
wrote:
>On Sun, Apr 26, 2015 at 12:31:16AM +0200, Franco Lanza wrote:
>> On Sat, Apr 25, 2015 at 05:16:42PM -0400, Hendrik Boom wrote:
>> > 
>> > acpid and acpi-support-base have already been removed from tasksel.
>> 
>> 
>> We already forked tasksel, so, it should not be an issue for us as
>long
>> as those two packages are maintained, or we will need to fork both
>acpid
>> and acpi-support-base too.
>
>Indeed.  Is there a mechanism in place to watch for this kind of thing?

the Devuan SDK facilitates auditing of changes and import of packages at any 
version through git branching. that is explicitly planned to facilitate the 
task you are mentioning.

>There might be a lot of packages dropped if Debian decides that systemd

indeed, and we are prepared for it.

after all, we really are a fork. we mean it.

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[Franco Lanza]

On Thu, Apr 30, 2015 at 01:44:47AM +0100, David Hare wrote:
> 
> debootstrap --exclude systemd,systemd-sysv,libsystemd0 jessie .
> 
> without specifying a URL is working here (are the excludes needed?)
> 
> However after I chroot it and apt update:
> 
> W: GPG error: http://packages.devuan.org jessie InRelease: The following
> signatures were invalid: BADSIG 94532124541922FB Devuan Repository (Primary
> Devuan signing key) 
> 
> "devuan-keyring" is installed.

fixed with the commit at
https://git.devuan.org/packages-base/debootstrap/commit/821623d33a4a75d73120cf3c4e4d6d236f391427

in few minutes there will be an updated version of debootstrap available in
our repository that fix the issue and make useless to add your
--exclude

There are chances you will get libsystemd0 installed actually, but avoid
it can break packages not yet in our repo, so, i suggest to deal with it 
for the moment, when our repo will be complete, libsystemd0 will NOT 
be installed in any case.

-- 

Franco (nextime) Lanza
Lonate Pozzolo (VA) - Italy
SIP://c...@casa.nexlab.it
web: http://www.nexlab.net

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
---
echo 
16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq
 | dc
---



signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[Jaret Cantu]

Edward Bartolo  writes:

> I replaced stable with jessie as follows. debootstrap did better but
> failed. These are the results:
>
> # debootstrap --arch amd64 jessie /mnt/sda8 
http://packages.devuan.org/devuan/

> 
> I: Extracting util-linux...
> W: Failure trying to run: chroot /mnt/sda8 mount -t proc proc /proc
> W: See /mnt/sda8/debootstrap/debootstrap.log for details


I see that, too. The problem is apparently a missing library for the 
mount executable (the "No such file or directory" reported in 
debootstrap.log):


[jaret@ragnarok mnt]$ ldd bin/mount

libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 
(0x7f91b68ee000)


But that is my system libselinux and is not available to the chroot 
mount, which apparently lacks libselinux:


[jaret@ragnarok mnt]$ find -name 'libselinux*'
[jaret@ragnarok mnt]

So I guess (at least) libselinux needs to be pulled in as part of the 
initial bootstrapping.  It is listed as a pre-depends in Devuan, too:


Package: mount
Source: util-linux
Version: 2.25.2-4.1+devuan1
Essential: yes
Installed-Size: 419
Maintainer: Denis Roio 
Architecture: amd64
Pre-Depends: libc6 (>= 2.17), libmount1 (>= 2.25), libselinux1 (>= 
2.0.15), libsmartcols1 (>= 2.25)




I am just now getting acquainted the whole seedy Apt underbelly; 
otherwise, I'd throw in a patch for this instead of just "There's your 
problem"ing.



Cheers,
Jerry
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] acpi and systemd

[Jürgen Buchmüller]

Am Donnerstag, den 30.04.2015, 23:58 +0100 schrieb Jaromil:
> after all, we really are a fork. we mean it.

*Me* applauds. And throwing away the outdated yet sane levels of
knowledge and wisdom has already proven to evocate disaster[1].

"Back then most things were better; and they were, of course, made of
wood." - Martin, Zonenwirt

kthx pm

[1] One of them: https://www.youtube.com/watch?v=nGWkYuZ5eyQ - at least
busybox was alive and avid, even without tty :)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Feedback installing Devuan through debootstrap in Debian Testing.

[David Hare]

On 01/05/15 01:32, Franco Lanza wrote:

On Thu, Apr 30, 2015 at 01:44:47AM +0100, David Hare wrote:


debootstrap --exclude systemd,systemd-sysv,libsystemd0 jessie .

without specifying a URL is working here (are the excludes needed?)

However after I chroot it and apt update:

W: GPG error: http://packages.devuan.org jessie InRelease: The following
signatures were invalid: BADSIG 94532124541922FB Devuan Repository (Primary
Devuan signing key) 

"devuan-keyring" is installed.


fixed with the commit at
https://git.devuan.org/packages-base/debootstrap/commit/821623d33a4a75d73120cf3c4e4d6d236f391427

in few minutes there will be an updated version of debootstrap available in
our repository that fix the issue and make useless to add your
--exclude

There are chances you will get libsystemd0 installed actually, but avoid
it can break packages not yet in our repo, so, i suggest to deal with it
for the moment, when our repo will be complete, libsystemd0 will NOT
be installed in any case.




Thanks! I just tested the new debootstrap (same opts as before). There 
were no such errors in the bootstrap nor subsequent manual chroot.


Later yesterday, the gpg error seemed to resolve itself during chroot, 
no clue how or why. I went on to build a nice xfce system (without 
enabling mainstream debian repos)!


/etc/apt/preferences.d/01systemd excludes *systemd* here. I also exclude 
"recommends". However, I'm using a few packages from angband.pl and a 
few custom recompilations because devuan either doesn't have them yet or 
they are older versions than mainstream Jessie.


I look forward to devuan repo completion, then we don't need custom or 
3rd party packages.


I'm using custom packages (they work but are probably not 
lintian-clean): sane-utils consolekit2


Consolekit2 I built from latest git, I have user handling for removables 
and shutdown/reboot/suspend in xfce and lightdm menus.


If they are any use to devuan I posted debs and sources here: 
http://www.exegnulinux.net/refracta/experimental/debs-nosystemd/


Note for those who would not normally want pulseaudio: mplayer depends 
libpulse0 (which depends libsystemd0)


Packages installed from angband.pl:

bsdutils
cups
cups-bsd
cups-client
cups-common
cups-core-drivers
cups-daemon
cups-ppdc
cups-server-common
dbus
dbus-x11
gir1.2-polkit-1.0
gvfs
gvfs-backends
gvfs-common
gvfs-daemons
gvfs-libs
init
init-system-helpers
libblkid1
libcolord2
libcups2
libcupscgi1
libcupsimage2
libcupsmime1
libcupsppdc1
libdbus-1-3
libmount1
libpolkit-agent-1-0
libpolkit-backend-1-0
libpolkit-gobject-1-0
libpulse-mainloop-glib0
libpulse0
libsmartcols1
libudisks2-0
libupower-glib1
libuuid1
mount
policykit-1
udisks2
upower
util-linux
uuid-runtime
xfce4-power-manager
xfce4-power-manager-data

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] About (k)dbus in LKML

[Jude Nelson]

Hi James,

On Thu, Apr 30, 2015 at 4:26 AM, James Powell  wrote:

> The discussion has not been favorable towards the adoption from current
> reading on LKML. Past tests have not proven reliability, nor any
> significant increase of speed of messaging across the IPC. Linus seems to
> be of no love for it.
>
> IMO from the collective discussion, kdbus doesn't seem to be really well
> designed, fast, or reliable compared to traditional D-Bus and only has a
> small if minimal gain over traditional D-Bus near negligible. In short, one
> could wonder if this effort was a complete waste of time, or a convoluted
> effort to introduce a proprietary IPC in the kernel that can only be used
> by system so they can kill off netlink support in udev in favor of kdbus.
> My pick is the latter as we all know how the systemd kabal thinks, and we
> all can make an educated guess as to where Greg Kroah-Hartman's
> true loyalties lie.
>

The D-Bus implementation you're using isn't really fast or reliable in the
first place :P  Linus's benchmarks suggest that the reason the D-Bus
implementation is so slow is because it suffers
performance-death-by-a-thousand-cuts.  There are a bunch of needless
malloc()s, copies, locks, etc. per call that aren't costly by themselves,
but they add up.  What remains to be seen is how a *well-written* userspace
D-Bus performs, or even a D-Bus that uses memfds or page-spicing for large
messages.

Also, netlink isn't going anywhere.  Linus does not break userspace, and
other device managers (including vdev) and hotplug programs all rely on
netlink to receive device events.


> The native IPC for Linux has been reliable, though it's not exactly fast
> by all means, but in terms of working, it works, does it's job well, and
> has a proven track record.
>

Shared memory is pretty damn fast--close to as fast as theoretically
possible.  Once set up, there is literally zero overhead (no context
swtiches, no MMU reprogramming, no TLB flushes, etc.) since the pages of
RAM are mapped in both the producers and consumer's page tables.

Also, according to Kay Sievers himself, the humble pipe is faster than
kdbus for messages smaller than 32K on an x86_64 system.  This is even
without vmsplice(2).

All it needs are new protocols worked in to help it out by introducing new
> methods of using the IPC while maintaining legacy pathways. Oddly enough
> another IPC, Plumper from 9P has been available for some time now, but has
> never been attempted at a port.
>
>
IIRC 9P gets used today in libvirt and qemu for sharing folders.  Also,
it's "plumber" :)


> I, and possibly others, can only hope Linus actually and ultimately says
> "no" to kdbus and sees the purpose behind kdbus not being a successor
> to D-Bus but a proprietary IPC that can be used by system for udev, and
> only for that purpose.
>

It doesn't really matter to us whether or not kdbus gets accepted.
Obviously, Linus won't accept it if he feels that it'll be a maintenance
hassle, since once it's in the kernel, its interface is not allowed to
change.

Gazing into my cracked and cloudy crystal ball, what'll probably happen is
the policy and marshaling logic will be kept in userspace, and the kernel
will get a patch that adds the minimal set of primitives needed to address
the actual shortcomings with the D-Bus design (but not problems with the
current implementation).  This includes memfd and file descriptor sealing
today.  Maybe down the road send(2) and write(2) will get a new flag to
atomically check if the receiver is still connected and abort if not, and
maybe read(2) and recv(2) will an option to atomically check the sender's
credentials before receiving data.  I get the impression from the
discussion that these are all the D-Bus developers really need the kernel
to do for them, but I could be wrong.


>
> Though should it become part of the mainline, we all know Lennart will
> waste no time in dropping netlink support in udev just to get his way.
>

He's already said as much.


>
>
If that becomes the case, eudev can hopefully make an effort to keep
> netlink alive in a separate tree while backporting code in from
> system-udev, but who knows how long that will last. However, Linus did make
> a stern warning that if they did anything to break the userspace (and
> breaking netlink in udev would do just that), they could have any number of
> penalties from more developers from systemd banned from kernel
> developments, to as well as possibly code excised from the kernel.
>

No doubt that eudev will continue regardless of systemd-udev.  Plus, we'll
have vdev soon enough too (which addresses problems that neither udev nor
eudev handle).

-Jude


Date: Tue, 28 Apr 2015 23:00:55 +1000
> From: ad_u...@runbox.com
> To: dng@lists.dyne.org
> Subject: [Dng] About (k)dbus in LKML
>
>
> https://news.ycombinator.com/item?id=9450806
>
> Hot discussion about merging kdbus in kernel.
>
> TL;DR: The people who talk about how kdbus improves performance are just
> ful