Hello there! I heard some complains about Garuda editions using only systemd as their init system, using too much RAM and overall being bloated. That's why I want to share what I view as a minimalist Garuda. This might turn into my first serious project, or at least a good concept.
First of all, what does it mean to suck less? In relation to software, it means to be simpler. In unique way. Mainly, in development. It's hard to put everything about suckless programs that I (and many others) like, but generally it's the convenience of using them once you learn how to. More about suckless software In general, programs that suck less tend to:
Be fast
Be privacy-respecting
Prefer quality and simplicity of code over quantity of code (therefore, they are minimalist)
Remember, I haven't said that this software is "easy to use" for an average user. Usually, programs that suck less don't have a GUI, or have a really basic one, and most of the configuration is done in config files rather then on a separate section in the GUI.
That's why this edition of Garuda is so special - it's not for inexperienced users, it's for those who want something small, fast, and configurable.
I will update this thread as soon as I learn about new software that should be included alongside or instead of mentioned below, so feel free to suggest even smaller software.
The main thought is to make Artix-based distro with some tools from Alpine Linux and other tiny distros.
Kernel
I think that you should pick your own kernel for your situation, so it's the discussion about what to include in the ISO.
It's hard to decide what Linux kernel will perfectly fit for most users. There are a some options that I would like to try:
Lts kernels (stability and broad hardware support)
Custom kernels from other minimalist distros like tinycore, Alpine Linux, etc. (potential problems with hardware)
Just a responsive kernel like linux rt, linux-tkg, linux-zen etc. (known hardware issues, but great performance when you are lucky enough to not have any problems).
Default init system
As of now, I think I will choose Runit. It's small and lets you boot really fast even on HDD. Alternatives include OpenRc and s6.
Default packages
This is where I need more investigation as of now, but still can name a few important packages:
-rEFInd as bootloader (less then 4 mbytes, but still does the job)
-dash as default shell
-doas as sudo replacement
-tmux for terminal multiplexing (later about that)
-micro as default text editor
-elinks-git as browser (in case you need arch/gentoo wiki during install)
-libressl-git as replacement for openssl
-rufus or openrc or s6
-zathura as a document viewer
-busybox instead of GNU core utils
Installation
When you boot your live image, my small shell script greets you with a request to input "micro garuda_manual.txt" in order for you to receive all of the needed instructions. Using tmux mentioned above you can split your terminal in order to make installation process more comfy. I might also make a TUI using termbox library, in case it is not enough. Overall, it's just what wasn't enough for perfect arch/artix linux installation.
What kernel(s) should Garuda suckless live use?
linux-lts (default mainline)
linux-tkg
linux-zen
linux-xanmod
linux-rt
Alpine kernel
Tiny Core kernel
Other custom kernel (suggest below)
My own custom kernel (another week for development, lol)
The only reason I said zen instead of lts in case someone has a new computer that lts doesn't work with lts. Otherwise I almost exclusively use the lts.
This is not necessary and will only damage the freedom of choice. In the manual I will recommend these, but including them in the iso will certainly be overkill. The simpler the better
Another day to implement, and it still doesn't really fit. I guess if you want to you can inject resources in the iso yourself, if you need to. Btw, that will be a good page for the wiki/manual
I do like the TUI installer though which gave me an idea. What if we take the archlabs approach where you can (optionally) choose a DE in the installer.
Your idea is not really thought out unfortunately. To use runit, openrc, or s6 and satisfy the purists you need to rebuild every package that uses systemd that is a lot of work to achieve is it not.
Don't get me wrong I use Artix, but as it uses shims it is not systend free, i have also used Void, and Arch based Obarun that is systemd free they are a lot of work to maintain needing their own repros and continually rebuilding packages on a daily basis.
It really is better to use a fixed release in the long run and for stability, I would also consider if you want Arch based to look at Artix as a base, that is not putting this exellent Garuda down in any way Garuda is its own why try to compromise it. Manjaro had big problems trying to support Openrc
I know that this will require a lot of work, and I know that I need to put more thought into it. That’s why I will take my time with this and plan everything accordingly. This is only a raw concept and as I mentioned, I will rewrite some parts and plans.
Probably it will be as other Garuda releases - rolling in the end, but new features in the newer releases.
I was wrong you are putting thought into it. But why not talk this over on the Artix forum we don't bite over their.
Plus good luck I hope all goes well for you.
yeah, but I’m still not sure what exactly do I need to ask there. “Will you help me with something?” “Can I get your permission?”. Or just announce it and get some hate for advertising? I don’t know what to say to them yet, anyway.
Well, Garuda is what people make from it, not what you see in it. It will still be as much user-friendly as possible, without sacrificing the simplicity of code.
I would talk to Artoo he is the lead dev he is a nice guy ask if you can use the repros i'm sure you don't have to but its just polite to do so. i'm almost sure you could volunteer to help the project, and this one as well as long as you acknowledge them with your work the same goes for Garuda that way we could have the best of both worlds init wise. I recomment runit by the way so simple and fast.
I am not quite sure how it’s implemented in Archlabs, but I still think that I will be focusing on the documentation for the CLI installation rather then creating a separate installer. It’s just simpler.
