71–80 of 164 posts
How would you approach making immutable live-cd like Linux? No persistence at all, just boot it and run some app - think some kind of presentation panel which shows predefined program/URL. Ideally net booted to avoid having storage at all.
Been using Fedora Silverblue since its release and it's absolutely the future. ostree is what everyone should be using.
I found Silverblue to not be flexible enough for my person computers. Maybe I use Linux in a hacky way, not having write access to /usr or /bin or other folders drove me crazy about once every two weeks. For example, I was using a script written by an ubuntu user that was looking for a library with the name/location ubuntu puts it in. Fedora uses a different name for the library. My instinct here is to create a symbo…
1. With Fedora Silverblue 39 the most straightforward way is to add a Dockerfile layer just which makes your changes directly to the base image.
2. You can also create your own RPM and make the changes there.
3. Best is to actually run your script in an Ubuntu container (distrobox, toolbx, or podman).
I think the definition should be: Installing any number of packages, then removing them in any order, at any future point(s) in time, is equivalent to never having installed them at all. This leaves some distros out, but I feel like it’s the important part of the concept.
Been using Fedora Silverblue since its release and it's absolutely the future. ostree is what everyone should be using.
In my (limited) experience with something like Silverblue, the base system can be configured but when you start adding applications (like say, Firefox), it is lacking when it comes to configuring that because you're using Flatpak and I don't know of a way to tell it to both install all Flatpaks I want along with all of the configuration.
I guess there's some way of installing Flatpaks en masse and then dotfiles can take care of the rest?
https://universal-blue.org/tinker/mindset/#resist-the-urge-t...
The problem I had with flatpak and the immutable approach in general is that I can't modify them in ways that aren't supported by the developer. For example, I use decsync to sync my calandars but as far as I can tell, it's impossible to add the decsync plugin to the evolution flatpak. Until these immutable systems support the stacking of custom overlay filesystems as a first class feature^1, people will continue to…
> add the decsync plugin to the evolution flatpak This sort of thing is very common with GUI software on Linux. Outside of this bubble, most software comes with batteries included. Eg Solidworks never makes me download optional dependencies, but FreeCAD made me do it literally every 15 minutes as I move to the next step in a CAD/CAM/sim/render workflow. Also see https://www.joelonsoftware.com/2001/03/23/strategy-lett…
FreeCAD might not come with enough battery to power a full workflow, but I have also seen entire engineering firm not able to work without a particular AutoCAD plugin.
Is anyone running diskless Alpine in production? It seems optimal to me but extremely uncommon. In the past I’ve tried running a small USB drive in rented bare metal w/ diskless alpine, but the machine seemed to reboot randomly IIRC.
The problem I had with flatpak and the immutable approach in general is that I can't modify them in ways that aren't supported by the developer. For example, I use decsync to sync my calandars but as far as I can tell, it's impossible to add the decsync plugin to the evolution flatpak. Until these immutable systems support the stacking of custom overlay filesystems as a first class feature^1, people will continue to…
You can add plugins to applications in flatpak; package these plugins as extensions. How it is done can be seen with OBS: flathub has several OBS plugins available (com.obsproject.Studio.Plugin.*).
A problem that's less well-solved is situations like Cantor, where a single application is a front-end for multiple executables. To get it to actually work you'd have to package Scilab, Sage, Maxima, Octave, R, and Julia in the flatpak itself, and these are non-trivial programs to package. There are workarounds with flatpak-spawn, but at that point why not just install the application natively? (I think the "right" answer is to set up a dbus service for like "system-octave" or whatever and have a separately flatpak'ed interpreter register it, but as aesthetically pleasing as this solution is it doesn't seem to have induced me or anybody else to actually do it...)
The problem I had with flatpak and the immutable approach in general is that I can't modify them in ways that aren't supported by the developer. For example, I use decsync to sync my calandars but as far as I can tell, it's impossible to add the decsync plugin to the evolution flatpak. Until these immutable systems support the stacking of custom overlay filesystems as a first class feature^1, people will continue to…
NixOS gives you precisely this kind of control- through a few different mechanisms. Some packages in nixpkgs, and most NixOS and home manager modules, expose a lot of configuration options where you can configure various plugins, add extra packages, etc. Nix also lets you provide overlays and overrides to add custom packages (new packages, or customized versions of existing packages) and gives you the option of chang…
> 4.1. Pros § > 4.1.1 you can roll back changes if something went wrong. > 4.1.2 transactional-updates allows you to keep the system running correctly during packages changes. Last time I needed to roll back was OpenSSL in Ubuntu 18.04 and that was on one system. I don think I've ever had a problem that 4.1.2 solves. I don't want to have yet another Linux OS to solve a problem that happens once a decade. If I wanted…
I purchased a 7900XTX on release day, with the Linux drivers being in a fairly rough state and new fixes being added daily. So, for the next 3-4 months, I was running Fedora Rawhide with the Koji repo added - about as bleeding edge as it gets, short of building locally from source. Rolling back definely came in handy once or twice.
Once things stabilized, I rebased back to non-Rawhide Fedora 37 and stayed there. Then, a few weeks ago, I found out that AMD had been working on ROCM for the 7xxx series, so I've rebased to Rawhide again to play around with AI tools on the 6.6 kernel.
I've also occasionally encountered non-critical bugs, suspected it might have been fixed upstream, and temporarily rebased to Rawhide just to check out if that was the case before reporting it. Pretty nice.