:: Re: [DNG] /usr to merge or not to m…
Inizio della pagina
Delete this message
Reply to this message
Autore: Alessandro Selli
Data:  
To: dng
Oggetto: Re: [DNG] /usr to merge or not to merge... that is the question
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 explain your reasons
to them, since your rant here is *totally* *out* *of* *scope*."


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



  If you think my reasons to be against the proposed / -> /usr merge are
irrilevant to a thread with "Subject: [DNG] /usr to merge or not to
merge... that is the question" then I understand that Devuan developers
too want to be free to produce 'their' distribution regardless of what
it's desktop users need/want/do with it.  If this is the case, I'll be
happy to leave, so that you will not longer be faced with unwanted
dissent and I will free up the time I'll need to experiment alternatives



  With kind regards,



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