Re: [DNG] /usr to merge or not to merge... that is the question??

[Dario Niedermann]

Il 16/11/2018 alle 10:11, Daniel Reurich ha scritto:

> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf

I vote NO: keep it as it is.
I've seen the merged /usr in Void Linux, hated it.

-- 
Dario Niedermann. Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[karl]

Roger:
> On 29/11/2018 12:57, k...@aspodata.se wrote:
...
> > Why not agree on a certain set of programs/libs that should be in /bin,
> > /sbin, and /lib, just to not break my and others packages. That set
> > don't need to cover all booting possibilities.
> 
> This is what we used to (try) to do, but we failed at it.
...

I think your goal was different than what mine is.

Since there are already support for an initrd kernel that supports 
general booting, my kernel/package don't have to cover that. It is 
sufficient that it covers a subset of the debians kernels capability.
And thus, there isn't a need to have binaries for all kind of 
filesystems and setupts in /. All I'm asking for is to have a common
subset available in /bin, /lib and /sbin.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 29/11/2018 à 22:10, Rick Moen a écrit :

Solution to this: Boot from Knoppix (yes, seriously) and manually create
the partitions with parted. Once this was done, rebooted from the RHEL
image. On the "Installation Destination" submenu I selected "I will
configure partitioning" and then clicked on the blue Done button.


    I'm not sure I've caught the purpose of the conversation, but, in 
Debian/Devuan installer, you are running a live OS and you can escape 
the installer and go to an interactive root session in which you can 
perform the partitionning with the tool of your choice - I like cfdisk. 
Then go back to the DI and use the existing partitions. The tools you 
want to use must be present but the DI gives you the opportunity to 
install some packages which aren't included by default, such as 
filesystems and partitionners.


        Didier


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 29/11/18 at 18:19, Roger Leigh wrote:


> If you're a ZFS user


  Yeah, that's it.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Adam Borowski]

On Thu, Nov 29, 2018 at 04:40:52PM -0500, Hendrik Boom wrote:
> On Thu, Nov 29, 2018 at 01:30:53PM -0800, Rick Moen wrote:
> > 
> > Compiling a kernel locally to include inline essential hardware drivers
> > is so simple I _think_ I could teach even a Republican Party voter how
> > to do it.  ;->
> > 
> > ITYM 'will probably never support without sysadmin manual work to create
> > a bespoke kernel and eliminate local dependency on an initramfs', which,
> > sure, fair enough.  Personally, though, my fingers aren't broken.
> 
> Is there ... could there be with reasonable effort ... a tool that 
> investigates the hardware, figures out what drivers it needs, and 
> compiles a kernel accordingly?
> 
> Perhaps even looks at the file systems that are present?
> 
> Is there something arcane that makes this kind of thing diffcult?

make localyesconfig
make -j`nproc` bindeb-pkg
su -
dpkg -i linux-imagedeb


Perhaps even a Democrat Party voter could do it? ;)


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a wordly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Thu, Nov 29, 2018 at 01:30:53PM -0800, Rick Moen wrote:
> 
> Compiling a kernel locally to include inline essential hardware drivers
> is so simple I _think_ I could teach even a Republican Party voter how
> to do it.  ;->
> 
> ITYM 'will probably never support without sysadmin manual work to create
> a bespoke kernel and eliminate local dependency on an initramfs', which,
> sure, fair enough.  Personally, though, my fingers aren't broken.

Is there ... could there be with reasonable effort ... a tool that 
investigates the hardware, figures out what drivers it needs, and 
compiles a kernel accordingly?

Perhaps even looks at the file systems that are present?

Is there something arcane that makes this kind of thing diffcult?

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):

> On Do, Nov 29, 2018 at 01:22:05 -0500, Steve Litt wrote:
> >My understanding is that Devuan will ask in the fresh installer whether
> >the user wants to merge or not, with the default being no merge. This
> >is fine with me. Do you have a problem with it?
> 
> Nope, but even Devuan will probably never support a separate /usr
^^^
> without mounting it in early boot via initrd.

Compiling a kernel locally to include inline essential hardware drivers
is so simple I _think_ I could teach even a Republican Party voter how
to do it.  ;->

ITYM 'will probably never support without sysadmin manual work to create
a bespoke kernel and eliminate local dependency on an initramfs', which,
sure, fair enough.  Personally, though, my fingers aren't broken.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

> I do not expect an OS that does not even let you chose on what disk to
> perform the install will let you choose a filesystem layout that is not
> the recommended one, that is LVM across all the available devices.

Yeah, and in agreement with your implication, here, I share your
opinion about a good remedy:

> Solution to this: Boot from Knoppix (yes, seriously) and manually create
> the partitions with parted. Once this was done, rebooted from the RHEL
> image. On the "Installation Destination" submenu I selected "I will
> configure partitioning" and then clicked on the blue Done button.

Exactly like that, except my personal preference as a general 'boot to
this to do most maintenance work' live distro is Siduction (as I
mentioned recently).  They don't always hit their target of a quarterly 
ISO release, but are still (last I checked) releasing pretty frequently,
which means they have pretty cutting-edge hardware drivers, so its
hardware support is about as broad as you could wish for.

But I'd still maybe try the Ctrl-Alt-F2 and try /sbin/fdisk (or parted)
trick in many cases (because of laziness).


Perhaps you'll indulge a moment of my being a proud grandpa, though:
Back in 1999, I was a (minor) member of the group lead by my friend
Duncan MacKinnon at Linuxcare, Inc.  that designed and released the
Linuxcare Bootable Business Card (Linuxcare BBC) just in time for the
first LinuxWorld Conference and Expo in San Jose, at which that 85MB
compressed ISO burned to a business-card-sized CD disc was a hit.  Among
the people who noticed was Klaus Knopper, who intently studied how we
did the pivot_root trick from the initrd to change the root FS to a
RAMdisk.  At the time, this required some tweaks directly to libc.
Anyway, this was the key trick required for live CDs, so Knopper copied
our work to produce Knoppix.

(Some history at:
https://www.revolvy.com/page/Bootable-business-card)

So, basically all of us who invented the Linuxcare BBC feel that we're
in a sense the grandparents of Knoppix and great-grandparents of other 
live CDs that said 'Hey, let's do the Knoppix thing, too.'

(If I've already done that particular humblebrag on Dng, sorry.  You 
get old, you start repeating the same stories a lot.)

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

Re: [DNG] /usr to merge or not to merge... that is the question

[golinux]

On 2018-11-29 06:14, Hendrik Boom wrote:

On Thu, Nov 29, 2018 at 12:44:35AM -0600, goli...@dyne.org wrote:

On 2018-11-29 00:22, Steve Litt wrote:
>
> My understanding is that Devuan will ask in the fresh installer whether
> the user wants to merge or not, with the default being no merge. This
> is fine with me.
>

I installed a test beowulf mini.iso a few days ago and there was 
indeed an

option to merge.  The default is to keep them separate.

golinux


Great!  It has been tested.

Because that which is not tested is broken.

-- hendrik



Well, that option is clearly in the d-i.  But . . . there are other 
things that still need fixing on beowulf that make the mini.iso 
installation unusable for me.  So we're not out of the woods yet . . .

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 11:37, Didier Kryn wrote

:
> Le 28/11/2018 à 10:35, Rick Moen a écrit :
>> Quoting Didier Kryn (k...@in2p3.fr):


[...]

>     Hi Rick.
>
>     It seems to me you're fighting to get the last bit of performance
> out of mechanical hard drives, including by using different
> filesystems for different partitions, which makes a lot of sense for
> servers. I agree that filesystem play a major role in performance and
> safety. For the performance of the disks, and considering you speak of
> servers, you ommit to speak of the RAID configuration, which seems to
> me more important than the location of the partitions.

  Different mount options for different parts of the Unix filesystem 
apply also to RAID and LVM metadevices/device-mapper backed
filesystems, too.


>     For what concerns, laptops, I think we are in the era of ssd and,
> unfortunately, there is usually only one disk drive per laptop, except
> of older ones where the cdrom drive can be replaced by a disk.


  So what?  What's wrong in securing the filesystem and optimizing it's
performance even on SSDs, even on laptops, even when one has only one
storage device?
  Besides, an increasing number of people give up on the DVD unit to make room 
for a second HD/SSD installed with an adaptor.

>     Today, servers are probably still the domain of RAIDs based on
> mechanical hard drives, laptops, the domain of ssds, and desktops are
> the place where both live together - I have one desktop like this.


  Server's peculiarities do deserve to be taken into consideration by a 
soi-disant universal OS.  IIRC Debian is used a lot on servers.
  Why do you think ro, nodev, barrier, sync and other mount options do no make 
sense on a RAID/LVM filesystem?


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:11, Didier Kryn wrote:
> Le 28/11/2018 à 11:25, Rick Moen a écrit :
>> Quoting Didier Kryn (k...@in2p3.fr):
>>
>>> Le 28/11/2018 à 08:11, Rick Moen a écrit :
 If I were relying on NFS during early boot, I'd file a bug against
 package
 nfs-common, and also, meanwhile, compile a local-package substitute
 with
 either static binaries or ones linked to libs in /lib (and provide
 those).
>>> Debian supports diskless hosts mounting an NFS filesystem on /.
>> Of course yes.  _But_, what I was commenting on was the dependency on
>> /usr for the NFS mounting utility in /sbin.  That means -- KatolaZ's
>> point -- that /sbin/mount.nfs will not function in the absence of /usr.
>> My answer to KatolaZ amounted to:  Yes, and that's a bug.  I would, if I
>> needed that during early boot (e.g., during maintenance operation, thus
>> needing to be functional even if /usr cannot be mounted), then I would
>> file a bug against mount.nfs and, while awaiting attention to the bug,
>> compile a local replacement.
>>
>>> When using initrd/initramfs, this kernel option is no longer
>>> necessary and I guess it is just simpler to rely on the modules
>>> provided by nfs-common. The motivation is the same as for device
>>> drivers and filesystems: boot a generic kernel, have all modules
>>> available during early boot to mount / (and /usr).
>> But notice that if /usr _is not_ (e.g., cannot be, for some reason)
>> mounted, then you are screwed:  /sbin/mount.nfs breaks.  KatolZ cited
>> that utility's dynamic library dependency on a lib in /usr/lib as a
>> reason why separate /usr is impractical (for systems needing NFS access
>> even if /usr is unavailable).  I replied that, IMO, no, that's a reason
>> why /sbin/mount.nf thus constructed, has a build error.  ;->
>>
>     IIUC, your argument boils down to "depending on /usr for early
> boot is a *bug*", while Roger told us why it has become a *feature* (~:


  Yes, I got it:

From: Roger Leigh 
Message-ID: <147710ba-7cd8-25e2-1d05-4b0f1589e...@codelibre.net>
Date: Fri, 23 Nov 2018 17:01:07 +To: dng@lists.dyne.org

"A separate /usr is no different.  It has a very real cost to support"


  That is, since software devs and packagers have been making a mess of
/ and /usr use, dumping everything together in the same bin makes the
whole system easier to deal with.


  To me it's like saying: "Since most people at home have been doing a
poor job at using different closets to store only their own stuff and
each different closet's drawer to put different kinds of clothing, let's
dump together whatever belongs to anyone in a big chest placed in the
middle of the room.  Let's cal this awful mess a feature and voilà! 
Problem solved!"


  Not.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:45, KatolaZ wrote:


[...]


> Unfortunately, most of this thread has been just about "oh look how
> cool MY setup is, oh I went around that, oh I tried this and that, oh
> I want to have /var on a tmpfs, oh I mount /usr over NFS and you
> should try it as well..."  and so on and so forth.


  Yeah, there used to be a time when GNU/Linux allowed sysadmins to
easily customize the filesystem layout for whatever reason, it didn't
stand in the way because what someone chose not to follow the deafults,
or because someone had specific needs that were not taken into account
when the distribution was setup.

  Today this is no longer the case, sadly, Linux is following the path
of proprietary OSes that prevent user's choice in the name of ease of
upstream packagers.  "One size fits all, shut up and fit the mold".


  It's a shame to me that to regain that freedom of choice I hade to
"roll-up my sleeves", fork and maintain packages to undo decisions that
were ill-though of at the start.


> IMHO, this is mostly out of scope, and does not help Devuan improving
> by a single bit. I understand it's hard to appreciate for most of us,
> but putting together a distro is not about catering for the needs of
> just one user: there is an entire world of possibilities outside :)


  "just one user"?  Really?

  We're talking of not taking out choices and freedom to customize and
tinker, i.e. to cater to the needs of entire classes of users, that they
are already here or that they may develop in the future.  GNU/Linux is
just losing in adaptability, potability and customizability, which was
one of the reasons many people switched to it.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:36, Rick Moen wrote:
> Quoting Didier Kryn (k...@in2p3.fr):
>
>> IIUC, your argument boils down to "depending on /usr for early boot is
>> a *bug*", while Roger told us why it has become a *feature* (~:
> My view, which I expressed in detail prior to Roger joining the thread, 
> is that it's vital to the most vital function of the root filesystem's 
> maintenance software directories (/sbin, /bin, /lib, /lib64) that their 
> binaries function _even_ if /usr is not (or at the moment cannot be)
> mounted -- because the most vital function of those subtrees is backup,
> restore, repair, maintenance (functions that might be required to
> recover/fix /usr).


  I'd like to point out that even in the case /usr was mounted, and even
if it was on the same partition/filesystem as /, it's still very
positive that the system does not come down crashing and burning was
/usr damaged, allowing the superuser to login to see what happened and
attempt to recover the lost data when the system is still online.



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 11:37, Didier Kryn wrote:
> Le 28/11/2018 à 10:35, Rick Moen a écrit :
>> Quoting Didier Kryn (k...@in2p3.fr):
>>

[...]


>>
>     Hi Rick.
>
>     It seems to me you're fighting to get the last bit of performance
> out of mechanical hard drives, including by using different
> filesystems for different partitions, which makes a lot of sense for
> servers. I agree that filesystem play a major role in performance and
> safety. For the performance of the disks, and considering you speak of
> servers, you ommit to speak of the RAID configuration, which seems to
> me more important than the location of the partitions.


  Different mount options for different parts of the Unix filesystem 
apply also for RAID and LVM metadevices/device-mapper backed
filesystems, too.


>     For what concerns, laptops, I think we are in the era of ssd and,
> unfortunately, there is usually only one disk drive per laptop, except
> of older ones where the cdrom drive can be replaced by a disk.


  So what?  What's wrong in securing the filesystem and optimizing it's
performance even on SSDs, even on laptops, even when one has only one
storage device?


>     Today, servers are probably still the domain of RAIDs based on
> mechanical hard drives, laptops, the domain of ssds, and desktops are
> the place where both live together - I have one desktop like this.


  Do you imply that Debian's decisions regarding filesystem layout do
not take into consideration servers?
  Why do you think ro, nodev, barrier, sync and other mount options do
make sense on a RAID/LVM filesystem?



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 12:15, Alessandro Selli wrote:
>   Why do you think ro, nodev, barrier, sync and other mount options do
> make sense on a RAID/LVM filesystem?


"... do NOT make sense ..."



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 11:13, Didier Kryn wrote:
> Le 28/11/2018 à 08:11, Rick Moen a écrit :
>> If I were relying on NFS during early boot, I'd file a bug against
>> package
>> nfs-common, and also, meanwhile, compile a local-package substitute with
>> either static binaries or ones linked to libs in /lib (and provide
>> those).
>
>     Debian supports diskless hosts mounting an NFS filesystem on /.


  This lies outside the case at hand, that was not centered on booting
out of a NFS /.


>     Until the invention of initrd/initramfs, one could use an option
> of the kernel, which allows to link all the NFS client logic
> statically in  the kernel and to pass the mount command arguments
> through the kernel command line.
>
>     When using initrd/initramfs, this kernel option is no longer
> necessary and I guess it is just simpler to rely on the modules
> provided by nfs-common. The motivation is the same as for device
> drivers and filesystems: boot a generic kernel, have all modules
> available during early boot to mount / (and /usr).
>
>         Didier


  This does not address the issue of an NFS binary exec in / that has
libraries in /usr on a system that mounts /usr over an NFS mount
regardless of what the local / is lying on (local disk or network
filesystem).



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 08:11, Rick Moen wrote:
> Quoting KatolaZ (kato...@freaknet.org):
>
>> # ldd /sbin/mount.nfs | grep "/usr"
>> libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
>> (0x7f82f53ac000)
>> libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
>> (0x7f82f52cf000)
>> libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
>> (0x7f82f529b000)
>> libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
>> (0x7f82f4fd1000)
>  
> If I were relying on NFS during early boot, I'd file a bug against package
> nfs-common, and also, meanwhile, compile a local-package substitute with
> either static binaries or ones linked to libs in /lib (and provide those).


  I agree.  Everything that sits on / must have it's dynamical libraries
in / too.  Everything under /usr that uses the same libraries will work
correctly, the opposite is not necessarily true.


>> # ldd /sbin/lvscan | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7fde00702000)
>>
>> # ldd /sbin/lvs | grep "/usr"
>  liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7fd3b7fa1000)
>
> Ditto package lvm2.  (Which FWIW I've avaoided needing.)


  I don't use it for my personal systems, but I do acknowledge LVM is a
boon on servers where the disk/filesystem occupation is hard to predict
at install time or that might see their use change consistently over
time, such a NFS fileserver that at some point it's decided it's going
to double as a mail server too.


>> # ldd /sbin/sysctl | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7f3ab7b18000)
> Um, I know of no reason why /sbin/sysctl would be urgently needed in a
> minimal system prior to availability of /usr for purposes of backup,
> restore, system repair, etc.


  I wonder, too.


>  I've never needed to futz with /proc/sys/*
> entries while running in maintenance mode, but, if one did need to do
> so, doing the task using 'echo' is more than sufficient.
>
>> # ldd /sbin/gdisk | grep "/usr"
>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
>> (0x7f7ddf10f000)
> I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far
> successfully avoided GPT.


  I always use GPT whenever I can, to take advantage of it's increased
resiliency to accidental damage (that's because it copies it's boot and
partitioning data at the end of the drive).


>  The obvious alternative to gdisk is GNU
> parted (package parted), and FWIW it suffers a similar build boo-boo,
> requiring library libtic.so.5 (terminfo) from inside /usr/lib.  
>
> Tsk-tsk.  ;->


  Agree. 


>> # ldd /bin/kill | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7f9f6aa4a000)
>>
>> # ldd /bin/ps | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
>> (0x7fd7f6ebc000)
> Yeah, those two are really annoying.  FWIW, my server system has older
> versions of those two utilities that do _not_ have that (IMO) build
> error.  Local packages will be an immediate resort, when/if I hit that.


Package: liblz4-1
Description: Fast LZ compression algorithm library - runtime


   Why on Earth do kill and ps need a "compression algorithm library"?  


>> # ldd /bin/efibootmgr | grep "/usr"
>> libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 
>> (0x7f7ed22bd000)
>>  libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 
>> (0x7f7ed20b)
> As with GPT, I've managed so far to step sideways and successfully evade
> the Second System Effect poster child that is EFI.


  EFI anyway is connected to boot, very early boot actually, and for
this reason it should reside on /.


> I'm also unconvinced that efibootmgr is essential to a 'recovery'
> minimal maintenance system, anyway.  My readings suggest that I would
> want to have a 'EFI stub kernel' configuration where you place an
> (unsigned) kernel binary image in the EFI System Partition and rely on 
> the EFI firmware to boot that kernel and mount the root fs directly
> without needing a bootloader.  Coverage at, among other places:
> https://wiki.gentoo.org/wiki/EFI_stub_kernel 
>
> (As usual, I'm saying this is an example of what would Work for Me[tm].
> What might suit others or some entire abstract group of people is a
> different discussion.)


  Anyway, as I already stated, this has to do with boot, and everything
connected with it should be in / (and /boot).


>> Most of the utilities you would need to debug a problem in mounting a
>> /usr over NFS, or a failing lvm volume, or a scrambled efi partition
>> (some of the use cases somebody mentioned before) need stuff in
>> /usr. 
> This has not been my experience for my own use case (granting your point
> about /bin/kill and /bin/ps as provided in packaged versions I am not
> yet running).  If I encounter that, I will consider that 

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 28/11/18 at 09:08, Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>  Can you name me one distribution other than Red Hat (which in
>> fact is not a desktop-friendly distribution) that does not allow one to
>> "do their own partition setup"?
> I'm curious, Alessandro:  Is RHEL now completely hostile to custom
> filesystem setup?


 I haven't dealt with a RH installation for a looong time, however I did
witness to an incident that happened at a former employer of mine years
ago.  We let a classroom to RH Italy for them to held a course of
theirs.  Of course they had to install the latest RHEL on it's PCs (I
don't remember if it was a RHEL6 or one of the early 7s).  The PCs had a
storage controller that could be operated either in SATA/AHCI or in RAID
mode, the already present Windows installation was using the only HD
present as a plain SATA device.  We installed a second HD on each PC and
told the RH sysadmin who came to prepare the machines to install the
RHEL system only on the second HD, leaving the first one intact (the
Windows installation was needed other classes).  The RH sysadmin first
said "Of course, no problem" and got himself busy with the installation,
but after less than two minutes he went: "Oh shit!".  Before I knew what
had happened I understood at week end I was going to be busy
reinstalling Windows, applications and the courseware material on that
PC.  He then explained me what had happened.  He had never installed
RHEL on such a PC, with a RAID-capable controller with two HDs before,
and he expected the installation program, Anaconda, to ask him on what
disk to perform the install.  Instead Anaconda the very first thing it
did, before he was asked anything about the preferred HD/partitioning
layout, was to automatically put the two HDs in a RAID setup, and went
ahead on it's own setting up RAID metadata and superblocks on them. 
Before he could stop it the Windows disk was made unbootable and had to
be recovered (reinstalled, actually).

  I do not expect an OS that does not even let you chose on what disk to
perform the install will let you choose a filesystem layout that is not
the recommended one, that is LVM across all the available devices.

  However I haven't performed a RHEL installation since RHEL5, and then
my job was to hack the Kickstart files to customize the install process
to the customer's specifications.


>  A long time ago (like maybe RHEL3), Red Hat built
> into its Anaconda installer an ncurses-oriented 'guided' partitioning
> tool that was guilty of both concealing information (suppressed display
> of any extended partition, though logical partitions within it were
> displayed) and also unacceptably overrode the installing admin's
> judgement (e.g., rearranging following its own criteria the filesystems
> to be created).


  Looks like with RHEL7 things have not improved any:


https://www.claudiokuenzler.com/blog/691/custom-partitioning-rhel-red-hat-enterprise-linux-7-setup-installation

Custom partitioning on new Red Hat Enterprise Linux 7 setup


Thursday - Jan 26th 2017 - by Claudio Kuenzler
 - (0 comments)



Unbelieveable how annoying this RHEL 7 installation wizard is! Try to
setup manual partitioning with a mix of primary partitions and logical
volumes - and RHEL will not boot. Even worse: Although I created the
root partition first, somehow the wizard switched it with the swap
partition making swap on /dev/sda1 instead of /dev/sda2 (where I wanted
it to be).

Solution to this: Boot from Knoppix (yes, seriously) and manually create
the partitions with parted. Once this was done, rebooted from the RHEL
image. On the "Installation Destination" submenu I selected "I will
configure partitioning" and then clicked on the blue Done button.


>  First time I encountered the latter misbehaviour, I 
> exercised my vocubulary in several languages on the topics of theology
> and biology,


  LOL!


> further commented 'Sod _this_ for a lark', cancelled out of
> that subscreen, switched to Ctrl-Alt-F2, and used /sbin/fdisk instead.


  That *might* still work, but I wouldn't bet a dime on it.


> Just offhand, I'm betting that a similar approach may still be fruitful,
> though I've not needed to deal with the darned thing in quite a while.
>
> Years later, based partly on that lesson, I started leaning towards a 
> preference for using a best-of-breed live distro for partitioning and
> mkfs'ing all of my filesystems _before_ using the desired distro
> installer.  FWIW, I found the Siduction live CD ideal for this purpose.
> (Siduction is the surviving fork of an innovative distro, Sidux, that 
> was a quarterly CD ISO release based on Debian Sid + stabilisation
> packages.)  

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 24/11/2018 15:08, k...@aspodata.se wrote:

Roger:
...

There's no clean separation between the "base" system and "everything else".

...

I think my urge to have a separate /usr is that I want such a
separation and there isn't a clear other place to have it.


Is there an underlying rationale for why you want this separation?


The other part of the scenario you mentioned here is "doesn't want to
use an initramfs".  Why?

...

I skip initrd to keep the boot setup simple.


I touched on this in another reply with regard to the relative number of 
people testing a separate /usr, but I wanted to come back to this point 
because there's a very important consequence to note here.


It's absolutely true that direct booting without an initrd is simple. 
You're cutting out a relatively large amount of complexity, and you're 
mounting the rootfs directly as a device from the kernel command-line. 
You can't get much simpler than that.


However, there is a cost to bear in mind.  Because this is a relatively 
uncommon usage scenario (most people do use the initramfs since it's the 
default), it's much, much less tested.  There are a lot of special-cases 
in many of the early boot scripts which are only run when direct 
booting, and they are not exercised by the vast majority of systems out 
there.  By choosing to use the least-tested uncommon option, you are 
bearing a certain risk.


The standard initrd generated by initramfs-tools is simply a busybox 
shell, and a few shell scripts.  It also copies in a few tools like udev 
and a fsck for your system if needed.  There is certainly some 
complexity here.  But it's not really all that complicated.  No moreso 
than the early init scripts.  You could read through the scripts in a 
few minutes.  And you can even step through them by hand with the break= 
option on the kernel command-line.



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 29/11/2018 13:44, Olaf Meeuwissen wrote:

Q: Isn't there some filesystem type that supports settings at a more
  granular level than the device?  Like directory or per file?
A: Eh ... Don't know.  Haven't checked ...
Solution: Go fish!

# I haven't gone fishing yet but a vague recollection of Roger's post
# where he mentioned ZFS seemed promising ...


You could set them at the directory level if you wanted with ZFS, by  
creating a filesystem per directory.  But that might get a bit  
unmanageable, so doing it in a coarser-grained way is usually  
sufficient.  Let me show some examples.


Firstly, this is an example of a FreeBSD 11.2 ZFS NAS with a few  
terabytes of HDD storage.  There's a dedicated system pool, plus this  
data pool:


% zpool status red
  pool: red
 state: ONLINE
  scan: scrub repaired 0 in 4h12m with 0 errors on Wed Nov 28  
19:51:31 2018

config:

NAME STATE READ WRITE CKSUM
red  ONLINE   0 0 0
  mirror-0   ONLINE   0 0 0
gpt/zfs-b1-WCC4M0EYCTAZ  ONLINE   0 0 0
gpt/zfs-b2-WCC4M5PV83PY  ONLINE   0 0 0
  mirror-1   ONLINE   0 0 0
gpt/zfs-b3-WCC4N7FLJD34  ONLINE   0 0 0
gpt/zfs-b4-WCC4N4UDKN8F  ONLINE   0 0 0
logs
  mirror-2   ONLINE   0 0 0
gpt/zfs-a1-B492480446ONLINE   0 0 0
gpt/zfs-a2-B492480406ONLINE   0 0 0

errors: No known data errors

This is arranged as a pair of two mirrors, referenced by GPT labels.  
Each of the mirror "vdev"s is RAID1, and then writes are striped across  
them.  It's not /actually/ striping, it's more clever, and it biases the  
writes to balance throughput and free space across all the vdevs, but  
it's similar.  The last vdev is a "log" device made of a pair of  
mirrored SSDs.  This "ZIL" is basically a fast write cache.  I could  
also have an SSD added as an L2ARC read cache as well, but it's not  
necessary for this system's workload.  No errors have occurred on any of  
the devices in the pool.


All filesystems allocate storage from this pool.  Here's a few:

% zfs list -r red | head -n6
NAME USED  AVAIL  REFER  MOUNTPOINT
red 2.57T  1.82T   104K  /red
red/bhyve872K  1.82T88K  /red/bhyve
red/data 718G  1.82T   712G  /export/data
red/distfiles   11.9G  1.82T  11.8G  /red/distfiles
red/home 285G  1.82T96K  /export/home

There are actually 74 filesystems in this pool!  Because the storage is  
shared, there's no limit on how many you can have.  So unlike  
traditional partitioning, or even LVM (w/o thin pool) it's massively  
more flexible.  You can create, snapshot and destroy datasets on a whim,  
and even delegate administration of parts of the tree to different users  
and groups.  So users could create datasets under their home directory,  
snapshot them and send them to and from other systems.  You can organise  
your data into whatever filesystem structure makes sense.


Let's look at the pool used on the Linux system I'm writing this email on:

% zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 0h5m with 0 errors on Mon Nov 26  
17:15:55 2018

config:

NAMESTATE READ WRITE CKSUM
rpool   ONLINE   0 0 0
  sda2  ONLINE   0 0 0

errors: No known data errors

This is a single SSD "root pool" for the operating system; with data in  
other pools not shown here.


% zfs list -r rpool
NAME USED  AVAIL  REFER  MOUNTPOINT
rpool   45.4G  62.2G96K  none
rpool/ROOT  14.7G  62.2G96K  none
rpool/ROOT/default  14.7G  62.2G  12.0G  /
rpool/home  3.18M  62.2G96K  none
rpool/home/root 3.08M  62.2G  3.08M  /root
rpool/swap  8.50G  63.2G  7.51G  -
rpool/var   5.72G  62.2G96K  none
rpool/var/cache 5.32G  62.2G  5.18G  /var/cache
rpool/var/log398M  62.2G   394M  /var/log
rpool/var/spool 8.14M  62.2G  8.02M  /var/spool
rpool/var/tmp312K  62.2G   152K  /var/tmp

These datasets comprise the entire operating system (I've omitted some  
third-party software package datasets from rpool/opt).


% zfs list -t snapshot -r rpool
NAME USED  AVAIL  REFER  MOUNTPOINT
rpool@cosmic-post  0B  -96K  -
rpool/ROOT@cosmic-post 0B  -96K  -
rpool/ROOT/default@cosmic-post  2.66G  -  12.3G  -
rpool/home@cosmic-post 0B  -96K  -
rpool/home/root@cosmic-post0B  

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 28/11/2018 à 16:12, Hendrik Boom a écrit :

On Wed, Nov 28, 2018 at 12:11:25PM +0100, Didier Kryn wrote:


Instead, it
seems /lib has become a holly directory where only the libc and the 
dynamic

linker are allowed to live.

I do *not* mean this sarcastically; I am confused.
Is "holly" a new technical use of an existing English word?
Or is it berely a typo.



    Typo: I meant holy, in the sense other libraries thanthe dynamic 
libc aren't saint enough to stay in this directory. It was intended as a 
form mof humour.


        Didier




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Thu, 29 Nov 2018 22:44:31 +0900
Olaf Meeuwissen  wrote:

 
> Stephan Seitz writes:
> 
> > Maintainers are encouraged to install everything in /usr because it
> > must be available in early boot.  
> 
> Call me dumb but I totally, completely and utterly fail to understand
> why "Maintainers are *encouraged* to install everything in /usr".

Follow   the   money.
 
SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Thu, 29 Nov 2018 13:24:01 +0100
Stephan Seitz  wrote:

> On Do, Nov 29, 2018 at 01:22:05 -0500, Steve Litt wrote:
> >My understanding is that Devuan will ask in the fresh installer
> >whether the user wants to merge or not, with the default being no
> >merge. This is fine with me. Do you have a problem with it?  
> 
> Nope, but even Devuan will probably never support a separate /usr
> without mounting it in early boot via initrd.

If you define "support" as "not prevent", then Devuan already does
support what you say in the preceding sentence. If you define "support"
as "install with the package manager", I don't care about support, and
a heck of a lot of DIY people have the same view I'm expressing.

SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 29/11/2018 à 14:44, Olaf Meeuwissen a écrit :

  restrictions (think ro/nodev/nosuid) or tune performance (think
  noatime).


    You can mount / with nodev. Except if you absolutely want static 
device files, /dev is now a mountpoint with device files managed either 
by udev/eudev/vdev/mdev, or by the kernel itself.


    Didier


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 29/11/2018 12:57, k...@aspodata.se wrote:

Roger:
...

Note that to return to the pre-merge policies would be an exercise in
futility.  It was already an exercise in futility back in 2011 because
the number of libraries which /could/ be moved to /lib is an unbounded
set.  There's always another tool which /might/ be required, which pulls
in yet more libraries, and their dependencies, and the dependencies of
their dependencies and so on.  It's a Sisyphean task.


It wouldn't be for a subset of booting setups. It is perfectly possible
for a certain set. If I make a make a kernel package, I can certainly
say that that this package supports direct boot to disk without initrd
and with a separate /usr, with the constraint that it don't support
e.g. lvm and other setups.

Why not agree on a certain set of programs/libs that should be in /bin,
/sbin, and /lib, just to not break my and others packages. That set
don't need to cover all booting possibilities.


This is what we used to (try) to do, but we failed at it.  Even when the 
policy was to not allow any library dependencies in /usr for binaries in 
/ there were many dozens that crept in unnoticed.  The fact that they 
crept in is also part of the problem; mounting /usr was sufficiently 
niche that it didn't get enough testing to pick up these problems and 
resolve them before they caused trouble.  That alone was a warning sign 
that this option wasn't well supported and was subject to breakage as a 
result, and is also a factor in its demise.


The problem is agreeing on what is essential for booting, and what is 
not.  There's so much variety in differing requirements that satisfying 
everyone is impossible.  For example, ext[234], md and lvm2 might be a 
common requirement, maybe xfs and btrfs-tools as well.  How about ZFS? 
Ceph? GlusterFS? Or proprietary third-party filesystems like IBM GPFS. 
LDAP.  Encryption.  Networking.  CA Certificates.  SSL/TLS.  There's 
always "just one more" requirement, which critically breaks someone's 
system if it's not specially catered for.  This is why the problem is 
unbounded and this situation was untenable.  It made a separate /usr 
completely unusable for a good number of perfectly legitimate setups, 
many of which were hard requirements for working in large corporate or 
academic IT environments, where it had to inter-operate well with the 
existing infrastructure.  The fact that Debian was hideously broken by 
default for all these use cases had been an embarrassment for a number 
of years which we needed to solve.


We could certainly pick an essential subset of tools and filesystems, 
and state that this combination is allowed for mounting /usr.  But this 
is basically drawing a line in the sand and saying that outside those 
essential packages, everything else is a second-class citizen which 
isn't properly supported.  One of the points which has been made 
multiple times is the need for freedom for the admin to configure their 
systems as they like.  It's obviously important.  But by drawing this 
line we are saying that you /can't/ have the freedom to use anything 
outside this essential set because it will break.  Forget about 
experimenting with new and interesting filesystems.  And forget about 
integrating with the infrastructure required by your company.


And lest anyone forget history, it was once impossible to use md or lvm 
(or btrfs etc.) for booting, before all that special-casing and 
bootloader support was in place.  I was one of the first people to try 
all that out and identify the problems when it was brand spanking new. 
The same restrictions apply to any new technologies which come along in 
the future.  We don't want to deliberately limit future possibilities.


Those factors had to be weighed against the need to mount a /usr without 
an initramfs.  The number of people doing this was a niche subset of a 
already very small subset.  We support booting without an initramfs.  We 
support booting with a separate /usr.  But not both together.  There are 
limits to what is possible and reasonable to support, and that use case 
was judged to be so tiny that the other use cases were of greater benefit.


No matter how you slice it, restrictions were going to be placed upon 
the use of a separate /usr for one subset of users or another.  The 
status quo was that it worked without an initramfs, but was broken for a 
large number of other scenarios.  We stopped it working without an 
initramfs but made it work for **all** of the other scenarios.  So in 
terms of allowing a separate /usr, we actually /increased/ its 
flexibility and utility at the expense of this one use case.  I tried my 
hardest to avoid any breakage at all, but I couldn't figure out a 
supportable way to do this.  If anyone can figure out a solution, then 
I'd be very happy.  However, given that the solution to the problem is 
to simply use an initramfs, that's the official solution here.  Keep a 
separate /usr, but use the 

Re: [DNG] /usr to merge or not to merge... that is the question

[Olaf Meeuwissen]

Hi Stephan,

# Disclaimer: / and /usr live on the same partition on my systems.
# Heads up: I just might change that ... back to what I used to do.

Stephan Seitz writes:

> Maintainers are encouraged to install everything in /usr because it must
> be available in early boot.

Call me dumb but I totally, completely and utterly fail to understand
why "Maintainers are *encouraged* to install everything in /usr".

# Emphasis added.

I just don't get what benefits

  for d in bin sbin lib; do
mv /$d /usr/$d
rmdir /$d
ln -s /usr/$d /$d   # to avoid major mayhem
  done

will bring *me*.  For maintainers, the only benefit I can think of is
removal of the need to think where something should go (and addressing
any fall-out of that should dependencies not be on the same partition).

For the record, /usr (whether on a *separate* partition or not) just
happens to be available in "early boot" because keeping it out was
deemed undoable, i.e. "requires more effort than the Debian maintainers
are willing to spend".

# I don't blame them for that, it's just that even though it might make
# economic sense, it is not a technologically or organizationally sound
# justification.  I've been trying to point out that putting the system
# critical and non-critical stuff in different "drawers" makes sense in
# terms of organization.  So has Didier.
# Insisting on putting these "drawers" in different "chests" (often for
# rather good reasons as Rick has tried to show) is actually why things
# get complicated.

> That’s why the usrmerge is only the logical next step. If you can’t live
> without /usr, you can put everything in it. Why should you waste your
> precious resources? There are enough other problems.

Fact: You can't live without /.
Hence, you can put everything in it.
Let's move /usr/{bin,sbin,lib} to /{bin,sbin,lib}, yeah!
Q: Why would you waste your precious resources moving stuff around?
A: Because needed stuff is on a different partition.
Solution: Disallow the different partition.
Objection: But the different partition makes it easy to impose
 restrictions (think ro/nodev/nosuid) or tune performance (think
 noatime).
Q: Isn't there some filesystem type that supports settings at a more
 granular level than the device?  Like directory or per file?
A: Eh ... Don't know.  Haven't checked ...
Solution: Go fish!

# I haven't gone fishing yet but a vague recollection of Roger's post
# where he mentioned ZFS seemed promising ...

> With the many features an application can have today you will have a
> hard time finding and moving all the stuff [from /usr to /].  And then
> people would complain that their / doesn’t have enough space…

Tell them to increase the size of the partition that holds '/'.
Tell them to nuke the partition that holds '/usr'.
Make a usr-merge package that actually merges the partition that holds
the '/usr' file system tree with the partition that holds '/'.

Okay, so the three suggestions immediately above are tongue-in-cheek.
My main "stumbling block" is really about the (near) orthogonality of
filesystem tree organization and how that is mapped onto partitions.

If / and /usr are on a single partition, what is the benefit of moving
the contents of /bin, /lib and /sbin to their /usr counterparts?  What
are the drawbacks?

If / and /usr are on different partions, what is the benefit of moving
the contents of /bin, /lib and /sbin to their /usr counterparts?  What
are the drawbacks?

@KatolaZ Thanks for making the usr-merge an option in the installer.
 Even more thanks for making the default *not* merged because
 system-critical and system-non-critical really should be kept
 in different "drawers", IMNSHO.

Hope this helps, but somewhat afraid it won't :-/
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[karl]

Roger:
...
> Note that to return to the pre-merge policies would be an exercise in 
> futility.  It was already an exercise in futility back in 2011 because 
> the number of libraries which /could/ be moved to /lib is an unbounded 
> set.  There's always another tool which /might/ be required, which pulls 
> in yet more libraries, and their dependencies, and the dependencies of 
> their dependencies and so on.  It's a Sisyphean task.

It wouldn't be for a subset of booting setups. It is perfectly possible
for a certain set. If I make a make a kernel package, I can certainly 
say that that this package supports direct boot to disk without initrd 
and with a separate /usr, with the constraint that it don't support
e.g. lvm and other setups.

Why not agree on a certain set of programs/libs that should be in /bin,
/sbin, and /lib, just to not break my and others packages. That set
don't need to cover all booting possibilities.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Stephan Seitz]

On Do, Nov 29, 2018 at 01:22:05 -0500, Steve Litt wrote:

My understanding is that Devuan will ask in the fresh installer whether
the user wants to merge or not, with the default being no merge. This
is fine with me. Do you have a problem with it?


Nope, but even Devuan will probably never support a separate /usr without 
mounting it in early boot via initrd.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 29/11/2018 10:21, Arnt Karlsen wrote:> On Wed, 28 Nov 2018 15:26:59 
+, Roger wrote in message

<38625727-08b2-2816-85b0-8f57d6796...@codelibre.net>:


This isn't a bug, or even a feature.  It's a deliberate design
decision which affects the functioning of the system as a whole.  I
understand your concerns, and I even sympathise with them, but the
decision to do this was taken over six years ago after extensive
discussion,


..links to the important parts of those discussions would be nice
and very helpful.


I don't have the time to dig through all the separate mailing lists, IRC 
logs, bug ticket and all the rest.  It's scattered too widely and over 
too long a period of time.  However, I have dug up some public mailing 
list threads over the time period concerned which might be informative.


https://lists.debian.org/debian-devel/2011/12/threads.html
  Red Hat is moving from / to /usr/
  from / to /usr/: a summary

https://lists.debian.org/debian-devel/2011/12/thrd2.html
  #652011
  #652275

https://lists.debian.org/debian-devel/2012/01/threads.html
  from / to /usr/: a summary

https://lists.debian.org/debian-devel/2012/09/msg00010.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/08/thrd2.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/09/threads.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://lists.debian.org/debian-devel/2012/12/threads.html
  Stuff from /bin, /sbin, /lib depending on /usr/lib libraries

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459
  Contains most of the implementation discussion and iterative 
refinement of the patchset.



and it's been implemented and released six and four years ago,
respectively.


...appearantly with trumpian eptitude, running Karl's usr.pl on my
"life boat" install of devuan_ascii_2.0.0_amd64_desktop-live.iso,
I found 20 programs in /bin or /sbin in 12 packages that might need
a fix.


Interestingly, if you read some of these threads, you'll see people 
doing exactly this auditing back in 2011-12 because this was already 
causing breakage back then, even before the mounting of /usr in the 
initramfs.



..I put Karl's usr.pl in /sbin and ran it first bare, then counted
with: usr.pl |grep ^/ |wc -l
and: dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq |wc -l

..fixing 2 or 3 packages a year, is very doable. ;o)

..now, do we return to the pre-merge policies 6 and 4 years ago?
Yes, as a first step, I believe we should[…]


Note that to return to the pre-merge policies would be an exercise in 
futility.  It was already an exercise in futility back in 2011 because 
the number of libraries which /could/ be moved to /lib is an unbounded 
set.  There's always another tool which /might/ be required, which pulls 
in yet more libraries, and their dependencies, and the dependencies of 
their dependencies and so on.  It's a Sisyphean task.


On 29/11/2018, 06:22 Steve Litt wrote:

> I see the fingerprints of Redhat, Poettering and Freedesktop all over
> such encouragement, and highly doubt it's for technical reasons.

If you read the threads above, you will see that RedHat were planning to 
merge /usr at this point.  It's no secret that there is some 
cross-pollination of ideas between distributions, and that there is also 
some degree of pressure for conformity to benefit interoperability. 
However, it's also /not/ a conspiracy in any way.  This was all 
discussed and implemented in public, not done in secret.  There were 
solid technical reasons for doing this, and it's likely this would have 
happened with or without any degree of influence from RedHat.  The fact 
that it was actually implemented by the sysvinit maintainers should be a 
big hint that we saw a good deal of value in it which would greatly 
improve the flexibility and maintainability of the initscripts for the 
benefit of our users.  And also, without it, there would have been /even 
more/ pressure to adopt systemd, since it removed the arguments about 
sysvinit/initscripts being unable to handle a number of scenarios which 
it previously couldn't cope with.



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Thu, Nov 29, 2018 at 12:44:35AM -0600, goli...@dyne.org wrote:
> On 2018-11-29 00:22, Steve Litt wrote:
> > 
> > My understanding is that Devuan will ask in the fresh installer whether
> > the user wants to merge or not, with the default being no merge. This
> > is fine with me.
> > 
> 
> I installed a test beowulf mini.iso a few days ago and there was indeed an
> option to merge.  The default is to keep them separate.
> 
> golinux

Great!  It has been tested.

Because that which is not tested is broken.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Arnt Karlsen]

On Wed, 28 Nov 2018 15:26:59 +, Roger wrote in message 
<38625727-08b2-2816-85b0-8f57d6796...@codelibre.net>:

> On 28/11/2018 11:36, Rick Moen wrote:
> > Quoting Didier Kryn (k...@in2p3.fr):
> >   
> >> IIUC, your argument boils down to "depending on /usr for early
> >> boot is a *bug*", while Roger told us why it has become a
> >> *feature* (~:  
> > 
> > My view, which I expressed in detail prior to Roger joining the
> > thread, is that it's vital to the most vital function of the root
> > filesystem's maintenance software directories
> > (/sbin, /bin, /lib, /lib64) that their binaries function _even_
> > if /usr is not (or at the moment cannot be) mounted -- because the
> > most vital function of those subtrees is backup, restore, repair,
> > maintenance (functions that might be required to
> > recover/fix /usr).  
> 
> Prior to wheezy, this was considered vital and was explicitly
> required and enforced.  From wheezy onward, this requirement was
> deliberately and intentionally dropped.
> 
> If you want to backup, restore, or repair your system, you can still
> do so.  But you have to do so with /usr present either as part of the 
> rootfs or mounted as a separate filesystem.
> 
> This isn't a bug, or even a feature.  It's a deliberate design
> decision which affects the functioning of the system as a whole.  I
> understand your concerns, and I even sympathise with them, but the
> decision to do this was taken over six years ago after extensive
> discussion,

..links to the important parts of those discussions would be nice 
and very helpful.

> and it's been implemented and released six and four years ago,
> respectively.


...appearantly with trumpian eptitude, running Karl's usr.pl on my
"life boat" install of devuan_ascii_2.0.0_amd64_desktop-live.iso, 
I found 20 programs in /bin or /sbin in 12 packages that might need 
a fix.  

..I put Karl's usr.pl in /sbin and ran it first bare, then counted 
with: usr.pl |grep ^/ |wc -l 
and: dpkg -S $(usr.pl |grep ^/ ) |cut -d":" -f1 |sort |uniq |wc -l

..fixing 2 or 3 packages a year, is very doable. ;o)


..now, do we return to the pre-merge policies 6 and 4 years ago? 
Yes, as a first step, I believe we should, while we revisit boot 
policy history and sites like:
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/etc.html
where I recommend scrolling down to gems like: "/etc/rcS.d
The scripts in this directory are executed once when booting the
system, even when booting directly into single user mode. 
The files are all symbolic links, the real files are located
in /etc/init.d/. For a more general discussion of this technique,
see /etc/init.d/README.", and then back up to: "/etc/init.d

Order of scripts run in /etc/rc?.d
==

0. Overview. " etc, which is quite different from Debian's version.


..me, I'd like to see /boot/initrd.img-recovery-$(uname -r) in the
grub menu recovery stanzas guarantee boot into runlevel S or 1, so
broken systems can be fixed, and lessons can be learned from those
fixes.

..to make those system maintenance lessons useful etc, my proposed 
/boot/initrd.img-recovery-$(uname -r) should carry at least the same
tools I expect to find in runlevel S or 1, or drop me home there, in 
runlevel S or 1.


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Wed, Nov 28, 2018 at 09:12:33PM -0500, Steve Litt wrote:
> On Wed, 28 Nov 2018 12:11:25 +0100
> Didier Kryn  wrote:
> 
>  
> >      IIUC, your argument boils down to "depending on /usr for early
> > boot is a *bug*", while Roger told us why it has become a *feature*
> > (~:
> 
> I can think of very few cases where a disallowed usage is a feature.
> Private and local variables are two of the few. The pre-UEFI inability
> to brick your mobo was definitely another.
> 
> But I don't think foreclosing the opportunity to boot exclusively
> from the / partition, without an initramfs, is a "feature". Giving a
> choice is a feature, removing the alternative choice is not.
>  

Features, choices, alternatives, and freedom are not cheap, or
granted, or automatic.

Providing features costs energy, time, and work. Providing choice
costs energy, time, and work. Providing alternatives costs energy,
time, and work.

The required energy and time must come from somewhere, and the work
needs to be done by somebody. 

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[etech3]

On 11/29/2018 01:44 AM, goli...@dyne.org wrote:

On 2018-11-29 00:22, Steve Litt wrote:


My understanding is that Devuan will ask in the fresh installer whether
the user wants to merge or not, with the default being no merge. This
is fine with me.



I installed a test beowulf mini.iso a few days ago and there was 
indeed an option to merge.  The default is to keep them separate.


golinux


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


I can confirm this in the the 32 bit beowulf mini iso version also.

Just throwing in my 2cents...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[golinux]

On 2018-11-29 00:22, Steve Litt wrote:


My understanding is that Devuan will ask in the fresh installer whether
the user wants to merge or not, with the default being no merge. This
is fine with me.



I installed a test beowulf mini.iso a few days ago and there was indeed 
an option to merge.  The default is to keep them separate.


golinux


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Wed, 28 Nov 2018 13:27:04 +0100
Stephan Seitz  wrote:

> On Mi, Nov 28, 2018 at 12:11:25 +0100, Didier Kryn wrote:
> >    IIUC, your argument boils down to "depending on /usr for early
> >boot is a *bug*", while Roger told us why it has become a *feature*
> >(~:  
> 
> You can discuss if this is a feature but the fact is that most 
> distributions have given up supporting a separate /usr in later
> boot.  

Devuan isn't most distros. By nature of its banishment of systemd,
Devuan is a DIY friendly distro. DIY friendly means exposing all the
dials and levers to the computer's operator/admin/user, which means
leaving /sbin and /lib where they are.

Devuan != Ubuntu

And, because of what Debian has become:

Devuan != Debian

[snip]

> Maintainers are encouraged to install everything in /usr because it
> must be available in early boot.

I see the fingerprints of Redhat, Poettering and Freedesktop all over
such encouragement, and highly doubt it's for technical reasons.

> 
> That’s why the usrmerge is only the logical next step. If you can’t
> live without /usr, you can put everything in it. Why should you waste
> your precious resources? There are enough other problems.

My understanding is that Devuan will ask in the fresh installer whether
the user wants to merge or not, with the default being no merge. This
is fine with me. Do you have a problem with it?

SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Wed, 28 Nov 2018 12:11:25 +0100
Didier Kryn  wrote:

 
>      IIUC, your argument boils down to "depending on /usr for early
> boot is a *bug*", while Roger told us why it has become a *feature*
> (~:

I can think of very few cases where a disallowed usage is a feature.
Private and local variables are two of the few. The pre-UEFI inability
to brick your mobo was definitely another.

But I don't think foreclosing the opportunity to boot exclusively
from the / partition, without an initramfs, is a "feature". Giving a
choice is a feature, removing the alternative choice is not.
 
SteveT

Steve Litt
November 2018 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> On Wed, Nov 28, 2018 at 03:36:12AM -0800, Rick Moen wrote:
> > 
> > (This is why I tend not to waste time hyperventilating about dumb distro
> > policy decisions:  Submit a bug.  If it's rejected or never acted on,
> > just make a local configuration that works around the stupid distro
> > action, and move on to more rewarding parts of life.  If moved to
> > public-spiritedness, also publish one's fix a part of a third-party
> > package repo, pro bono public, to help others benefit from your work
> > without needing to replicate ito.)
> 
> Sounds like a description of devuan.

Serendipitously so, yes!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Hendrik Boom (hend...@topoi.pooq.com):

> On Wed, Nov 28, 2018 at 12:11:25PM +0100, Didier Kryn wrote:
> 
> > Instead, it
> > seems /lib has become a holly directory where only the libc and the dynamic
> > linker are allowed to live.
> 
> I do *not* mean this sarcastically; I am confused.
> Is "holly" a new technical use of an existing English word?
> Or is it berely a typo.

I would guess that the word Didier intended to type (and to use
metaphorically) was 'holy', and that indeed this was merely ('berely' ;-> )
a typo.

-- 
Cheers,"I never quarrel with a man who buys ink by the barrel."
Rick Moen-- Rep. Charles B. Brownson (R-Indiana), ca. 1960
r...@linuxmafia.com
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 28/11/2018 11:36, Rick Moen wrote:

Quoting Didier Kryn (k...@in2p3.fr):


IIUC, your argument boils down to "depending on /usr for early boot is
a *bug*", while Roger told us why it has become a *feature* (~:


My view, which I expressed in detail prior to Roger joining the thread,
is that it's vital to the most vital function of the root filesystem's
maintenance software directories (/sbin, /bin, /lib, /lib64) that their
binaries function _even_ if /usr is not (or at the moment cannot be)
mounted -- because the most vital function of those subtrees is backup,
restore, repair, maintenance (functions that might be required to
recover/fix /usr).


Prior to wheezy, this was considered vital and was explicitly required 
and enforced.  From wheezy onward, this requirement was deliberately and 
intentionally dropped.


If you want to backup, restore, or repair your system, you can still do 
so.  But you have to do so with /usr present either as part of the 
rootfs or mounted as a separate filesystem.


This isn't a bug, or even a feature.  It's a deliberate design decision 
which affects the functioning of the system as a whole.  I understand 
your concerns, and I even sympathise with them, but the decision to do 
this was taken over six years ago after extensive discussion, and it's 
been implemented and released six and four years ago, respectively.



I addressed the main part of Roger's initial post upthread, and don't
care to revisit that discussion, except to mention that he dismissed the
use-case cited above, which is the traditional Unix use-case, in wording
that didn't address the substance of those concerns.


I tried to explain the rationale for the decision in a reasonable amount 
of detail, along with some of the competing concerns which affected it. 
I'm not trying to convince you that your points are not important for 
your needs or that they are irrelevant.  But the decision was already 
made and implemented for quite a long time now.  I'm simply trying to 
explain why things are the way they are today.


I'm also not trying to say that I'm fully happy with the decision or its 
consequences.  Like many decisions, it arose as a imperfect compromise 
which considered many different competing use cases and requirements, 
and tried to pick the path which provided the most benefit for the least 
harm.  We did the best we could.  And if we had to do it over again, I 
don't think much would be materially different.  We did a pretty good 
job given the constraints.  Limitations on the use of a fully separate 
mountable /usr were the price we had to pay for a whole host of benefits 
which were considered to be worth that cost.



It would certainly be possible to move all applications and dynamic
libraries needed for early boot from the /usr tree to /bin, /sbin and
/lib, but Debian has made a different choice.


Debian did try this choice, for most of the 2000s.  We repeatedly moved 
libraries and tools from /usr to the rootfs which were needed for early 
boot.  But the number of libraries and tools which *might* be needed was 
ever increasing.  The problem was not scalable or tractable for a 
general-purpose distribution.


We only switched to the current solution when it became clear that this 
approach wasn't working and that there were a number of problems which 
couldn't be resolved by this approach.  A lot of effort was put into 
trying to make this approach work.


The current solution *is* scalable and tractable for pretty much any 
esoteric boot requirements you might have.  Because it doesn't depend 
upon having a pre-approved shortlist of early-boot packages treated 
specially, it works for all packages.



(This is why I tend not to waste time hyperventilating about dumb distro
policy decisions:  Submit a bug.  If it's rejected or never acted on,
just make a local configuration that works around the stupid distro
action, and move on to more rewarding parts of life.  If moved to
public-spiritedness, also publish one's fix a part of a third-party
package repo, pro bono public, to help others benefit from your work
without needing to replicate ito.)


This is good advice.  But for the problem in question, it's not a bug 
which can be worked around this way, it's a fairly fundamental design 
choice which just isn't fixable with small patches here and there.  It's 
systemic.



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Wed, Nov 28, 2018 at 12:45:25PM +0100, KatolaZ wrote:
> On Wed, Nov 28, 2018 at 02:25:20AM -0800, Rick Moen wrote:
> > Quoting Didier Kryn (k...@in2p3.fr):
> > 
> > > Le 28/11/2018 à 08:11, Rick Moen a écrit :
> > > >If I were relying on NFS during early boot, I'd file a bug against 
> > > >package
> > > >nfs-common, and also, meanwhile, compile a local-package substitute with
> > > >either static binaries or ones linked to libs in /lib (and provide 
> > > >those).
> > > 
> > > Debian supports diskless hosts mounting an NFS filesystem on /.
> > 
> > Of course yes.  _But_, what I was commenting on was the dependency on
> > /usr for the NFS mounting utility in /sbin.  That means -- KatolaZ's
> > point -- that /sbin/mount.nfs will not function in the absence of /usr.
> > My answer to KatolaZ amounted to:  Yes, and that's a bug.  I would, if I
> > needed that during early boot (e.g., during maintenance operation, thus
> > needing to be functional even if /usr cannot be mounted), then I would
> > file a bug against mount.nfs and, while awaiting attention to the bug,
> > compile a local replacement.
> 
> Or you can tinker with the initscripts. Or you can also use another
> distribution. Or Linux From Scratch. Or whatever you like :) We all
> could do that, and let Debian/Devuan go to hell. My computing would
> actually be just fine with OpenBSD...
> 
> Unfortunately, most of this thread has been just about "oh look how
> cool MY setup is, oh I went around that, oh I tried this and that, oh
> I want to have /var on a tmpfs, oh I mount /usr over NFS and you
> should try it as well..."  and so on and so forth.
> 
> IMHO, this is mostly out of scope, and does not help Devuan improving
> by a single bit. I understand it's hard to appreciate for most of us,
> but putting together a distro is not about catering for the needs of
> just one user: there is an entire world of possibilities outside :)

The discussion just points out that flexibility is important, and 
reminds us to be cautious in rulling out plausible ways of organising a 
system.

This comes up every time our upstream looks like it's going to become 
restrictive in one way or another.

But I agree that we do have to focus our efforts carefully -- we 
don't have the resources to do otherwise.

I hope this kind of discussion also helps us decide how to 
allocate those resources.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Wed, Nov 28, 2018 at 03:36:12AM -0800, Rick Moen wrote:
> 
> (This is why I tend not to waste time hyperventilating about dumb distro
> policy decisions:  Submit a bug.  If it's rejected or never acted on,
> just make a local configuration that works around the stupid distro
> action, and move on to more rewarding parts of life.  If moved to
> public-spiritedness, also publish one's fix a part of a third-party
> package repo, pro bono public, to help others benefit from your work
> without needing to replicate ito.)

Sounds like a description of devuan.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Wed, Nov 28, 2018 at 12:11:25PM +0100, Didier Kryn wrote:

> Instead, it
> seems /lib has become a holly directory where only the libc and the dynamic
> linker are allowed to live.

I do *not* mean this sarcastically; I am confused.
Is "holly" a new technical use of an existing English word?
Or is it berely a typo.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Tue, Nov 27, 2018 at 11:11:41PM -0800, Rick Moen wrote:
> Quoting KatolaZ (kato...@freaknet.org):
> 
> > # ldd /sbin/mount.nfs | grep "/usr"
> > libgssapi_krb5.so.2 => 
> > /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f82f53ac000)
> > libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
> > (0x7f82f52cf000)
> > libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
> > (0x7f82f529b000)
> > libkrb5support.so.0 => 
> > /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f82f4fd1000)
>  
> If I were relying on NFS during early boot, I'd file a bug against package
> nfs-common, and also, meanwhile, compile a local-package substitute with
> either static binaries or ones linked to libs in /lib (and provide those).
> 
> > # ldd /sbin/lvscan | grep "/usr"
> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> > (0x7fde00702000)
> > 
> > # ldd /sbin/lvs | grep "/usr"
>  liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7fd3b7fa1000)
> 
> Ditto package lvm2.  (Which FWIW I've avaoided needing.)
> 
> > # ldd /sbin/sysctl | grep "/usr"
> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> > (0x7f3ab7b18000)
> 
> Um, I know of no reason why /sbin/sysctl would be urgently needed in a
> minimal system prior to availability of /usr for purposes of backup,
> restore, system repair, etc.  I've never needed to futz with /proc/sys/*
> entries while running in maintenance mode, but, if one did need to do
> so, doing the task using 'echo' is more than sufficient.
> 
> > # ldd /sbin/gdisk | grep "/usr"
> > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> > (0x7f7ddf10f000)
> 
> I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far
> successfully avoided GPT.  The obvious alternative to gdisk is GNU
> parted (package parted), and FWIW it suffers a similar build boo-boo,
> requiring library libtic.so.5 (terminfo) from inside /usr/lib.  
> 
> Tsk-tsk.  ;->
> 
> > # ldd /bin/kill | grep "/usr"
> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> > (0x7f9f6aa4a000)
> > 
> > # ldd /bin/ps | grep "/usr"
> > liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> > (0x7fd7f6ebc000)
> 
> Yeah, those two are really annoying.  FWIW, my server system has older
> versions of those two utilities that do _not_ have that (IMO) build
> error.  Local packages will be an immediate resort, when/if I hit that.
> 
> > # ldd /bin/efibootmgr | grep "/usr"
> > libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 
> > (0x7f7ed22bd000)
> > libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 
> > (0x7f7ed20b)
> 
> As with GPT, I've managed so far to step sideways and successfully evade
> the Second System Effect poster child that is EFI.  

I'm happily using a GPT file system on a machine that does not EFI.  
There's a so-called "protective" MBR.  But the first lowest-level boot 
is from an MBR on an older, smaller MBR-formatted disk.

I suspect, though, that it is possible to boot directly to the GPT disk 
starting from the so-called provective MBR.

> 
> I'm also unconvinced that efibootmgr is essential to a 'recovery'
> minimal maintenance system, anyway.  My readings suggest that I would
> want to have a 'EFI stub kernel' configuration where you place an
> (unsigned) kernel binary image in the EFI System Partition and rely on 
> the EFI firmware to boot that kernel and mount the root fs directly
> without needing a bootloader.  Coverage at, among other places:
> https://wiki.gentoo.org/wiki/EFI_stub_kernel 

As far as I can tell, the EFI partition on my old laptop (which is not 
the machine I mentioned above) is completely borked.  It doesn't even 
seem to have a mountable FAT file system.  The EFI partition is still 
there from the days it used to have a Windows XP system preinstalled on 
it.  Is it plausible that that partition wasa borked fro the get-go?

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Wed, Nov 28, 2018 at 03:00:40AM -0800, Rick Moen wrote:
> Quoting Didier Kryn (k...@in2p3.fr):
> 
> > For what concerns, laptops, I think we are in the era of ssd
> > and, unfortunately, there is usually only one disk drive per laptop,
> > except of older ones where the cdrom drive can be replaced by a
> > disk.
> 
> Yes, and this is in my opinion a very regrettable omission from the market.
> Many laptop enclosures have adequate physical space for a pair of
> equal-sized SSDs.  If they would only please leave an empty bay for a
> second device and unused power and data connectors, I would be happy
> with the option of RAID1-mirroring the entire system.

Interesting.  One option would even be RAID-1 mirroring between an SSD 
and a disk drive.  Save money by avoiding a second large SSD.  Writes 
would be slow, but reads would often be served fast from the SSD.  
Useful when reads are much more common that writes.  If one of the 
drives fails, your data are still safe, though your system may slow 
down or not depending on which drive failed.

> 
> Worse, some lovely small systems like the Zotac ZBOX C-series, likes
> this one as a current example
> (https://store.zotac.com/zbox-ci325-nano-with-windows-10-zbox-ci325nano-u-w2b),
> would make great little silent home servers, except that they support
> only one 63.5 mm (2.5") SSD plus one SSD in the M.2 slot.  Grr, so
> close, and yet so far.

My Purism system has the wiring and space for an extra SSD.  
Interesting prospect.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):

> You can discuss if this is a feature but the fact is that most
> distributions have given up supporting a separate /usr in later
> boot.
> 
> So any bugreport against lvm2 or nfs-common will be closed because
> it is not a supported use case.
> 
> Maintainers are encouraged to install everything in /usr because it
> must be available in early boot.
> 
> That’s why the usrmerge is only the logical next step.

I'll bet you didn't even notice that you just made a circular argument,
nor that your third paragraph is a total non-sequitur.

-- 
Cheers,"I never quarrel with a man who buys ink by the barrel."
Rick Moen-- Rep. Charles B. Brownson (R-Indiana), ca. 1960
r...@linuxmafia.com
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting KatolaZ (kato...@freaknet.org):

> Yeah, on a personal level you can do that, and I totally agree. On a
> distribution level, and with the current number of active developers
> in Devuan, the way forward is that people with interest in the matter
> to roll their sleeves up and do something to solve the problem, if
> they think it is a problem ;)

You know, one great thing about personal fixes is that you often can
share them.

I haven't yet this hapless /bin/ps and /bin/kill breakage.  If I do, and
Debian package maintainers decline to fix their build errors (which
seems sadly likely, since it substantively involved, in each case, some
other idiot moving an essential lib to /usr/lib, and the procps
package maintainer deciding that's not his/her problem), then I'd be
glad to share my packages and patches.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Stephan Seitz]

On Mi, Nov 28, 2018 at 12:11:25 +0100, Didier Kryn wrote:
    IIUC, your argument boils down to "depending on /usr for early boot 
is a *bug*", while Roger told us why it has become a *feature* (~:


You can discuss if this is a feature but the fact is that most 
distributions have given up supporting a separate /usr in later boot.  

So any bugreport against lvm2 or nfs-common will be closed because it is 
not a supported use case.


Maintainers are encouraged to install everything in /usr because it must 
be available in early boot.


That’s why the usrmerge is only the logical next step. If you can’t live 
without /usr, you can put everything in it. Why should you waste your 
precious resources? There are enough other problems.


    It would certainly be possible to move all applications and dynamic 
libraries needed for early boot from the /usr tree to /bin, /sbin and 
/lib, but Debian has made a different choice. In the case of 


With the many features an application can have today you will have a hard 
time finding and moving all the stuff. And then people would complain 
that their / doesn’t have enough space…


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting KatolaZ (kato...@freaknet.org):

> Unfortunately, most of this thread has been just about "oh look how
> cool MY setup is, oh I went around that, oh I tried this and that, oh
> I want to have /var on a tmpfs, oh I mount /usr over NFS and you
> should try it as well..."  and so on and so forth.

Again, sorry if I annoyed, but I've merely responded to several people 
who seemed either unaware of, or worse are aware of but proclaim
impractical or impossible or useless techniques of partitioning and
mount options that I've found useful and refined over decades of
professional experience.  I wished to politely point out that those
people had erred, and to assist everyone.  Judging by some expressions
of thanks, I at least helped some, and perhaps provided food for thought
to others.

I'll be delighted if I can make some of that deliverable through Devuan.  
At the same time, despite the Debian Project motto, there is no such
thing as a universal operating system.  To get full and proper use of
*ix, one must learn how to do local customisation above and beyond what
any distro installer will ever provide, and also when and how much it's
sensible to do so (and when and why it isn't).  Conversations to
propagate that cultural tradition are part of our Unix heritage, and I
hope and expect are welcome here in moderation.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Wed, Nov 28, 2018 at 04:04:18AM -0800, Rick Moen wrote:

[cut]

> 
> > and there is little we can do to avoid that...
> 
> Um..., didn't I just describe what I'm likely to do to avoid that?
> I could swear I did.
> 

Yeah, on a personal level you can do that, and I totally agree. On a
distribution level, and with the current number of active developers
in Devuan, the way forward is that people with interest in the matter
to roll their sleeves up and do something to solve the problem, if
they think it is a problem ;)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting KatolaZ (kato...@freaknet.org):

> Great. This is your opinion. We got it.

Apologies if I annoyed.  I restated that view only becaused Didier said
'IIUC, your argument boils down to "depending on /usr for early boot is
a *bug*", while Roger told us why it has become a *feature* (~:', and
that really wasn't my argument (leaving aside my not having addressed
'early boot', whatever Didier meant by that).

> This is not what is happening in Debian...

On present evidence, not much.  The only Debian build errors (/sbin or
/bin contents needed for maintenance that break in /usr's absence)
I've so far seen mentioned that matter to me are /bin/ps and /bin/kill.
Those are rather sadly hapless errors, but certainly easy to fix.

> and there is little we can do to avoid that...

Um..., didn't I just describe what I'm likely to do to avoid that?
I could swear I did.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Wed, Nov 28, 2018 at 03:36:12AM -0800, Rick Moen wrote:
> Quoting Didier Kryn (k...@in2p3.fr):
> 
> > IIUC, your argument boils down to "depending on /usr for early boot is
> > a *bug*", while Roger told us why it has become a *feature* (~:
> 
> My view, which I expressed in detail prior to Roger joining the thread, 
> is that it's vital to the most vital function of the root filesystem's 
> maintenance software directories (/sbin, /bin, /lib, /lib64) that their 
> binaries function _even_ if /usr is not (or at the moment cannot be)
> mounted -- because the most vital function of those subtrees is backup,
> restore, repair, maintenance (functions that might be required to
> recover/fix /usr).  

Great. This is your opinion. We got it. This is not what is happening
in Debian, and there is little we can do to avoid that, unless people
who are concerned aobut that roll-up their sleeves and fork and
maintain the relevant packages.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Wed, Nov 28, 2018 at 12:11:25PM +0100, Didier Kryn wrote:

[cut]

> 
>     It would certainly be possible to move all applications and dynamic
> libraries needed for early boot from the /usr tree to /bin, /sbin and /lib,
> but Debian has made a different choice. In the case of NFS, I agree that the
> only thing to do would be to move the dynamic library to /lib. Instead, it
> seems /lib has become a holly directory where only the libc and the dynamic
> linker are allowed to live.

Actually, Debian has not made any decision at all so far. The
merged-usr transition is still under discussion on debian-devel. At
the moment it seems quite unlikely to be pushed into Buster before
freeze, but I have no idea of what will happen in the end.

I guess it's better to just move on ;)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Wed, Nov 28, 2018 at 02:25:20AM -0800, Rick Moen wrote:
> Quoting Didier Kryn (k...@in2p3.fr):
> 
> > Le 28/11/2018 à 08:11, Rick Moen a écrit :
> > >If I were relying on NFS during early boot, I'd file a bug against package
> > >nfs-common, and also, meanwhile, compile a local-package substitute with
> > >either static binaries or ones linked to libs in /lib (and provide those).
> > 
> > Debian supports diskless hosts mounting an NFS filesystem on /.
> 
> Of course yes.  _But_, what I was commenting on was the dependency on
> /usr for the NFS mounting utility in /sbin.  That means -- KatolaZ's
> point -- that /sbin/mount.nfs will not function in the absence of /usr.
> My answer to KatolaZ amounted to:  Yes, and that's a bug.  I would, if I
> needed that during early boot (e.g., during maintenance operation, thus
> needing to be functional even if /usr cannot be mounted), then I would
> file a bug against mount.nfs and, while awaiting attention to the bug,
> compile a local replacement.

Or you can tinker with the initscripts. Or you can also use another
distribution. Or Linux From Scratch. Or whatever you like :) We all
could do that, and let Debian/Devuan go to hell. My computing would
actually be just fine with OpenBSD...

Unfortunately, most of this thread has been just about "oh look how
cool MY setup is, oh I went around that, oh I tried this and that, oh
I want to have /var on a tmpfs, oh I mount /usr over NFS and you
should try it as well..."  and so on and so forth.

IMHO, this is mostly out of scope, and does not help Devuan improving
by a single bit. I understand it's hard to appreciate for most of us,
but putting together a distro is not about catering for the needs of
just one user: there is an entire world of possibilities outside :)

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> IIUC, your argument boils down to "depending on /usr for early boot is
> a *bug*", while Roger told us why it has become a *feature* (~:

My view, which I expressed in detail prior to Roger joining the thread, 
is that it's vital to the most vital function of the root filesystem's 
maintenance software directories (/sbin, /bin, /lib, /lib64) that their 
binaries function _even_ if /usr is not (or at the moment cannot be)
mounted -- because the most vital function of those subtrees is backup,
restore, repair, maintenance (functions that might be required to
recover/fix /usr).  

I addressed the main part of Roger's initial post upthread, and don't
care to revisit that discussion, except to mention that he dismissed the
use-case cited above, which is the traditional Unix use-case, in wording
that didn't address the substance of those concerns.

> It would certainly be possible to move all applications and dynamic
> libraries needed for early boot from the /usr tree to /bin, /sbin and
> /lib, but Debian has made a different choice.

I'm not 100% sure what you mean by 'early boot' in context of recent
discussion about separate /usr.  What I'm talking about is maintenance,
approximating as mentioned backup, restore, repair, maintenance.  It is
an integral part of Rick Moen system local policy that those functions
must work whether or not /usr is yet present (because they may be called
upon to rebuild or recover /usr).  If indeed Debian policy differs, to
the extent that it differs, then that still doesn't bother me a great
deal, since Rick Moen local policy is applied as required to overrule
Debian policy.  Problem solved.  ;->

(This is why I tend not to waste time hyperventilating about dumb distro
policy decisions:  Submit a bug.  If it's rejected or never acted on,
just make a local configuration that works around the stupid distro
action, and move on to more rewarding parts of life.  If moved to
public-spiritedness, also publish one's fix a part of a third-party
package repo, pro bono public, to help others benefit from your work
without needing to replicate ito.)

> In the case of NFS, I agree that the only thing to do would be to move
> the dynamic library to /lib. Instead, it seems /lib has become a holly
> directory where only the libc and the dynamic linker are allowed to
> live.

That would fix the ldd depency of mount.nfs on /usr/lib contents, yes.


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 28/11/2018 à 11:25, Rick Moen a écrit :

Quoting Didier Kryn (k...@in2p3.fr):


Le 28/11/2018 à 08:11, Rick Moen a écrit :

If I were relying on NFS during early boot, I'd file a bug against package
nfs-common, and also, meanwhile, compile a local-package substitute with
either static binaries or ones linked to libs in /lib (and provide those).

Debian supports diskless hosts mounting an NFS filesystem on /.

Of course yes.  _But_, what I was commenting on was the dependency on
/usr for the NFS mounting utility in /sbin.  That means -- KatolaZ's
point -- that /sbin/mount.nfs will not function in the absence of /usr.
My answer to KatolaZ amounted to:  Yes, and that's a bug.  I would, if I
needed that during early boot (e.g., during maintenance operation, thus
needing to be functional even if /usr cannot be mounted), then I would
file a bug against mount.nfs and, while awaiting attention to the bug,
compile a local replacement.


When using initrd/initramfs, this kernel option is no longer
necessary and I guess it is just simpler to rely on the modules
provided by nfs-common. The motivation is the same as for device
drivers and filesystems: boot a generic kernel, have all modules
available during early boot to mount / (and /usr).

But notice that if /usr _is not_ (e.g., cannot be, for some reason)
mounted, then you are screwed:  /sbin/mount.nfs breaks.  KatolZ cited
that utility's dynamic library dependency on a lib in /usr/lib as a
reason why separate /usr is impractical (for systems needing NFS access
even if /usr is unavailable).  I replied that, IMO, no, that's a reason
why /sbin/mount.nf thus constructed, has a build error.  ;->

    IIUC, your argument boils down to "depending on /usr for early boot 
is a *bug*", while Roger told us why it has become a *feature* (~:


    It would certainly be possible to move all applications and dynamic 
libraries needed for early boot from the /usr tree to /bin, /sbin and 
/lib, but Debian has made a different choice. In the case of NFS, I 
agree that the only thing to do would be to move the dynamic library to 
/lib. Instead, it seems /lib has become a holly directory where only the 
libc and the dynamic linker are allowed to live.


        Didier

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> It seems to me you're fighting to get the last bit of performance out
> of mechanical hard drives, including by using different filesystems
> for different partitions, which makes a lot of sense for servers. 

No, not any more.  Those configuration details come from HD-based server
systems I constructed many years ago.  My new prototype to which I'm 
migrating my main linuxmafia.com AKA unixmercenary.net system dispenses
with spinning rust entirely, in favour of a RAID1 pair of SSDs.  Good
riddance to spinning rust (except for high capacity and ancillary
storage, of course).

It's not just _performance_, though, but also longevity.  The hard
drives in system I construct in the manner described tend to last quite
a lot longer.

> I agree that filesystem play a major role in performance and safety.
> For the performance of the disks, and considering you speak of
> servers, you ommit to speak of the RAID configuration, which seems to
> me more important than the location of the partitions.

It is indeed important.  I didn't mention that because it had no
application to the discussion we were having at that moment.  (I'm a
huge fan of md-driver RAID1.)

> For what concerns, laptops, I think we are in the era of ssd
> and, unfortunately, there is usually only one disk drive per laptop,
> except of older ones where the cdrom drive can be replaced by a
> disk.

Yes, and this is in my opinion a very regrettable omission from the market.
Many laptop enclosures have adequate physical space for a pair of
equal-sized SSDs.  If they would only please leave an empty bay for a
second device and unused power and data connectors, I would be happy
with the option of RAID1-mirroring the entire system.

Worse, some lovely small systems like the Zotac ZBOX C-series, likes
this one as a current example
(https://store.zotac.com/zbox-ci325-nano-with-windows-10-zbox-ci325nano-u-w2b),
would make great little silent home servers, except that they support
only one 63.5 mm (2.5") SSD plus one SSD in the M.2 slot.  Grr, so
close, and yet so far.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 28/11/2018 à 10:35, Rick Moen a écrit :

Quoting Didier Kryn (k...@in2p3.fr):


     Files are stored in different directories, that's it for
clean bookkeeping. Making these directories mountpoint does not add
any sort of ordering. Only the impression they are more secure.

Here's a real-world example of ordering using filesystem divisions.
Let's assume a system using spinning rust -- a jocular term for hard
drives, where 'seeking', the process of moving heads between cylinders,
is by orders of magnitude the slowest read or write operation, as
opposed to SSDs, where the concept of 'seeking' doesn't even apply, and
all sectors are equally reachable in the same ultra-quick amount of
time, with no seek delay ever.

Ordering the file trees to minimise average seek distance and time
will thus both speed disk access and reduce wear.

Based on a lot of experimenting by me and others, and occasional but
seldom systematic measurement, a _reasonable_ general scheme for each
spindle is as follows:

Near the middle of the set of cylinders, you put the spindle's swap
partition.  On _either_ side of the swap, you put a filessytem tree that
has a high percentage of the system's reads and/or writes_.  /var is
one obvious candidate.  Others might depend on the role of the machine,
e.g., I tend to have a Web server's public HTML root mounted as /var/www
(as I disagree with recent FHS releases about /srv for this), so it
might go on the other side of the swap.  And then, proceeding both
inwards and outwards through the cylinders, other file trees with less
and less average activity.  If you have more than one spindle
(unmirrored), then put likewise a swap partition in the middle, and
festoon trees on either side following the same logic.

About the 'impression that they are more secure', the problem with the
word 'secure' in this context is that two speakers will often use it
with entirely different referents in mind.

For example, I might outline for you a partition scheme where /usr is
ext2 and mounted read-only except during package operations and has the
nodev mount option set, /var/lib is mounted nodev, /var/www is mounted
nodev,nosuid, and /, /home /var/spool, and /usr/local have default mount
options -- and your reaction was this gives only the _impression_ of being
more secure, because a system intruder who cracks root can remount
anything as desired to overcome such pitiful obstacles.

But that assumes that 'secure' is intended to mean 'defeats remote
intruders who steal shell and then successfully escalate to system
privilege' -- whereas by 'secure' I might mean, in this context,
something much more modest yet pragmatically useful:  The biggest
security threat to any *ix system is a tired and error-prone sysadmin
working at a shell prompt.  Anything that makes common blunders less
disastrous without excessive cost is a win, e.g., /usr being normally
mounted read-only averting disaster from an admin recklessly carries out
a command with system authority that crosses into /usr without he/she
intending to.  Almost as threatening to systems is misbehaving regular
software.  Anything that makes processes going haywire less able to do
harm without excessive cost is likewise A Good Thing.  Last, although
it's certainly true that a competent human intruder able to break in and
escalate to root can trivially remount filesystems, most system attacks
and privilege escalation are carried out by fully automated scripts,
and, if they fail because they rely on writing to /usr, it's very likely
they will _not_ be written to debug the problem as mount options and
do a remount and try again.

As usual, words are the problem.  Maybe we should switch to interpretive
dance.  ;->


    Hi Rick.

    It seems to me you're fighting to get the last bit of performance 
out of mechanical hard drives, including by using different filesystems 
for different partitions, which makes a lot of sense for servers. I 
agree that filesystem play a major role in performance and safety. For 
the performance of the disks, and considering you speak of servers, you 
ommit to speak of the RAID configuration, which seems to me more 
important than the location of the partitions.


    For what concerns, laptops, I think we are in the era of ssd and, 
unfortunately, there is usually only one disk drive per laptop, except 
of older ones where the cdrom drive can be replaced by a disk.


    Today, servers are probably still the domain of RAIDs based on 
mechanical hard drives, laptops, the domain of ssds, and desktops are 
the place where both live together - I have one desktop like this.


        Didier

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> Le 28/11/2018 à 08:11, Rick Moen a écrit :
> >If I were relying on NFS during early boot, I'd file a bug against package
> >nfs-common, and also, meanwhile, compile a local-package substitute with
> >either static binaries or ones linked to libs in /lib (and provide those).
> 
> Debian supports diskless hosts mounting an NFS filesystem on /.

Of course yes.  _But_, what I was commenting on was the dependency on
/usr for the NFS mounting utility in /sbin.  That means -- KatolaZ's
point -- that /sbin/mount.nfs will not function in the absence of /usr.
My answer to KatolaZ amounted to:  Yes, and that's a bug.  I would, if I
needed that during early boot (e.g., during maintenance operation, thus
needing to be functional even if /usr cannot be mounted), then I would
file a bug against mount.nfs and, while awaiting attention to the bug,
compile a local replacement.

> When using initrd/initramfs, this kernel option is no longer
> necessary and I guess it is just simpler to rely on the modules
> provided by nfs-common. The motivation is the same as for device
> drivers and filesystems: boot a generic kernel, have all modules
> available during early boot to mount / (and /usr).

But notice that if /usr _is not_ (e.g., cannot be, for some reason)
mounted, then you are screwed:  /sbin/mount.nfs breaks.  KatolZ cited
that utility's dynamic library dependency on a lib in /usr/lib as a
reason why separate /usr is impractical (for systems needing NFS access
even if /usr is unavailable).  I replied that, IMO, no, that's a reason
why /sbin/mount.nf thus constructed, has a build error.  ;->

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

>     Files are stored in different directories, that's it for
> clean bookkeeping. Making these directories mountpoint does not add
> any sort of ordering. Only the impression they are more secure.

Here's a real-world example of ordering using filesystem divisions.
Let's assume a system using spinning rust -- a jocular term for hard
drives, where 'seeking', the process of moving heads between cylinders,
is by orders of magnitude the slowest read or write operation, as
opposed to SSDs, where the concept of 'seeking' doesn't even apply, and
all sectors are equally reachable in the same ultra-quick amount of
time, with no seek delay ever.

Ordering the file trees to minimise average seek distance and time
will thus both speed disk access and reduce wear.

Based on a lot of experimenting by me and others, and occasional but
seldom systematic measurement, a _reasonable_ general scheme for each
spindle is as follows:

Near the middle of the set of cylinders, you put the spindle's swap
partition.  On _either_ side of the swap, you put a filessytem tree that 
has a high percentage of the system's reads and/or writes_.  /var is
one obvious candidate.  Others might depend on the role of the machine,
e.g., I tend to have a Web server's public HTML root mounted as /var/www
(as I disagree with recent FHS releases about /srv for this), so it
might go on the other side of the swap.  And then, proceeding both
inwards and outwards through the cylinders, other file trees with less
and less average activity.  If you have more than one spindle
(unmirrored), then put likewise a swap partition in the middle, and 
festoon trees on either side following the same logic.

About the 'impression that they are more secure', the problem with the
word 'secure' in this context is that two speakers will often use it
with entirely different referents in mind.

For example, I might outline for you a partition scheme where /usr is
ext2 and mounted read-only except during package operations and has the
nodev mount option set, /var/lib is mounted nodev, /var/www is mounted
nodev,nosuid, and /, /home /var/spool, and /usr/local have default mount
options -- and your reaction was this gives only the _impression_ of being
more secure, because a system intruder who cracks root can remount
anything as desired to overcome such pitiful obstacles.

But that assumes that 'secure' is intended to mean 'defeats remote
intruders who steal shell and then successfully escalate to system
privilege' -- whereas by 'secure' I might mean, in this context,
something much more modest yet pragmatically useful:  The biggest 
security threat to any *ix system is a tired and error-prone sysadmin
working at a shell prompt.  Anything that makes common blunders less
disastrous without excessive cost is a win, e.g., /usr being normally
mounted read-only averting disaster from an admin recklessly carries out
a command with system authority that crosses into /usr without he/she
intending to.  Almost as threatening to systems is misbehaving regular
software.  Anything that makes processes going haywire less able to do
harm without excessive cost is likewise A Good Thing.  Last, although
it's certainly true that a competent human intruder able to break in and
escalate to root can trivially remount filesystems, most system attacks 
and privilege escalation are carried out by fully automated scripts, 
and, if they fail because they rely on writing to /usr, it's very likely
they will _not_ be written to debug the problem as mount options and 
do a remount and try again.

As usual, words are the problem.  Maybe we should switch to interpretive
dance.  ;->

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting KatolaZ (kato...@freaknet.org):

> Roger has also explained that the rants about "not being able to boot
> with a separate /usr and without initramfs" are totally pointeless,
> since this has been the case in Debian and all the derivatives at
> least since Wheezy was testing (i.e., about 7 years ago). 

This was factually erroneous when he said it (at minimum for my servers,
where by preference I compile bespoke kernels), it was wrong _before_ he
said it (e.g,, when I cited the particulars of my architectural
preference, 1-2 days before he joined the thread), and it was wrong when
you spoke to me to convince me I should agree to his position and I
objected that dismissal of my server best practices as 'unecessary,
undesirable, and gain[ing] little' and as 'not really doing more than
adding extra unnecessary complexity', while concluding that 'none of it
actually matters').  

And, guess what?  It's still factually erroneous.  

Roger's statement is doubtless true of users who lack the initiative or
minimal competence to customise a Linux system (in which case, that
qualifier should be added to repair his claim.  Otherwise, it's just
dead wrong (leaving aside the rather arrogant hand-wavery in which he
stated it).

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting Alessandro Selli (alessandrose...@linux.com):

>  Can you name me one distribution other than Red Hat (which in
> fact is not a desktop-friendly distribution) that does not allow one to
> "do their own partition setup"?

I'm curious, Alessandro:  Is RHEL now completely hostile to custom
filesystem setup?  A long time ago (like maybe RHEL3), Red Hat built
into its Anaconda installer an ncurses-oriented 'guided' partitioning
tool that was guilty of both concealing information (suppressed display
of any extended partition, though logical partitions within it were
displayed) and also unacceptably overrode the installing admin's
judgement (e.g., rearranging following its own criteria the filesystems
to be created).  First time I encountered the latter misbehaviour, I 
exercised my vocubulary in several languages on the topics of theology
and biology, further commented 'Sod _this_ for a lark', cancelled out of
that subscreen, switched to Ctrl-Alt-F2, and used /sbin/fdisk instead.

Just offhand, I'm betting that a similar approach may still be fruitful,
though I've not needed to deal with the darned thing in quite a while.

Years later, based partly on that lesson, I started leaning towards a 
preference for using a best-of-breed live distro for partitioning and
mkfs'ing all of my filesystems _before_ using the desired distro
installer.  FWIW, I found the Siduction live CD ideal for this purpose.
(Siduction is the surviving fork of an innovative distro, Sidux, that 
was a quarterly CD ISO release based on Debian Sid + stabilisation
packages.)  My thought is:  If you find a maintenance bootable image 
that is reliably perfect for filesystem creation/layout, maybe you
should rely on it.  Sometimes, specialised tools justify themselves.

>   And again, I do get the technical reasons that have datacenter and
> cluster sysadmins prefer a merged filesystem

FWIW, I suspect that the premise (from an upstream poster) is pretty
much rubbish, analogue to Usenet's infamous 'the lurkers support me 
in e-mail' rejoider, and of null information value either way.

I suspect the aforementioned datacentre and cluster admins are the same
lunkheads who think default Docker configurations are the right way to
build Internet infrastructure.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] /usr to merge or not to merge... that is the question

[Rick Moen]

Quoting KatolaZ (kato...@freaknet.org):

> # ldd /sbin/mount.nfs | grep "/usr"
> libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
> (0x7f82f53ac000)
> libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
> (0x7f82f52cf000)
> libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
> (0x7f82f529b000)
> libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
> (0x7f82f4fd1000)
 
If I were relying on NFS during early boot, I'd file a bug against package
nfs-common, and also, meanwhile, compile a local-package substitute with
either static binaries or ones linked to libs in /lib (and provide those).

> # ldd /sbin/lvscan | grep "/usr"
> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7fde00702000)
> 
> # ldd /sbin/lvs | grep "/usr"
 liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fd3b7fa1000)

Ditto package lvm2.  (Which FWIW I've avaoided needing.)

> # ldd /sbin/sysctl | grep "/usr"
> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7f3ab7b18000)

Um, I know of no reason why /sbin/sysctl would be urgently needed in a
minimal system prior to availability of /usr for purposes of backup,
restore, system repair, etc.  I've never needed to futz with /proc/sys/*
entries while running in maintenance mode, but, if one did need to do
so, doing the task using 'echo' is more than sufficient.

> # ldd /sbin/gdisk | grep "/usr"
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
> (0x7f7ddf10f000)

I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far
successfully avoided GPT.  The obvious alternative to gdisk is GNU
parted (package parted), and FWIW it suffers a similar build boo-boo,
requiring library libtic.so.5 (terminfo) from inside /usr/lib.  

Tsk-tsk.  ;->

> # ldd /bin/kill | grep "/usr"
> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7f9f6aa4a000)
> 
> # ldd /bin/ps | grep "/usr"
> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
> (0x7fd7f6ebc000)

Yeah, those two are really annoying.  FWIW, my server system has older
versions of those two utilities that do _not_ have that (IMO) build
error.  Local packages will be an immediate resort, when/if I hit that.

> # ldd /bin/efibootmgr | grep "/usr"
> libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 
> (0x7f7ed22bd000)
>   libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 
> (0x7f7ed20b)

As with GPT, I've managed so far to step sideways and successfully evade
the Second System Effect poster child that is EFI.  

I'm also unconvinced that efibootmgr is essential to a 'recovery'
minimal maintenance system, anyway.  My readings suggest that I would
want to have a 'EFI stub kernel' configuration where you place an
(unsigned) kernel binary image in the EFI System Partition and rely on 
the EFI firmware to boot that kernel and mount the root fs directly
without needing a bootloader.  Coverage at, among other places:
https://wiki.gentoo.org/wiki/EFI_stub_kernel 

(As usual, I'm saying this is an example of what would Work for Me[tm].
What might suit others or some entire abstract group of people is a
different discussion.)

> Most of the utilities you would need to debug a problem in mounting a
> /usr over NFS, or a failing lvm volume, or a scrambled efi partition
> (some of the use cases somebody mentioned before) need stuff in
> /usr. 

This has not been my experience for my own use case (granting your point
about /bin/kill and /bin/ps as provided in packaged versions I am not
yet running).  If I encounter that, I will consider that situation to
involve critical bugs that I would resolve through the package
maintainer if possible, or via a locally built alternative if not.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Hendrik Boom]

On Thu, Nov 22, 2018 at 06:21:01PM +, Roger Leigh wrote:
> 
> It would be possible to share the ports tree on a FreeBSD system, since it's
> mostly self-contained, so long as it's read-only (it has unshared data in
> /var including the package database, so can't be read-write). But this is
> not reasonable with dpkg, by design.  The packages are putting data in / and
> /usr, as well as /var.  You cannot just export /usr without getting into an
> inconsistent and incoherent mess.

The only way I can see for BSD to have a package system with a separate 
and shared /usr is
(1) to absolutely forbid any dependencies from anything on /usr from 
anything in the root file system, 
(2) No package to have files in both /usr and the root file system
(3) Split the package data base so that packages in /usr are tracked in 
/usr and that packages in the root file system are tracked in the root 
file system.
(4) Make sure that you don't need anything in /usr to to packaage 
maintenance on the root file system.

Then upgrading the root file system can be done independently of 
upgrading /usr.

I suspect that this may be too severe a set of restrictions for BSD to 
tolerate, and as you mention, for Debian that ship has sailed long ago.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 24/11/2018 à 13:13, Roger Leigh a écrit :
(Like many, I used to routinely use a separate /usr on a separate 
partition, then LVM LV, until I really looked at the practice and 
questioned the real underlying problems which it was solving. I've not 
needed one in over a decade at this point.  I'm not particularly for 
or against having one.  It's simply ceased to be a relevant concern 
for any of the diverse systems I've worked on, from desktops and 
workstations, to cluster nodes, VMs, servers and container images.  
None of them needed it.)



    Like you I did mount /usr separately for over a decade, with the 
idea that my OS would be recoverable if /usr was corrupted. Untill I 
realized it simply wouldn't. I tend to prefer, now to reserve a 
partition for another Linux OS. It could be a clone, of the main one, 
but I prefer experimenting with fancy things, even custom. Disks are so 
big nowadays that there is a lot of room for it.


    In my last install, I still had /tmp and /var on separate 
partitions, but I'm questionning the validity of such a setup.


        Didier


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Clarke Sideroad]

Roger,

I appreciate you taking the time for the explanation of the flow of 
logic driving the developments.
It adds some depth that the average user, like me is not normally 
exposed to.


I remember doing installations with various partitions for directories, 
as much for coolness as anything, paper install manuals pointed the way.
I don't know if I represent the average use case, but now days other 
than swap and UEFI stuff, I just keep /home in a separate partition, 
spinning on its own when I can.


Thanks,

Clarke


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

Re: [DNG] /usr to merge or not to merge... that is the question

[karl]

Roger:
...
> There's no clean separation between the "base" system and "everything else".
...

I think my urge to have a separate /usr is that I want such a 
separation and there isn't a clear other place to have it.

> The other part of the scenario you mentioned here is "doesn't want to 
> use an initramfs".  Why?
...

I skip initrd to keep the boot setup simple.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 24/11/2018 02:45, Steve Litt wrote:

On Wed, 21 Nov 2018 12:17:21 +
Roger Leigh  wrote:



Some general points to consider:

1) A separate /usr serves no practical purpose on a Debian/Devuan
system

 Historically, /usr was separately mountable, shareable over NFS.
With a package manager like dpkg, / and /usr are an integrated,
managed whole.  Sharing over NFS is not practical since the managed
files span both parts, and you can't split the package database
between separate systems.


What I hear in the preceding paragraph is that dpkg considers /
and /usr a package deal (no pun intended), and so can't abide an NFS
mounted /usr. Telling people to merge / and /usr for this reason is
fixing the symptom and letting the root cause remain. That's usually
not a good idea, but perhaps in this case fixing dpkg would be too
difficult...


This part isn't a problem with the dpkg tool itself.  It's down to the 
content of packages not having a clean separation between / and /usr. 
Programs, libraries and data on both sides of the split are mutually 
interdependent upon the other.  KatolaZ illustrated this nicely in his 
last post with library dependencies across the divide.  (This was 
forbidden before the MountUsrInInitramfs work.)


There's no clean separation between the "base" system and "everything else".

You can absolutely mount /usr over NFS.  But it's not very practical to 
share that filesystem between multiple systems.  And it isn't a very 
useful configuration choice compared with other possibilities.  If you 
want to use NFS, you can mount the rootfs over NFS (including /usr). 
It's a simpler, more practical arrangement, and it's exactly what tools 
like debian-live do (for example).


Contrast this with the BSDs where there's a defined "base system" and 
then a separate and largely independent collection of packages under 
/usr/local.  But even on the BSDs, the primary split is between / and 
/usr/local, not / and /usr.  /usr/local/etc and /usr/local/var exist, 
while /usr/etc and /usr/var do not exist on Debian (or FreeBSD); they go 
on the rootfs, which is one of the causes of the tight coupling.  And 
it's not necessarily a bad thing.  It's simply a part of the basic 
design of Debian that we've accepted for over two decades.


  Take a copy of e.g. 
http://mirrorservice.org/sites/ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.0-RC1/base.txz


The "base" is the content of / and /usr from a single build of the base 
source tree.  While there's a separate static /rescue and it's 
technically possible to mount /usr separately (there's similar 
convoluted logic in the initscripts to what Debian used to have), the 
system as provided is a collection encompassing both.


Because it's not (yet) managed by a true package manager, you could 
actually set this up in the traditional way if you wished, and share a 
static /usr between several systems.  But it might still interact badly 
with freebsd-update (not tested it myself), and it's planned to come 
under the remit of the pkg package manager in time, so like Debian it 
may run into logistical problems due to the package management.



Modern disk sizes make partitioning a
separate /usr unnecessary and undesirable.  (Both are of
course /possible/, but there is precious little to gain by doing so.)


Well, *you* might not want a mounted /usr, and *I* certainly don't want
a mounted /usr, but we don't speak for every user in every context, and
we can't anticipate every context. So "serves no purpose" as a blanket
statement is false if we find one person using or wanting to use a
separate /usr on a De??an system.


Absolutely.  However, "wanting" to use a separate /usr doesn't imply 
that the reasons for that desire are sound or reasonable.  This is why I 
very much would like to know the underlying rationale for each use. 
Some may be genuinely valid.  Others may not be.  But we need to be able 
to objectively evaluate each one to determine this.


If you look back in the debian-devel and other list archives 5-7 years 
back or more, this was discussed on several occasions, and it was 
increasingly a struggle to identify genuinely valid use cases.  Some 
were bad.  Others were valid, but... pointless.  Over the years, the 
need for a separate /usr has weakened.  Most of the time, a single root 
partition is just fine, and this is the default for the installer, and 
the way the vast majority of people run their systems.  For these 
people, a separate /usr doesn't solve any of their problems.


Several of the uses are borne out of habit rather than necessity.  The 
sharing of /usr over NFS is an instructive one.  In discussions a few 
years back, this was brought up as a valid use case.  One or two users 
and developers brought this possibility up.  Some people claimed to be 
working with this setup.  But when questioned about how they actually 
made it work, it came down to doing rather custom and fragile stuff 
outside the package manager.  It turned 

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Fri, Nov 23, 2018 at 09:45:50PM -0500, Steve Litt wrote:

[cut]

> 
> What I hear in the preceding paragraph is that dpkg considers /
> and /usr a package deal (no pun intended), and so can't abide an NFS
> mounted /usr. Telling people to merge / and /usr for this reason is
> fixing the symptom and letting the root cause remain. That's usually
> not a good idea, but perhaps in this case fixing dpkg would be too
> difficult...
>

Dear Steve,

I don't understand what you mean by "fixing" dpkg. Please have a look:

# ldd /sbin/mount.nfs | grep "/usr"
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7f82f53ac000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 
(0x7f82f52cf000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 
(0x7f82f529b000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 
(0x7f82f4fd1000)

# ldd /sbin/lvscan | grep "/usr"
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fde00702000)

# ldd /sbin/lvs | grep "/usr"
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fd3b7fa1000)

# ldd /sbin/sysctl | grep "/usr"
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f3ab7b18000)

# ldd /sbin/gdisk | grep "/usr"
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f7ddf10f000)

# ldd /bin/kill | grep "/usr"
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f9f6aa4a000)

# ldd /bin/ps | grep "/usr"
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fd7f6ebc000)

# ldd /bin/efibootmgr | grep "/usr"
libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 
(0x7f7ed22bd000)
libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 
(0x7f7ed20b)

Most of the utilities you would need to debug a problem in mounting a
/usr over NFS, or a failing lvm volume, or a scrambled efi partition
(some of the use cases somebody mentioned before) need stuff in
/usr. 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Steve Litt]

On Wed, 21 Nov 2018 12:17:21 +
Roger Leigh  wrote:

> Hi folks,
> 
> I've been following the discussion with interest.  It's certainly not
> a new discussion, since I remember debating it a good few years back,
> but there are still the same opinions and thoughts on the topic that
> I remember from back then.
> 
> Some general points to consider:
> 
> 1) A separate /usr serves no practical purpose on a Debian/Devuan
> system
> 
> Historically, /usr was separately mountable, shareable over NFS. 
> With a package manager like dpkg, / and /usr are an integrated,
> managed whole.  Sharing over NFS is not practical since the managed
> files span both parts, and you can't split the package database
> between separate systems.  

What I hear in the preceding paragraph is that dpkg considers /
and /usr a package deal (no pun intended), and so can't abide an NFS
mounted /usr. Telling people to merge / and /usr for this reason is
fixing the symptom and letting the root cause remain. That's usually
not a good idea, but perhaps in this case fixing dpkg would be too
difficult...

> Modern disk sizes make partitioning a
> separate /usr unnecessary and undesirable.  (Both are of
> course /possible/, but there is precious little to gain by doing so.)

Well, *you* might not want a mounted /usr, and *I* certainly don't want
a mounted /usr, but we don't speak for every user in every context, and
we can't anticipate every context. So "serves no purpose" as a blanket
statement is false if we find one person using or wanting to use a
separate /usr on a De??an system.

I can imagine that somewhere there's a guy who gains speed by, boot
after boot, copying executables to /usr on a mounted RAM drive, and who
doesn't want to use an initramfs, who would be quite perturbed by the
merge.


[snip]
> 
> The point about /usr being a good place for "static" content is a 
> reasonable one.  But for better or worse, / is "the system".  It's
> still part of the managed whole, and hiving off a static /usr rather

That's not what I said upthread. What I said upthread is to continue to
have static programs in /sbin, sufficient to mount everything and to
troubleshoot if /usr fails to mount or something else goes wrong. As
far as /usr, its executables can and should use loadable libraries.

[snip]

> 2) Moving the content to /usr doesn't preclude moving it to / later

Huh?

> RedHat/systemd have decided to move everything to /usr, and

If you agree with me that the Linux landscape is no longer a
technocracy, then the preceding half sentence is a reason not to make
the move.

> Debian have decided to copy this as they have for most
> systemd-dictated changes.  

This is no surprise. Today's Debian is nothing like 20th century or
early 21st century Debian. I already linked a few days ago to the
kangaroo court way they forced systemd through.

> I'd prefer it to be the other way around;
> it's cleaner and it's what we would choose given a clean slate.

The preceding sentence is true, I'd imagine. But like the original
systemd debate, it's not an either-or situation. A third alternative is
to not copy anything anywhere, but instead leave the
early-boot-necessary stuff in /sbin, where it can be accessed the
microsecond / is mounted, without the need for /usr to be mounted.

> However, when multiple filesystems are in use, /usr is often larger
> and this is potentially the safer move *for upgrades*.

And here again, for upgrades, the "make no change" solution would be
even safer.

[snip the instructions on how to do unification: I don't see
unification as a good thing]

[snip the upgrade compatibility section because I'm not knowledgeable
enough to comment or critique, and because whenever faced with a whole
number version number increase, I wipe and reinstall]

> 
> 4) None of it actually matters

 ^^^
 For   most   people.

> 
> The whole discussion is based on the premise that they are
> separate. In practice, the vast majority of us have them on the same
> filesystem, given that there is no practical purpose to the
> separation as in (1) above.

"vast majority of us". Not a distro on this earth has avoided
disenfranchising a few for perceived ease for the many. But unlike
Ubuntu and Mint, pre-2014 Debian and post-2014 Devuan have
traditionally opted for maximum user configurability.

[snip containers and BSD]

> 
> Like a lot of systemd-driven changes, unifying these filesystems is 
> technically possible, slightly desirable, but at a huge practical
> cost. 

Couldn't have said it better myself.

> The main costs are the severe risks taken to migrate essential
> system files and rearrange the root filesystem during an upgrade.
> Given that from the user's and sysadmin's point of view, the system
> behaves the same both before and after the upgrade, they are being
> required to undertake a large risk for *almost zero* practical
> benefit.  

I'd speculate the main costs are breaking running 

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 18:26, goli...@dyne.org wrote:
> On 2018-11-23 09:03, Alessandro Selli wrote:
>> On 23/11/18 at 14:32, Stephan Seitz wrote:
>>>
>>> Again, are you doing the work for your setup you care so much?
>>
>>
>>   Yes, I am.  It's me who designs the filesystem layout when I chose
>> "Manual" in the install program menu.
>>
>>   It's me who reconfigures the kernel to fit my specific use-cases.
>>
>>   It's me who removes and installs software after checking the default
>> packages that were installed, it's me who hacks App-armor recipies, PAM
>> settings, iptables chains, security/limits settings, login.defs
>> settings, udev rules, system services, server configs and so on.  I do
>> not expect the distribution maintainers to do this for me.  I just want
>> to keep being free to do it.
>>
>>
>
> ME, ME, ME . . . that says it all.  Arrogant and selfish too.


   Yes, it's me who does the work on my systems.  Do you have a maid
that does that for you?

  I'm not calling you names because I'm not such a low man like you.


>
   So, regardless from what's best to the datacenter, can I be
 allowed to
 follow the 40 years long path and keep having a /usr split from /?
   Yes && I stay || I leave.
>
> Feel free to do so . . .


  Did it several times before, this time too won't kill me.


>>> The choice will probably stay as long as the work to keep it won’t be
>>> too much work for the volunteers.
>>
>>   And the day the choice will be gone I will surely jump ship.
>>
>
> If only . . .  You just don't get that providing choice is the
> responsibility of EACH AND EVERYONE OF US.  If WE don't make it
> happen, it won't.


  Seriously, am I asked to prevent people from taking away choices that
have been around for 40 years?

  No way, since there is choice, I just chose the systems that fit my
needs and desires.  Full stop.


> So please stop flapping your gums, roll up your sleeves and and DO
> something to make the OS of your dreams a reality not just for you
> only but for Devuan.


  Stop sabotaging things that work!  What can I do to prevent people (in
Debian, not in Devuan, so far) from doing so?


> On 2018-11-23 08:52, KatolaZ wrote:
>>
>> The fact that somebody is not a Devuan maintainer or developer does
>> not empower you to be rude or aggressive with him/her. Apparently you
>> are not a Devuan developer or maintainer either, so what? Shall we
>> stop reading your emails for this reason, or is the fact that your
>> emails are totally irrelevant to this thread (and your tone
>> inapprropriate for a civilised place) just enough?
>>
>> A basic rule of civilised conversations is that you should treat other
>> people twice better than you would like them to treat you, especially
>> if you don't know them personally. You have been treating a lot of
>> people here very badly and irrespectfully. This behaviour is not
>> tolerated. Either you stop immediately, or your emails will be
>> moderated.
>>
>> HND
>>
>> KatolaZ
>>
>
> I have access to the big red button and am getting a bit trigger happy
> . . .


  I am totally unimpressed.



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 18:10, goli...@dyne.org wrote:
> On 2018-11-23 07:32, Stephan Seitz wrote:
>>
>
> [trim]
>
>> Since Devuan and Debian are build by volunteers they will do what they
>> want to do. If no one is interested in keeping the choices they will
>> fade away. Will you step forward and work to keep the choices?
>>
>
> [trim]
>
>>
>> Again, are you doing the work for your setup you care so much?
>>
>
> I suggested something similar about a week ago and no response.
>
> https://lists.dyne.org/lurker/message/20181118.010137.9938d5f1.en.html


  Wrong, you did get my response:

https://lists.dyne.org/lurker/message/20181118.033658.96309362.en.html



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 23:17, Roger Leigh wrote:
> So if you're insistent upon retaining a separate /usr, that shouldn't
> be a problem.


  Tomorrow morning at 4:00 o'clock I'll wake everyone up ringing the
Church's bells to celebrate.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 22/11/2018 18:21, Roger Leigh wrote:

Before I follow up on any of the points you (and others) made in 
response, let me begin with some history you may be unaware of.  It 
actually predates systemd, and is largely unrelated to systemd.


I just rediscovered

  https://wiki.debian.org/ReleaseGoals/MountUsrInInitramfs

which has some additional details.  Though it actually contains less 
detail overall than my email yesterday, but there are some additional 
small bits of information there.  It never got fully updated after 
completion of the goal.  But it might be of general interest.


  https://wiki.debian.org/UsrMerge

Looking at the details of the /usr merge in more detail, if you're 
currently running with a separate /usr, this shouldn't have any impact 
on booting via the initramfs with initramfs-tools.  The only 
consideration would be that you would need to have sufficient disc space 
under /usr for the files being moved over from the rootfs.


So if you're insistent upon retaining a separate /usr, that shouldn't be 
a problem.  Though it will definitely break booting of / without an 
initramfs; you won't be able to do a direct boot of the rootfs since all 
the binaries will be missing.



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

Re: [DNG] /usr to merge or not to merge... that is the question

[Ismael L. Donis Garcia]

Best Regards
--
Ismael
- Original Message - 

From: "KatolaZ" 
To: 
Sent: Thursday, November 22, 2018 12:39 AM
Subject: Re: [DNG] /usr to merge or not to merge... that is the question

I would be more inclined towards leaving the dialog more or less as it
is but making it only available in the expert install (leaving
non-merged-usr as the default). The main problem is that usrmerge (the
package) is a hack, which will be discontinued and become unmaintained
as soon as merged-usr is declared "standard" (and we have seen this
happening already with systemd-shim and libsystemd-dummy, from the
same authors of usrmerge).


I also think that it is the best option, but without losing sight of this 
topic and the decions to take for version 4 of devuan.

by then we will know the pros and cons of each decision






___
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] /usr to merge or not to merge... that is the question

[Martin Steigerwald]

Dear Roger.

Roger Leigh - 23.11.18, 18:01:
[…]
> On a personal note: I spent well over a decade working on different
> parts of Debian and loved being a part of it, and had many friends
> there.  I left the Debian project after enduring over two years of
> abusive and disrespectful communications, primarily with regard to the
> systemd "debate" becoming overly personal, rather than sticking to
> technical facts.  It got to the point that I dreaded opening my mail
> client to see what new abuse had been sent.  Over the course of

Martin hugs Roger.

Best!
-- 
Martin


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

Re: [DNG] /usr to merge or not to merge... that is the question

[golinux]

On 2018-11-23 09:03, Alessandro Selli wrote:

On 23/11/18 at 14:32, Stephan Seitz wrote:


Again, are you doing the work for your setup you care so much?



  Yes, I am.  It's me who designs the filesystem layout when I chose
"Manual" in the install program menu.

  It's me who reconfigures the kernel to fit my specific use-cases.

  It's me who removes and installs software after checking the default
packages that were installed, it's me who hacks App-armor recipies, PAM
settings, iptables chains, security/limits settings, login.defs
settings, udev rules, system services, server configs and so on.  I do
not expect the distribution maintainers to do this for me.  I just want
to keep being free to do it.




ME, ME, ME . . . that says it all.  Arrogant and selfish too.

  So, regardless from what's best to the datacenter, can I be allowed 
to

follow the 40 years long path and keep having a /usr split from /?
  Yes && I stay || I leave.


Feel free to do so . . .



The choice will probably stay as long as the work to keep it won’t be
too much work for the volunteers.


  And the day the choice will be gone I will surely jump ship.



If only . . .  You just don't get that providing choice is the 
responsibility of EACH AND EVERYONE OF US.  If WE don't make it happen, 
it won't.  So please stop flapping your gums, roll up your sleeves and 
and DO something to make the OS of your dreams a reality not just for 
you only but for Devuan.


On 2018-11-23 08:52, KatolaZ wrote:


The fact that somebody is not a Devuan maintainer or developer does
not empower you to be rude or aggressive with him/her. Apparently you
are not a Devuan developer or maintainer either, so what? Shall we
stop reading your emails for this reason, or is the fact that your
emails are totally irrelevant to this thread (and your tone
inapprropriate for a civilised place) just enough?

A basic rule of civilised conversations is that you should treat other
people twice better than you would like them to treat you, especially
if you don't know them personally. You have been treating a lot of
people here very badly and irrespectfully. This behaviour is not
tolerated. Either you stop immediately, or your emails will be
moderated.

HND

KatolaZ



I have access to the big red button and am getting a bit trigger happy . 
. .


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

Re: [DNG] /usr to merge or not to merge... that is the question

[golinux]

On 2018-11-23 07:32, Stephan Seitz wrote:




[trim]


Since Devuan and Debian are build by volunteers they will do what they
want to do. If no one is interested in keeping the choices they will
fade away. Will you step forward and work to keep the choices?



[trim]



Again, are you doing the work for your setup you care so much?



I suggested something similar about a week ago and no response.

https://lists.dyne.org/lurker/message/20181118.010137.9938d5f1.en.html

If you want the freedom to have it YOUR way, you damn well better stop 
bitching and start contributing.  End of story.


golinux

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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 22/11/2018 22:24, Alessandro Selli wrote:

On 22/11/18 at 19:21, Roger Leigh wrote:

On 21/11/2018 16:11, Alessandro Selli wrote:

On 21/11/18 at 13:17, Roger Leigh wrote:

Hi folks,

I've been following the discussion with interest.



    No, you definitely have not followed it.  In fact you are
disregarding
all the points that were expressed against the merge.


Let me begin by stating that I found your reply (and others) to be
rude, unnecessarily aggressive, and lacking in well-reasoned objective
argument.



   Oh poor show flake, did I hurt your tender feelings when I state facts?


I did find your reply unacceptably rude.  This had nothing to do with 
the "facts" (which were largely absent) or the points you were trying to 
make, and everything to do with the manner in which you said it.


Impolite and intemperate language does not add anything of value to the 
points you are making.  It rather detracts from them and leads the 
reader to devalue and dismiss what you are saying as a result.  This 
doesn't just apply to yourself, but several of the other posters over 
the last few days.  Productive technical discussion is impeded by 
treating others with contempt and accusations of bad faith.


On a personal note: I spent well over a decade working on different 
parts of Debian and loved being a part of it, and had many friends 
there.  I left the Debian project after enduring over two years of 
abusive and disrespectful communications, primarily with regard to the 
systemd "debate" becoming overly personal, rather than sticking to 
technical facts.  It got to the point that I dreaded opening my mail 
client to see what new abuse had been sent.  Over the course of several 
months I became thoroughly stressed out, demoralised and demotivated by 
the continual barrage of negativity and disrespect.  It caused real 
depression which seriously affected my wellbeing in the real world. 
Coupled with severe RSI problems (which might not have been unrelated), 
I decided leave the project.  Not because I wanted to, but for my 
physical and mental wellbeing.  When you're saddled with a huge 
responsibility for keeping everyone's systems working, and have an 
unwritten obligation to do so, and you have to spend a huge fraction of 
your unpaid off-work time on it, and that time has become unpleasant, 
stressful, physically damaging due to the RSI and no longer provides 
even the last bit of enjoyment you once derived from it, it's time to 
call it quits.  It was the RSI which forced the issue; I could no longer 
physically meet my duties and commitments as a developer while also 
doing my day job.  But I'd been desperately unhappy for many, many 
months as well.


The words you write from the anonymity and comfort of your home or 
office do have an effect upon those who receive them.  I'm not a 
snowflake.  I'm a 39 year old professional software developer with over 
18 years of experience in several different fields, and a science PhD as 
well.  I'm very happy to engage in robust technical debate, but that 
isn't what you're doing here.  If people aren't prepared to attempt a 
minimum amount of politeness and respect for their fellow human beings, 
I simply move to work on other projects which have more mature people 
working on them.  Life is too short to tolerate or suffer from 
unnecessary abuse.


In short: Don't remove the joy people get out of participating in free 
software projects by being abusive.  We can all be better than that.



   Again I express something so simple I'm really beginning to lose my mind:


   I do not intend to deprive anyone with the freedom to merge /usr to /,
damn it!

   I want to preserve *MY* freedom of choice, I want to be able to split
from / anything that is not required on *MY* systems or that will never
be required on any system (Java, Apache, Squid, Xorg, LibreOffice etc).

   I am not fighting against people who want to introduce different
filesystem layouts because of their special needs, I WANT THEM TO STOP
FORCING THEIR DESIGN CHANGES TO ME FOR NO OTHER REASON THAT TO THEIR
SYSTEMS THEIR LAYOUT MAKES MORE SENSE!


The individual components of the operating system are not developed in a 
vacuum.  They are developed in collaboration with and consideration of 
the rest of the system they reside within and interoperate with.


For the /usr mounting in initramfs history I posted, this body of work 
took over a year to finish.  Not because of technical complexity, but 
because it required precise coordination between several different parts 
of the system, including: initramfs-tools, initscripts, grub and others 
(including systemd).  And it needed staging in a fixed order to avoid 
breakage.  All this required coordination and collaboration between 
multiple groups of people.  Each group needed to understand the big 
picture issues, as well as how their part was affected in relation to 
the parts around it.  This required extensive (and polite) negotiation 
and 

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 15:52, KatolaZ wrote:
> On Fri, Nov 23, 2018 at 02:52:00PM +0100, Alessandro Selli wrote:
>
> [cut]
>
>>
>>   My rants were an answer to a (former) Debian maintainer/devloper who
>> was on this list justifying the necessity of Debian's / -> merge based
>> on  the specific needs of datacenters or his own personal tastes.
>>
>>
> You still haven't read the email by Roger


  Yes, I did.  Stop attacking the straw man.


>  (who is the former sysvinit
> maintainer in Debian for several years, and knows what he is talking
> about), and probably you haven't fully understood it. He explained
> very well that the kind of mechanism he has implemented in initramfs
> for the early boot (which is the same damn thing that brings your
> computer up), has little or nothing to do with the massive merged-usr
> transition proposed now in Debian. Actually, he did that to *avoid*
> that a merged-usr was necessary at all. On top of that, the transition
> to merged-usr in Debian is still under question, and will most
> probably not happen in Buster. But you continue to bang your head
> against the wall.


  I quote Roger:

    "usr originated because of certain constraints on early Unix
systems, and it has persisted since then out of tradition and entrenched
usage patterns and designs long after those constraints were lifted."


  This is one of the moments when the WTF words must've been visible
hovering over my head.  I thought to myself: "Again with this false
argument?"  I get all the complexities involved in different FS layout
and related boot paths, but why on hell insisting that a split /usr only
exists because K. Thompson and D. Ritchie run out of HD space 40 years
ago?  I listed so many times the reasons I have a split /usr on my
systems and to what other uses it was put over time, even of the last
Fedora 28 install I have them split and it was the first distribution to
declare the split unsupported IIRC, why keep repeating this BS?


> Roger has also explained that the rants about "not being able to boot
> with a separate /usr and without initramfs" are totally pointeless,


  They are pointless to a datacenter, not to a desktop install, and I
wrote several times my reasons to want such a layout and the different
uses I put them to.

  Roger commented one of them this way:


>> 3) having a /usr partition shared by several local installs that are
>> booted on different / filesystems;
>
> It's important to point out here that this has never, *ever*, been a
> supported or recommended way of running a Debian system.  It's clearly
> (and obviously if you think about it) broken by design. 


  It's only broken if you do upgrades on one system and fail to
synchronize the others.  Of course I do take care of this, and I fully
understand that I'm using the OS in a way that it was not designed for
and that it's my full responsibility to keep it sane and working.  But
this is one of the reasons I've always liked GNU/linux: it doesn't
(strongly) get in the way when you decide to use in ways that were not
envisioned before or that were not endorsed by a Technical Committee.

  Still this layout is the only way for me to avoid virtualization when
I need two very differently configured systems according to what use I
put the system: personal workstation vs. course training testbed.  The
first time I setup such a system it was on a dual core with limited (60
GB) HD room and no virtualization hardware support.  It worked so fine I
kept running it this way even when I had available an i5 with 2GB HD
available.

  Debian never supported such a layout?  I'm fine with it, I can deal
with it.

  Debian proposes changes that will make running such a layout
impossible?  I'll let my opposition be known, just not to let them say
that no one spoke against those changes when the were been debated.

  Debian makes running such a layout (as well as others) impossible?  I
leave it.
  I already left it, in fact.  Shall Devuan follow suit, I'll leave it
too, so long as there's choice.


> since this has been the case in Debian and all the derivatives at
> least since Wheezy was testing (i.e., about 7 years ago). If you
> haven't noticed in the last seven years, I doubt it would make any
> difference to you at all at this point.


  Yes, I know.  Yet it's still been possible to freely customize the FS
layout so far, even at install time.  This is the reason I expressed no
objections before.

  Now decisions are been debated that will make those possibilities
either much more difficult to implement to or just impossible.  So, now
I do speak out against those proposed changes.


>>   Or, is Roger Leigh a Devuan maintainer or developer?
> The fact that somebody is not a Devuan maintainer or developer does
> not empower you to be rude or aggressive with him/her. Apparently you
> are not a Devuan developer or maintainer either, so what?


  I never claimed to be, it's you who wrote:

    "Is Debian you are angry with? Then please go 

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 14:32, Stephan Seitz wrote:
> On Fr, Nov 23, 2018 at 01:09:17 +0100, Alessandro Selli wrote:
>>   I do get the reasons the merge proponents prefer this filesystem
>> layout.  What I rant against is their choices being imposed on me.
>
> They are not imposed on you. No one is going to your desktop/server
> and is changing your disc layout.


  Debian is (going to).  In order to avoid this imposition in Devuan too
the install procedure needs to be modified to provide with a choice and
a new package is beeing introduced.  Debian is not going to do this,
because to them the split /usr is:


 1. silly;
 2. old-time;
 3. useless;
 4. hard to maintain though it's been done since the early 70s;
 5. not datacenter and cluster friendly;
 6. esoteric.


>>   While I did not state this claim, I thought desktop use was one of the
>> targets Devuan would try to accomodate.  If this is not the case then I
>> think I'd better go search some desktop-friendly distribution.
>
> Sorry, you’re funny. A desktop-friendly distribution is certainly not
> a distribution which will ask you about your partition layout and
> filesystem choices because the majority of people who want to use a
> desktop-friendly distribution is not interested in these details.


  Speak for yourself.  "Desktop install" does not equate to "directed to
the uncultivated masses", even if this was the most common case.  Lots
of long-time Unix and GNU/linux sysadmins and developers do desktop
installs, both for their employer and for themselves.  And they do hack
and customize lots of things.


> They want very few questions and working desktop after the installation.


  This has nothing to do with the possibility of performing any kind of
customization.

  And again, speak for yourself.


> This is probably one of the reason why people who want to do their own
> partition setup are not using desktop-friendly distributions…


  What?  Can you name me one distribution other than Red Hat (which in
fact is not a desktop-friendly distribution) that does not allow one to
"do their own partition setup"?


> You are the first desktop user I have met who insists on having his
> own layout.


  You must have lived in a walled garden then, because everybody I know
who regularly uses some GNU/Linux distribution (for their own use and
often at work) regularly does some level of customization of key
elements of the OS: the kernel, the filesystem, PAM settings, the
initramfs, init, service configuration (both SysV init scripts and
systemd unit files) etc.

  This is in fact one of the major reasons they use Linux, one of them I
remember saying that he switched to Linux when he quickly got bored at
how little his brand new Windows 98 installation allowed him to do.


>>   This is my precisely my point: trumping desktop users' needs (or just
>> freedom of customization and choice)  because of cluster ease-of-use
>> considerations make the distribution *not* universal.  If Devuan is
>
> Of course it is still universal, or does your desktop (whatever you
> use) stop working after a /usr-merge?


  Of course it is no longer universal when I can no longer have a split
/usr filesystem because it makes management of datacenter clusters more
difficult.


> No one removes fvwm, xfce, kde, or the X server.


  Straw man attack: I never said the merge prevents me to install this
or any other software.  I listed the things it prevents me to do several
times, why are you ignoring those points and make up never before stated
claims?


> And as Roger has tried to tell you every freedom of customization and
> choice you want is work that has to be done by someone.


  Don't you tell me!

  Even taking away the possibilities I have to customize installations
"is work that has to be done by someone".


> More choices means you need more testing.


  Err, mostly not.  A distribution can (and in fact they do) have a
default layout that {could be|is} the only officially supported one.

  I am fine with testing and troubleshoot my own customizations and
hacks, I do not ask others to do them for me.  If for no other reason
that they'd take the fun away.  I just want to be able to do them.  And
to have some documentation available, next.  Many critics of systemd
correctly pointed out how little it lets you customize *your* system,
often making it more fragile.  I run into this problem myself, with a
Fedora installation, when systemd was waiting minutes for the swap
partition activation to time out at boot.  This was due to the fact that
I had encrypted it's partition, which was working well after the system
booted.  But the swap.service had nothing at all that could be
customized, it could not even de disabled, it was a thoroughly
internally managed service.  This is one of the reasons I decided to
ditch Fedora and to only use systemd-free distributions.  Now Debian is
going the Red Hat way to prevent you from booting on an unmerged
filesystem.  If this became impossible or too 

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Fri, Nov 23, 2018 at 02:52:00PM +0100, Alessandro Selli wrote:

[cut]

> 
> 
>   My rants were an answer to a (former) Debian maintainer/devloper who
> was on this list justifying the necessity of Debian's / -> merge based
> on  the specific needs of datacenters or his own personal tastes.
> 
>

You still haven't read the email by Roger (who is the former sysvinit
maintainer in Debian for several years, and knows what he is talking
about), and probably you haven't fully understood it. He explained
very well that the kind of mechanism he has implemented in initramfs
for the early boot (which is the same damn thing that brings your
computer up), has little or nothing to do with the massive merged-usr
transition proposed now in Debian. Actually, he did that to *avoid*
that a merged-usr was necessary at all. On top of that, the transition
to merged-usr in Debian is still under question, and will most
probably not happen in Buster. But you continue to bang your head
against the wall.

Roger has also explained that the rants about "not being able to boot
with a separate /usr and without initramfs" are totally pointeless,
since this has been the case in Debian and all the derivatives at
least since Wheezy was testing (i.e., about 7 years ago). If you
haven't noticed in the last seven years, I doubt it would make any
difference to you at all at this point.

>   Or, is Roger Leigh a Devuan maintainer or developer?

The fact that somebody is not a Devuan maintainer or developer does
not empower you to be rude or aggressive with him/her. Apparently you
are not a Devuan developer or maintainer either, so what? Shall we
stop reading your emails for this reason, or is the fact that your
emails are totally irrelevant to this thread (and your tone
inapprropriate for a civilised place) just enough?

A basic rule of civilised conversations is that you should treat other
people twice better than you would like them to treat you, especially
if you don't know them personally. You have been treating a lot of
people here very badly and irrespectfully. This behaviour is not
tolerated. Either you stop immediately, or your emails will be
moderated.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 14:25, KatolaZ wrote:
> On Fri, Nov 23, 2018 at 01:09:17PM +0100, Alessandro Selli wrote:
>
> [cut]
>
>>
>>>  Devuan is currently used in a mutlitude of
>>> environments that include server farms, corporate and personal
>>> servers, embedded systems, personal devices, and desktops. So any
>>> choice Devuan will make has to take into account *all* the different
>>> uses of Devuan.
>>>
>>> We are going to provide the users with the choice of having or not
>>> having a merged-usr.
>>
>>   Yes, we are.  Debian apparently is no longer going to be.  And again I
>> was listed the many good reasons the merge is good for the datacenter as
>> an answer to my question: "Why must I be denied the possibility to do
>> otherwise?".
>>
> You continue not reading and not understanding. Who is denying you the
> possibility to do otherwise? Surely not Devuan, which is still
> offering you a choice. You are welcome.


  Re-read what you just quoted, darn it!

    «Yes, we [Devuan] are [provide the users with the choice].  *Debian*
apparently is no longer going to be.»


  Who is who fails to understand?


> Is Debian you are angry with?


  Yes.


>  Then please go explain your reasons to
> them, since your rant here is *totally* *out* *of* *scope*.


  My rants were an answer to a (former) Debian maintainer/devloper who
was on this list justifying the necessity of Debian's / -> merge based
on  the specific needs of datacenters or his own personal tastes.


  Or, is Roger Leigh a Devuan maintainer or developer?


>>   Plus the many-times repeated BS of: "The / - /usr split is silly",
> I won't discuss anything about the technical motivations behind
> merged-usr with people that have not read what Roger said in his
> email. And apparently you haven't, so the thread ends here.


  I did read it, in full.  It does not concern desktop installations,
only datacenter and clustered installs.

  He wrote: "This is one of the major factors why I would question the
use of esoteric methods of partitioning and booting the system."

  Esoteric?  Esoteric something that's been done for 40 years in most
Unixes and in all GNU/Linux distros since 1991?

  C'm on, stop kidding me!



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Stephan Seitz]

On Fr, Nov 23, 2018 at 01:09:17 +0100, Alessandro Selli wrote:

  I do get the reasons the merge proponents prefer this filesystem
layout.  What I rant against is their choices being imposed on me.


They are not imposed on you. No one is going to your desktop/server and 
is changing your disc layout.



  While I did not state this claim, I thought desktop use was one of the
targets Devuan would try to accomodate.  If this is not the case then I
think I'd better go search some desktop-friendly distribution.


Sorry, you’re funny. A desktop-friendly distribution is certainly not 
a distribution which will ask you about your partition layout and 
filesystem choices because the majority of people who want to use 
a desktop-friendly distribution is not interested in these details. They 
want very few questions and working desktop after the installation.


This is probably one of the reason why people who want to do their own 
partition setup are not using desktop-friendly distributions…


You are the first desktop user I have met who insists on having his own 
layout.



  This is my precisely my point: trumping desktop users' needs (or just
freedom of customization and choice)  because of cluster ease-of-use
considerations make the distribution *not* universal.  If Devuan is


Of course it is still universal, or does your desktop (whatever you use) 
stop working after a /usr-merge? No one removes fvwm, xfce, kde, or the 
X server.


And as Roger has tried to tell you every freedom of customization and 
choice you want is work that has to be done by someone. More choices 
means you need more testing.


Since Devuan and Debian are build by volunteers they will do what they 
want to do. If no one is interested in keeping the choices they will fade 
away. Will you step forward and work to keep the choices?


I don’t know about distribution statistics but in the usr-merge thread 
(debian-devel) it was mentioned that in future distributions are more 
a source to build containers and are less and less used directly. And 
that they have lost users who found Debian not modern enough.


I don’t know the future but a distribution can’t wait too long to choose 
its direction.



  Yes, we are.  Debian apparently is no longer going to be.  And again I


Bullshit, that isn’t decided yet. And for now it would seem that the 
decision for a forced usr-merge is postponed. It can be that they’ll do 
it like the migration from /usr/doc to /usr/share/doc: slowly moving 
files from / to /usr until / has only symlinks.



was listed the many good reasons the merge is good for the datacenter as
an answer to my question: "Why must I be denied the possibility to do
otherwise?".


Again, are you doing the work for your setup you care so much?


  So, regardless from what's best to the datacenter, can I be allowed to
follow the 40 years long path and keep having a /usr split from /?
  Yes && I stay || I leave.


The choice will probably stay as long as the work to keep it won’t be too 
much work for the volunteers.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Fri, Nov 23, 2018 at 01:09:17PM +0100, Alessandro Selli wrote:

[cut]

> 
> 
> >  Devuan is currently used in a mutlitude of
> > environments that include server farms, corporate and personal
> > servers, embedded systems, personal devices, and desktops. So any
> > choice Devuan will make has to take into account *all* the different
> > uses of Devuan.
> >
> > We are going to provide the users with the choice of having or not
> > having a merged-usr.
> 
> 
>   Yes, we are.  Debian apparently is no longer going to be.  And again I
> was listed the many good reasons the merge is good for the datacenter as
> an answer to my question: "Why must I be denied the possibility to do
> otherwise?".
>

You continue not reading and not understanding. Who is denying you the
possibility to do otherwise? Surely not Devuan, which is still
offering you a choice. You are welcome.

Is Debian you are angry with? Then please go explain your reasons to
them, since your rant here is *totally* *out* *of* *scope*.

>   Plus the many-times repeated BS of: "The / - /usr split is silly",

I won't discuss anything about the technical motivations behind
merged-usr with people that have not read what Roger said in his
email. And apparently you haven't, so the thread ends here.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 23/11/18 at 06:26, KatolaZ wrote:
> On Thu, Nov 22, 2018 at 11:24:05PM +0100, Alessandro Selli wrote:
>> On 22/11/18 at 19:21, Roger Leigh wrote:
>>> On 21/11/2018 16:11, Alessandro Selli wrote:
 On 21/11/18 at 13:17, Roger Leigh wrote:
> Hi folks,
>
> I've been following the discussion with interest.

    No, you definitely have not followed it.  In fact you are
 disregarding
 all the points that were expressed against the merge.
>>> Let me begin by stating that I found your reply (and others) to be
>>> rude, unnecessarily aggressive, and lacking in well-reasoned objective
>>> argument.
>>
>>   Oh poor show flake, did I hurt your tender feelings when I state facts?
>>
>>
> Alessandro, you are not funny at all.


  I admit I did not intend to be.


>  Roger is one of the DDs who
> stood the systemd avalanche in Debian, and the first one to publicly
> support Devuan (please read https://devuan.org/os/debian-fork/ to see
> what I mean).


  All right, thanks be to him for this.


> Roger took the time and effort to provide a first-hand explanation
> about the whats and whys behind early boot incantations.


  I do get the reasons the merge proponents prefer this filesystem
layout.  What I rant against is their choices being imposed on me.


>  And his
> insight in this respect is precious and fundamental. I appreciate that
> not everybody might be interested in these details, but this thread is
> *exactly* about that, not about your own personal experience with this
> or that setup. 
>
> On a related point: no, Alessandro, Devuan is not a Desktop-oriented
> distribution.


  While I did not state this claim, I thought desktop use was one of the
targets Devuan would try to accomodate.  If this is not the case then I
think I'd better go search some desktop-friendly distribution.


>  Devuan strives to remain as a universal operating system
> as Debian claims to be.


  This is my precisely my point: trumping desktop users' needs (or just
freedom of customization and choice)  because of cluster ease-of-use
considerations make the distribution *not* universal.  If Devuan is
going to ignore the former users, if Devuan too is going to be a
datacenter distribution like Red Hat is and Debian is becoming, fine,
you have a right to do so.  I'll move on.


  i state one more:

    I'm not trying to impose my views, considerations and preferences on
others, I'm trying to protect the freedom I've had so far to customize
*my* GNU/Linux installations the way I deem fit, that they are to be
primarilly used as servers, workstations, routers or emergency/rescue
systems.  I want the freedom to customize the install to the most
radical way, not to prevent others from doing what they want to *their*
systems.  For this reason it's useless that people keep listing the
benefits of a merged / -> /usr for datacenter clusters to justify the
Technical Committee's decisions, I don't care what the datacenter guys
do to their systems, I'm fine with them merging / -> /usr, as well as
splitting /etc from / ro whatever.  I don't care so solng as *their*
choices and customizations do not turn out to adversely affect *my*
customizations and alternative (though decades-long proven) layouts. 
Because preventing me from dong what I have been doing since the late
'90s, and what has been done in many Unixes since the '70s is *not*
providing a Universal OS.


  Is this clear enough?


  In fewer words:


  Dear Debian TC, merge or split what the hell you want in the
datacenter, but keep you hands off *my* desktop/server installations.


>  Devuan is currently used in a mutlitude of
> environments that include server farms, corporate and personal
> servers, embedded systems, personal devices, and desktops. So any
> choice Devuan will make has to take into account *all* the different
> uses of Devuan.
>
> We are going to provide the users with the choice of having or not
> having a merged-usr.


  Yes, we are.  Debian apparently is no longer going to be.  And again I
was listed the many good reasons the merge is good for the datacenter as
an answer to my question: "Why must I be denied the possibility to do
otherwise?".

  Plus the many-times repeated BS of: "The / - /usr split is silly",
"it's a leftover of a distant and bad past", "there's no reason to do
it", "storage devices today are big, so why bother?", "you do not gain
anything setting /usr ro" while they keep ignoring whatever I write: ro
is just one of the many mount options that I set different from the /usr
and / filesystems, ro does add security, a merged / -> /usr does make my
non-clustered, non-datacenter installs more difficult to manage and
rescue and backup and less flexible.


  So, regardless from what's best to the datacenter, can I be allowed to
follow the 40 years long path and keep having a /usr split from /?



  Yes && I stay || I leave.



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and 

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 22/11/2018 à 21:55, Alessandro Selli a écrit :

On 22/11/18 at 16:25, Didier Kryn wrote:

Le 22/11/2018 à 13:25, Alessandro Selli a écrit :

chown -R a-w /bin
chown -R a-w /sbin
chown -R a-w /lib

     Sorry, I meant chmod.

     Mounting read-only isn't more secure than marking a directory
read-only. root can change it anytime in a single command.


    Do you think root cannot change anytime file's permissions on the
filesystem?

   Of course it adds security to the system, because if the filesystem
was mounted ro root HAS to remount it rw in order to be able to do
changes on the filesystem.  Should you only change file's permissions
you have NOT protected anything, because I inform you, on any Unix,
since the dawn of Unix time, ROOT CAN DO WHAT IT WANTS REGARDLESS OF
FILE PERMISSIONS!

   Didn't you know this?  Whom am I debating with, a Windows sysadmin, a
full time Valve gamer, a systemd developer?

   You are again blockheadedly ignoring the fact that read-only is *NOT*
the only setting that make sense changing on the /usr filesystem!  There
are several, and I already *twice* listed a few of them: nobarrier,
noatime, iversion, nodev, etc etc.


   Do you know so little of filesystem management or are you trolling?

    Plonk.

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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Thu, Nov 22, 2018 at 11:24:05PM +0100, Alessandro Selli wrote:
> On 22/11/18 at 19:21, Roger Leigh wrote:
> > On 21/11/2018 16:11, Alessandro Selli wrote:
> >> On 21/11/18 at 13:17, Roger Leigh wrote:
> >>> Hi folks,
> >>>
> >>> I've been following the discussion with interest.
> >>
> >>
> >>    No, you definitely have not followed it.  In fact you are
> >> disregarding
> >> all the points that were expressed against the merge.
> >
> > Let me begin by stating that I found your reply (and others) to be
> > rude, unnecessarily aggressive, and lacking in well-reasoned objective
> > argument.
> 
> 
>   Oh poor show flake, did I hurt your tender feelings when I state facts?
> 
> 

Alessandro, you are not funny at all. Roger is one of the DDs who
stood the systemd avalanche in Debian, and the first one to publicly
support Devuan (please read https://devuan.org/os/debian-fork/ to see
what I mean).

Roger took the time and effort to provide a first-hand explanation
about the whats and whys behind early boot incantations. And his
insight in this respect is precious and fundamental. I appreciate that
not everybody might be interested in these details, but this thread is
*exactly* about that, not about your own personal experience with this
or that setup. 

On a related point: no, Alessandro, Devuan is not a Desktop-oriented
distribution. Devuan strives to remain as a universal operating system
as Debian claims to be. Devuan is currently used in a mutlitude of
environments that include server farms, corporate and personal
servers, embedded systems, personal devices, and desktops. So any
choice Devuan will make has to take into account *all* the different
uses of Devuan.

We are going to provide the users with the choice of having or not
having a merged-usr. This serves best the purpose of Devuan, and its
commitment to guarantee as much freedom as possible to the people who
decide to use Devuan. Those who think Devuan is not fit for their
purpose have still the freedom to either contribute to Devuan and make
it "better" (for whatever definition of "better") or to choose among a
variety of other distributions.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 22/11/18 at 22:31, Martin Steigerwald wrote:
> barrier related mount options are deprecated, well even removed at least 
> for XFS, deprecated in 4.10 and and removed in 4.19¹. Write barriers 
> have been replaced by explicit cache flushes² (somewhere around 2.6.39… 
> I am too lazy to look it up in my Linux Performance tuning and analysis 
> training slides right now).


  To bad I can't take advantage of them because of this:

[    1.031094] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA

>  But with kernels still supporting the mount 
> option, nobarrier or barrier=0 would have been simply dangerous for data 
> integrity unless you have made sure that no sudden write interruption by 
> for example power loss can happen.


  I use them on battery-backed systems.


  Bye,




-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 22/11/18 at 19:21, Roger Leigh wrote:
> On 21/11/2018 16:11, Alessandro Selli wrote:
>> On 21/11/18 at 13:17, Roger Leigh wrote:
>>> Hi folks,
>>>
>>> I've been following the discussion with interest.
>>
>>
>>    No, you definitely have not followed it.  In fact you are
>> disregarding
>> all the points that were expressed against the merge.
>
> Let me begin by stating that I found your reply (and others) to be
> rude, unnecessarily aggressive, and lacking in well-reasoned objective
> argument.


  Oh poor show flake, did I hurt your tender feelings when I state facts?


[...]


  Again I express something so simple I'm really beginning to lose my mind:


  I do not intend to deprive anyone with the freedom to merge /usr to /,
damn it!

  I want to preserve *MY* freedom of choice, I want to be able to split
from / anything that is not required on *MY* systems or that will never
be required on any system (Java, Apache, Squid, Xorg, LibreOffice etc).

  I am not fighting against people who want to introduce different
filesystem layouts because of their special needs, I WANT THEM TO STOP
FORCING THEIR DESIGN CHANGES TO ME FOR NO OTHER REASON THAT TO THEIR
SYSTEMS THEIR LAYOUT MAKES MORE SENSE!


  Is it clear enough now?


  I hope so.


>> 1) mounting /usr with different mount options (like barrier, ro,
>> nodev etc); 
>
> Could you describe the specific goals of the separation? 


  Damn it, again?  Re-read the thread yourself, it's going to take you
less time than it must have taken writing 58 lines, 1458 words and 8565
characters of text to justify the necessity of a / -> /usr merge.


[...]


> think about the specific problems which you are really trying to
> solve, rather than tying the solution to this specific mountpoint.

  What? Did you read the Subject line at least?  All this discussion is
centered on "this specific mountpoint"!


> Most of / should be ro+nodev just like for /usr.

  Yeah.  Only, / can't be, but /usr can be.


> So one deeper question is which bits of / shouldn't be ro/nodev? 
> /etc?  /var?

Everything except /dev, of course.


> Maybe it should be between / and /etc and /var?  Others?
Are you kidding?  How could you split /etc and /var from /?  Are you
really saying that keeping /usr split from / makes no sense because you
can't split /var and /etc from /?


> I should point out that I wrote a set of patches for mounting /etc in
> the initramfs as well as /usr, specifically so that you could do this.

First you stated that having a separate /usr is to be avoided because
it's too troublesome and unmanageable, now you say you split even /etc
from /?

Great!  I'm overjoyed!  Since you could do something even more
difficult, that no Unix system did before TIKO, could I ask you to
please do me a favour?

Will you keep /usr splittable from /, as it's been the case for decades
even before Linux existed?


>> 2) having /usr mounted over the network keeping / local; 
> While the initramfs does support both local / and remote /usr (by *my
> own design and intent*), this is purely to avoid breakage on upgrades.
> It's not a recommended setup.
What does not "recommended" entail?

Is moving /home to /var/Drake/shared recommended?  I don't think so. 
Should this be made impossible then?

And is so why?


> All the cluster nodes
Here we have it again: the changes that are being pushed have clusters
as their reference system.

But I mostly use GNU/Linux as a desktop system.  If Debian is going to
follow the Red Hat path, that is design their system tailored just for
the Big Data Centers (BDC) needs precluding most desktop customizations,
fine, it's their right.  I will stay clear of it and will chose other
distros that have commoners and their laptops as the typical target.


> The content of that /usr filesystem is under the control of *one* dpkg
> package database on a single system.  If *any* of the other systems
> install or remove any package touching /usr (which is all of them!),
> they will be corrupting the installation.
This only has sense for cluster installs, not desktop ones.  If what
you're writing means: "Debian from now on will only cater to the needs
of BDCs, local desktop customizations will be ignored" well, I'm fine
with it.  I'll just not go back to Debian, as I do not run a BDC home or
on my portable devices.

Anyway, syncing updates of shared filesystems can be done with shared
mounts.  I thought to do some experiments with it some time ago, but
then didn't.  The relevant documentation is in
Documentation/filesystems/sharedsubtree.txt .  It should be enough to do
this:


# mount --make-shared /

# mount nfs_server:/storage/shared_root /mnt/root

# mount --bind / /mnt/root

# mount /dev/sda5 /usr


  If I am correct, now both / and /usr should be visible under
/mnt/root.  This way a local update should be propagated to the NFS
filesystem.


> Even mounting it read-only is giving you an incomplete view of the
> installed packages' contents. 

Why is that?

Did I already 

Re: [DNG] /usr to merge or not to merge... that is the question

[golinux]

On 2018-11-22 14:55, Alessandro Selli wrote:

On 22/11/18 at 16:25, Didier Kryn wrote:

Le 22/11/2018 à 13:25, Alessandro Selli a écrit :

chown -R a-w /bin
chown -R a-w /sbin
chown -R a-w /lib


    Sorry, I meant chmod.

    Mounting read-only isn't more secure than marking a directory
read-only. root can change it anytime in a single command.



   Do you think root cannot change anytime file's permissions on the
filesystem?

  Of course it adds security to the system, because if the filesystem
was mounted ro root HAS to remount it rw in order to be able to do
changes on the filesystem.  Should you only change file's permissions
you have NOT protected anything, because I inform you, on any Unix,
since the dawn of Unix time, ROOT CAN DO WHAT IT WANTS REGARDLESS OF
FILE PERMISSIONS!

  Didn't you know this?  Whom am I debating with, a Windows sysadmin, a
full time Valve gamer, a systemd developer?

  You are again blockheadedly ignoring the fact that read-only is *NOT*
the only setting that make sense changing on the /usr filesystem!  
There

are several, and I already *twice* listed a few of them: nobarrier,
noatime, iversion, nodev, etc etc.


  Do you know so little of filesystem management or are you trolling?



It seems you missed this good advice from Roger Leigh:

"Let me begin by stating that I found your reply (and others) to be 
rude, unnecessarily aggressive, and lacking in well-reasoned objective 
argument.  It's poor communication like this which caused me to 
unsubscribe from the Debian lists, and also to this list a good while 
back (I only read the digest summary on occasion, and rarely 
participate).  I find it fosters an unfriendly, unpleasant and 
unproductive environment which I don't enjoy working in.  When you're 
doing this type of work as a part-time volunteer, it's extremely 
demotivating and disheartening to be treated this way.  It would be 
unacceptable in a professional setting, and it's equally unacceptable 
here.  Please do think about what you have written before sending it; it 
costs nothing to be nice, even when you are in disagreement with 
someone."


PThere is no need to be rude and insulting (often repeatedly).  That 
goes for everyone of us.


golinux








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

Re: [DNG] /usr to merge or not to merge... that is the question

[Martin Steigerwald]

[… personal attacks against Didier omitted …]

I recommend to go back to basic netiquette. Attacking others in person 
is not going to help anyone, nor does it add to a friendly community 
around Devuan.

Alessandro Selli - 22.11.18, 21:55:
>   You are again blockheadedly ignoring the fact that read-only is
> *NOT* the only setting that make sense changing on the /usr
> filesystem!  There are several, and I already *twice* listed a few of
> them: nobarrier, noatime, iversion, nodev, etc etc.

barrier related mount options are deprecated, well even removed at least 
for XFS, deprecated in 4.10 and and removed in 4.19¹. Write barriers 
have been replaced by explicit cache flushes² (somewhere around 2.6.39… 
I am too lazy to look it up in my Linux Performance tuning and analysis 
training slides right now). But with kernels still supporting the mount 
option, nobarrier or barrier=0 would have been simply dangerous for data 
integrity unless you have made sure that no sudden write interruption by 
for example power loss can happen. Cause it would cause journaling 
filesystems to be unable to met strict write ordering demands that are 
required for journaling to actually work reliably. By doing so, you 
could basically also run Ext4 without journal at all, in order to 
optimize performance. There are use cases for that, but if you 
appreciate your filesystem integrity even in a case of power loss… I'd 
recommend not doing so.

[1] xfs: remove deprecated barrier/nobarrier mount options
https://patchwork.kernel.org/patch/10487561/

[2] Jonathin Corbet,The end of block barriers:
https://lwn.net/Articles/400541/

Ciao,
-- 
Martin


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 22/11/18 at 16:28, Didier Kryn wrote:
> Le 22/11/2018 à 13:42, terryc a écrit :
>> IME, absolutely nothing in real life works that way.
>> Do you dump all your clothes into one big bin or store them by say
>> type?
>
>     Files are stored in different directories, that's it for clean
> bookkeeping.


  So, you are in favour of retaining a slit / and /usr layout?  Good.

  What does it change if some have /usr mounted on a different device
compared to /?


> Making these directories mountpoint does not add any sort of ordering.


  Merging /usr to / does indeed take away ordering.


> Only the impression they are more secure.


  Different mount options do increase the system's overall security
*and*  they increase flexibility in other areas (like performance and
resiliency).


> My opinion is that impression is only an impression. Am I allowed to
> express my opinion without causing flames?


  In principle you are, but I do flame when I have to repeat for the
2^64th time reasons to have / split from / while the person I speak to
keep ignoring those points and repeating inconsequential matters that
either do not apply or are plain wrong.


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 22/11/18 at 16:25, Didier Kryn wrote:
> Le 22/11/2018 à 13:25, Alessandro Selli a écrit :
>> chown -R a-w /bin
>> chown -R a-w /sbin
>> chown -R a-w /lib
>
>     Sorry, I meant chmod.
>
>     Mounting read-only isn't more secure than marking a directory
> read-only. root can change it anytime in a single command.


   Do you think root cannot change anytime file's permissions on the
filesystem?

  Of course it adds security to the system, because if the filesystem
was mounted ro root HAS to remount it rw in order to be able to do
changes on the filesystem.  Should you only change file's permissions
you have NOT protected anything, because I inform you, on any Unix,
since the dawn of Unix time, ROOT CAN DO WHAT IT WANTS REGARDLESS OF
FILE PERMISSIONS!

  Didn't you know this?  Whom am I debating with, a Windows sysadmin, a
full time Valve gamer, a systemd developer?

  You are again blockheadedly ignoring the fact that read-only is *NOT*
the only setting that make sense changing on the /usr filesystem!  There
are several, and I already *twice* listed a few of them: nobarrier,
noatime, iversion, nodev, etc etc.


  Do you know so little of filesystem management or are you trolling?



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Thu, Nov 22, 2018 at 06:21:01PM +, Roger Leigh wrote:
> On 21/11/2018 16:11, Alessandro Selli wrote:
> > On 21/11/18 at 13:17, Roger Leigh wrote:
> > > Hi folks,
> > > 
> > > I've been following the discussion with interest.
> > 
> > 
> >    No, you definitely have not followed it.  In fact you are disregarding
> > all the points that were expressed against the merge.
> 
> Let me begin by stating that I found your reply (and others) to be rude,
> unnecessarily aggressive, and lacking in well-reasoned objective argument.
> It's poor communication like this which caused me to unsubscribe from the
> Debian lists, and also to this list a good while back (I only read the
> digest summary on occasion, and rarely participate).  I find it fosters an
> unfriendly, unpleasant and unproductive environment which I don't enjoy
> working in.  When you're doing this type of work as a part-time volunteer,
> it's extremely demotivating and disheartening to be treated this way.  It
> would be unacceptable in a professional setting, and it's equally
> unacceptable here.  Please do think about what you have written before
> sending it; it costs nothing to be nice, even when you are in disagreement
> with someone.
> 
> 
> Before I follow up on any of the points you (and others) made in response,
> let me begin with some history you may be unaware of.  It actually predates
> systemd, and is largely unrelated to systemd.
> 

Dear Roger,

I wholehartedly thank you for your post. It has shown clearly how
little most of us (and I put myself in the lot) know about the whole
history and functioning of the stuff we use everyday.

This is exactly the kind of technical depth I was asking for in this
list a couple of days ago, and I am happy it eventually came from you.
My "research" in this direction (reviewing early-boot code and
changelogs and delving through several mailing lists) had not gotten
any close to the amount of information, context, knowledge and
motivations you provided in a single email.

I guess anybody willing to add even a comment to this thread must be
sure to have read, digested, understood, and internalised all the
content in Roger's email first.

And please do not forget his gentle but strong nudge regarding being
nice to other people, also and especially when you disagree with them.

ThankYou

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Roger Leigh]

On 21/11/2018 16:11, Alessandro Selli wrote:

On 21/11/18 at 13:17, Roger Leigh wrote:

Hi folks,

I've been following the discussion with interest.



   No, you definitely have not followed it.  In fact you are disregarding
all the points that were expressed against the merge.


Let me begin by stating that I found your reply (and others) to be rude, 
unnecessarily aggressive, and lacking in well-reasoned objective 
argument.  It's poor communication like this which caused me to 
unsubscribe from the Debian lists, and also to this list a good while 
back (I only read the digest summary on occasion, and rarely 
participate).  I find it fosters an unfriendly, unpleasant and 
unproductive environment which I don't enjoy working in.  When you're 
doing this type of work as a part-time volunteer, it's extremely 
demotivating and disheartening to be treated this way.  It would be 
unacceptable in a professional setting, and it's equally unacceptable 
here.  Please do think about what you have written before sending it; it 
costs nothing to be nice, even when you are in disagreement with someone.



Before I follow up on any of the points you (and others) made in 
response, let me begin with some history you may be unaware of.  It 
actually predates systemd, and is largely unrelated to systemd.



6-7 years ago, back when I was one of the Debian sysvinit maintainers, 
we had a problem.  The problem was that an increasing number of systems 
could no longer be booted up successfully.  The reason for this was that 
the boot process was becoming increasingly complex.  The process could 
be summarised like this with an initramfs:


  - mount / in initramfs
  - [early boot]
  - mount /usr and other filesystems
  - [late boot]

or directly, without an initramfs

  - mount /
  - [early boot]
  - mount /usr and other filesystems
  - [late boot]

The problems arose from the mounting of /usr part way through the boot 
process.  An increasing number of system configurations required tools 
and libraries from /usr, before it was mounted.  These could be NSS 
modules, LDAP stuff, dependencies of network filesystem tools, or 
others.  In some cases, this was solved by moving individual tools and 
libraries from /usr to /[s]bin and /lib.  But this became increasingly 
untenable as the requirements became more and more complex.  Not only 
did we have to move individual tools and libraries and datafiles from 
/usr to the root filesystem, we also had to move every dependency as 
well for them to be functional.  Also, service dependencies wanted 
services starting before /usr was mounted, moving chunks of the 
dependency graph into the early boot stage.  This was a losing battle, 
since we couldn't move /everything/ to the root filesystem.  Or could we?


It was due to logistical challenges like this that we first considered 
the merge of / and /usr.  Once low-level tools start requiring 
interpreters like Perl or Python, or libraries like libstdc++, or 
datafiles like timezone data, it was clear we needed a more general 
solution which would solve the problems for the long term.


The question arose of how we might handle the migration, or avoid the 
need for a migration entirely.  As the sysvinit maintainer, I did most 
of the investigation and implementation of this work, and you're likely 
using that solution right now yourself.  The solution I chose was one 
which would allow for making /usr available in early boot without the 
need for physically merging the filesystems, so that it wouldn't break 
any of the installed systems on upgrade.  We would add to the initramfs 
the ability to mount additional filesystems other than the rootfs, 
directly from the rootfs fstab.  And we would cater for local and NFS 
filesystems just as we do for the rootfs.  This was one of the more 
costly solutions (in terms of implementation complexity and testing 
needed), but it retained the flexibility some people required.  This was 
implemented 5 years back, and the result is this with an initramfs:


  - mount / and /usr in initramfs
  - [early boot]
  - mount other filesystems
  - [late boot]

or directly, without an initramfs:

  - mount /
  - [early boot]
  - mount other filesystems
  - [late boot]

Thus we could guarantee the availability of files in /usr from the 
moment the system starts, and is independent of all init systems.


The tradeoff is that we no longer supported direct booting of a system 
with a separate /usr; you had to use an initramfs.  You could still boot 
directly, but / and /usr had to be on the same filesystem to guarantee 
the availability of /usr.  But with this solution in place, all stages 
of the boot could rely on tools, libraries and datafiles present in /usr.


This has been in production use since wheezy, and because it was so 
transparent, very few people would even realise that the filesystems had 
been (effectively) unified since then, because I took great care to 
support (and test) every possible 

Re: [DNG] /usr to merge or not to merge... that is the question

[KatolaZ]

On Thu, Nov 22, 2018 at 04:28:55PM +0100, Didier Kryn wrote:
> Le 22/11/2018 à 13:42, terryc a écrit :
> > IME, absolutely nothing in real life works that way.
> > Do you dump all your clothes into one big bin or store them by say
> > type?
> 
>     Files are stored in different directories, that's it for clean
> bookkeeping. Making these directories mountpoint does not add any sort of
> ordering. Only the impression they are more secure. My opinion is that
> impression is only an impression. Am I allowed to express my opinion without
> causing flames?
> 

Sure you are, Didier, as is anybody else, and we should all strive for
this to remain the norm here :)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 22/11/2018 à 13:42, terryc a écrit :

IME, absolutely nothing in real life works that way.
Do you dump all your clothes into one big bin or store them by say
type?


    Files are stored in different directories, that's it for clean 
bookkeeping. Making these directories mountpoint does not add any sort 
of ordering. Only the impression they are more secure. My opinion is 
that impression is only an impression. Am I allowed to express my 
opinion without causing flames?


        Didier


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Didier Kryn]

Le 22/11/2018 à 13:25, Alessandro Selli a écrit :

chown -R a-w /bin
chown -R a-w /sbin
chown -R a-w /lib


    Sorry, I meant chmod.

    Mounting read-only isn't more secure than marking a directory 
read-only. root can change it anytime in a single command.


    Didier


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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 22/11/18 at 13:25, Alessandro Selli wrote:
>   Wrong.  Split / and /usr Unix systems have been around for decades and
> they have been upgradable.  Your "solution" instead:
>
> chown -R a-w /bin
> chown -R a-w /sbin
> chown -R a-w /lib
>
>
> would make them not.


  I am wrong here, as upgrades are performed as root to whom regular
read/write file permissions do not apply.  What I had in my mind was
what I actually use to protect public files in front-line servers, i.e.
running chattr +i on them.

  Still everything else does apply, mount options do much more than
preventing file modification, and I urge you to get a grasp of that
before you continue this debate.




-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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

Re: [DNG] /usr to merge or not to merge... that is the question

[Alessandro Selli]

On 22/11/18 at 13:42, terryc wrote:
> On Thu, 22 Nov 2018 10:10:20 +0100
> Didier Kryn  wrote:
>  But
>> the part of the OS (which is managed by dpkg) better stays on one
>> single partition. 
> IME, absolutely nothing in real life works that way.
> Do you dump all your clothes into one big bin or store them by say
> type?
> Do you store all your house fitments in one big bin, or store in many
> "partitions". I find it so annoying having to retrieve clean cups from
> under a pile of screws, bolts, light globes, etc.
>
> Sub-division of stuff is logical and leads to efficency and the same
> applies to computer OSs.


  +1

  



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




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