Introducing GoboLinux 016

[Posted December 16, 2016 by jake]

The GoboLinux project has announced the release of GoboLinux 016. The distribution takes a different approach to filesystem organization so that multiple versions of programs can all be installed at the same time. GoboLinux 016 has a new feature called Runner to manage that: "Runner is a brand new filesystem virtualization tool, specifically designed for GoboLinux. It dynamically changes a process' view of /System/Index based on the program's Dependencies file. From day one, GoboLinux has always supported keeping multiple versions of a program installed on disk at the same time, but when two versions had conflicts, you had to choose which one would be activated in the system as the default. With Runner, you don't need to worry about which version of a given dependency is currently linked (or activated) in /System/Index: Runner gives the process its own virtual /System/Index with all the right dependencies." Other features include the GoboNet wireless network manager and a desktop based on the awesome window manager.

Introducing GoboLinux 016

Posted Dec 16, 2016 18:52 UTC (Fri) by kash (guest, #113061) [Link] (1 responses)

If you enjoy the GoboLinux philosophy you should check out nixOs (and nix) - they have the same goals but they seem less of a hack

Introducing GoboLinux 016

Posted Dec 24, 2016 7:11 UTC (Sat) by mathnerd314 (guest, #108688) [Link]

They are pretty similar in terms of filesystem layout although NixOS tries to follow FHS in a few places. Also Nix adds a hashing scheme, which is both useful (for dependency detection & library flavors) and a curse (as it often means the entire package tree must be rebuilt)

/Programs/$name/$version/ <-> /nix/store/$hash-$name-$version
Resources/Dependencies <-> nix-support/*-inputs + a hash-scanning scheme
/System/Index <-> /run/current-system/sw
/System/Settings <-> /etc

Introducing GoboLinux 016

Posted Dec 16, 2016 20:31 UTC (Fri) by roskegg (subscriber, #105) [Link] (1 responses)

Was GoboLinux inspired by Plan9? Sounds like there is some philosophical similarity. Or at least, they are trying to do some of the same things that Plan9 did so well. Be nice to have a Plan9 distro based on the Linux kernel.

Plan9

Posted Dec 18, 2016 22:29 UTC (Sun) by lucasvr (guest, #110284) [Link]

The technical papers published by the Plan9 group are truly inspirational and did influence GoboLinux to some extent. Plan9's ability to create custom filesystem views for different programs by binding and mounting files onto a process namespace, for instance, reflects a bit on GoboLinux Runner's design -- although that's more of a happy coincidence. Gobo doesn't have the ability to seamlessly overlay-mount remote programs and files (yet), but once that feature arrives we may have a more clear correspondence between the two.

Introducing GoboLinux 016

Posted Dec 18, 2016 16:58 UTC (Sun) by rsidd (subscriber, #2582) [Link] (3 responses)

It sounds like the varying-views problem is what variant symlinks (LWN link from earlier this year) are meant to solve? Dragonfly BSD has supported variant symlinks for 12 years now, with this as one of the goals if I remember right, but I don't think they have done anything very useful on these lines so far.

Variant symlinks

Posted Dec 18, 2016 18:09 UTC (Sun) by lucasvr (guest, #110284) [Link] (2 responses)

I would say that variant symlinks could solve a subset of the problem. If you have a more complex arrangement of conflicting dependencies (say, Foo v1 provides a large libfoo.so, but Foo v2 splits that into two smaller files libfoo-base.so and libfoo-utils.so), then simply replacing the target of the symbolic link won't work; you would need to create (or remove) links on demand as well.

Variant symlinks

Posted Dec 19, 2016 17:35 UTC (Mon) by burdi01 (guest, #65371) [Link] (1 responses)

In the Gobo case Foo v1 and Foo v2 would be kept in separate directories, so there would be no problem.
:D

Variant symlinks

Posted Dec 19, 2016 18:37 UTC (Mon) by lucasvr (guest, #110284) [Link]

Precisely. I have thought this was implicit on my original reply -- thanks for emphasizing that.