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

[Daniel Reurich]

Hi Devuan followers, fans and friends,

Debian as of the upcoming Buster release looks to be implementing a
merged /usr by default.  At this stage there is no plan to make it
forced... but you never know what happens when their Technical Committee
 suddenly decides it's an issue they need to force a decision on...

So... for Devuan, do we want to default to a merged /usr in our coming
release of Beowulf or are we going to resist another pointless
rearranging of the deck chairs...

Keen to get some feedback on this

Cheers,
Daniel
-- 
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



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??

[Rowland Penny]

On Fri, 16 Nov 2018 22:11:17 +1300
Daniel Reurich  wrote:

> Hi Devuan followers, fans and friends,
> 
> Debian as of the upcoming Buster release looks to be implementing a
> merged /usr by default.  At this stage there is no plan to make it
> forced... but you never know what happens when their Technical
> Committee suddenly decides it's an issue they need to force a
> decision on...
> 
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...
> 
> Keen to get some feedback on this
> 
> Cheers,
>   Daniel

Can anybody explain the bad points of doing the merger ?
I ask this because everything I can find says it is a good thing, but
they said systemd was a good thing ;-)

Rowland
___
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 Fri, 16 Nov 2018 22:11:17 +1300
Daniel Reurich  wrote:

> Hi Devuan followers, fans and friends,
> 
> Debian as of the upcoming Buster release looks to be implementing a
> merged /usr by default.  At this stage there is no plan to make it
> forced... but you never know what happens when their Technical
> Committee suddenly decides it's an issue they need to force a
> decision on...
> 
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...
> 
> Keen to get some feedback on this

Back in the what, 1970's, the Unix guys
split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
by separating out statically compiled stuff used in the earliest boot.
But then initramfs made these separate directories unnecessary, so why
in the world would we continue the split?

Well, maybe because initramfs is a PITA many people choose to avoid.
When things go wrong, it's the ultimate black box. And I'm very scared
that one day Poettering/Redhat/Freedesktop.org will corner the market
on initramfs makers, will make them systemd only, sans-systemd distros
who have completed the merge will have the choice of backing out the
merge or going to systemd.

Initramfs (or initrd before it) is the ultimate black box. You can't
get your normal voltmeter probes in there: You need to use special
stuff that's hard to use. You can init the hard disk with /bin/bash,
but not the initramfs. Oh, and not even the /bin/bash if the merge
happens.

Here's some info on dracut, the most prevalent initramfs maker:

https://www.techradar.com/news/software/operating-systems/what-on-earth-is-dracut-1078647

Oooh,  notice they say dracut is "based on udev events". If you're
avoiding systemd,  and Redhat has taken over udev, what could
*possibly* go wrong?

Here's some recommended reading on "the merge":

https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

The gist of the preceding links is "hey, other programs conflate early
with late boot programs, so don't blame us for doing it too. Oh, and by
the way, most of those conflaters, like udev, are under our control.
Conflation is another form of entanglement, but don't blame us."

For those using ext4, assuming a kernel with ext4 compiled in, without
need for root disk lvm, encryption, and raid, the init system can
immediately use the static executables in /sbin to mount necessary
disks and then go about the rest of the boot.

Systemd loves to brag about their boot time, but on a system with ext4
drivers compiled into the kernel, a separate /sbin guaranteed on the
root partition, and minimal use of udev in the boot (you *could* run it
as a daemon, in parallel, using runit), boots would be quick indeed.
Switch-root, killall5, and all the other stuff done before disks begin
to mount, goes away.

I vote against "the merge".
 
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??

[Rowland Penny]

On Fri, 16 Nov 2018 05:11:01 -0500
Steve Litt  wrote:

> On Fri, 16 Nov 2018 22:11:17 +1300
> Daniel Reurich  wrote:
> 
> > Hi Devuan followers, fans and friends,
> > 
> > Debian as of the upcoming Buster release looks to be implementing a
> > merged /usr by default.  At this stage there is no plan to make it
> > forced... but you never know what happens when their Technical
> > Committee suddenly decides it's an issue they need to force a
> > decision on...
> > 
> > So... for Devuan, do we want to default to a merged /usr in our
> > coming release of Beowulf or are we going to resist another
> > pointless rearranging of the deck chairs...
> > 
> > Keen to get some feedback on this
> 
> Back in the what, 1970's, the Unix guys
> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
> by separating out statically compiled stuff used in the earliest boot.
> But then initramfs made these separate directories unnecessary, so why
> in the world would we continue the split?
> 
> Well, maybe because initramfs is a PITA many people choose to avoid.
> When things go wrong, it's the ultimate black box. And I'm very scared
> that one day Poettering/Redhat/Freedesktop.org will corner the market
> on initramfs makers, will make them systemd only, sans-systemd distros
> who have completed the merge will have the choice of backing out the
> merge or going to systemd.
> 
> Initramfs (or initrd before it) is the ultimate black box. You can't
> get your normal voltmeter probes in there: You need to use special
> stuff that's hard to use. You can init the hard disk with /bin/bash,
> but not the initramfs. Oh, and not even the /bin/bash if the merge
> happens.
> 
> Here's some info on dracut, the most prevalent initramfs maker:
> 
> https://www.techradar.com/news/software/operating-systems/what-on-earth-is-dracut-1078647
> 
> Oooh,  notice they say dracut is "based on udev events". If you're
> avoiding systemd,  and Redhat has taken over udev, what could
> *possibly* go wrong?
> 
> Here's some recommended reading on "the merge":
> 
> https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/
> 
> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/
> 
> The gist of the preceding links is "hey, other programs conflate early
> with late boot programs, so don't blame us for doing it too. Oh, and
> by the way, most of those conflaters, like udev, are under our
> control. Conflation is another form of entanglement, but don't blame
> us."
> 
> For those using ext4, assuming a kernel with ext4 compiled in, without
> need for root disk lvm, encryption, and raid, the init system can
> immediately use the static executables in /sbin to mount necessary
> disks and then go about the rest of the boot.
> 
> Systemd loves to brag about their boot time, but on a system with ext4
> drivers compiled into the kernel, a separate /sbin guaranteed on the
> root partition, and minimal use of udev in the boot (you *could* run
> it as a daemon, in parallel, using runit), boots would be quick
> indeed. Switch-root, killall5, and all the other stuff done before
> disks begin to mount, goes away.
> 
> I vote against "the merge".
>  
> SteveT
> 

So, after reading Steve's enlightening description, I am with him, the
merge is only needed by systemd and seems to be a way of forcing it on
everybody, so I am against it.

Rowland

___
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??

[Irrwahn]

Daniel Reurich wrote on 16.11.18 10:11:
[...]
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...
> 
> Keen to get some feedback on this
[...]

I cast my vote in favor of making merged /usr the default.

My reasoning behind this is as follows (disclaimer: rant mode = medium):

The practice of storing system files in a secondary hierarchy below
/usr was born out of disk space constraints on hardware that has been
obsoleted many, many decades ago. It is and has always been an ill
conceived kludge that somehow managed to cross the times and still be
present on some Unix-like operating systems.

The artificial separation of system files into the "essential" and
"non-essential" categories has always been a vague and arbitrary one,
and in the Debian case is botched since at least Wheezy, effectively
rendering the endeavor of making /usr a mount point for a separate disk
partition a nontrivial task (think initramfs).

The fact that split /usr has been abused to craft pathologic setups
like network mounted /usr volumes shared across multiple installations
is a moot point. This practice is demonstrably a recipe for disaster
when used for anything but fun experiments on non-critical toy
installations or as a demonstration piece on how to /not/ design a
reliable system.

Split /usr is an abomination that should have been put to rest long ago,
only to be referred to as quirky anecdote in some obscure footnote.
Merging /usr back is a small step on the long way to restore the FSH to
what it was meant to be.

(rant off)

TL;DR:
The Unix file system hierarchy is a mess. A merged /usr subtree brings
back a tiny little bit of sanity. Thus I vote for it to be the default
for new Devuan installations.

Best regards,
Urban


-- 
Sapere aude!



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 Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote:

[cut]

> 
> So, after reading Steve's enlightening description, I am with him, the
> merge is only needed by systemd and seems to be a way of forcing it on
> everybody, so I am against it.
> 

It would be actually more productive to base this discussion on solid
technical arguments. I have no opinion on the matter at the moment,
since I have done very little research on it, and I will try to
understand what's the technical side of it before judging on the basis
of a gut feeling. 

I guess it would be more useful if we could all do owr own research
and construct an informed opinion before participating to this
thread. This is what I will do.

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??

[Irrwahn]

Steve Litt wrote on 16.11.18 11:11:
> On Fri, 16 Nov 2018 22:11:17 +1300
> Daniel Reurich  wrote:
[...]
>> So... for Devuan, do we want to default to a merged /usr in our coming
>> release of Beowulf or are we going to resist another pointless
>> rearranging of the deck chairs...
>>
>> Keen to get some feedback on this
> 
> Back in the what, 1970's, the Unix guys
> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
> by separating out statically compiled stuff used in the earliest boot.
> But then initramfs made these separate directories unnecessary, so why
> in the world would we continue the split?

Steve, 

with all due respect, in think your reasoning suffers from some kind of
slight misconception: 

The file system hierarchy split between / and /usr happened because the
disk mounted at / on one particular machine was filling up. Neither was 
it a deliberate design decision, nor was it deemed elegant at the time 
(and still is not). It was nothing but a dirty makeshift botch to quickly 
compensate for some transient hardware constraint almost fifty years ago.
It has nothing to do with the practice of using an initramfs (or similar 
construct) for early user space system initialization.

In fact, if anything, a merged /usr obsoletes the need for an initramfs 
WRT mounting system partitions, as it is highly unlikely for /usr to 
reside on a separate volume when it is merged into the root hierarchy, 
where it belongs. If you dislike initramfs, you should go for a merged 
/usr tree to err on the safe side when it comes to ensure availability 
of essential system components during system initialization.

And bringing anything related to systemd into the picture just because 
its proponents also happen to support merged /usr is a red herring.

[Cut reasoning based on aforementioned misconception about the history 
of split /usr, and initramfs or systemd being relevant to the question 
at hand.]


Best regards,

Urban

-- 
Sapere aude!



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??

[Rick Moen]

Quoting Rowland Penny (rpe...@samba.org):

> Can anybody explain the bad points of doing the merger ?
> I ask this because everything I can find says it is a good thing, but
> they said systemd was a good thing ;-)

This topic has been obscured by a massive amount of special-pleading and
rationalisation.  I'll merely address my _own_ view reflecting my local
policy as a Linux server administrator (not purporting applicability to
Devuan or Debian or desktop computing, or anything else).

Text below (drafted impromptu while-u-wait) serves as my rejoinder to
several frequently-cited Web pages, primarily those from the
Freedesktop.org and Fedora people, that make arguments I deem some
combination of disingenuous and incompetent, FWIW.  Said pages are
liberally quoted (usually verbatim) in the 'Objection' paragraphs.

(Strictly speaking, what follows will not argue against any distribution
'doing the merger'.  It merely articulates that *I* will be un-doing 
any such merger impinging on my local systems from distro defaults,
or similar, and why.)


My view:  I need the contents of /bin, /sbin, /lib, and /lib64 
to be functional if /usr for any reason cannot be, or is not, mounted,
because the role of those subtrees on my systems is to house tools the
superuser might need for backup, recovery, system repair, and system
diagnosis (collectively, 'rescue') in the absence of /usr.


Objection:  But Rob Landley reminded us at
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
that that isn't why Thompson and Richie invented the /usr split in 1971.

Answer:  True enough, but also blatantly, blazingly, and somewhat 
insultingly-to-our-intelligence irrelevant.  It's what generations of
sysadmins have found the /usr split useful for _since_ not long after
1971, and the split's origin in an ancient PDP-11 two-disk-pack kludge
is amusing but has no bearing on more than four decades' subsequent best
practices. 


Objection:  But your /usr-less system won't work properly because
of udev rules invoking binaries from /usr/bin, libs in /usr/lib, and/or
data files in /usr/share, e.g., for udev-pci-db/udev-usb-db, PulseAudio,
NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch,
gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip,
multipath, Argyll, VMWare, etc.

Answer:  My server systems' basic backup, recovery, system repair, and
system diagnosis utilities aren't dependent on the latter (mostly)
GNOME/freedesktop crud.  If my systems _were_ dependent on, e.g.,
LVM, and I found it depended on components in /usr, I'd recompile those
packages locally to remove what I regarded as a build error.  Likewise, 
no udev rules on _my_ server systems depend on /usr.  Moreover, I'm
sufficiently unhappy with udev that I'm currently testing migration away
from it to reduce system complexity and protect security.


Objection:  The roles of a proper minimal system is better filled by an
initrd.

Answer:  I elect to run a simplified system without initrd, and greatly
prefer that nothing on my server systems require one..  Moreover, I'm
sufficiently unhappy with udev that I'm currently testing migration away
from it to reduce system complexity and protect security.  mdev's
looking promising.  (And no, I don't care if it's popular, as long as
it's popular with me.)


Objection:  The role of a proper minimal rescue system is better filled
using an initrd.  Thus, the alleged historical justification no longer
applies.

Answer:  That is an opinion I happen to not share.  I elect instead to
run a simplified system locally configured to run without initrd, and
greatly prefer that nothing on my server systems require one.  I'd in
fact consider any system breakage in the absence of an initrd a critical
bug, and would fix that immediately.


Objection:  It makes no sense for a Linux distribution in 2018 to
default to supporting operation without initrd.

Answer:  Possibly so, yet utterly irrelevant to my server systems, which 
follow Rick Moen policy, if required overriding distro policy:  My local
system, my local rules.  (By the way, that's called 'system
administration'.  Try it, some time.)


Objection:  How are you so sure that nothing in your /bin, /sbin, /lib,
or /lib64 files needed for backup, recovery, system repair, and system
diagnosis doesn't depend on /usr?

Answer:  Because I checked.  'ldd' isn't rocket science, y'know.  And,
if something I relied on for the indicated 'rescue' functions did suffer
such a dependency, I would fix that, if necessary by recompiling
statically.


Objection:  Why would you consider something as antediluvian as static
binaries in 2018?

Answer:  Because I'm serious that those tools need to work with or
without availability of /usr, and highly reliable operation for critical
tools is more important than a small amount of extra binary footprint.
Also, I didn't say I wanted to resort to static binaries.  I said I'd
_even_ resort to static binaries, rather than rely on

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

[Stephan Seitz]

On Fr, Nov 16, 2018 at 03:23:53 -0800, Rick Moen wrote:

My view:  I need the contents of /bin, /sbin, /lib, and /lib64
to be functional if /usr for any reason cannot be, or is not, mounted,
because the role of those subtrees on my systems is to house tools the
superuser might need for backup, recovery, system repair, and system
diagnosis (collectively, 'rescue') in the absence of /usr.


That’s fine for you and your server, but the question is what this 
distribution should do. Devuan is for servers and for desktops. And 
people are using distributions like Devuan to not recompile packages with 
other options.


And for the record: since the time, /bin, /sbin and /lib are part of the 
same disc as /usr (in my case more then 15 years), I never had a need to 
recover /usr but still had access to /bin or /sbin.


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??

[spiralofhope]

On Fri, 16 Nov 2018 22:11:17 +1300
Daniel Reurich  wrote:

> At this stage there is no plan to make it forced...

Not publicly.

On the one hand, this is additional work.

On the other hand, we've seen efforts focused toward fewer choices /
committing to less development variety (though whether it's less
actual development effort is debatable).


I conclude this is a transitory step toward making this mandatory;
something like propagating the idea to ease transitional pains.
___
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):

> That’s fine for you and your server, but the question is what this
> distribution should do. 

Actually, no.  That is _not_ the question I was answering.  To reresh
your memory, Rowland Perry asked:  "Can anybody explain the bad points
of doing the merger?"  I did.  Sorry my answer didn't meet your needs,
but OTOH it wasn't your question I answered.

> Devuan is for servers and for desktops.

That's nice.

Distro policy is significant and important.  But it is not dispositive
of questions like the one Rowland Perry asked.

> And people are using distributions like Devuan to not recompile packages
> with other options.

1.  Most local customisations don't require that.  Some do.

2. _Some_ people are using distributions like Devuan to completely
avoid local compilation.  Others are not.  (E.g., you did not speak for
me.)

> And for the record: since the time, /bin, /sbin and /lib are part of
> the same disc as /usr (in my case more then 15 years), I never had a
> need to recover /usr but still had access to /bin or /sbin.

I'm happy for your luck in not needing to follow system administration
best practices in this area, just as I'm happy about domain owners
scraping by with fewer than the minimum three authoritative DNS
nameservers recommended in RFC 2182 section 5 but through good luck not
suffering DNS outages.

Good luck is to be celebrated, particularly when it overcomes avoidable
risk.

___
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??

[spiralofhope]

On Fri, 16 Nov 2018 04:10:17 -0800
spiralofhope  wrote:

> I conclude this is a transitory step toward making this mandatory;
> something like propagating the idea to ease transitional pains.

Oh, and I suppose I could chime in on the notion of Devuan following
suit.

Of course it should.  At this point, it must.

From what I understand, not all Devuan-specific efforts have concluded.
Every upstream change that's resisted is another burden that distracts
from Devuan's core goals.. unless this becomes a discussion of
broadening them.

One could think that resisting Debian's choices in this matter could
just become someone's pet project, and that the core project would not
be diluted, but all this does is insert another effort and person as
something like an expansion of the "bus factor".[1]

I can't quite articulate it, but not following suit feels something like
scope creep.



[1] https://en.wikipedia.org/wiki/Bus_factor
___
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]

Hi Daniel.

Daniel Reurich - 16.11.18, 10:11:
> Debian as of the upcoming Buster release looks to be implementing a
> merged /usr by default.  At this stage there is no plan to make it
> forced... but you never know what happens when their Technical
> Committee suddenly decides it's an issue they need to force a
> decision on...
> 
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...
> 
> Keen to get some feedback on this

I do not yet have a firm opinion on this. So for now I just like to 
share an experience I had with Debian without usrmerge:

I downloaded a software – I do not remember that it was – from somewhere 
– I do not remember where that was at the moment – and there has been a 
shell script with the following shebang:

#!/usr/bin/bash

Of course it did not work on this Debian installation without changing 
it to "#!/bin/bash". I was surprised about this shell script, cause even 
with usrmerge usually there are symlinks that make all binaries 
available in '/bin' and '/sbin' as well. And I'd give it some transition 
time or use "#!/usr/bin/env bash" (or 'sh' where that is enough, but on 
Debian by default '/bin/sh' points to 'dash' and dash does not provide 
most of the usual bashisms).

My personal view is that the FHS has quite some deficiencies. I agree 
with lots from:

https://cr.yp.to/slashpackage.html

https://cr.yp.to/slashpackage/studies.html

But to move to a completely different standard would be 1) lots of work, 
2) make it impossible to base Devuan on Debian. So in my opinion it is 
outside of the scope of Devuan for now.

In any case: Regarding a decision I'd take the amount of effort into 
account which would be needed to divert from Debian's default. As long 
as Debian still supports the usr split, I bet that effort would be 
minimal, but as soon as packages appear that just stuff anything in
'/usr', then diverting becomes more and more pointless or Devuan would 
need to carry packages with different directory layout.

So for now no firm opinion. Maybe that means I do not care all that much 
about it.

Thanks,
-- 
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??

[Clarke Sideroad]

On 2018-11-16 4:11 a.m., Daniel Reurich wrote:

Hi Devuan followers, fans and friends,

Debian as of the upcoming Buster release looks to be implementing a
merged /usr by default.  At this stage there is no plan to make it
forced... but you never know what happens when their Technical Committee
  suddenly decides it's an issue they need to force a decision on...

So... for Devuan, do we want to default to a merged /usr in our coming
release of Beowulf or are we going to resist another pointless
rearranging of the deck chairs...


Given the current "definition" of Devuan, I see little choice other than 
following Debian, it is after all the source of most packages used in 
Devuan.
Merged /usr will creep in 100% over time and one day not to far away it 
will taint sid/ceres to the point that there is no choice anyway.
The dodging of systemd is already a big enough chunk to gnaw away, it 
makes little sense to make the situation many times worse.


Like it or not systemd and its limitations are forcing changes to the 
landscape and merged usr for little other reason, the once possible 
uniting force of LSB is done for.
Systemd's preferred hierarchy _is_ the new LSB.   Live with it or go it 
alone.


Ideally Devuan would be the new Debian and calling the shots, but that 
is not happening soon, although at some point Devuan may be the required 
lifeboat for Debian passengers.
There is likely a fairly solid Devuan installed base out there, but a 
lot of that is based on close Debian compatibility at least for initial 
install, IMHO we can't lose that or Devuan will quickly follow various 
niche distros into oblivion.


Clarke


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

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

[Edward Bartolo]

A merger is when two or more entities become unified into one entity
like two companies becoming one single company. So, /usr merging
should require other directories becoming part of it. Googling brought
me a question on Ubuntu forums which asked: "Are {/bin, /lib, /sbin}
symlinks into /usr in Ubuntu?" If that is what is understood by this
'fearsome' unification then /bin, /lib and /sbin should become
symlinks with their usual contents moved to /usr. A program should
still be able to find files under /bin, /lib and /sbin provided there
are no two different files with the same name. A disadvantage of the
merger is a merged /usr requires more storage space than before. This
should not be a problem with modern hardware that is more energy
efficient, quieter, and smaller in physical size. Finally, a merger of
a system base directory should not bring instability problems like the
changing of an insufficiently debugged system core executable.

Problems may, however, arise with setups that specifically require
/usr to be unmerged. Here, the question should be how frequent these
setups are, and what role they play in setups that do not tolerate
downtime.
___
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 Fri, 16 Nov 2018 11:34:05 +0100
Irrwahn  wrote:


> I cast my vote in favor of making merged /usr the default.
> 
> My reasoning behind this is as follows (disclaimer: rant mode =
> medium):
> 
> The practice of storing system files in a secondary hierarchy below
> /usr was born out of disk space constraints on hardware that has been
> obsoleted many, many decades ago. It is and has always been an ill
> conceived kludge that somehow managed to cross the times and still be
> present on some Unix-like operating systems.
> 
> The artificial separation of system files into the "essential" and
> "non-essential" categories has always been a vague and arbitrary one,
> and in the Debian case is botched since at least Wheezy, effectively
> rendering the endeavor of making /usr a mount point for a separate
> disk partition a nontrivial task (think initramfs).
> 
> The fact that split /usr has been abused to craft pathologic setups
> like network mounted /usr volumes shared across multiple installations
> is a moot point. This practice is demonstrably a recipe for disaster
> when used for anything but fun experiments on non-critical toy
> installations or as a demonstration piece on how to /not/ design a
> reliable system.
> 
> Split /usr is an abomination that should have been put to rest long
> ago, only to be referred to as quirky anecdote in some obscure
> footnote. Merging /usr back is a small step on the long way to
> restore the FSH to what it was meant to be.

Wait a minute. You and I are talking about two different things,  so
perhaps I should ask what the "/usr merge" really is.

Urban, you seem to be against having both a /usr/bin and a /bin.
Personally, I don't care about that.

What *I'm* talking about is I want to continue having /sbin separate
from /bin and /usr/bin, because the /sbin varieties holds statically
compiled programs guaranteed to work at the earliest of boots, and in
the case of /sbin, guaranteed to be available as soon as / is mounted.

I want there to always exist a /sbin, where static executables become
available the microsecond / is mounted. /sbin should be there only for
statically compiled executables needed for early boot. As long as /sbin
contains everything needed to boot in all but the craziest situations,
I don't care what happens to /usr/sbin.

But the minute somebody combines /sbin with /usr/bin or /usr/sbin,
everything I said in my previous post becomes true.

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 Fri, 16 Nov 2018 11:43:21 +0100
KatolaZ  wrote:

> On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote:
> 
> [cut]
> 
> > 
> > So, after reading Steve's enlightening description, I am with him,
> > the merge is only needed by systemd and seems to be a way of
> > forcing it on everybody, so I am against it.
> >   
> 
> It would be actually more productive to base this discussion on solid
> technical arguments. 

Here's your technical argument: If you get rid of /sbin AND you
mount /usr on a separate partition, you cannot, under any circumstances,
boot without an initramfs.

 
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 Fri, 16 Nov 2018 16:04:42 +0100
Martin Steigerwald  wrote:


> I do not yet have a firm opinion on this. So for now I just like to 
> share an experience I had with Debian without usrmerge:
> 
> I downloaded a software – I do not remember that it was – from
> somewhere – I do not remember where that was at the moment – and
> there has been a shell script with the following shebang:
> 
> #!/usr/bin/bash

If this is the main disadvantage of the split, then a couple symlinks
or hardlinks solves 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 Fri, 16 Nov 2018 12:08:34 +0100
Irrwahn  wrote:


> And bringing anything related to systemd into the picture just
> because its proponents also happen to support merged /usr is a red
> herring.

That's   just   not   true.

We have a half a decade's history of seeing systemd stick its nose in
the tent, and then keep pushing until the DIY human must leave the
tent. I made very clear in my first post it's not a case of "just
because its proponents also happen to support merged /usr". It's
because eliminating /sbin (and also some others that Rick enumerated)
forces use of an initramfs, and the systemd forces can easily acquire,
monopolize and decompatablize the tools to create initramfs. After 5
years systemd observation, this is not paranoia, this is an educated
guess based on past behavior.
 
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??

[Rowland Penny]

On Fri, 16 Nov 2018 12:27:50 -0500
Steve Litt  wrote:

> On Fri, 16 Nov 2018 16:04:42 +0100
> Martin Steigerwald  wrote:
> 
> 
> > I do not yet have a firm opinion on this. So for now I just like to 
> > share an experience I had with Debian without usrmerge:
> > 
> > I downloaded a software – I do not remember that it was – from
> > somewhere – I do not remember where that was at the moment – and
> > there has been a shell script with the following shebang:
> > 
> > #!/usr/bin/bash
> 
> If this is the main disadvantage of the split, then a couple symlinks
> or hardlinks solves it.
> 

Bash is in /bin on Debian, but on Centos it is in /usr/bin and also
in /bin, so the shell script was probably written by a red-hat user ;-)

Rowland
___
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??

[Chandler Wise]

I am personally against such a change as being default in Devuan. I view it
as a change that makes things less forgiving to newbies and to people who
occasionally make mistakes.

An example of this is about three years ago, when I was new to Linux and
accidentally blew away my /usr/bin directory and had to fix it. The common
wisdom "reinstall" was not an option for me, as I couldn't because of
technical restraints. After some time I fixed it, with the help of a friend
and #debianfork. (i still use the system today and it is remarkably stable.
I have had little issues with it, albeit I do not think any issues I have
had were due to this mistake).

It was a mistake of my own, but it was also a learning experience. Because
/usr/bin was somewhat standalone from /bin I did not entirely hose my
system. I shudder to think what would have happened if it was merged. While
this is just one anecdote, it does make me wonder how many people might
have had something like this happen while new or just mistype something.
___
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??

[Nate Bargmann]

* On 2018 16 Nov 10:03 -0600, Edward Bartolo wrote:
> A merger is when two or more entities become unified into one entity
> like two companies becoming one single company. So, /usr merging
> should require other directories becoming part of it. Googling brought
> me a question on Ubuntu forums which asked: "Are {/bin, /lib, /sbin}
> symlinks into /usr in Ubuntu?" If that is what is understood by this
> 'fearsome' unification then /bin, /lib and /sbin should become
> symlinks with their usual contents moved to /usr. A program should
> still be able to find files under /bin, /lib and /sbin provided there
> are no two different files with the same name.

I recently did a clean install of Debian Buster and here is the current
configuration:

$ ls -l /
total 68
lrwxrwxrwx   1 root root 7 Oct 14 07:32 bin -> usr/bin/
drwxr-xr-x   4 root root  4096 Nov  4 14:34 boot/
drwxr-xr-x  21 root root  3600 Nov 13 20:01 dev/
drwxr-xr-x 130 root root 12288 Nov 16 08:00 etc/
drwxr-xr-x   5 root root  4096 Feb 25  2018 home/
lrwxrwxrwx   1 root root30 Oct 14 09:05 initrd.img -> 
boot/initrd.img-4.18.0-2-amd64
lrwxrwxrwx   1 root root30 Oct 14 07:35 initrd.img.old -> 
boot/initrd.img-4.18.0-1-amd64
lrwxrwxrwx   1 root root 7 Oct 14 07:32 lib -> usr/lib/
lrwxrwxrwx   1 root root 9 Oct 14 07:32 lib32 -> usr/lib32/
lrwxrwxrwx   1 root root 9 Oct 14 07:32 lib64 -> usr/lib64/
lrwxrwxrwx   1 root root10 Oct 14 07:32 libx32 -> usr/libx32/
drwx--   2 root root 16384 Oct 14 07:32 lost+found/
drwxr-xr-x   4 root root  4096 Oct 14 12:06 media/
drwxr-xr-x   2 root root  4096 Oct 14 07:32 mnt/
drwxr-xr-x  11 root root  4096 Aug 23 06:37 opt/
dr-xr-xr-x 304 root root 0 Nov 13 20:00 proc/
drwx--   6 root root  4096 Oct 30 20:22 root/
drwxr-xr-x  26 root root   720 Nov 15 07:43 run/
lrwxrwxrwx   1 root root 8 Oct 14 07:32 sbin -> usr/sbin/
drwxr-xr-x   2 root root  4096 Oct 14 07:32 srv/
dr-xr-xr-x  13 root root 0 Nov 13 20:00 sys/
drwxrwxrwt  20 root root  4096 Nov 16 11:50 tmp/
drwxr-xr-x  14 root root  4096 Oct 16 13:26 usr/
drwxr-xr-x  12 root root  4096 Oct 14 13:25 var/
lrwxrwxrwx   1 root root27 Oct 14 09:05 vmlinuz -> 
boot/vmlinuz-4.18.0-2-amd64
lrwxrwxrwx   1 root root27 Oct 14 07:35 vmlinuz.old -> 
boot/vmlinuz-4.18.0-1-amd64

As my systems are all desktops of one variety or another, I keep /home
on a separate partition where it makes sense to do so.

$ df -h
Filesystem  Size  Used Avail Use% Mounted on
udev7.8G 0  7.8G   0% /dev
tmpfs   1.6G   18M  1.6G   2% /run
/dev/sda520G  8.4G  9.8G  47% /
tmpfs   7.8G  100M  7.7G   2% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
tmpfs   7.8G 0  7.8G   0% /sys/fs/cgroup
/dev/sdb192G   67G   21G  77% /opt
/dev/sda1   511M  2.1M  509M   1% /boot/efi
/dev/sda6   359G  147G  205G  42% /home
tmpfs   1.6G   27M  1.6G   2% /run/user/1000

Given my layout, the merged directories are not an issue but just look
odd at first glance after 22 years of my seeing them as stand alone
directories.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB


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

[DNG] initramfs?

[Hendrik Boom]

On Fri, Nov 16, 2018 at 05:11:01AM -0500, Steve Litt wrote:
> 
> Well, maybe because initramfs is a PITA many people choose to avoid.
> When things go wrong, it's the ultimate black box. And I'm very scared
> that one day Poettering/Redhat/Freedesktop.org will corner the market
> on initramfs makers, will make them systemd only, sans-systemd distros
> who have completed the merge will have the choice of backing out the
> merge or going to systemd.

(1) Is initramfs so weird that only one or two people in the world can 
make one?

(2) What is initramfs good for?  Linux used to work just fine without 
it.

-- 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??

[Irrwahn]

Steve Litt wrote on 16.11.18 18:17:
> On Fri, 16 Nov 2018 11:34:05 +0100
> Irrwahn  wrote:
> 
>> I cast my vote in favor of making merged /usr the default.
[...]
>> Split /usr is an abomination that should have been put to rest long
>> ago, only to be referred to as quirky anecdote in some obscure
>> footnote. Merging /usr back is a small step on the long way to
>> restore the FSH to what it was meant to be.
> 
> Wait a minute. You and I are talking about two different things,  so
> perhaps I should ask what the "/usr merge" really is.
> 
> Urban, you seem to be against having both a /usr/bin and a /bin.
> Personally, I don't care about that.

Steve,

since we're having this discussion in the light of Debian making (or at 
least planning to make) merged /usr the default selection in the next 
stable version installer, I guess we should consult the FAQ that comes 
with the `usrmerge´ package in Debian, c.f.:

 https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian

Excerpt:

| * What is the purpose of this package?
| The usrmerge package will convert the system it is installed on to the
| everything-in-usr directories scheme, i.e. the /{bin,sbin,lib}/ directories
| become symbolic links to /usr/{bin,sbin,lib}/.
|  [...]
 
| * Will usrmerge also merge /usr/bin/ and /usr/sbin/?
| No.

| * Does this require systemd?
| No.

| * Does this really not require systemd?
| Yes, I promise.

| * Does this require an initramfs?
| Only if /usr is on a standalone file system.

So, bin and sbin will stay separate, but /bin, /sbin and /lib will get 
merged into, and replaced by symlinks to, their counterparts in /usr.

> What *I'm* talking about is I want to continue having /sbin separate
> from /bin and /usr/bin, because the /sbin varieties holds statically
> compiled programs guaranteed to work at the earliest of boots, and in
> the case of /sbin, guaranteed to be available as soon as / is mounted.

When was the last time you checked what actually resides in /sbin?
It may come as a surprise, but statically linked programs it's not.
Picking some random example, let's have a quick look at `getty´:
  $ ldd /sbin/getty 
linux-vdso.so.1 (0x7fff16f88000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f3afe0ec000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3afdee8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3afdccb000)
/lib64/ld-linux-x86-64.so.2 (0x7f3afe8a3000)

It's less surprising when taking into consideration that with all but 
the most trivial of programs it's basically impossible to achieve 
statical linkage with glibc, and it has been like that for years now. 
If you really want statically linked executables you need to have a 
look beyond glibc, e.g. at musl-libc. (Which is what I did in my past 
experiments to build a small non-GNU Linux system around toybox and
clang/musl-libc.)

> 
> I want there to always exist a /sbin, where static executables become
> available the microsecond / is mounted. /sbin should be there only for
> statically compiled executables needed for early boot. As long as /sbin
> contains everything needed to boot in all but the craziest situations,
> I don't care what happens to /usr/sbin.
> 
> But the minute somebody combines /sbin with /usr/bin or /usr/sbin,
> everything I said in my previous post becomes true.

Only if you insist on mounting /usr separately from /. If your hardware 
is no older than ~40 years there should exist no compelling /technical/
reason to do so. The only arguments pro separate /usr I came across so 
far were all based on either ill advised practice to abuse the artificial 
/usr split (e.g. shared /usr via NFS), or some variation of "but I always
did it that way".

If your mass storage devices are too tiny to allow for a single partition 
to hold the combined content of /{bin,sbin,lib} and /usr, something else 
is fundamentally amiss. Even on my kitchen sink desktop PC the entire / 
hierarchy *including everything except /home*, amounts to a meager 10GB.
(1.4 GB of which is /var, BTW, for which there actually exist sound 
technical reasons to have it on a separate partition, as is the case for 
/home.)

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] initramfs?

[Irrwahn]

Hendrik Boom wrote on 16.11.18 19:08:
> (1) Is initramfs so weird that only one or two people in the world can 
> make one?

No. 

And even though stock De(bi|vu)an installations by default use an 
initramfs (an intrd, to be precise): if you ever find yourself in a 
position where you have to _manually_ tweak it, chances are high that 
something much more fundamental is broken either in the distribution 
itself or on your particular box.

> (2) What is initramfs good for?  Linux used to work just fine without 
> it.

It's only needed if you have to do stuff before running the `real´ init 
process to bring up the system and all services. If, e.g., for some reason 
you decided to place stuff like kernel modules or other essential system 
components not in the root file system and therefore have to perform some 
special action and mounting before being able to bring up user space in 
its final form.

Most, if not all, contemporary Linux based operating systems should be 
able to boot just fine without resorting to any kind of initramfs mechanism,
provided all the essential bits are located in the root-fs, and the kernel
has all the drivers necessary to access said root-fs compiled in.

Regards,
Urban
-- 
Sapere aude!



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??

[karl]

Daniel Reurich:
...
> So... for Devuan, do we want to default to a merged /usr in our coming
> release of Beowulf or are we going to resist another pointless
> rearranging of the deck chairs...

I don't want it.
My view seems to coincide with Rich Moens.

> Keen to get some feedback on this

It is important to keep the boot setup simple, reliable and easy to 
manage for the local admin.

Initrd provides an obstacle and is counterprodictive to that principle
as is udev.

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] initramfs?

[karl]

Urban:
> Hendrik Boom wrote on 16.11.18 19:08:
...
> > (2) What is initramfs good for?  Linux used to work just fine without 
> > it.
> 
> It's only needed if you have to do stuff before running the `real´ init 
> process to bring up the system and all services. If, e.g., for some reason 
> you decided to place stuff like kernel modules or other essential system 
> components not in the root file system and therefore have to perform some 
> special action and mounting before being able to bring up user space in 
> its final form.
> 
> Most, if not all, contemporary Linux based operating systems should be 
> able to boot just fine without resorting to any kind of initramfs mechanism,
> provided all the essential bits are located in the root-fs, and the kernel
> has all the drivers necessary to access said root-fs compiled in.

You will have problems doing that when the boot fs is on a partition on 
a md-raid partition and probably when the boot fs is somewhere on a lvm 
thing. At least you'd have the problem of telling the kernel where the 
root fs is that has dynamic device numbers and must be assembled or 
something before the rootfs is available.

Booting from a md-raid with v0.90 metadata can be done though, since 
theese can be autodetected by the kernel, and the same is valid for 
nfs-booting; though the kernel devs. seems to view that as a hack and
points to initrd as the solution.

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] initramfs?

[Simon Hobson]

Hendrik Boom  wrote:

> (1) Is initramfs so weird that only one or two people in the world can make 
> one?

**AT THE MOMENT** no it isn't. AIUI (and I stand to be corrected) it's simply a 
CPIO archive that's been (optionally) compressed. So it can be uncompressed, 
extracted, modified, and rebuilt using standard tools.
Also ** at the moment** I can't see that changing since the process that needs 
to extract that archive at boot time isn't under Poettering's control.

As for the future - who knows.

Also, echoing another comment, I can't remember ever having to fiddle with the 
contents of one as a means of fixing a problem.


> (2) What is initramfs good for?  Linux used to work just fine without it.

Yes, I remember the days of having to have either a) a huge kernel with 
everything including the kitchen sink linked in, or b) having to relink the 
kernel when the hardware changes. And back when I had SCO Openserver under my 
remit, making boot (hence placing a limit on kernel size) and root floppies for 
emergency booting - oh the fun of working out what I could leave off the root 
floppy to make space for CPIO ...

I can certainly see the use of initramfs : It allows the use of modular kernels 
(so non of this "you've changed something, lets relink" malarky), and gets 
round the catch 22 of needing to mount a filesystem before you can load the 
modules you need to mount the filesystems.
If you'd prefer not to use it, then you can manually link the modules you need 
to be able to mount the filesystems into your custom kernel and do it the old 
way.

Is it easier building initramfs images than statically linking  kernel ? Dunno, 
but that's the way we've gone - and I'd say (see above) that an initramfs is 
less opaque than a statically linked kernel.


As to the original question ...
I have no strong feelings either way, but as has already been mentioned, once 
Debian goes merged, then it's inevitable that more and more packages will 
assume a merged system. The work required to maintain a derived distro keeping 
separate /usr/bin and /bin etc will keep increasing. Given the limited dev 
resource available to Devuan, one has to question whether it would be a good 
investment to maintain the split.
___
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??

[Irrwahn]

Steve Litt wrote on 16.11.18 18:35:
> On Fri, 16 Nov 2018 12:08:34 +0100
> Irrwahn  wrote:
> 
> 
>> And bringing anything related to systemd into the picture just
>> because its proponents also happen to support merged /usr is a red
>> herring.
> 
> That's   just   not   true.

Yes   it   is.  (Thanks for making me feel >40 years younger! :-)

If you are under the impression the merged /usr concept was invented 
by Redhat, or the freedesktop and/or the systemd people, you are 
demonstrably wrong.

On System V Release 4 and later /bin has already been a symlink to 
/usr/bin, and Solaris implemented the /usr merge about a decade ago.
Effectively, only some Unices and some Linux based distributions are 
the odd ones out in that respect.

> 
> We have a half a decade's history of seeing systemd stick its nose in
> the tent, and then keep pushing until the DIY human must leave the
> tent. I made very clear in my first post it's not a case of "just
> because its proponents also happen to support merged /usr". It's
> because eliminating /sbin (and also some others that Rick enumerated)
> forces use of an initramfs, and the systemd forces can easily acquire,
> monopolize and decompatablize the tools to create initramfs. After 5
> years systemd observation, this is not paranoia, this is an educated
> guess based on past behavior.

In my reply to your other post I explain why the notion of a merged /usr 
allegedly forcing the use of an iniramfs is a myth, I won't repeat it 
here for the sake of brevity. 

The part about "acquire, monopolize and decompatablize the tools to 
create initramfs" is ridiculous, as an initrd is nothing more than an 
(optionally compressed) cpio archive, loaded by the Linux kernel itself. 
Put some statically linked executable (e.g. a shell) inside, renamed to 
/sbin/init, and you have the most bare-bone of Linux systems imaginable, 
without even the need for a "real" root file system. (Where I used to work 
we regularly built entire embedded Linux systems that consisted of 
nothing more than a boot loader, a kernel and an initrd - go figure.)

Sorry, but no matter how educated, in this case your guess simply failed.

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] initramfs?

[Irrwahn]

k...@aspodata.se wrote on 16.11.18 20:45:
> Urban:
[...]
>> Most, if not all, contemporary Linux based operating systems should be 
>> able to boot just fine without resorting to any kind of initramfs mechanism,
>> provided all the essential bits are located in the root-fs, and the kernel
>> has all the drivers necessary to access said root-fs compiled in.
> 
> You will have problems doing that when the boot fs is on a partition on 
> a md-raid partition and probably when the boot fs is somewhere on a lvm 
> thing. At least you'd have the problem of telling the kernel where the 
> root fs is that has dynamic device numbers and must be assembled or 
> something before the rootfs is available.
> 
> Booting from a md-raid with v0.90 metadata can be done though, since 
> theese can be autodetected by the kernel, and the same is valid for 
> nfs-booting; though the kernel devs. seems to view that as a hack and
> points to initrd as the solution.

You are correct. I oversimplified a bit, the reason being that scenarios 
like the one you just outlined won't be affected by /usr being merged 
or not, which is what the original subject of the thread was about.

Regards,
Urban

-- 
Sapere aude!



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??

[g4sra]

> Back in the what, 1970's, the Unix guys
> split /usr/sbin, /sbin, /usr/bin, and /bin to accommodate early boot,
> by separating out statically compiled stuff used in the earliest boot.
Close, not restricted to statically linked, but not dependant on
anything not available in /lib (which were very few) so many binaries
were static.

The *original* purpose was to be able to boot a machine to a state where
it supported network file systems (yes typically nfs, but also others)
and then mount /usr from the network.

In a typical organisation only one server would have very expensive
large hard disk capacity of 20MB or so which would be brought up first
to share its local /usr filesystem read-only to all other nodes.
This server would typically also be the only host with the application
software installed on it.

> But then initramfs made these separate directories unnecessary, so why
> in the world would we continue the split?
Eh? initramfs was originally introduced to provide kernel file and
driver *module* support to allow the kernel to control the hardware
device and read the root file system containing /etc /bin /sbin /lib.

> Well, maybe because initramfs is a PITA many people choose to avoid.
Trivial to work with, no different to the debootstrapping and chrooting
you are familiar with using looped files as devices.

> When things go wrongSNIP...
Agree 100%

> 
> I vote against "the merge"
I also vote against the merge.


The concept of which is at fault anyway, if root file system network
support no longer required the merge should go the other way in any
case, it is /usr/{bin,sbin,lib} that is depreciated.

/usr/bin > /bin
/usr/sbin > /sbin
/usr/lib > /lib

with the exception of special cases which are frequently abused by
distros but are not supposed to be a part of the standard OS and should
stay under /usr.
e.g.

/usr/local
/usr/share

___
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??

[Irrwahn]

g4sra wrote on 16.11.18 21:19:
> The concept of which is at fault anyway, if root file system network
> support no longer required the merge should go the other way in any
> case, it is /usr/{bin,sbin,lib} that is depreciated.
> 
> /usr/bin > /bin
> /usr/sbin > /sbin
> /usr/lib > /lib
> 
> with the exception of special cases which are frequently abused by
> distros but are not supposed to be a part of the standard OS and should
> stay under /usr.
> e.g.
> 
> /usr/local
> /usr/share

I once was on the same page, but have since changed my mind when I 
realized that the other way round, i.e. /{bin,sbin,lib} -> /usr/...
actually to me makes more sense, as it keeps all the "static" files 
that are part of the distribution neatly in one place. The only other 
significant things left in / then are site specific configuration in 
/etc and, if not already placed in a dedicated file system, persistent 
variable data in /var.

This allows e.g. for things like rendering the entire "static" part 
of the system effectively immutable simply by mounting /usr read-only. 
(And yes, referring to other sub-threads, in that case one would 
indeed have to mount /usr by means of an initrd, which is neither 
brain science nor rocket surgery.)

Regards,
Urban

-- 
Sapere aude!



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

Re: [DNG] initramfs?

[Dr. Nikolaus Klepp]

Am Freitag, 16. November 2018 schrieb Hendrik Boom:
> On Fri, Nov 16, 2018 at 05:11:01AM -0500, Steve Litt wrote:
> > 
> > Well, maybe because initramfs is a PITA many people choose to avoid.
> > When things go wrong, it's the ultimate black box. And I'm very scared
> > that one day Poettering/Redhat/Freedesktop.org will corner the market
> > on initramfs makers, will make them systemd only, sans-systemd distros
> > who have completed the merge will have the choice of backing out the
> > merge or going to systemd.
> 
> (1) Is initramfs so weird that only one or two people in the world can 
> make one?
Definitly not. If you want to play with initrd vs. no initrd you should look at 
buildroot.

> (2) What is initramfs good for?  Linux used to work just fine without 
> it.
If you want your system to boot real fast to userland (that is: < 1s), then you 
most likely end up using an initrd that is linked to the kernel and loaded by 
the bootlader. That said, my rpi0 boots from kernel start to userland in < 
0.5s, but the bootloader takes a minimum of 1 second to load the kernel :-)

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



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
v
___
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 Irrwahn (irrw...@freenet.de):

[...]

> On System V Release 4 and later /bin has already been a symlink to 
> /usr/bin, and Solaris implemented the /usr merge about a decade ago.
> Effectively, only some Unices and some Linux based distributions are 
> the odd ones out in that respect.

I note without objection (but rather with active appreciation, on
entertainment grounds) that every single one of your talking point so
far -- including the one above -- appear to have been copied
near-verbatim from the pair of Freedesktop.org UsrMerge advocacy Web
pages I dissected in this forum yesterday.  Nicely played, sir!
 
The above appears to have been copied from:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

   Myth #6: A split /usr is Unix “standard”, and a merged /usr would be
   Linux-specific

   Fact: On SysV Unix /bin traditionally has been a symlink to /usr/bin. A
   non-symlinked version of that directory is specific to non-SysV Unix and
   Linux.

and 

   Myth #1: Fedora is the first OS to implement the /usr merge

   Fact: Oracle Solaris has implemented the /usr merge in parts 15 years
   ago, and completed it in Solaris 11. Fedora is following suit here, it
   is not the pioneer.


...which is a profoundly silly argument, but one I touched on by saying

Objection:  Separate /usr hasn't been consistently standard, e.g.,
/bin was a symlink to /usr/bin on many Unixes.

Answer:  I don't give a rat's ass.  It's standard on mine.


Anyway, please do carry on with the retyping of other people's talking
points (unless perhaps you are the uncredited author of one or both of
those Freedesktop.org pages, which is also possible).  It makes for
amusing reading.

___
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 Steve Litt (sl...@troubleshooters.com):

> What *I'm* talking about is I want to continue having /sbin separate
> from /bin and /usr/bin, because the /sbin varieties holds statically
> compiled programs guaranteed to work at the earliest of boots, and in
> the case of /sbin, guaranteed to be available as soon as / is mounted.

Steve, I'm not sure where you arrived at the notion that binaries in
/sbin should be expected to be, or necessarily ought to be, static
binaries.  I'm not aware of any such norm.  (Compiling static is a crude
but certainly effective way to end some dependency issues, but not
necessarily desirable.)

In case you were not aware (and absolutely no condescension intended if
you were already well aware of this), the 's' in 'sbin' signifies
'normally needed only by the superuser'.  It doesn't signify static.

(BTW, .signature below is #500.  Entire herd gathers here:
http://linuxmafia.com/pub/humour/sigs-rickmoen.html )

-- 
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??

[Harald Arnesen]

Irrwahn [11/16/18 9:10 PM]:

> On System V Release 4 and later /bin has already been a symlink to 
> /usr/bin, and Solaris implemented the /usr merge about a decade ago.
> Effectively, only some Unices and some Linux based distributions are 
> the odd ones out in that respect.

And all the BSDs, macOS,...
-- 
Hilsen Harald
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] initramfs?

[Harald Arnesen]

Hendrik Boom [11/16/18 7:08 PM]:

> (2) What is initramfs good for?

Early loading of CPU microcode update.
-- 
Hilsen Harald

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

[DNG] ..I too vote against "the merge"!, was: /usr to merge or not to merge... that is the question??

[Arnt Karlsen]

On Fri, 16 Nov 2018 05:11:01 -0500, Steve wrote in message 
<20181116051101.4d06f...@mydesk.domain.cxm>:

> I vote against "the merge".

..I too vote against "the merge"!


-- 
..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??

[Daniel Taylor]

On 11/16/18 4:42 PM, Rick Moen wrote:

Quoting Steve Litt (sl...@troubleshooters.com):


What *I'm* talking about is I want to continue having /sbin separate
from /bin and /usr/bin, because the /sbin varieties holds statically
compiled programs guaranteed to work at the earliest of boots, and in
the case of /sbin, guaranteed to be available as soon as / is mounted.

Steve, I'm not sure where you arrived at the notion that binaries in
/sbin should be expected to be, or necessarily ought to be, static
binaries.  I'm not aware of any such norm.  (Compiling static is a crude
but certainly effective way to end some dependency issues, but not
necessarily desirable.)

In case you were not aware (and absolutely no condescension intended if
you were already well aware of this), the 's' in 'sbin' signifies
'normally needed only by the superuser'.  It doesn't signify static.

I thought it was "system", but I don't even know who originated the 
separation. It certainly precedes Linux.


As for the "statically linked binaries in /sbin", that may come from the 
(formerly?) common practice of having all the binaries needed for system 
startup statically linked in case something happened to /lib.


It's scary how unreliable our systems used to be compared to now.

--

Daniel Taylor

___
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 Fri, 16 Nov 2018 11:43:21 +0100, KatolaZ wrote in message 
<20181116104321.3kpm4g2wlbpjg...@katolaz.homeunix.net>:

> On Fri, Nov 16, 2018 at 10:19:30AM +, Rowland Penny wrote:
> 
> [cut]
> 
> > 
> > So, after reading Steve's enlightening description, I am with him,
> > the merge is only needed by systemd and seems to be a way of
> > forcing it on everybody, so I am against it.
> >   
> 
> It would be actually more productive to base this discussion on solid
> technical arguments.


..this is primarily a matter of policy, and politics, on what sort 
of tools do you want to have available for whatever you wanna do, and, 
on what sort of tools do you want other people to have available for 
whatever you want them to do. ;o)

..once you have made up your mind on the above, those technical and
tactical issues merely concern how best to make your decision happen.

> I have no opinion on the matter at the moment,
> since I have done very little research on it, and I will try to
> understand what's the technical side of it before judging on the basis
> of a gut feeling. 


..most people can trust their gut feeling because your own gut is
always on your side, precisely because your gut can not escape the
painful ramifications of getting these bad things, badly wrong.   


> I guess it would be more useful if we could all do owr own research
> and construct an informed opinion before participating to this
> thread. This is what I will do.
> 
> My2Cents
> 
> KatolaZ
> 


-- 
..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] reliability (Was: /usr to merge or not to merge... that is the question??)

[Simon Hobson]

Daniel Taylor  wrote:

> It's scary how unreliable our systems used to be compared to now.

Were they ? Or did they just have different fragilities ?
Example:
There's the discussion here about having essential tools available without 
having all filesystems mounted. Go back to the times under discussion and we 
had relatively primitive filesystems without journalling - so an uncontrolled 
shutdown (crash, power loss, ...) was highly likely to cause some filesystem 
damage and need at least a fsck to fix it. Now we routinely have journalling 
filesystems and I note that in most cases there's a quick "replay the log, were 
Ok to go" step during the next boot after a crash.
So there's one aspect where we now have more reliable systems.

But, our systems are so much more complicated now. Once over we had "static" 
hardware, and when changing it you had to (or the device driver installation 
had to) run some admin program that would update the static device nodes in 
/dev. As long as the hardware didn't change, your /dev would reliably have the 
right nodes in it - and you could manually change the device files if needed 
and the changes would be persistent. Now we have dynamic /dev nodes - which 
while very convenient is also subject to a a certain amount of "plug and pray", 
and fixing issues can mean delving into non-trivial config files to get a 
persistent change.
So one aspect where systems are less reliable.

Overall I suspect that there isn't much of a net gain or loss - just a 
different set of problems.

___
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 Fri, 16 Nov 2018 21:50:11 +0100, Irrwahn wrote in message 
:

> g4sra wrote on 16.11.18 21:19:
> > The concept of which is at fault anyway, if root file system network
> > support no longer required the merge should go the other way in any
> > case, it is /usr/{bin,sbin,lib} that is depreciated.
> > 
> > /usr/bin > /bin
> > /usr/sbin > /sbin
> > /usr/lib > /lib
> > 
> > with the exception of special cases which are frequently abused by
> > distros but are not supposed to be a part of the standard OS and
> > should stay under /usr.
> > e.g.
> > 
> > /usr/local
> > /usr/share  
> 
> I once was on the same page, but have since changed my mind when I 
> realized that the other way round, i.e. /{bin,sbin,lib} -> /usr/...
> actually to me makes more sense, as it keeps all the "static" files 
> that are part of the distribution neatly in one place.

...which is a neat way to crash and burn when that neat one place fails.


> The only other 
> significant things left in / then are site specific configuration in 
> /etc and, if not already placed in a dedicated file system,
> persistent variable data in /var.
> 
> This allows e.g. for things like rendering the entire "static" part 
> of the system effectively immutable simply by mounting /usr
> read-only. (And yes, referring to other sub-threads, in that case one
> would indeed have to mount /usr by means of an initrd, which is
> neither brain science nor rocket surgery.)

..some of us has had to do such stunts to try escape expensive
ramifications. 

-- 
..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??

[Rick Moen]

Quoting Daniel Taylor (ran...@argle.org):

> I thought it was "system"

Could be -- but as, in effect, a synonym for superuser.

, but I don't even know who originated the
> separation. 

Thompson and Ritchie, as a kludge to deal with the need to span two disk
packs on their PDP-11, back in 1971.  (Subsequent functional use for 
the split of course differs.)

Upthread, I provided the link to my friend Rob Landley telling the
anecdote about that '71 kludge.

> As for the "statically linked binaries in /sbin", that may come from
> the (formerly?) common practice of having all the binaries needed
> for system startup statically linked in case something happened to
> /lib.

Seems farfetched. Also, I've been in *ix for a long time, and haven't
heard that particular concern.

___
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 Fri, 16 Nov 2018 12:27:50 -0500, Steve wrote in message 
<20181116122750.5ab73...@mydesk.domain.cxm>:

> On Fri, 16 Nov 2018 16:04:42 +0100
> Martin Steigerwald  wrote:
> 
> 
> > I do not yet have a firm opinion on this. So for now I just like to 
> > share an experience I had with Debian without usrmerge:
> > 
> > I downloaded a software – I do not remember that it was – from
> > somewhere – I do not remember where that was at the moment – and
> > there has been a shell script with the following shebang:
> > 
> > #!/usr/bin/bash  
> 
> If this is the main disadvantage of the split, then a couple symlinks
> or hardlinks solves it.


..will such links solve our Debian /usr merge problem?  As in, "let 
them do their idiot merge, we'll just toss in a coupla symlinks." 


-- 
..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] initramfs?

[Arnt Karlsen]

On Fri, 16 Nov 2018 23:45:39 +0100, Harald wrote in message 
:

> Hendrik Boom [11/16/18 7:08 PM]:
> 
> > (2) What is initramfs good for?  
> 
> Early loading of CPU microcode update.


..this is the only good reason for it?


-- 
..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] Devuan on a Purism

[taii...@gmx.com]

On 11/01/2018 10:20 AM, Alessandro Selli wrote:
> On 01/11/18 at 13:19, m712 wrote:
>> Your best bet is a killfile since he's guaranteed to bomb our inboxes after 
>> your message.

(not asking for a reply)

What makes you think that?

I am entitled to share my opinions no matter how unpopular they are.

Why can the other side constantly repeat what they have to say but I can't?

Is one person vs the entire tech media and millions in VC capital really
so terrible that I must be silenced?

> 
> 
>   Never mind, I'll stick to my statement and will ignore him.
> 
>   However, I'm happy to read today there is more activity in the
> open-hardware front:
> 
> 
> https://blog.system76.com/post/179592732883/system76-on-us-manufacturing-and-open-hardware
> 
> 
> "So, what makes Thelio open hardware? 

Nothing unfortunately - that term has been diluted quite a bit recently.

RISC-V is the only real open hardware out there where the files you are
provided really could make every bit of your computer not just an
overpriced case.

> The Thelio design we’ve worked on
> for three years is open source. That means anyone can study, modify,
> distribute, make, and sell the design. You can send the design files to
> a metal shop to make your own Thelio. 

* with entirely proprietary components *

Metal shops don't make computers!

> You can adapt the design for your
> needs. Open source hardware is the physical version of open source
> software. We believe it’s important to apply the same passion we have
> about software freedom to the hardware itself. The open hardware
> community is young and small compared to open source software. We hope
> adding Thelio and Thelio Io to the ranks of open hardware will encourage
> others to join the movement and make their designs free as well. We’re
> very excited to see what people will do with free hardware designs. This
> is relatively new territory."

It isn't - other companies have been doing this for decades just without
millions in VC capital and slick madison avenue marketing teams who have
connections in the tech media.

> 
>   I am yet to see what they've done so far, but it seems they are close
> to start production.
> 
>   Forget it, it was straight on their home page:
> 
> https://system76.com/desktops
> 
> The Open Hardware Computer Is Coming 

Only Risc-V stuff can be considered open hardware - what sys76 is doing
is simply a motherboard design for a collection of proprietary computer
components.

They can't legally call that computer "made in usa" since a case isn't a
computer - the board and chips are and not one of them is made here thus
all they are doing is selling american made computer cases not american
made computers.

Having a computer legally made in usa is difficult as the standards are
strict (as they should be)

The legal standard is "all or virtually all" components of a finished
product - therefore *everyone* currently claiming it is being dishonest
either a little bit (eg: raptorcs with the us made power cpus and us
assembled motherboards but with foreign everything else) or entirely
(eg: system76 and a litany of industrial OEM's doing simple screwdriver
assemblies and calling their hardware us made to get a shady edge in
government contracts)

> Eventually, all that will be left are proprietary hardware
> initialization bits and convincing Intel and AMD to open up there

If google can't convince intel to do that then no one can and I
guarantee companies like this will still be saying the same thing in 10
years "just a little longer" rather than dropping x86 as they should.
___
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 Fri, 16 Nov 2018 19:52:13 +0100
Irrwahn  wrote:

> Steve Litt wrote on 16.11.18 18:17:
> > On Fri, 16 Nov 2018 11:34:05 +0100
> > Irrwahn  wrote:
> >   
> >> I cast my vote in favor of making merged /usr the default.  
> [...]
> >> Split /usr is an abomination that should have been put to rest long
> >> ago, only to be referred to as quirky anecdote in some obscure
> >> footnote. Merging /usr back is a small step on the long way to
> >> restore the FSH to what it was meant to be.  
> > 
> > Wait a minute. You and I are talking about two different things,  so
> > perhaps I should ask what the "/usr merge" really is.
> > 
> > Urban, you seem to be against having both a /usr/bin and a /bin.
> > Personally, I don't care about that.  
> 
> Steve,
> 
> since we're having this discussion in the light of Debian making (or
> at least planning to make) merged /usr the default selection in the
> next stable version installer, I guess we should consult the FAQ that
> comes with the `usrmerge´ package in Debian, c.f.:
> 
>  https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian
> 
> Excerpt:
> 
> | * What is the purpose of this package?
> | The usrmerge package will convert the system it is installed on to
> the | everything-in-usr directories scheme, i.e. the /{bin,sbin,lib}/
> directories | become symbolic links to /usr/{bin,sbin,lib}/.
> |  [...]
>  
> | * Will usrmerge also merge /usr/bin/ and /usr/sbin/?
> | No.
> 
> | * Does this require systemd?
> | No.
> 
> | * Does this really not require systemd?
> | Yes, I promise.

Note the answer about initramfs below, and note that systemd and their
crew could easily monopolize initramfs makers. Note that dracut is
already built around Redhat owned udev.

> 
> | * Does this require an initramfs?
> | Only if /usr is on a standalone file system.

Which is exactly what I said.

> 
> So, bin and sbin will stay separate, but /bin, /sbin and /lib will
> get merged into, and replaced by symlinks to, their counterparts
> in /usr.

Which means if /usr is a mountpoint, you need an initramfs, which was
the basis of my objection.


[snip]

> > But the minute somebody combines /sbin with /usr/bin or /usr/sbin,
> > everything I said in my previous post becomes true.  
> 
> Only if you insist on mounting /usr separately from /. 

A heck of a lot of people insist on a separate partition mounted
as /usr, and for them this requires an initramfs, which might become a
problem like udev or netword, etc, in the future.

Now personally, my root partition is on an ssd, and it includes /usr so
all my /usr/bin, /usr/local/bin, etc, come straight off SSD at
lightning speed. I like it like that. But a lot of people want /usr to
be mounted.

[snip remarks about tiny diskspace requiring the split: That's not the
source of my objection.]
 
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] initramfs?

[Steve Litt]

On Fri, 16 Nov 2018 20:19:57 +0100
Irrwahn  wrote:

> Hendrik Boom wrote on 16.11.18 19:08:
> > (1) Is initramfs so weird that only one or two people in the world
> > can make one?  
> 
> No. 
> 
> And even though stock De(bi|vu)an installations by default use an 
> initramfs (an intrd, to be precise): if you ever find yourself in a 
> position where you have to _manually_ tweak it, chances are high that 
> something much more fundamental is broken either in the distribution 
> itself or on your particular box.
> 
> > (2) What is initramfs good for?  Linux used to work just fine
> > without it.  
> 
> It's only needed if you have to do stuff before running the `real´
> init process to bring up the system and all services. If, e.g., for
> some reason you decided to place stuff like kernel modules or other
> essential system components 
> not in the root file system and therefore
  ^^^

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