Announcing GoboLinux 017.01 - Passing the Torch 🔥

[nuc1eon]

We are pleased to announce the release of GoboLinux 017.01, an eagerly awaited bug-fix update that addresses several critical issues since the 017 ISO release!

Along with this release, Hisham Muhammad, founder and steward of GoboLinux for the past 25 years, is officially stepping down! The project now continues under the stewardship of @nuc1eon.

Hisham's vision and dedication have shaped GoboLinux into a novel experimental distribution, pushing past the perceived boundaries of traditional Unix concepts. We thank him for his remarkable contribution to the Linux community. As Philip takes over, the project is set to continue evolving in new and exciting directions!

Special thanks goes out to Lucas Correia Villa Real (aka paranoidd) who had been maintaining GoboLinux unwaiveringly along with Hisham up until June 2021.

Stay tuned for future updates as the project transitions to its next phase!

We extend our gratitude towards our contributors, who shaped this release: Sage I. Hendricks (@sage-etcher), @xplshn, Rune Morling (@ermo), @thebitstick, Jean-Michel T.Dydak (@yann-kaelig), Samuel Dionne-Riel (@samueldr)... plus countless others!

For changes in detail please consult our release notes. Grab your ISO here.

[rubyFeedback]

I just read it on distrowatch.

I have three desktop computer systems at home (one is very old, one is semi-old, one is modern, my main computer that is); two of these can run linux, the current one here, and the one to the left side. (I also have a laptop, but this one I don't tamper with at all really, as it must reliably work, for work-related tasks.)

On my left system I installed MX-Linux a few days ago. I'll continue testing it. I have a few go-to points to test there; two I want to test are updating the linux kernel more easily, as well as updating the glibc version (probably using a variant that LFS/BLFS uses, e. g. having a separate toolchain available and using this to recompile everything).

Having read the announcement for GoboLinux new version released recently, though, it makes me want to test gobolinux on that machine. So, next installation candidate for that machine on my left side is GoboLinux.

I have a ton of scripts written in ruby that may be helpful for GoboLinux. If there is a want, I can also begin to try to update the GoboLinux related ruby scripts, even though others wrote it. (For this I would probably add the toplevel namespace "module GoboLinux"; right now I can not find them, but I am about 100% certain there used to be some ruby scripts). Anyway, I'll begin to clean up my local documentation first, slowly; I used to write some documentation for me back when I was using GoboLinux more frequently.

I guess Passing the Torch will take a little while - probably one of the more useful things is to start somewhat slowly, and wait to see how many old folks re-emerge, and how many new folks may come.

Some of my own ruby scripts I have to update once I have a GoboLinux system again. In theory I should be able to autogenerate all GoboLinux recipes, for instance, as most of the dataset I already have described in .yml files (this was my go-to format; short .yml file, which is then expanded into a full .yml set, which can then be used e. g. for SQL or any other format).

By the way, Hisham and Lucas had some ideas in regards to new ideas for GoboLinux, be it AlienFS and so forth; in this regard NixOS I also find somewhat related to GoboLinux (they also use one versioned directory, though the version they use for the name is that hash). If you find some time in the future it may be interesting to have a few ideas, no matter if old or new, to be specified somewhere, similar to Hisham's old inspirational "I am not clueless" article.

It would also be nice if GoboLinux could, in the long run, specify things more strictly. With that I mean, e. g. the individual tasks performed by various scripts. That way people could then adhere to a specification and write conforming code. Also, individual tasks could be specified and streamlined more easily; for instance I was never absolutely sure how to download a new kernel, apply gobohide to it, then compile it. I do not remember if we have any such document, but if not then it would be nice to have it, so people could update things on their own, even if they do not understand what these patches, such as gobohide, would do. Anyway best wishes to everyone.

[daemonspudguy]

I had been following GoboLinux for a few years up until it stopped being worked on for so long and honestly had written it off as dead. I'm happy to see that it's back.

[ermo]

Hi there and thanks for the shoutout Philip. 😅 🤗

I wish you the very best in this endavour and I hope you get to have a lot of fun along the way! 🚀 🖖

[nuc1eon]

You're welcome Rune! You've had contributed a lot in the initial days of 017, so it was only fair to give you a shoutout! ☺️

Thank you so much... there's a lot of work to be done (as you know lol), so keeping fun at the forefront is an excellent approach - thanks my friend for the reminder! 🚀🖖

I wish the same for your endavour as well!:)

[xplshn]

I'm so glad it is back, having an updated kernel and libraries is a welcome thing.
Perhaps some efforts could be directed to making two releases, a barebones rootfs and a full-fledged live ISO.

The first would be for testing, and developers, etc.
And the second for end-users.

A rootfs would be useful for anyone that wants to make a derivative of Gobo. Perhaps also a rootfs+kernel release.

---

I have some experience with Github Actions, so if @nuc1eon could guide me, I'd be more than thrilled to try and do this.

[nuc1eon]

I think that's an excellent idea! Please feel free to do this, contact me anytime:)

PS: I am aware the ISO currently has accumulated some 'junk' - this will be tackled in our next releases (so hopefully the ISO size should shrink).

[xplshn]

I think that's an excellent idea! Please feel free to do this, contact me anytime:)

PS: I am aware the ISO currently has accumulated some 'junk' - this will be tackled in our next releases (so hopefully the ISO size should shrink).

If you can outline how to create a rootfs, then an ISO, from within another distro, I can try to do it in GH actions

NOTE: Once the GH action can produce at least a rootfs, all following releases would be made using the last GoboLinux rootfs :)

[nuc1eon]

Yes. Atm (I think since the 017 release) we are "cheating". That means we are simply editing the current ISO with this script: RefreshLiveCD (it uncompresses the ISO, lets one add packages or edit the rootfs directly - and eventually re-compresses a new ISO). But some stuff from its main repo BuildLiveCD could prove useful to you.

However for your endeavor you'd have do it the right way (which we will have to re-adapt eventually in any case!), that would mean figuring out GoboALFS: GoboALFS (checkout CreateGoboLinuxTree within that repo).

The init scripts for the ISO are in the InitRDScripts repo.

Also see https://github.com/gobolinux/LiveCD and https://github.com/gobolinux/ConfigTools.

We sadly lack documentation for this process, and once it it "re-figured out" we should add it to our wiki to the How-To section to give a clearer picture how these parts fit together. @lucasvr is the one with the best knowledge on this process (maybe he chimes in to share some tips), but you might have to figure it out on your own.

Hope that helps.

[rubyFeedback]

We sadly lack documentation for this process

I think this was in part always a problem in regards to GoboLinux, even in the past. Now,
documentation has improved since 2004, but many things are not well-specified, in
particular some of the scripts' behaviour. If possible I would think that it may "pay
dividends" so to speak if we can more formalize the required tasks and steps to be
taken, such as AlienFS. The automated-Gobo we can probably re-create without a
problem (a package that works in LFS/BLFS will almost always also work on GoboLinux).

One reason why I think a more formalized specification may be useful is not only in
regards to better documentation in general, but also when people want to re-create
the logic in other programming languages, be it ruby, python, lua - you name it. Or
shell scripts, too, though I personally do not use shell scripts. A more formalized
documentation can also help in regards to e. g. errors or problems such as the
default installer not working. With a specification folks can probably work around
it on their own. (Perhaps we can also isolate the steps taken by Installer via a
second rescue-GUI or so, or an advanced Installer, where the individual steps +
invocation is shown. Right now the Installer seems to cater primarily to the less
computer-savvy folks, which is perfectly fine, but I am kind of used to more
detailed explanation such as LFS/BLFS, which I think helps with learning and
remembering too. Anyway, more on that later; for the time being I have slackware
installed on the computer to the left, but I can install GoboLinux again without a
problem. There are some things I want to improve in my scripts first. I have all
the major KDE components registered, by the way, so I should be able to have
this on GoboLinux as well eventually; need to do manual installation next time
I guess, if Installer does not work.)

[rubyFeedback]

By the way here is also a short-ish review in regards to GoboLinux, from April 13, 2025:

https://www.howtogeek.com/what-is-gobolinux/#:~:text=What%20It's%20Like%20to%20Use,is%20quite%20a%20nice%20desktop).

"I decided to abandon any installation attempts and work solely from the live environment to test this distro."

This part probably works now, thanks to sage-etcher and Nuc1eoN. There are a few other small-ish
things we could perhaps improve on in the main installer in the long run. For instance, we could
select a default keyboard (say, english), and then allow the user to change it via some option or
so. I am not too familiar with ncurses, but it could perhaps be an entry on the right side. And a
few other small-ish changes, like the "check for validity of the filesystem layout". Anyway, just
mentioning this a little bit. I'll probably try to have GoboLinux work via qemu, such as Nuc1eoN
did; once I have a working GoboLinux installation I am reasonably confident to be able to
update my own scripts and then test contributing various recipes - hopefully that part works. \o/