this post was submitted on 25 Feb 2024
200 points (97.2% liked)

Linux

48310 readers
985 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

I would just like to preface this. This is the first blog post I've ever written, so please please please give me feedback if you can. I also didn't intend on it being here on Lemmy, but Hugo is quite a complex tool that'll take some time for me to understand. Webdev is not my cup of tea.

Introduction.

About a month ago, I switched from Endeavour OS to a spin of Fedora called Fedora Onyx (Now Fedora Atomic Budgie, from now on shortened to FAB). Why? I love Arch, it was even my first distro (I am sane I promise) thanks to a friend, but it's infamous for breaking. Which it did. Time and time again.

Whether I was doing something wrong or not is irrelevant now, but on every Arch or Arch-based install I've done; overtime something has caused seemingly random parts of the system to begin to break down or slow down.

After 3 years of this behavior across countless installs, enough was enough. I'd played around with Atomic, otherwise known as Immutable, distros before in VMs but never used one on bare metal. I knew what I was getting into though, sandboxing and containerization left right and center, Flatpak for apps and restriction to the base directories. A routine backup later, and it was distro-shopping time.

What I looked for.

I initially didn't plan on FAB nor an Atomic distro, I was actually going for NixOS (and if I were to switch from Atomic, NixOS would be my new home). But I'm of the mind of I want to use my computer more than building it, at least on the software side of things, and I know that if I had a NixOS system I'd never stop tweaking it. After trying NixOS in a VM a couple times, this constant tweaking ended up in the system breaking both times to the point where it was impossible to edit the .nix config file without chroot (and a lot of GRUB entries, a rather bit messy if you ask me).

I needed a system that:

  • Wouldn't break without my active attempt to do so.
  • Was modern, had the latest versions of software available and the newest kernels (once an Arch user, always an Arch user).
  • Had a large community and buzz in-case I needed support.

After the events of NixOS, I turned to Fedora. I've used Fedora Workstation a couple times on my laptop & desktop, and Fedora Silverblue (technically Fedora Atomic Gnome) I'd tried in a VM. Fedora Workstation fits two of those three requirements, omitting only the reliability I craved. But Fedora's Atomic spins were a perfect fit.

Budgie?

Desktop Environments are incredibly subjective and no one is better than another, I don't like Gnome nor KDE simply due to the scale of them. Large enough to jokingly label those desktops as Gnome/Linux and KDE/Linux rather than GNU/Linux. This is a nightmare if you ask me, the system and the DE should be separate areas of an OS stack.

Gnome's scale can be felt across the entire Linux-verse, more and more apps are being made with Libadwaita; essentially alienating anyone who doesn't use Gnome if they value consistency in the appearance of their system. KDE uses the Qt framework for UI, which causes itself to be alienated from the majority of Linux apps.

So I need a small desktop that uses GTK, but has modern features and animations while being under active development. Out of the 2 remaining Fedora Atomic spins, Sway or Budgie, it has to be Budgie.

I. Love. Budgie. I've used it many times in my old Arch installs and I'm constantly on the lookout for the best Budgie experience. Budgie is everything I want out of a DE, it's small, it's fast, it's modern, it's GTK, and under active development. It was also the first FOSS project I donated to!

With everything backed up, the distro chosen and a USB flashed. It was time to switch.

Week 1 & 2.

FAB started out exactly like most distros, you have to use Flatpak to manage all your apps otherwise going Atomic is almost pointless. FAB shipped with Gnome Software installed but again, I love consistency in the appearance of my system and so opted to use Flatpak and Flathub straight from a terminal. Gnome Software also seems to take a good minute to finish the 'Loading Software Catalogue' step, whereas the CLI faces no such issue.

To install packages onto the base system, known as 'layering', you have to use a specialized package manager that supports layering on Atomic. Fedora Atomic ships with a tool called rpm-ostree that replaces dnf . I layered Xfce-Terminal, Flatseal*, Vim, Neofetch, and packages for virtualization onto my system. Your layered packages can be seen with the command:

rpm-ostree status

*The flatpak version of Flatseal didn't seem to apply any of the overrides.

It started out quite nicely, I usually mount my secondary drives into /mnt/DRIVELABEL but due to the restrictions to the base directories I had to change this to /run/media/USERNAME/DRIVELABEL, not a big deal and should be expected.

Gaming was obviously fine as it was on Arch. Blender did everything perfectly too, after overrides to access my projects folder. It was almost easy to forget I was on an Atomic distro. So far, I'm loving it.

Week 3.

Week 3 is when things start to get interesting, Atomic distros such as VanillaOS advertise themselves as perfect for developers. I'm a hobbyist developer, I make odd projects here and there for my personal use and other automations. Week 3 is when I wanted to start a new project.

Week 3 is also when I almost gave up on 'Immutable' distros.

I introduced myself to Toolbox , a program that's used to create containerized images of non-Atomic distros right under your host system; like a Docker container (It actually uses Podman as the backend so it is a Docker container of sorts). Running:

toolbox create

Defaults to creating a Fedora container (I'm guessing it's Fedora server), so you have access to dnf and the total mutability of non-Atomic distros on your Atomic distro. I then proceeded to installing my editor of choice and packages for Python & Rust.

I learnt a lot about how to manage development on an Atomic distro in Week 3, Toolbox advertises that it enables 'seamless' integration of software from the container and host system. In my experience, it's not quite that simple.

I won't divulge into what went wrong because it's completely my fault and nothing wrong with Fedora, Atomicity or Toolbox. But to summarize the containerization was almost too much, causing me to flash a NixOS USB and plan to switch. VSCodium wouldn't see that I've installed the languages I did, nor find my font (Geist Mono Nerd Font). This put a very sour taste for Toolbox in my mouth.

But the weekend came and I left my computer for a good day.

I came back and wiped everything from my dev environment, even the Toolbox container. Toolbox allows you to specify what distro you want to install, so I came up with the brilliant idea of Arch. After that I proceeded to install Yay, VSCodium, Python and a couple other languages. Finally, peace at last. The trick was to install VSCodium from the Toolbox, I knew that prior to the wipe but VSCodium isn't in the Fedora repos. So now, with everything all under the Toolbox container, programming is quite a nice experience.

Week 4 & Beyond.

So this is it, one month after installing and I can't see myself ever going back to a non-Atomic distro. Even using NixOS doesn't seem quite as likely now. I've grown to enjoy and embrace the sandboxing & containerization now that I've figured out what to do in order to achieve a task. The best part, my system is (mostly) identical to what it was at the start. So in theory, it'll be the same even as the years go by. Not that I'm likely to keep this exact install for years, on my desktop at least I like to try new things and ultimately end up getting bored of an install after an amount of time.

So to answer the popular question right now, is Atomicity the future of the Linux desktop? I say yes, if we can make them easier for first-timers. Right now, I'd recommend everyone to use a normal distro for a while before trying Atomic distros. During setup, the two are quite distinct from each other, and doing the setup on a normal distro is required foundation for an Atomic setup. However...

Do I believe anyone who has some experience using Linux should try an Atomic distro? Absolutely! Even if you never encounter breakages on a normal distro, using something Atomic if you don't have specific use-cases brings no downsides. Going Atomic definitely teaches you a lot about Sandboxing, Containerization, Linux and miscellaneous Security concepts. Plus, doesn't it just sound cool? "Yeah, I use an Atomic system."

It even has a psychological benefit, I feel a stronger sense of solidarity and security from this system. Maintenance is easier, as I know where and how each app has installed itself and what it can access or do. I've layered on all the packages I could want so my base system should almost never change now beyond updates. I could even re-base to a different Fedora Atomic spin if I wanted to.

So, if you've used Linux for some amount of time, I highly recommend giving Atomic a try. It's quite a unique & interesting way to use your system. If you've never used Linux, I don't recommend going straight to Atomic as there are certain new and developing concepts that are used heavily throughout the system. Do I think Atomicity is the future? Yes, I can definitely see them gaining a larger share of the Linux desktop given time. To make a reliable Linux desktop, I see almost no other solution than Atomicity that doesn't require extensive Linux experience.

you are viewing a single comment's thread
view the rest of the comments
[–] winety@lemmy.zip 7 points 9 months ago (2 children)

So, I've tried using Toolbox on my Debian machine. It works and it's nice to have access to newer versions of the programming languages I use. But much like OP, I encountered a problem with VS Code in that the IDE cannot work with the compilers from my toolboxes. For example, Debian has Go 1.19 and Fedora (in a toolbox) has Go 1.21. In-between the versions a small change of the go.mod configuration file has happened, so VS Code which uses Go 1.19 cannot parse it.

Is there a way to solve this? OP's way of solving this, i.e. installing the IDE in the container seems like a hack. I don't want to manage 20 different instances of VS Code.

[–] dan@upvote.au 5 points 9 months ago* (last edited 9 months ago)

installing the IDE in the container seems like a hack.

Interestingly, more and more projects are doing this now that devcontainers are growing in popularity.

VS Code has two separate parts:

  • The server, which handles linting, debugging, the built-in terminal, etc.
  • The client, which handles the UI (including file navigation, debugger UI, etc.)

When you run VS Code on your computer, it runs both parts by default. However, it also has the ability to run the server on another system, for example over SSH or using WSL on Windows. This is useful because you can use your preferred desktop OS for the VS Code UI, but have the dev tooling running on a system with an OS closer to what you use in production. It still feels the same as if you were just using VS Code locally, as the UI still runs locally.

Devcontainers are the next logical step from there. Instead of manually installing development tools either on your computer or on a dev server, devcontainers let each project specify a Docker container (there's a few prebuilt ones), extra features to add, and a list of VS Code extensions to install when connecting to the container. The VS Code server runs inside the container. This essentially containerizes the entire development environment so that anyone can download the project's code and immediately start working without having to manually install anything other than VS Code and Docker. It's very helpful when dealing with things like projects that use old versions of Ruby that are otherwise painful to do manually.

[–] ProtonBadger@lemmy.ca 1 points 9 months ago

I don’t want to manage 20 different instances of VS Code.

The way I do it is all my development in one or two distroboxes, other stuff in another. So I don't end up having 20 but just a few. Nothing really to manage.