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.

    • harsh3466@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      4 months ago

      Edit: tl;dr is that Grav worked out of the box.

      Bear in mind that I just started messing around with Grav, so I’m no expert. With that being said, I tried 11ty and Hugo (spent 2-3 weeks messing around testing them).

      What I was looking for was a static site generator that let me easily use a simple/clean theme, and would generate the webpages from markdown files.

      What prompted me to look for this was my Wordpress site breaking. I’m currently self hosting wordpress via docker. While retooling my server (install updated server os, import raid, relaunch containers), my Wordpress container broke. It was still serving my website, but I couldn’t do anything on the backend because of a database permission error. I had just spent a day fighting with and fixing database permissions on another container, and I decided I wanted to look into these ssgs and see if it would simplify dealing with my website.

      11ty seemed really promising until I tried to theme it with a starter pack. What was confusing to me at first was that 11ty doesn’t theme like you think of theming something like Wordpress. You don’t set up/intstall 11ty, and then download/install a theme. Instead, you use a starter pack, which is a theme that includes an implementation of 11ty. (You can write your own theme with a barebones 11ty setup, but I’m not a web dev and don’t want to be.) I must have tried 15 different 11ty starter packs, and not a single one of them worked and/or was maintained, and these were the ones linked/provided on the 11ty website.

      Had I found a pack/theme that worked (and met my criteria of being a simple/clean theme), I’d have been very happy with 11ty. The core of 11ty worked great for me (take a .md file and make it html), but the starter pack situation IMO is a disaster to anyone who isn’t a competent web dev.

      Hugo was much simpler when it comes to theming, just git clone a repository (which, I get is not ideal for everyone, but also, isn’t all that different from downloading a theme zip file for something like wordpress). Hugo seemed promising to me, but despite the relative ease of cloning a repo for a theme, I couldn’t get Hugo to generate a single page of content. I read the docs, watched tutorials, got frustrated, kept getting errors, and noped out.

      Grav when I tried it was exactly what I was looking for. Out of the box it has a nice simple theme. I can drop a markdown file into a folder and it automatically generates it. That part is even better than Hugo, 11ty and other ssgs. You don’t have to run a command to generate or edit an html file from a markdown file. It watches the content folder and when it finds new/changed .md files it auto generates them.

      I also really liked that Grav easily did what these other ssgs claim is easy to do (but in my experience failed to deliver on), and provided some additional complexity for making management a little easier via the web ui.

      Overall I like Grav, but I’m not actually using it. I ended up fixing the database permissions on my wordpress container. I’m going to keep Grav around in case I decide to migrate, or if I ever decide to launch another site/project.