10 ms·

I've always liked the concept behind GoboLinux[1], it makes so much more sense in comparison to the legacy mainframe style file structure other linux distros us

• vezzy-fnord 11y ago
  Don't count on it. It's probably going to be this: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc...
  • craftkiller 11y ago
    Why is /usr/bin being adopted as the place for binaries with /bin linking to it instead of the other way around? Since they're essentially the same directory under this setup why not favor the short path?
    • zarvox 11y ago
      http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT... In short: because having things in /usr is equally compatible, and makes some useful things like atomically snapshotting /usr to snapshot all executables, mounting /usr readonly, etc. possible.
      • craftkiller 11y ago
        Ah I had not considered snapshotting just /usr before. Thanks for the link, it makes a lot more sense now!
    • jonhohle 11y ago
      In addition, on more complex setups, `/usr` might not be mounted during certain failure modes.
      • marcosdumay 11y ago
        It's also not available at the first moment of the boot process. But it is this kind of stuff that they are trying to change (as usual for systemd, without fully thinking why people do it differently now).
        • geofft 11y ago
          A lot of those designs predated initramfs. I have yet to hear of a setup where there's a good reason for not mounting /usr in the initramfs. (Though, yes, I have heard of setups where you can, it would just be a fairly involved change. It is a legitimate problem for these sysadmins to be compelled to rearchitect things, although I'd personally blame that more on the distro model where all parts of userspace are tied together than on systemd itself.)
    • JdeBP 11y ago
      It's an interesting question. One part of the the answer is that the idea is for there to be a single subtree off the root where "the operating system" lives. Where MacOS 10 has /System, OS/2 has \OS2, Windows has \Windows, and Digital Research DOS has \DOS, systemd Linux has /usr. Of course, another part is that this is an old idea, already implemented once in the commercial Unices a quarter of a century ago. They merged /bin into /usr/bin, with a symbolic link from the former to the latter.
• motoboi 11y ago
  We have a Linux distributing organizing programs in a different way: Android. It seems to be working pretty good, actually, with compartmentalization and tight security.
  • hiphopyo 11y ago
    Doesn't Android borrow a lot of code from NetBSD and OpenBSD?
    • duskwuff 11y ago
      Not significantly. Some parts of Bionic (Android's libc equivalent) is based on BSD equivalents, but most of userland is Android-specific.
      • pjmlp 11y ago
        > but most of userland is Android-specific. Meaning Java, which makes POSIX irrelevant.
      • rhabarba 11y ago
        Android has a few hundred unmodified OpenBSD files.
        • duskwuff 11y ago
          A few hundred files is very little in a project the size of Android. :)
  • alphapapa 11y ago
    It's funny you should say that. I've been using Android for several years after using iPhones. And I find myself wishing all the time for a phone that simply runs Debian Stable. Tight security? Well, how about Stagefright? Cyanogen no longer supports my phone. Even when they did, it wasn't well-supported: each new release had a high chance of breaking something fundamental. Right now I'm stuck on a "milestone" release that isn't even the newest one (it's over a year old now!), because later ones all have some unacceptable problem, like GPS not working or cell data not working. I can't just install an updated browser component package, because Android is monolithic. On Debian it'd be in a package like libwebkit, and it'd be a simple "apt-get upgrade" away. So I'm stuck with a vulnerable Android version. If I try to upgrade to fix it, I'll lose GPS or cellular data. The only way to get a fix is to buy a new phone. Now Google is trying to push more of the components into its Google Play Service app/framework. So, great: more parts can be upgraded independently of the monolithic core. But that also means that Google can push out updates to more components without my knowledge or consent: not great. That means more instances of feeling something warm in my pocket, pulling out my phone, and finding that Google Play Services has kept my phone awake for 10 hours and my battery is at 12%. This has happened to me on multiple occasions: one day my phone works fine. The next day it eats the battery like candy. I didn't change any settings or install any updates--Google merely decided to push out an automatic update to its APKs without my knowledge or consent, and Google Play Services constantly crashes every 5 seconds, popping up a dialog box that I have to manually dismiss. I can't even do a simple task like send an SMS or check my email, because every 5 seconds it pops up another "Unfortunately..." box. There's no practical way to roll it back, nor even to report the problem. The best I can do is find people reporting the same problem on Reddit and hope that Google gets its act together so I can actually have a usable phone again; maybe one morning I'll wake up and my phone will not be "sick" anymore. In the meantime I have a really dumb "smartphone" that keeps my leg warm. I have had high hopes for Android, but I now consider it to be a mess, and consider Google to be a highly irresponsible steward. I don't want an iPhone, but if someone wants a reliable smartphone without nasty surprises, they are probably better served with one.
• caf 11y ago
  Debian has specifically said that they will be continuing to use the FHS (Filesystem Hierarchy Standard).
• hiphopyo 11y ago
  Something like http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/hier.7?query=hier&sec=7 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man7/... would be nice.
• thaumaturgy 11y ago
  That looks fine for embedded systems or maybe some end-user systems, but doing that in a server context would be scary. The original filesystem hierarchy was designed so that /usr, /etc, /bin, and so on would have their own partitions and in the event that something tried to eat the filesystem, you might still be able to boot into single user mode and repair the damage. I've had to do this on a handful of different servers where /usr is boned and won't mount, but I still have enough stuff available that I can fix it. Plus there are a handful of tools with smart option that take advantage of the multiple partition approach, like rm and rsync's --one-file-system option.
  • JdeBP 11y ago
    Except, of course, that /etc/init and /bin/sh being on "their own partitions" is the opposite of what was actually the case in the original filesystem hierarchy. (Hint: Yes, /etc/init not /sbin/init .)
    • thaumaturgy 11y ago
      [root@mail /]# ls -laF /etc/init ls: cannot access /etc/init: No such file or directory Sorry, I don't follow what you're saying. Or why that would make putting everything under /Programs better for that matter.
      • cesarb 11y ago
        I believe that what JdeBP is refering to is that, before /sbin existed, the binary which is now at /sbin/init used to be at /etc/init, if I recall correctly what I once read in an old FSSTND rationale.
        • thaumaturgy 11y ago
          Huh, interesting. If that's the case, it's new to me. Neat.
  • powera 11y ago
    The original filesystem hierarchy was designed when 1MB was a large amount of space. If you want to have a separate read-only partition for system programs (and require going into single-user mode to modify that), go for it. But the rest of the /bin /etc /usr /usr/local nonsense is just because it's easier than changing to something better for most people.
• codemac 11y ago
  You should look at Nix and Guix if you like distros with novel file systems.
• avn2109 11y ago
  I remember being baffled by the file tree as a Linux n00b, and a scheme like this would be way more discoverable.
• bitL 11y ago
  Exactly! I wish Gobo and its filesystem structure was used more outside Brazil!
  • digi_owl 11y ago
    There is a smattering of users across the globe...
• JdeBP 11y ago
  This is nothing new, of course. NeXTStep introduced things like ~/Apps, /LocalLibrary, and /LocalApps back in the early 1990s. Daniel J. Bernstein, around the turn of the century, proposed a /package hierarchy (for package management without the need for conflict resolution) and a /command directory. (http://cr.yp.to/slashpackage.html http://cr.yp.to/slashpackage.html) Their major problem was the idea that one had to register things with what was to most of the world just some bloke on another continent. But they had concepts like a hierarchical package naming scheme ("admin/", "mail/", &c.), self-contained build trees with versioned names, and an "index" directory full of symbolic links.
  • gcb0 11y ago
    the problem is exactly that. some group in an ivory tower refuses to (or can't?) move. most of posix is like that. Linux "standard" for gui stuff is still some definition from IBM to normalize DOS apps (reason why F10 open menus, copy paste with ctrl+ins, shift+ins, etc). then people that can't work together with others (eg Jobs) does retarded things like /localLibrary which benefit nobody, not even themselves. just throw everything up. then if those folks succeed despite that, it becomes the new immutable thing to follow, like gnome is doing with following blindly apple ui specs. edit: i never tried to contribute to any larger standard. i did develop against most of them, cursed at their anachronistic ways and coded around it praising consistency. so i am pretty sure i am part of the problem described above. I'm not saying the fine people in those ivory towers are the problem. I'm glad we have that little help for world consistency. it's just not enough.
    • JdeBP 11y ago
      You're taking received wisdom from Wikipedia, and it's wrong. Common User Access was for normalizing IBM applications, across its then hardware platforms: the PC, System/3x, and System/370. Indeed, it's most promiment PC success was 32-bit IBM OS/2, which implemented the later CUA 91 and which most definitely wasn't DOS.
      • gcb0 11y ago
        well, whatever the actual reason, i actually (used to) consult it when writing CURSE applications only because it is the closest we have for a curses application usability standard. where it came from originally is not much of concern. but the fact that it is the best we have, is.
• lifeisstillgood 11y ago
  I like the idea here (every app / installable) sits entirely under one directory, all config, binaries etc. However isn't the problem that we need everyone to agree to do this? Additionally it is nice to have all config in /etc
  • digi_owl 11y ago
    Well Gobo basically don't care, it maintains a replica FHS so that minimal effort is needed to get existing software running. Heck, it originated as one guy's solution for managing self-compiled programs within his home dir on the university mainframe (or some such). You can still find Rootless (the bootstrap tool for using Gobolinux in the home directory) on the Gobolinux site, but i can't comment on how well maintained it is these days.
• wscott 11y ago
  Or Nix https://nixos.org/ https://nixos.org/ where every package is stored by a hash of its build environment. So every version can coexist.
  • baldfat 11y ago
    I have been saying for years our Linux Package System is broken and antiquated. When we had 40 MB hard drives or no hard drives at all these systems made sense. Today we can have a system that just works like this or Gobo Linux. I have hopes that with containers that we will see some major distro switch (Looking at Arch Linux) to a non-shared everything libraries.
    • deleted 11y ago
      [deleted]
    • lsaferite 11y ago
      Well, then why have any libs if none will be shared? Why not just statically compile the application so it's a single binary?
      • baldfat 11y ago
        I love the idea EXCEPT for Desktop Enviroments. Does that mean any KDE/Gnome App has the whole desktop installed in each folder? What about OpenSSH does that mean any program that uses SSH needs its own copy and then we have 12 different versions of SSH? Its not easy but I am sure someone is smart enough to figure this stuff out. NixOS and Gobo Linux have tried.
        • digi_owl 11y ago
          The scheme that Canonical seems to be playing with is that larger projects (DEs, central libs) are put into what they call frameworks. These are packages that other packages can refer to rather than massively duplicating the content within themselves. These frameworks will in turn be versioned, so that if package X wants framework Z, while Y wants Z+1 they can both be happy without descending into dependency hell. Note that Gobolinux gets around this to a degree by using age old soname and symlinks. This in that ld and similar is pointed at a directory containing symlinks. libxyz.so.1 will be pointing to whatever is the active version of libxyz, while something like libxyz.so.1.1 will be pointing to that specific lib version. Disabling a specific lib version is done by removing the relevant symlinks. Gobolinux provides tools for doing this, but they are basically shell scripts. And so in a pinch someone can do all that manually.
• Zardoz84 11y ago
  I should give a try to it. Looks interesting.
• digi_owl 11y ago
  One thing about Gobo is that it does not try to enforce any specific layout outside the distro itself. Heck, the last version basically have a legacy layout inside /System/Index. This so that it is less likely that anything with hardcoded paths will throw a hissy fit. Frankly Gobo demonstrate the massive flexibility of classic unix tools, as most of it is shell script and symlinks. There is perhaps a few binaries, purely for performance (and those are third iteration, the first being shell script, the second Python).