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 state that ro is not the only mount option that makes
sense to have different between the /usr and the / filesystems?


> This is not a sensible or robust strategy
I beg to differ, as it's been done for decades.  It might not make sense
*on* *a* *cluster*, but allow me not to care about the corporate
datacenter needs, they are not mine own.  Even if I were a datacenter
sysadmin, I didn't want to manage my laptop the same way I manage the
big iron.  And I want to preserve my liberty to choose the way I can
customize my laptop regardless of what does not make sense to the
datacenter.

>> 4) having the smallest possible / filesystem to ease recovery of a
>> botched system.

> I'd personally go for a dedicated rescue disk/USB stick/live CD for
> this specific purpose.
Personal choice is just that, a personal choice, nothing technically
compelling.

I do use "rescue disk/USB stick/live CD" to do system recovery, and I
figured out that it still makes sense recover 4GiB of filesystem data
instead of 10, especially with slow devices like USB sticks and DVDs
(and I can't put 10GiB of data on DVDs):

[alessandro@wkstn02 ~]$ df / /usr
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/pt4_crypt  9,8G  4,3G    5,0G  47% /
/dev/mapper/pt5_crypt  9,8G  6,2G    3,1G  68% /usr
[alessandro@wkstn02 ~]$


On one systems I no longer run I installed two / filesytems, first they
were independent and were put in sync periodically, then I make them
mirrors.  But they shared the same /usr (and /home).  /usr and /home
were regularly backupped, / was not.  On a laptop (that too I no longer
have) I had two /s that were meant to stay separate.  One I booted from
when I held classes, the second I used for all other uses.  They were
devised to keep different configuration concerning users and servers
according to the different circumstances, after i got fed up scripting
the reconfiguration of many services and system settings for the
different scenarios.

With a merged / and /usr all of these things would be more difficult or
would require more time and stuff (larger USB sticks, separate external
backup disks, full separate installations of system virtualization and
so forth).


> If you can emergency boot a current system with a separate /usr, that
> is a lucky happenstance.
I did it dozens of times.  In fact I do it expressly  in my system
recovery classes: "Now let's see what happens if in /etc/fstab the /usr
line is commented out and I reboot!".

Which is an easy way of simulating a major filesystem corruption.


>   I hope that the explanations I've given above give you just a little
> bit of insight into some of the problems for which I have thought
> quite deeply upon over the course of several years, and spent
> significant time investigating, implementing and testing.
All you wrote boils down to: "We're designing Debian for the Data
Center.  Like it or leave it".

Well, I leave it.



  Bye,



--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE