GoboLinux 016 Released With Its Own Filesystem Virtualization Tool (gobolinux.org) 47
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."
"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."
sounds like Mac OS X app resources (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Ubuntu also has something similar now: http://snapcraft.io/docs/core/... [snapcraft.io]
Re: (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 ./configure --prefix=~/programs/library2/2.4.1 && make && make install ./configure --prefix=~/programs/program
$
$ cd ~/source/library2-v2.4.1
$
$ cd ~/source/program1-v3.11
$
Re: (Score:3)
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)
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
Re: sounds like Mac OS X app resources (Score:2)
Bingo
chroot (Score:1)
So... they re-invented the chroot?
Re: (Score:3)
So... they re-invented the chroot?
Sounds more like UnionFS [wikipedia.org].
Re: chroot (Score:2)
we do use unionfs (more specifically, overlayfs) combined with per-process mount tables (like containers do).
and it does not use systemD (Score:2)
Re: (Score:3)
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)
"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)
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)
I can see the discussions in 5 years:
1> I put it in /etc/hosts but it doesn't resolve /etc/hosts is the one used by chrome, you need to modify the ones for firefox and ssh too /ETC/HOSTSEES WITH SIMPLE SCRIPT
2> Ok, you also need to add an SE Linux permission
1> Did that, but it still doesn't respond
2> Wait that
3> CAN YOUR ADBLOCK DO 16 THINGS? HOSTS ENGINE MODIFIES ALL
Re: Wrong /etc/hosts (Score:2)
Oh boy! (Score:2)
Sounds like an open invitation for gaining root access.
Those who do not know Unix... (Score:2)
Re: (Score:2)
Re: Those who do not know Unix... (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... [gobolinux.org]
Re: (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.
Amiga did this back in the 80's! (Score:4, 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.....
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: Amiga did this back in the 80's! (Score:2)
Same way macosx works today, mostly
Re: (Score:3)
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 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.
Didn't MS-DOS do this? (Score:2)
Everything about dBase was in your dBase directory, etc.
Relational filesystems? (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
Nuke it from orbit, it's the only way to be sure. (Score:2)
Re: Nuke it from orbit, it's the only way to be su (Score:2)
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).