Slashdot Mirror

← Back to Stories (view on slashdot.org)

GoboLinux 016 Released With Its Own Filesystem Virtualization Tool (gobolinux.org)

Posted by EditorDavid on from the dedicated-directory-trees dept.

Long-time Slashdot reader paranoidd writes: GoboLinux announced Thursday the availability of a new major release. What's special about it is that it comes together with a container-free filesystem virtualization that's kind of unique thanks to the way that installed programs are arranged by the distro. Rather than having to create full-fledged containers simply to get around conflicting libraries, a lightweight solution simply plays with overlays to create dynamic filesystem views for each process that wants them. Even more interesting, the whole concept also enables 32-bit and 64-bit programs to coexist with no need for a lib64 directory (as implemented by mostly all bi-arch distributions out there).
"Instead of having parts of a program thrown at /usr/bin, other parts at /etc and yet more parts thrown at /usr/share/something/or/another, each program gets its own directory tree, keeping them all neatly separated and allowing you to see everything that's installed in the system and which files belong to which programs in a simple and obvious way."

47 comments

  1. sounds like Mac OS X app resources by dknj · · Score: 1

    All Mac OS X apps are actually directories consisting of resources and binaries. This is why you can copy a single "app" and take all of its data to a new location in a portable manner.

    I wonder if patent expiration is playing into gobolinux's new format.

    -dk

    1. Re:sounds like Mac OS X app resources by pixel+sorceress · · Score: 2

      I kinda doubt Apple could've patented that. It's not substantially different to what the older (and incredibly awesome) RISC OS did. This news made me think of RISC OS first, which made me smile.

    2. Re: sounds like Mac OS X app resources by Anonymous Coward · · Score: 0

      Well behaved OSX apps do not store user data in the application bundle. It goes in a app specific directory under ~/Library (even sandboxed apps).

    3. Re:sounds like Mac OS X app resources by nawcom · · Score: 1

      The bundling style from OS X is an evolved version of NeXTSTEP application bundling from 1989.

    4. Re:sounds like Mac OS X app resources by TheRaven64 · · Score: 2

      OS X uses almost exactly the same .app bundle format as NeXTSTEP. If there were any patents, they'd have expired in 2008 at the latest. That said, this doesn't sound much like the bundle format, it sounds more like the PC-BSD package format.

      --
      I am TheRaven on Soylent News
    5. Re:sounds like Mac OS X app resources by Anonymous Coward · · Score: 1

      It's not really much like Mac OS apps; each program is installed in one directory, but dependencies are not bundled. Gobo started as scripts to automate compiling and installing software into your home directory:

      $ cd ~/source/library1-v1.2
      $ ./configure --prefix=~/programs/library1/1.2 && make && make install
      $ cd ~/source/library2-v2.4.1
      $ ./configure --prefix=~/programs/library2/2.4.1 && make && make install
      $ cd ~/source/program1-v3.11
      $ ./configure --prefix=~/programs/program1/3.11 --with-lib1=~/programs/library1/1.2 --with-lib2=~/programs/library2/2.4.1 && make && make install

      The system symlinks simplify the process by automatically linking to library1/1.2 and library2/2.4.1 from /usr/lib and /usr/include so the last configure can automatically find them without extra command-line options. None of this is new (gobo goes back more than 10 years and the idea of home-directory installation goes back much farther).

      What is new is the ability to provide per-program views of the system links so program1 may see library1/1.2 and library2/2.4.1 while program2 will see library1/1.2 and library2/1.2.

      I simplified the above explanation a bit, the actual links are more like: /usr/bin -> /System/Binaries ; /usr/lib -> /System/Libraries ; /System/Libraries/liblibrary1.so -> /Programs/library1/1.2/lib/liblibrary1.so ; /System/Libraries/liblibrary2.so -> /Programs/library2/2.4.1/lib/liblibrary2.so ; /System/Binaries/program1 -> /Programs/program1/bin/program1 ;

    6. Re:sounds like Mac OS X app resources by gweilo8888 · · Score: 1

      Since when did we let prior art get in the way of junk patents?

    7. Re:sounds like Mac OS X app resources by caseih · · Score: 2

      GoboLinux has been using symlinks to do this sort of things for years now. Don't think patents have any part of it. NextStep also used to do it.

      I think the overlay file system idea is a very good one. It's a nice compromise between full containers and just wanting to run an app that has particular dependencies. Especially if you don't particularly want or need the kind of isolation docker has. Though perhaps isolation as a fundamental aspect of the OS security like QubesOS will become ubiquitous in an increasingly dangerous computer world.

      I find it sufficiently interesting that I may download it and try it in a virtual machine.

    8. Re:sounds like Mac OS X app resources by pixel+sorceress · · Score: 2

      A very fair point. This is the company that managed to patent "rounded corners", and "moving your finger in a line across a touchscreen (to unlock the device)".

    9. Re:sounds like Mac OS X app resources by Anonymous Coward · · Score: 0

      one directory for each app is also part of GNU Guix, and also the paradigm of GNU GSRC (Gnu Source Release Collection) gnu.org/s/guix and gnu.org/s/gsrc
      as well as GNUstep

    10. Re: sounds like Mac OS X app resources by tigersha · · Score: 1

      Bingo

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    11. Re:sounds like Mac OS X app resources by Burz · · Score: 1

      I think both Qubes and Gobo are interesting, but to me Gobo's promise was about making the system more sane and manageable to both app developers and their users.

      OTOH, this filesystem virtualization could be a nice compliment to AppArmor and maybe enhance security. The underlying problem remains, however: Relying on security features provided by a huge monolithic kernel is always a risky proposition. At the end of the day, I'll organize my computing by threat model (Qubes domains) instead of by convenience (OS X, Gobo).

    12. Re:sounds like Mac OS X app resources by Burz · · Score: 1

      Ubuntu also has something similar now: http://snapcraft.io/docs/core/...

  2. chroot by Anonymous Coward · · Score: 1

    So... they re-invented the chroot?

    1. Re:chroot by fahrbot-bot · · Score: 2

      So... they re-invented the chroot?

      Sounds more like UnionFS.

      --
      It must have been something you assimilated. . . .
    2. Re: chroot by HishamMuhammad · · Score: 1

      we do use unionfs (more specifically, overlayfs) combined with per-process mount tables (like containers do).

      --
      The filesystem is the package manager
  3. and it does not use systemD by FudRucker · · Score: 1

    thats great!!! being an old school Linux user that learned how to use Linux on mostly Slackware and the older Debian with sysv i prefer non-systemD distros, i just may give this distro a spin within the next few days, and i like the new idea of portability for multi arch software since all my machines are 64 bit, and since slackware has kept its 64 bit build strictly 64 bit and getting a slackware install to go multi arch requires jumping through hoops i been leaning on non-systemd forks of debian, antiX-16 is good, same with MX-16 it is good too,, looks like Gobo is going to be taken for a spin in an extra disk partition on a thinkpad and my desktop before the end of the year, Thanks :)

    --
    Politics is Treachery, Religion is Brainwashing
    1. Re:and it does not use systemD by SumDog · · Score: 2

      I too was impressed by what I've seen. I don't like the idea of monolithic apps that we see in MacOS and even with newer Linux package managers like Snappy. They seem to have combined both single application folders while also not repeating dependencies. The symbolic linking looks a bit messy, but so long as they have good tooling around it, it could be really beneficial. Their Current links seem to take the place of eselect in Gentoo or etc-alternatives in Debian/Ubuntu.

      I might give this OS a shot. I recently tried Void Linux on my custom router and am very impressed by it and its use of the runit init system:

      http://penguindreams.org/blog/building-a-thin-itx-router/

    2. Re:and it does not use systemD by Burz · · Score: 1

      Which means its ability to handle system events and manage power must be sh!t. I remember the first time I booted an OS X system that had LaunchD; It only took a few minutes to know it was better. Had the same experience when Ubuntu got Upstart.

    3. Re:and it does not use systemD by Burz · · Score: 1

      "Monolithic apps" is nothing but a formal acknowledgement that the OS stops providing APIs at some boundary. This helps keep both the OS and the app(s) well-defined. What an app needs beyond that point should be supplied by the app's author. Windows follows this model to a certain extent as well as OS X.

      OTOH, Linux distros have taken the management model for OSs internals and extended it into applications. This reduces the apps' integrity as a separate (if dependant) thing.

      OS maintainers should not be meddling in app packaging to the extent they do on regular Linux distros. It means that every app must be chewed-up into little pieces and sprayed around different places in the filesystem. It means your app will be paired with library revisions it was never tested with, not just for traditional OS functions but also for a lot of the features that make the app(s) interesting. It means app developers have to track the developments in 1,000 different projects instead of worrying about Apple/Microsoft + the 4 extra libraries added to their app. This is one of the reasons Linux repels app developers, and people more intelligent than me, like Mark Shuttleworth, have complained about it for a long time.

      Here is Ubuntu's solution - https://www.ubuntu.com/desktop...

  4. Wrong /etc/hosts by Anonymous Coward · · Score: 5, Funny

    I can see the discussions in 5 years:

    1> I put it in /etc/hosts but it doesn't resolve
    2> Ok, you also need to add an SE Linux permission
    1> Did that, but it still doesn't respond
    2> Wait that /etc/hosts is the one used by chrome, you need to modify the ones for firefox and ssh too
    3> CAN YOUR ADBLOCK DO 16 THINGS? HOSTS ENGINE MODIFIES ALL /ETC/HOSTSEES WITH SIMPLE SCRIPT

    1. Re: Wrong /etc/hosts by Anonymous Coward · · Score: 0

      Quickly followed by a bunch of run forrest runs, bold text and quotes taken out of context.

    2. Re: Wrong /etc/hosts by Anonymous Coward · · Score: 0

      Mocking the great APK? You've made a great blunder!

    3. Re: Wrong /etc/hosts by paranoidd · · Score: 2

      Note that settings files are not overlaid by GoboLinux's virtualization tool. Runner only creates customized views of bin, lib, include, share, libexec, and sbin -- your typical /usr tree. So, unless somebody borrows this idea and apply it poorly on another distro, there is no chance this particular discussion will take place in 5 years from now. :-)

  5. Oh wow by Anonymous Coward · · Score: 0

    I haven't played with Gobo in close to... 10 years... And I really liked it, but not everything wanted to cooperate with it.

    How exciting!

  6. Oh boy! by ArchieBunker · · Score: 1

    Sounds like an open invitation for gaining root access.

    --
    Only the State obtains its revenue by coercion. - Murray Rothbard
  7. Those who do not know Unix... by OneHundredAndTen · · Score: 1

    ... are destined to reinvent it - poorly. GoboLinux, a new member of the club.

    1. Re:Those who do not know Unix... by guises · · Score: 1

      GoboLinux isn't new at all, they've been around since 2003. Sure they're newer than Slackware, but by Linux standards they've been kicking around for a long time.

    2. Re: Those who do not know Unix... by HishamMuhammad · · Score: 5, Informative

      This link is a bit outdated (for instance, we don't tweak the root user for years now), but I've already responded to some criticism of this kind back in 2004: http://gobolinux.org/doc/artic...

      --
      The filesystem is the package manager
    3. Re:Those who do not know Unix... by Anonymous Coward · · Score: 1, Insightful

      Those who don't know Unix... think many of its most glaring warts and systemic problems are actually computing perfected, and to try to improve any of those shortcomings is to commit blasphemy.

    4. Re:Those who do not know Unix... by Anonymous Coward · · Score: 0

      I'd be interested in reading what you think are the warts of UNIX design. Seriously. I don't believe UNIX-style is perfect but I've done (and learned) so much more on GNU/Linux systems than anything else, so it'd be nice to read a (hopefully civil) nitpick.

    5. Re:Those who do not know Unix... by Anonymous Coward · · Score: 0

      This book is old but the Unix Haters Handbook discusses many issues about how Unix evolved beyond its initial designs.
      http://web.mit.edu/~simsong/www/ugh.pdf
      http://wiki.c2.com/?TheUnixHatersHandbook

  8. Amiga did this back in the 80's! by gabrieltss · · Score: 3, Interesting

    The Commodore Amiga did this back in the 80's. Any installed programs installed all their files in a single directory. It allowed you to copy that directory ANYWHERE on the filesystem and you could still run it.

    Nothing new about this idea.....

    --
    The Truth is a Virus!!!
    1. Re:Amiga did this back in the 80's! by thegarbz · · Score: 1

      I didn't realise that Commodore Amiga ran Linux. Kind of the point of the article is that the idea is most definitely new in the Linux world.

    2. Re:Amiga did this back in the 80's! by gabrieltss · · Score: 1

      Actually not only did I run Amiga OS on it I ran the Commodore System V Unix on it AND I got Slackware to run on it.

      --
      The Truth is a Virus!!!
    3. Re:Amiga did this back in the 80's! by Anonymous Coward · · Score: 0

      And, he did it all with his huge penis. His huge, Slackware-enabled penis.

      Some people accomplish things. You do not. Deal with it.

    4. Re: Amiga did this back in the 80's! by tigersha · · Score: 1

      Same way macosx works today, mostly

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    5. Re:Amiga did this back in the 80's! by drinkypoo · · Score: 2

      The Commodore Amiga did this back in the 80's. Any installed programs installed all their files in a single directory. It allowed you to copy that directory ANYWHERE on the filesystem and you could still run it.

      First, the Amiga didn't have that. Lots of programs forced you to dick around with assigns to get them to run. It was copy the directory anywhere, and then dick with your startup-sequence.

      Further, it seems from your comment that you believe that this is a system for Linux which mimics OSX packages. It isn't. What this system is actually doing is creating a "container"
      (a set of mounts, really) dynamically for every process, so that they see a subset of the filesystem as if it were the entire filesystem. The Amiga definitely didn't do that.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Amiga did this back in the 80's! by Anonymous Coward · · Score: 0

      The Commodore Amiga did this back in the 80's. Any installed programs installed all their files in a single directory. It allowed you to copy that directory ANYWHERE on the filesystem and you could still run it.

      First, the Amiga didn't have that. Lots of programs forced you to dick around with assigns to get them to run. It was copy the directory anywhere, and then dick with your startup-sequence.

      No idea what you are talking about. I moved my program folders all the time to customize my system layout and never had to change any "startup-sequence" or anything.

    7. Re:Amiga did this back in the 80's! by Burz · · Score: 1

      By the time you get to AmigaOS 3.x (probably 2.x), an app author could choose to have their non-OS dependencies all relative to the app dir. The only exception was something that required a new hardware driver. Of course, there were a few large libraries (one add-on widget set, as I recall) that developers wanted to treat as a common resource.

      The Amiga did "do that" to an extent, but the built-in OS functions were too sparse to avoid the developer interest in shared, third-party libraries and runtimes.

  9. Oh boy! Fwaggles! by Anonymous Coward · · Score: 0

    Fraggle Linux!

  10. Didn't MS-DOS do this? by walterbyrd · · Score: 1

    Everything about dBase was in your dBase directory, etc.

  11. Relational filesystems? by enrique556 · · Score: 1

    Remember WinFS: Microsoft's aborted attempt at a relational filesystem? I thought it was a great idea and expected the concept to take off across the board, but it went nowhere.

    Such a thing could solve this problem and many others in a more elegant and comprehensive way, at a much lower level of the os/filesystem.

    I'm sure there's a good reason it's dead - performance maybe? Anyhow, emulating a default directory structure, permissions, and app-specific directory structure would be trivial to implement on top of such a thing.

  12. Nuke it from orbit, it's the only way to be sure. by RealGene · · Score: 1

    ..which is how I prefer to delete applications. This is simple and sensible, which is why it will probably never catch on.

    --
    Mission: To provide products that consume time and energy as entertainingly as permitted by the laws of thermodynamics.
  13. Re: Nuke it from orbit, it's the only way to be su by HishamMuhammad · · Score: 1

    Amusingly, in GoboLinux you can nuke a program with a single rm -rf since everything is under the /Programs entry, while in other distros you must rely on the package manager (or essentially manage packages by hand yourself).

    --
    The filesystem is the package manager