Hi,

People don't understand: it is bad to manage their own OS. That is the
work for EXPERTS who know BETTER. Users should only be allowed to move
the mouse, click its cool buttons, and sometimes use DVDs (CDs) to run
recovery software. Other than that, it is bad management.

[/sarcasm]

Edward


> On 03/01/2016, Roger Leigh <rleigh@???> wrote:
>> On 02/01/2016 23:39, Arnt Karlsen wrote:
>>> On Sat, 02 Jan 2016 05:50:15 -0500, Mitt wrote in message
>>> <jtiMA6Mbvw7CTU1emAUqy0_CPd1d4pjRvXxt0zby0A2XXS-dLes3dkdkEfmNfz50xSao-vdE4A_lgWu0zEpSiA==@protonmail.ch>:
>>>
>>>> Not sure about poetteringisation (of how should this be spelled?)
>>>> but take a look at this link:
>>>> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>>>>
>>>> and this
>>>> https://fedoraproject.org/wiki/Features/UsrMove (see owners)
>>>>
>>>> and even this
>>>> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>>>>
>>>> Simplification? Heh.
>>>>
>>>> The same thing: why change something that has been working
>>>> (flawlessly?) for four decades.
>>>
>>> ..to subvert and scuttle the competition.
>>
>> It's not something that nefarious. It's about inexperienced people
>> looking at historical practices/mistakes and trying to "correct" them.
>> That said, you can't ever remove something as entrenched as /usr, at
>> least, not without widespread breakage. No one who cared about
>> compatibility would consider that.
>>
>> The *real* goal here is something rather simpler: having both / and /usr
>> mounted in the initramfs. The primary reason for this is that there are
>> genuine problems with stuff on / needed in early boot having library
>> dependencies located in /usr. Libraries were moved to / on a
>> case-by-case basis, but it's really just the tip of the iceberg. E.g.
>> PAM modules needing openssl, datafiles from /usr/share, etc. It becomes
>> a nightmare to coordinate and manage, particularly when you also have to
>> consider third-party stuff out of your control. Simply ensuring that
>> /usr is available in the initramfs solves all these problems. The
>> requirements coming from systemd/freedesktop about this are essentially
>> the same, but in a typically inflexible and our-way-only manner. The
>> actual problem here predates systemd by many years.
>>
>> Note that I wrote the patches which mount /usr in the initramfs in
>> addition to /. This gives all the primary benefits of the /usr merge
>> without actually changing anything. It means that from this point on,
>> you can freely make use of programs, libraries and datafiles in /usr
>> during early boot. I.e. the only change is a guarantee of when things
>> are available. The exception to this is that you can no longer boot
>> from a system with a split /usr unless you have an initramfs.
>>
>>
>> When you look at the /usr merge stuff which can follow on from this,
>> there are several steps one might take:
>> - having / and /usr on the same filesystem
>> - then symlink programs from /usr/bin to /bin (or vice versa) (and lib
>> etc.)
>> - or symlink the whole of /usr/bin to /bin (or vice versa) (and lib etc.)
>> - or symlink /usr to /
>>
>> RedHat chose to move the whole of / to /usr, and symlink to it from the
>> old locations. It's kind of backward. It was done since /usr was often
>> bigger than /, so makes sense for upgrades where migrating the other way
>> would fail. But as the long-term goal and for fresh installs, it's not
>> really solving any real-world problem. Just having everything on a
>> single filesystem (or mounting everything in the initramfs) already
>> solved those.
>>
>> Historically, GNU/Hurd symlinked /usr to /. It would have been a good
>> goal for Debian GNU/Linux. It needed an audit of potentially
>> conflicting files to ensure the package dependencies were OK, but would
>> otherwise be doable simply by making /usr a symlink in base-files (for
>> new installs).
>>
>> Whichever way you do the merge, hardcoded paths like /bin/sh and
>> /usr/bin/whatever are part of the platform. They will be required to be
>> accessible using the old names indefinitely. So the actual *need* for
>> the merge is moot.
>>
>> Regarding the comments people made about having separate / and /usr
>> filesystems. While it was common historically, there is little or no
>> practical benefit to doing so in 2016. Storage sizes make it
>> unnecessary for pretty much all practical scenarios. The two are
>> managed by dpkg as a coherent whole; they are logically inseparable.
>> They serve the same purpose. Do reconsider whether it's actually
>> necessary for you to do this, or whether it's merely habit. Some
>> historical practices continue to have value; others, including this one,
>> do not.
>>
>>
>> Regards,
>> Roger
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>