Debian considers merging /usr
dralnux.com
dralnux.com
On the other hand, it does not change much compared to the revolution of adopting the gobolinux filesystem that has been proposed more than 10 years ago. [1]
[1]: http://gobolinux.org/index.php?page=at_a_glance http://gobolinux.org/index.php?page=doc/articles/clueless
but if another program needs a older or newer version you can install that version in parallel without it disturbing the rest.
And I don't see either what prevents one to distribute an application as standalone by stuffing all the libs needed in the application directory.
Nix (and NixOS) does most of the same things, and then some, achieving more of the potential benefits. If you're going to break compatibility anyway, you might as well do it in a big way.
A 2x improvement isn't enough to be worth the cost. 10x might be.
Note though that Gobolinux is largely constructed from shell scripts.
Also, since this comparison was made Gobolinux replace /System/Links with /system/Index. The latter is more like the classic FHS, and came about because of various issues during software compiles (iirc).
Oh, one potentially interesting tidbit about Gobolinux history is that it apparently started out as one guy's way to manage compiles stored in his user directory on a university server. Sadly since the move to /System/Index the tool for bootstrapping such an environment, Rootless, has been nonfunctional.
It was actually the straw that broke the camel's back for me as an Arch user. This was around the time Arch Linux was going through lots of breaking changes.
Now we have docker. Probably not solved until we write all our applications as some sort of crazy monad to minimize maintenance pain. I think docker is a meaningful step toward that.
Desktop Linux seems to be finally moving towards self-contained formats like AppImage and Flatpak. They are clearly not oriented towards server apps, but who knows.
Not really, the KISS nature of arch means that stuff that could be automated isn't because reasons, while systemd gets a special pass.
The glibc update from around the same time was a much worse update update. I think that one did break every Arch install I had at that time.
index.php?page=at_a_glance
index.php?page=doc/articles/cluelessThe URL is 301 redirecting to itself.
My guess is the admin has a server side redirect to force http to https, but has CloudFlare configured to use http to the origin.
A couple of days ago I was reading some POSIX book from 1991 and there the layout of /bin /lib /shared /usr/name/bin /usr/name/lib /usr/name/shared and so on was much more logical than what we have now which is just weird as far as I can see because I don't understand it.
The ix file system standards are the retcons of a bunch of hacks made by sysadmins trying to stave off users with pitchforks. Philosophy my arse.
[1]: https://lists.archlinux.org/pipermail/arch-dev-public/2012-M...
site:bugzilla.redhat.com "UsrMove"
The reality is it caused lots of breakage throughout the system which required many man-hours to fix over years.
The gain from it is pretty minimal. And there are still bugs everywhere, for example these two commands ought to the do the same thing, but in fact the first breaks and the second works:
# dnf install /sbin/ifconfig
# dnf install /usr/sbin/ifconfig
The good thing from Debian's point of view is that Fedora and Arch already fixed many of the bugs, so things will probably be smoother for Debian.
http://lists.busybox.net/pipermail/busybox/2010-December/074...
Some fragment:
> When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
> Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago.
It was discussed here few times:
Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
You could use two partition update scheme as ChromeOS. I am working on Linux distribution that have rootfs as a squashfs image and I want to have as painless updates as on ChromeOS.
> Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require that they were actually on different file systems? I don't think you can have a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)
You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.
Right, but that's with OverlayFS and such, right? (I.e. not just straight bind mounts.)
Seems awfully complicated to solve what essentially should be a non-problem... (I'm aware OverlayFS has other uses, but in this instance it seems like overkill.)
EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
Most probably yes, but there are probably distributions using ro rootfs + specific mounts. I think that in many cases embedded devices would use such a scheme instead of OverlayFS.
EDIT: But you probably have to mount workdir and upperdir somewhere over this ro rootfs for OverlayFS to work.
> EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I guess it might have been easy to miss.
I was hoping that you could read between the lines also :) I mentioned my WIP distribution. I have mounted:
- squashfs ro on /
- ext4 rw on /mnt/rw
- /mnt/rw/var bind on /var
- /mnt/rw/home bind on /home
Oooh, burn! :) I honestly didn't see any relevant mention of the WIP-distro you're talking about... but now that you mention it I had a look back. "I am working on Linux distribution" (etc.).
> I have mounted:[snip]
So... separate file systems.
Surely there's a lot of horrible software out there that Makes Assumptions.
It doesn't make much sense anymore but before the turn of the century a meg of doc files might cost you a buck per machine, which might add up to a lot of money given a lot of machines and a lot of software... And usually you don't need /usr/doc but when you do need it you REALLY need it and don't mind if its a little slower to access via NFS than on a local drive.
In the same old days, some brave people exported /usr/src. Oh and X window fonts too.
You also had people who would build a Linux box out of any old hardware they had left over. That's how I ended up with my first firewall.
The Linux "community" have a bad habit of turning solutions for special scenarios into generic ones by hook or by crook.
Never mind that this was addressed to the busybox mailing list, a project aimed at reimplmenting the unix coreutils as a single static binary.
The merge does involve some loss of flexibility (for instance, "traditionally", you could use the programs in /bin to recover a failing system), but there are fewer and fewer users relying on it. It also involves departing from the FHS, but Debian already does that (e.g. they use /lib/<GNU triplet> rather than /lib{32,64}). I haven't heard any super convincing arguments from either side; normally, I'd go by the "not broken -- nothing to fix" route, but it's also hard to poke holes in the "this additional complexity isn't needed anymore" line of reasoning. Plus, like most arguments that involve tradition, it's pretty hard to tell robustness from cruft.
Whether this change can be done cleanly and without breaking users' systems is an entirely different story and past experience has shown that moderation is a far better friend than optimism. It's particularly difficult to migrate existing installation to this scheme (e.g. Arch failed quite badly, as I remember from those particular two afternoons, thanks a lot Arch!, and it didn't go more smoothly for others, either), but Debian can benefit from the lessons learned by more up-to-da^H^H^H^H fast-moving distributions and do things better.
Pretty much every binary in /bin in Debian (the OS I have at hand to check) links to a library of some sort. Therefore, if my /lib is hosed, I can't use any of the tools in /bin (I've had this happen, and I couldn't even use "ls". This would not have occured if those binaries were statically linked (I believe OpenBSD does that for /bin and /sbin).
Agreed. If distros wanted to try and champion the cause for a statically linked subset of critical coreutils, they could still do it in the merged tree. The only thing the separation would facilitate would be separate mount points or physical devices.
There are examples for both approaches. OpenBSD keeps /bin minimal and statically-linked, and it works. Solaris merged /bin and /usr/bin a long time ago, and -- unsurprisingly -- that works as well.
Frankly, as long as it doesn't bork my Debian machine when I move from Jessie to whatever Debian 9 is going to be called, they can merge all they want. At this point, seeing how many Linux systems are doing the merger, it's probably a good idea to do it, too. Packages whose developers give a flying fsck about portability (fewer and fewer nowadays because lockdown and unportability were bad only when Microsoft were doing it) already deal with both usr-merged and usr-unmerged systems (hardly rocket science in most cases), and the maintainers of packages whose developers don't give a flying fsck about portability and only develop for Linux can hope that four years from now, everyone will have merged, especially now that Debian is doing it too.
I think the fact that I can't even remember the last time I cared how things in /bin are linked is good proof of how important this "tradition" is, at least for me...
/bin and /usr/bin were on different drives. Now all those weird splits and choices make sense.
Fuller explanation here: http://lists.busybox.net/pipermail/busybox/2010-December/074...
With this change, this management format is gone. What is not a big loss nowadays.
I have a tmpfs on / and mount a ro-snapshot onto /usr. Fresh system in every reboot:-)
Can Computer Science help us decide if some people are right?
The measure of Informational entropy : a state with more compartment as more order, thus more information. By merging /usr you lose information, thus making the one in need losing it, whereas the one without a need for this gain nothing.
I laughed at the comment of philosophy by pitchforks of angry users, and I would claim these pitchforks are the one from the Maxwell Daemons telling us to remember that it is easy to lose information and that increasing entropy is messy.
Does cryptsetup need to go into /sbin or /use/sbin? Does network code belong into / or /use?
Must users will not care, but some might need either of them to set up their file systems.
If you pace something into /, then you also need to put all libraries and binaries that needs into /. That will rapidly blue up the size of /. It is also not automatically testable, so distributions will get things wrong (as they repeatedly did before).
You could have a script to only put the stuff your system needs into /... Most distributions use such a script for their initrd, which contains everything necessary to check and mount your root file system. So you could just extract that into / and be fine with it:-)
Or just use your initrd as that rescue medium.
While we're at it, why don't we add a real Plan-9-style bind and use union mounts?
There have been a few stabs at a union fs. The most recent one, OverlayFS was merged in 2014.
On a modern package-managed Linux distribution, both / and /usr are under the control of the package manager, and separating them doesn't make sense since they are modified in lockstep, and used as a coherent whole.
And while in the Linux world we're busy "unifying" these locations, other systems can have the whole system on ZFS, where these locations can be in separate datasets if desired, and the whole lot can be snapshotted at will. Since it's all in a single pool, there's no need to even consider splitting it.
# ln -s / /usrGah!!
Can't see any real advantage in this.
Also, why recover a system like that when I can just boot off a USB stick?
This is just a hack that's stuck around from when people had tiny drives and needed multiple partitions for these things, as far as I understand it.
> Why recover a system like that when I can just boot off a USB stick?
Because I can. The basic parts of the system are still available and working. I don't need to reboot to fix the problem, I could mount a different and working /usr in seconds. Is not just "a hack", is a design.
"The bootstrap utility for the upcoming release of Debian 9 “Stretch” will feature the ability to merge utilities from the root file system into the /usr file system. This essentially means directories like /bin and /sbin will simply be symbolic links to content stored in /usr/bin and /usr/sbin. Ansgar Burchardt has suggested this file system layout might be made the default behaviour for future versions of Debian:
“It has been previously suggested to make this the default for (at least) new installations. I think Russ’ earlier mail explains quite well why the split between / and /usr doesn’t really work out for Debian these days and that trying to maintain it for some configurations (which are not documented) is mostly busy-work. There is also a nice article on LWN summarizing earlier discussions. I found these arguments convincing enough and would like to see the default switched to merged-/usr for Stretch and later. Possibly also switching systems on upgrade to the new scheme (not necessarily already in the Stretch release cycle).”
Source: https://lists.debian.org/debian-devel/2016/09/msg00269.html"
https://lists.debian.org/debian-devel-announce/2016/11/msg00...
https://packages.qa.debian.org/d/debootstrap/news/20161116T0...
By education, I think mainly about the different way to use Linux compare to Windows.
Imagine you are traveling and need a file that is at home on your desktop PC. With your phone, you can wake up your PC, connect using ssh, convert the document to pdf and copy it to your phone.
Imagine you are visiting a friend and want to show something running on your PC, you wake up your PC, launch putty and a VNC client (portable applications) and you are at home.
Imagine you want to keep your machine lean and clean. With docker you can switch between images of preinstalled independent development environments. With sshfs, you access your remote website without a local copy.
Imagine you want to change the hard drive. I copy very quickly the very few files in my home directory that are not on NFS to a NFS backup directory. I change the disk, reinstall Linux then uses the small installation diary I keep on google drive to configure disk montages and to reinstall non default applications.
I think you're gonna have a hard time convincing people these days that the answer to all the scenarios you listed shouldn't just be "lol cloud", too. :/
AFAIK, rdesktop and logmein are far behind (more difficult to setup and to use).
https://code.google.com/archive/p/win-sshfs seems dead.
AFAIK, docker does not work on windows home edition.
My scenarios are not made up. These are my very usual and simple use cases of linux. I do not know any windows user that do the same. Do you have a backup copy of your 1TB hard drive on the cloud ?