Vibe Coding with Free Software Philosophy
Introduction
Vibe coding: The act of using AI/LLM models specifically tuned for coding in order that it codes for them, no human touch required.
Derek Ross and his son are into vibe coding, and after this exchange, it gave me an idea. Derek and his son should be able to use Free Software (notice the spelling) to vibe code, so they can put intentional trust into who they want to trust (using the GHOST method).
I will also be turning this into a podcast episode once I know how to structure it… because it will be unscripted.
That said, let me get started with exactly how Derek and his son can go about this (this is why I tagged you in that particular post I made, Derek).
The Operating System (Distribution)
Everyone’s gotta have an operating system. I know that Derek likes Pop_OS! from the looks of things. It’s also likely that his son is using Linux too. That’s what I’d recommend as well (though I use CachyOS as my daily driver right now), as that’s your best option.
I wouldn’t start with an Ubuntu-base unless it’s Mint or Pop. Otherwise, I’d do LMDE, PikaOS, Nobara Project or CachyOS, as stated. Choose based upon the experience you have with computers, and how likely you are to be a developer somehow (vibe coding counts too).
The Desktop Environment
There are two types of desktop environments: Desktop Environments (DE) and Window Managers (WM) on X11/XLibre, or Compositors on Wayland. This is crucial based upon your hardware specs.
X11/XLibre
If you have enough ram, and a powerful enough CPU and GPU combo, then a DE might be a good option. These include the following:
- Cinnamon, the Linux Mint flagship DE with X11 by default, and Wayland support in the works
- Has the looks of Windows Vista or Windows 7
- MATE, a GNOME 2-based DE with X11 by default, and Wayland support in the works
- Enlightenment, the flagship DE that ships with many distributions, with X11 by default, and Wayland support in the works
- LXQt, a continuation of LXDE, with X11 by default, and Wayland support in the works
- Moksha, a fork of Enlightenment DR17 designed for Bodhi Linux, with X11 by default, and Wayland support in the works
- Trinity Desktop Environment (TDE), a fork of KDE Plasma 3, with X11 only and no Wayland plans publicly
- XFCE, a low resource-friendly DE, with X11 by default, and Wayland support in the works
Wayland
For those who want to use the inferior, and objectively broken Wayland, then there are some options for this purpose, such as:
- KDE Plasma, a Windows-like DE designed for beginners coming from Windows
- Version 7 and beyond will be Wayland only, but Version 6 and earlier have X11 code (though are Wayland by default)
- GNOME, a Mac-style DE with customizability that fits with their standards
- Version 50 and above will be Wayland only, while version 49 and earlier have X11 (though are Wayland by default)
- The developers are one of three corporate entities that want to shove Wayland down our throats, the others being IBM (who owns RedHat and Fedora) and FreeDesktop
- Budgie, an interesting desktop environment that seems to be a mix of Windows 10 and Windows 11-inspired styles for a DE
- Version 10.10 and beyond will be Wayland only, but version 10.9 and earlier have X11 code (though it’s mixed depending on the distribution’s default)
- Any of the X11/XLibre DE’s that have Wayland support as a WIP
The Window Manager/Compositor
If your system has lower resources, or you just want to save on resources despite your massive amount, then a Window Manager (or compositor on Wayland) is a good option. Keep in mind that you’ll need to know how to bind key combinations in order to get the WM/compositor to do something you want it to do.
X11/XLibre
The WM’s are mostly for X11 or XLibre (if supported). Most config files for them are located in ~/.config/window-manager where “window-manager” is the WM or compositor you’re configuring. However, these are the following that I know are good fits for different types of users:
- i3, a beginner-friendly, manual tiling WM, written from scratch and based off of wmii (window manager improved 2) due to some features that were not present
- Has multi-monitor support
- Tree metaphor (whatever that is)
- Plan 9 interface from wmii isn’t implemented for speed purposes
- Has a beginner-friendly syntax in its config file
- Customizable with plugins (like Autotiling to configure it to perform master and stack layout)
- BSPWM, a manual tiler representing windows as the leaves of a binary tree
- Support for EWMH and multiple monitors
- Programmable in almost any language
- Bash is commonly used to program it
- Controlled using messages (in this case, SXHKD)
- Keep in mind that both the bspwmrc and sxhkdrc MUST by made executable, or the WM doesn’t run
- HerbstluftWM, a manual tiler using Xlib and Glib
- Frame-splitting layout similar to i3 or musca
- Tag manipulation (addition or removal) at runtime
- One layout per tag
- Tags are independent of the monitor
- Configured using herbstclient
- Has a script to use on startup, similar to BSPWM
- Awsome (AWM), a dynamic tiler written in C, but highly configurable using Lua in its config file
- Fast
- Extensible
- GPL-2 licensed
- System tray
- Info bar
- Built-in launcher
- Extensions available, all written in Lua
- XCB is used (in opposition to Xlib)
- Forked from dwm (a C-based WM that is configured with the source code, and requires 2000 lines of code per file [patching is required])
- Forked to remove the arbitrary line limit
- Xmonad, a dynamic tiler written and configured in Haskell
- Haskell’s major implementation outside of Facebook’s anti-spam
- Automation of window searching and alignment
- Requires the Haskell compiler
- Every time a change is made, it needs to be recompiled
- Additional features in xmonad-contrib for extra features
- Qtile, the Xmonad clone written and configured in Python
- Easy to write layouts, widgets, and built-in commands
- Extensible thanks to the power of Python (and I hate Python a lot in some cases)
- Otherwise, just as powerful as Xmonad or Awesome
- Wingo, a fully featured true hybrid WM
- Supports per-monitor workspaces
- Floating or tiling modes aren’t afterthoughts
- Scripted in its own command language
- Themability out the wazoo
- Supports user-defined webhooks
- Written in Go, and has no runtime dependencies
- Meaning, no dependency purgatory
- Hypr, a WM that sparked the beginning of what would be Hyprland
- Sports a beginner friendly syntax
- Has a bar by default, similar to Qtile
- Ratpoison, a manual tiler that’s simple and has no library dependencies
- Modeled after GNU Screen, which made major shifts in the virtual terminal market
- Configured with a text file
- Info bar serves as an app launcher and notification bar
- No systray
- Designed to minimize key clobbering that cripples Emacs and other great Free Software
Wayland
Now the compositors on Wayland… there’s a lot of them. These include the following:
- Miracle WM, a Mir-based compositor with the style of i3 and SwayFX
- Basically, if i3 but flashier and feature rich, for Wayland
- Qtile
- Despite being X11 by default, there’s a Wayland version of this
- Velox, an SWC-based compositor inspired by DWM and Xmonad
- Waymonad, think Xmonad for Wayland
- Niri, a scrolling window manager
- CWC, a WLRoots-based compositor based upon Awesome
- DWL, a WLRoots-based compositor based upon DWM
- Hyprland, a Wayland and JSON-configured version of the X11 WM, Hypr
- River, a dynamic tiler inspiried by DWM and Xmonad
- Vivarium, a compositor based upon WLRoots, with semantics to that of Xmonad
- Cagebreak, a WM based upon Cage (which allows a fullscreen app look like a kiosk), and inspired by Ratpoison
Why All This?
If AI were to be used, you’d kinda want the resources to be available while you do so. Especially when vibe coding locally, where the resources could become a problem if you don’t have enough to handle a specific model you’d want. That said, I mention this now, because that’s how you’ll be able to save resources if you configure your DE or WM of choice correctly.
The Software
The LLM
Now that we have everything set up that we’d want, let’s talk vibe coding software. From the research I had done, it’s recommended to use one of these in order to generate your code well:
- Qwen 2.5 Coder, Alibaba’s AI model that’s pretty capable of a lot, despite some setbacks in the lump sum calculations, though it’s based out of China
- DeepSeek R1, a controversial LLM based out of China that, while it can’t be uncensored due to Chinese law, is still a good pick overall
- DeepSeek Coder might be a better option, though I’d still have to test it
- StarCoder 2, an LLM made by volunteer researchers, with the 15b parameter model proficient in over 600 programming languages
- CodeGemma, Google DeepMind’s Gemma, but pretrained specializing in code completion, code generation, NLU, mathematical reasoning and instruction following
- Supports Python, JS, Java, Kotlin, C++, C#, Rust, Go and others
There are many more, but these ones seem to be recommended by most, and they can be run locally, or through a Free Software SaaS (and not a SaaS substitute).
The IDE
There are many IDE’s that utilize AI. However, most of them are proprietary, and I want to help you get out of that. For libreware alternatives to Cursor, this is what I was able to find, as follows:
- Zed, a lightweight alternative to VS Code, but isn’t Electron-based
- Written in Rust (I know Rustaceans will like that)
- AI-powered
- Allows for both cloud and local models to be used
- Supports real-time collaboration
- No registration is required
- Extensible
- Keyboard focused
- Includes a Vim mode
- Licensed under both AGPL-3 and Apache-2.0
- Void, a VS Code-based editor, and a competitor to Cursor
- Multiple modes for the AI
- Autocomplete just by using the Tab key
- Use of native tools
- Utilizes models, even if tooling isn’t supported
- Licensed under MIT and Apache-2.0
- Eclipse Theia, a part of the Eclipse IDE family
- Licensed under EPL-2.0, GPL-2.0 and MIT licenses
- Theia is a framework designed for custom, tailored IDE’s
- Electron-based
- Melty, an AI code editor where every message is a git commit
- Electron-based
- Supports Git
- Refactoring support
- Licensed under MIT
All of this for code editors that use AI to do their work… it’s kinda crazy what shenanigans can be pulled with this setup. Of course, you’ll need the proper libraries and dependencies and whatnot, but most of the time, your distribution of choice will have those packaged and ready to go when needed.
The Browser
This one’s actually very simple. If you want a Chromium-base for some ill-fitting reason, Brave is the only Chromium-base I’d recommend. Even that one has flaws that I’d rather not deal with, and touch with a 3-meter pole.
On the other hand, any Firefox-based browser will do the trick. You must harden it to the nines, and use the GHOST method to do this (which is my method with some additions). My browser of choice to do this for Nostr is LibreWolf, hardened to the nines, and with the plugins that will be explained shortly.
In both cases, you need uBlock Origin, NoScript and Nos2X (or Nos2X-Fox) to be able to use Nostr. Do not use Alby for your Nostr key. I repeat, DO NOT USE ALBY FOR YOUR NOSTR KEY. From my experience, Alby will override Nos2X-Fox for me, and that isn’t good news at all.
The Git Repos
There are multiple Git sites you can use, but I’d recommend something like Codeberg, which is a Free Software git repo storage site out of Germany. It’s based upon Forjego, and has some similarities to Gitea, which is based in the US. GitHub and GitLab are very popular, though they’re proprietary and absolutely garbage. Stay away from them at all costs.
There is a Nostr-based GitHub clone that seems to be popular, but I’d have to research it, and verify that it is what is advertised to be. I like using Codeberg for this reason, despite some setbacks that could come from it.
Anything Else?
Now I know that Derek’s son happened to be making a game by vibe coding it. I know there are some engines that allow for the use of an IDE to even write code for said game, like Redot (a fork of Godot), Torque3D and Torque2D (C++ engines under MIT), LÖVE (Lua), GDevelop (multi-language), and EasyRPG to name a few. However, those are all Free Software engines, so surely there should be other purposes to do vibe coding.
There is something called MKStack, which allows for the creation of Nostr clients using React (Alex, why Facebook’s JS framework?), Tailwind for CSS, Vite, shadcn/ui and Nostrify. I think someone should really do something about replacing React with a different framework entirely (that’s just me, though).
Conclusion
Despite all of these things being Free Software for the most part (maybe with some exceptions), this should get you started vibe coding on a GNU/Linux operating system, and it shouldn’t be all that bad.
If you decide to vibe code on Linux, consider this, and you’re good to go.
Write a comment