If you want a for-real free device your bes bet is a RISC-V Single Board Computer. RISC-V is open architecture meaning no hardware level spyware built Into Intel’s chips.
Chris over at explaining computers managed to get kdenlive to render a video with one and some other cool stuff, you should check it out
Immutability is useful from a sysadmin standpoint because it solves a couple problems. It’s a little easier to secure a system if you can know that, in fact, files outside the home directory have not been modified, and also, it’s a little easier to keep systems running because programs can’t just shit on each other’s files etc.
Unless these two are problems for you, you’re signing up to re-learn how to use Linux, and tbh not very elegantly, for basically no real gains at this time. Immutability has potential as a concept, but Red Hat’s approach is super weird and not very efficient. They have a tool that allows you to manage filesystem trees, and then they extended this tool with RPM to allow you to compose custom filesystem trees at install/upgrade time. This approach, in my experience, is shockingly inefficient if you need to add any custom packages to your base tree and you install updates with any frequency.
If you’re a sysadmin rolling out updates to workstations maybe once a month, these aren’t really issues, but for daily use, it didn’t seem worth it to me just yet, especially since we don’t really have any neat separation of code and config like you get with Docker. You can’t just zip up your home directory and move it to a new Silverblue installation and have your user back yet (there’s work in this direction with systemd-homed, likely once it’s good enough this will become standard, but also, that’s not an “immutability” feature). I believe /etc is mounted rw, which is a step in this direction, but until lots of stateful stuff gets moved out of /etc that isn’t going to be portable in the same way a Docker config is.
EDIT For a comparison of a different approach to immutability that includes a different bundle of tradeoffs, you can also look at OpenSUSE’s MicroOS. The TL;DR is that it’s easier to customize the base system, but it locks you into btrfs and it’s not as robust overall – ypsidanger.com/comparing-opensuse-microos-to-fedo…discussion.fedoraproject.org/t/…/3
I just wanted to point out that you pretty much can just tarball your user directory and drop it into a fresh system. If you embrace the Flatpak and container-based workflow, it’s incredibly easy to be up and running in no time. Obviously, containers and flatpaks aren’t unique to image-based distros, but are perhaps less common in traditional distros.
Sure, you’ll need to add a printer back, or reconnect to wifi networks, but your user and/or dev environment will carry over, and with a couple of commands, any package overlays and flatpaks will be reinstalled and ready to go.
I found flatpaks and containerization to be the only real learning curve with Silverblue, and only because I hadn’t used them previously. Compared to the learning curve and unorthodox approach of NixOS, Silverblue itself is as easy as using vanilla Fedora Workstation.
I mean, is this true in any way that hasn’t been true of Linux since nearly forever? You can always put your /home folder on a separate partition, install a new system, and as long as you make sure the UID of your new user matches the UID of the old user, the process is exactly the same. Just reinstall your apps and you’re good to go. I used to do this to keep configuration/data between reinstalls. EDIT – as opposed to a genuinely stateless user config, as systemd-homed is working towards
There difference is, to flatpaks and containers are in home, so you keep those even after a fresh install of you keep home.
It’s freaking great, specially in a work machine, to reinstall after breaking something and be able to just continue almost as if nothing had happened.
Lenovo G505S 16gb RAM - no (the A10-5750M processor has neither Intel ME nor AMD PSP), software probes - too, if instead of the closed UEFI from the manufacturer you install the open source BIOS coreboot+SeaBIOS: it will contain only a few small closed binaries , they were all dismantled and no backdoors were found. Someone made a script in which by rolling back 1% of the last commits (made after deleting the G505S) you can return AMD boards to coreboot - review.coreboot.org/c/coreboot/+/76832. You can install the AR9462 module, whose ath9k family WiFi is 100% open source.
Try to build Coreboot on Lenovo G505S using the restore_agesa.sh script in conjunction with the csb_patcher script, which applies a group of unofficial patches for AMD platforms
I don’t like it. Updating dependencies in case of security problems is impossible, I have to wait for the developer to release an update. Also, it wastes a lot of space. Pollutes df output. App startup is slooow.
Just use the native packaging system! There is no reason software can’t be released using that.
idk what type of drive you’re using, but flatpak startup times are indistinguishable to me, when compared to native packages. And I’ve used flatpaks on A LOT of computers…
Just to provide counter examples, in arch I can’t use the native steam package and play games with proton. It just doesn’t work. I think proton expects some ubuntu libraries or something (found something like that while spending 5 hours debugging nfs heat). And even if I manage to fix it, next time I update the system it’ll be broken again.
I use flatpak, and everything just works.
However, in arch if something is in the official repo or the AUR i prefer those.
In ubuntu I installed krita and gmic, but it doesn’t work. For some reason krita doesn’t find the gmic executable. Instead of debugging krita and gmic for hours I just installed the flatpak version, and it just works.
And yeah, app startup went from 5 to 7-10 seconds in krita, and from 1 to 2-3 seconds in firefox. It’s not snap, it’s 2023, we have SSDs.
Really? I use Arch native Steam and Proton no problem. You either use steam-runtime (uses built in Ubuntu runtime) or steam-native (expects Arch packages) but there is a meta package for pulling the runtime deps. Both have worked for me.
That said, Flatpak has come in clutch for me as well on the Steam Deck, and for things like Prism Launcher (modded Minecraft launcher) where you want to juggle multiple Java versions without needing to run archlinux-java between switching packs.
There’s a pretty simple reason. It’s that developers don’t have to spend the time to package for every single distro. I know I wouldn’t, I’d just focus on packaging for the distro that I use and flatpak. Having flatpak also means that some less known distros start with a big amount of apps available from the get go with flatpak.
I see that fragmentation of runtimes is a problem. If all apps would simply use the same runtime, and a modern one, and there was a package manager that installs the missing dependencies, that would be nice.
The diskspace is a true problem too, just because of the fragmented runtimes.
But Distros are fragmented too. If simply everyone could unify, at least a bit, instead of at least 5 different big Distros competing, every app could just work. But thats not the case, so Flatpaks often work best, and maany packages are either only .deb, .rpm or even only on Arch
AMD or Intel Graphics. Intel networking, Atheros, or a chipset that is known to be friendly with Linux.
CPU support is fairly diverse.
Sound is fairly well supported but with some devices can be a surprise, as are touchpads. Touchscreen and webcams are generally a bit more dubious.
With desktops, I very rarely have issues but it’s also easier to pick my own hardware. For laptops, I usually don’t buy something that’s new to market unless the component models are known to work. If it’s been around for a bit I can usually Google comments by somebody else who’s got one and tried to run Linux on it.
It sounds like you’d be better off with a DE or WM that isn’t gnome. The GNOME Project has been progressively sticking more and more of the customization features of the DE behind either gnome tweaks or the command line, likely to unify the experience for all users and improve the ability to provide support.
Personally, as far as gnome-based DEs are concerned, I prefer cinnamon, but I’m fine running Mint to just have it come pre-installed. I don’t know what dependencies it pulls in now if you install it standalone from Mint.
I’m using KDE, but my point still stands about both… also, would be nice for newbies if KDE had a few presets when it comes to layout to make the users realise how truly powerful it is
I would use something Fedora-based. It’s just a personal choice from myself, since it’s reliable and very up to date. By using a modern distro, you increase the chance your hardware will perform better.
Workstation: uses Gnome, which can utilize the great trackpad
KDE spin: as you wanted KDE
Atomic (preferably uBlue, but Silverblue or Kionite would be great too): my favourite, maybe you could test too. You can install the KDE version first, and if you dislike it, you can rebase easily to the Gnome or whatever version without reinstalling
What maybe won’t work is the WiFi and some keyboard things from what I’ve heart, but you can test it for yourself
I’m using official flatpak Firefox because I didn’t want to wait any longer for Fedora releasing their rpm version of it. This way I get new releases right away and they are official as intended by Mozilla.
Not really a flatpak advantage, but a Firefox advantage.
I do as well. I really appreciate the information density, key bindings, and optional web UI. Although I found if I leave glance is running for a prolonged amount of time, it has a tendency to crash from some python issue I haven’t dissected yet, as it takes so much time to reproduce.
There is a pre built distribution, you need to configure binary cache to get it. Refer to the “Substitute for nonguix” section: gitlab.com/nonguix/nonguix
Guile and Guix is way better documented than Nix. The language have more features, so you don’t have to use a hack to load packages, can actually know what is accepted in a function instead of blindly copying what others do, and it comes with a formatter.
I think the language is harder but more powerful than Nix’s.
Imo a better manual and examples would help a lot.
I’d say one of the biggest issues is the one with proprietary drivers - you can’t really find examples and guides on how to get drivers working because it’s kept hush-hush, and to install them yourself requires knowledge on how to set things up, knowledge which beginner users don’t have ofc.
I’m a big fan of Guix and Guile but atm I couldn’t switch over due to this.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.