Gobolinux + tinycore

#1

Hello everyone.
I’ve following gobolinux for about 2 years now and really like the concept as i can help low-tech users have access to a more understandable console environment, whiie retaining standard linux compatibility.
Another project I like, when related to embedded small distros mainly, is http://tinycorelinux.net/ because of its robutstness and speed.
While I’m a daily linux user and occasionnel programmer, i’m unable to figure out the answer to the following question :
“Would it be possible to mix gobolinux AND tinycore ?” probably by applying the gobolinux concept to a tinycore distribution ?

thanks for you tips

#2

Hello, @jerash!

That’s feasible, but you’d have to ask yourself what’s the advantage of mixing two distros when TinyCore already provides a packaging system. Despite the directory tree, GoboLinux comes with its own set of scripts to manage the installation/activation/deactivation/virtualization of programs. It also comes with its own set of scripts to manage boot tasks that are likely to be incompatible with what TinyCore uses.

Having said that, it shouldn’t be too difficult to get started. If you’d like to try it out, my suggestion for you is to look into the following resources:

  1. The CreateGoboLinuxTree script
  2. A minimalist version of the SymlinkProgram utility, written in C. It depends on the LinkOrExpandAll script that’s part of the same package. See the project’s Makefile for instructions on how to build them
  3. A tiny “which” wraper so you get the path to /Programs instead of /bin when checking where a given executable is installed
  4. Our RemoveBroken utility that cleans up broken links after a program has been uninstalled/deactivated
  5. The GoboHide kernel patch and its userspace tool can be used to hide the legacy directories and symlinks from your new rootfs
  6. Our Scripts package has several more utilities under bin and src that you may want to look too

Once you’ve got the basics, you’ll want to have a wrapper around TinyCore’s package manager so that it uncompresses the package under /Programs/Name/Version and then invokes SymlinkProgram to activate the program on /usr (/System/Index). You can also have wrappers around the uninstaller (so that broken links are automatically removed from /System/Index).

And that’s pretty much it.

Please let us know if you decide to go forward with this idea and do share your achievements with us! :slight_smile:

#3

Hi,
many thanks for the detailed information. To be honest this is probably too much for me right now, but i’m happy to hear this can be done, and worth a test.
I may need a year or two before it is started, but as i’m still dreaming about the optimal linux system (from my personal point of view) this will slowly live its life in my brain and some part of a hard drive before reaching completion.
Have fun in between, and receive my congratulations for all your excellent work !

1 Like
#4

So, this is a really neat idea, and I think I may do it, but not with TinyCore. I am thinking something more like a self-hosting musl+busybox+linux system that then utilizes a GoboLinux-like file hierarchy. It would make 1/2 of the package management job absolutely simple. In this scenario, a version of Compile written in just SH would read a dependency list, make sure the dirs exist, and then proceed to build and move the given package, and then call SymlinkProgram. Removal would be as easy as rm -rf /Program/Package/Version and then run RemoveBroken. This wouldn’t be as advanced as Gobo proper really, but it would accomplish something similar with a smaller system.

The main question for me would really be, does the GoboHide kernel patch require anything specific in the kernel build?

#5

No, you just apply the patch and enable it on make menuconfig (CONFIG_GOBOHIDE_FS=y). There is a userland application to tell the kernel component which directories and symlinks you want to hide. You can find it here on GitHub

#6

That’s really cute, exactly what a lamba user would expect (and what mac osx solds you, but still leaving lots of users data files behind).

In my initial idea, the combo with tinycore was expected because of “robbustness” = Always start from a known state, nothing saved on disk unless explicitely asked by the user, or only on some specified folder. This is good for embedded devices/project.
@GenBuckTurgidson is it a concept you envision or not ?