Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Open Source Operating Systems Linux

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

Posted by EditorDavid 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."
This discussion has been archived. No new comments can be posted.

GoboLinux 016 Released With Its Own Filesystem Virtualization Tool More

GoboLinux 016 Released With Its Own Filesystem Virtualization Tool

Comments Filter:

  • 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

    • 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.

      • Re: (Score:2)

        by nawcom ( 941663 )
        The bundling style from OS X is an evolved version of NeXTSTEP application bundling from 1989.
      • Since when did we let prior art get in the way of junk patents?
        • 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)".
    • 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.

    • Re: (Score:1)

      by Anonymous Coward

      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/program

    • Re: (Score:3)

      by caseih ( 160668 )

      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 i

      • Re: (Score:2)

        by Burz ( 138833 )

        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

  • chroot (Score:1)

    by Anonymous Coward

    So... they re-invented the chroot?

  • 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

    • Re: (Score:3)

      by SumDog ( 466607 )

      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 recen

      • Re: (Score:2)

        by Burz ( 138833 )

        "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 meddl

    • Re: (Score:2)

      by Burz ( 138833 )

      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.

  • Wrong /etc/hosts (Score:5, Funny)

    by Anonymous Coward on Saturday December 17, 2016 @03:02PM (#53504117)

    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

    • 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. :-)

  • Sounds like an open invitation for gaining root access.

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

  • Amiga did this back in the 80's! (Score:4, Interesting)

    by gabrieltss ( 64078 ) on Saturday December 17, 2016 @05:51PM (#53504889)

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

    • 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.

      • 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.

    • Same way macosx works today, mostly

    • 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

      • Re: (Score:2)

        by Burz ( 138833 )

        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.

  • Everything about dBase was in your dBase directory, etc.

  • 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

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

Slashdot Top Deals

Today is a good day for information-gathering. Read someone else's mail file.

Close