DEV Community: Yappaholic The Junior

The wicked path of independent Linux Distro

Yappaholic The Junior — Thu, 07 Nov 2024 15:49:01 +0000

Preface

Some time ago I wrote a post about Helix editor and questioned it existence. Since then I learned a lot(at least what Kakoune is) and started to grasp more about linux and why it is awesome (i.e. started distrohopping).

Anyone with enough Linux experience will tell you that to be a real Linux user You need to pick the MOST niche distro possible, and the less actual features you get from it the better. That's why I, as a real embodiment of ~~SoyDev~~ GigaChad, decided to move to NixOS and Gentoo, last being more preferred.

But at some point I encouraged myself to look up the source code for Portage, the Gentoo package manager. And lo and behold, almost everything is Python code. The view of it filled me with the rage of thousand suns and from that point all I thought about is making me own distro. So ladies and gentelmen, I am showing you

The Cave Linux

Imagine that the logo is finished... just as the other part of distro ;)

So, lets get it clear about what is what. The Cave Linux is going to be an independable meta Linux distribution powered by Zig with fast package manager called Grit. Grit is supposed to be blazingly fast, with minimal to zero headache on configuring and with nice CLI experience.

The big benefit of having Zig is that it ships with LLVM C and C++ compiler, which means that
a: No need to compile compiler, which takes eternity
b: Almost everything can be built using Zig only and not relying on GCC/Clang

Right now the path is hard, because to build the package manager from scratch one should use a lot of time and patience(and make a scripting language at some point).

But why not use Python/Nix/Bash/XYZ language?

The reasons for that are simple, really:

I don't want to build another nix wrapper, because anyone can get fresh Linux From Scratch build, slap nix on top and voila, distro is ready!
No python because I think there should be less need for system resources from the package manager itself, especially on slower hardware.
As one great 10x developer said "If you get to the point of writing for loops in Bash, you are doing something wrong with your life".
And not others because most of them are stinky for me (especially C/C++ or God forbid Rust).

But why make another distro?

Well, why not? At the end of the day, the amount of raw experience you get from making something like this is IMMENSE(making your own config language, parser, transpiler, database, installer, package manager and shipping it all within one tarball). Also because

F##K IT WE BALL

So what are the future goals?

Right now the most important things for this project are:

Try and build whole Linux with just Zig.
Write my own scripting language which will then build the package.
Make a site for the documentation and quirks of the distro(probably going to use functional language for that).
Pack everything in a tarball an let others try it out.
??? PROFIT!!!

Now, if you got somewhat interested or if your body is trembling in front of my personal Frankestein, I suggest you check my repository, when I try to make Grit a real thing to use. And thank you for your time reading this!

Helix Editor: a matter of questionable existence

Yappaholic The Junior — Sun, 09 Jun 2024 19:11:24 +0000

As a learning junior dev, I went from the depiction of soyest dev imaginable(python my beloved, windows and VS Code) to the true struggle and learning enjoyer(Neovim btw, Arch btw and Typescript(bearable)). So recently I landed my vim-motions on the helix editor to try and figure out: was it really necessary for helix to exist or should you try it out as a vimmer?

Prelude

From the start we should talk about the origins of the helix editor. Just as JavaScript came from Java, Helix came from Kakoune. What is Kakoune you ask? I have no idea, neither should you. All you should know is that Helix has a lot of similarities of vim and vim-motions but then it takes a rather strange approach to solve same problems. Let's take a look.

Selection over action

You heard it right. No more double y to copy line or double d(eez nuts) to delete line, Helix thinks otherwise. First you gotta select a line and then manipulate it. You think "Okay, just let me use visual block with V" and you wrong again. No more visual blocks, it's a matter of the past, now you need to use x to select line and x again to move one line down.

Okay, maybe I can start selecting at the start of the line and then use 0 to go to the end of the line, right? Right?

Sike! Helix thinks you are lazy to learn vim bindings, so now movement is bound to "go to"(or g) movement. To go to the end of the file, use ge and to select a line and go up you need to use vglk, when in vim you can just do Vk. Do you feel post-modernity yet? If not, then we go deeper.

Plugin system

Just as PlayStation 5 has no games, Helix editor has no plugin system yet. They are going to implement it using Lisp language and connecting it to Rust with some Steel plugin(did I mention it is written in Rust?) which is old and not post-modern at all. Forget about git with fugitive, forget about managing files with oil(also at the moment there is no file traversal in Helix except :open command and fuzzy finder), and the most important, no more file harpooning.

Instead, Helix comes with a lot of built-in stuff like fuzzy finder, tree-sitter, autocompletion, key bindings helper, diagnostics and lsp support when you install a correct language server. It is enough to make editor work with code but not enough to make it a complete IDE-like editor, so to get the most out of it modding community should do a lot of heavy lifting.

Too much FZF

Working with Helix feels kind of okay. You got most of the stuff done, autocompletion is snappy, files open a bit faster, but then you notice: there is too much fuzzy finder! Literally, it makes a lot of stuff. Diagnostics? FZF. File picker? FZF. Tree-sitter objects? FZF. Special names in the code? FZF. Hotel? FZF. Brazil? Mentioned.

Don't get me wrong, I think that fuzzy finder is awesome, but it has it's own caveats and is some cases it's better to use something else. For example, you can't really manipulate folders and files with FZF and when(as I understand) using FZF it goes through every folder no matter what you want to search and shows everything. That's when you want to search for something and get a screamer with all node_modules files. Yuck!

Configuration

Configs for Helix are written in .toml format, which is still better than some other options available(talking about you, ĴSON). Some terminal emulators and bun runtime also use toml to configure settings so you can get comfortable, and documentation covers enough settings to make experience personal and comfortable(no plugins tho).

"Post-modern" editor

At the end, Helix Editor is a sort of chimera from scrapped vim-motions, LSP, Tree-sitter, FZF and some other popular plugins from vim.

The main reason I don't like Helix isn't because there are no plugins, even though the version number is almost close to the one in emacs, but because of the motions. Vim-motions are designed with idea of mnemonics and being fast. When vim's g is responsible for many movements it makes sense, because it is short to "go". So G is going to the end, gg is going to the start, gf is to go to the closest matching character(the only gf you'll have), gd is to go to the declaration and so on. In Helix it is scattered everywhere and g is more like a leader key for other keys, so now you gotta make more hand movement and keystrokes. Just why? This is why sometimes it is better to stick with old ways, even when they are old. And also text wrapping is awful, just going to leave it there, think for yourself at least once.

So that's my thoughts about Helix Editor. Stay tuned to see how I test warp terminal to save you a couple of keystrokes, like a GigaChad.