boredsquirrel

@boredsquirrel@slrpnk.net

This profile is from a federated server and may be incomplete. View on remote instance

[Thread, post or comment was deleted by the author]

  • Loading...
  • boredsquirrel ,

    Never heard of nmtui and nm is a pain, thanks!

    boredsquirrel ,

    So the question is what the hell is "Ubi server" and why doesnt it preinstall network-manager?

    I would install both tools.

    boredsquirrel , (edited )

    This is pretty complex and I wanted to write a post about it, will follow.

    While OpenSUSE's model may look similar to Fedora's Atomic Desktops, it is not.

    In short:

    Fedora Atomic uses rpm-ostree for managing all installed RPM packages. This is basically git for binaries, meaning your system is 100% the system that Fedora tests and pushes to their servers.

    Then you have the ability to add and remove RPM packages, which will be transparent (rpm-ostree status) and reversible (rpm-ostree reset).

    This means

    • you can modify the system and install or uninstall any RPM you want
    • these changes will always be applied fresh to your system, meaning you will always start fresh and apply exactly them.
    • this means the entropy (amount of randomness, how much your system diverges from their system) is very little and transparent. "I cant reproduce on my system" is gone
    • you can switch (rebase) ostree remotes, also with support for container images like uBlue uses. This means you can have various upstream configurations with different goals, like Aurora/Bluefin, Bazzite etc
    • you can still reset your system to 100% upstream, to make sure you have reproducible bugs, or to find a broken package

    Most of these things are not possible on OpenSUSEs model. To my understanding they basically just use zypper but with BTRFS snapshots. So you normally update the system, but into a new snapshot to the updates dont affect the current one.

    But there is no way to reset or rebase, this means from day 1 there is a chance that your system is not the same as upstream.

    They try to tackle that by advising to not install any RPMs which is pretty hillarious. If you use a good RPM distribution model like rpm-ostree, installing or even removing packages is no problem because A: you see the changes transparently and B: you can always reset.


    As good as their efforts may be, their reproducible builds, their services, their YaST etc. Their "immutable variants" are not the same and way worse.

    You can also see that by the adoption of rpm-ostree I would say. OpenSUSE has microOS and Aeon, which dont share a common name and are separate projects. Kalpa, the KDE Plasma variant, is officially unmaintained.

    Fedora has

    • Atomic Desktops: GNOME, KDE, Sway, Budgy
      • uBlue: Bluefin, Aurora, Bluefin-DX, Aurora-DX, Bazzite (and all its variants), dozens of base images for various hardware and desktops
      • all the uBlue community images including secureblue
    • coreOS and IOT, which are a bit different
    • possibly future CentOS and RHEL adaption of the model
    boredsquirrel ,

    I wasnt aware of how bad this situation was actually.

    It started by me asking in their forum "where do I need to place a repo to add external RPMs"?

    Because on Atomic Fedora the dnf repo add command doesnt work, but the repos can be placed in the same dir and work the same. So I assumed this worked on "the OpenSUSE equivalent" the same.

    Instead of getting the needed answer (assuming that their model worked just as well as Fedoras) they told me

    • installing RPMs causes random changes to the system that are not reversible (yes they are, on Fedora)
    • installing RPMs is not supported, only Flatpaks (which dont support user namespace creation for process isolation in browsers, so not an option here)
    • the only RPMs that should be installed are drivers etc. So they advise something they dont support, lol
    • they supposedly hate Fedora?

    I still dont know where such a repo would be placed, and why they would support installing RPMs on the "chaotic" traditional variants, while they dont on their "more stable" "immutable" variants.

    Well yes I know. Because their model is not any better in solving the mentioned problems.

    I mean, by logic, a better package manager should improve stability when installing system packages. You shouldnt need to install Flatpaks or Distrobox containers only on "immutable" distros, but especially on traditional, messy ones.

    Because these traditional distros dont have measurements to revert the permanent changes that sometimes occur when installing, changing or upgrading packages.

    If your OS is so unreliable that you only support installing Flatpak, then the package management is crap.

    boredsquirrel , (edited )

    Apart from the other comment explaining the many benefits of rpm-ostree to transactional-update (apart from the horrendous name)

    it creates BTRFS snapshots between normal zypper updates. So you can have the benefits of offline updates without having to wait at boot or at shutdown.

    You are referring to standard Fedora here. Atomic variants have no offline update screen.

    Also just having snapshots between updates means you cannot rebase to the updated AND vanilla variant.

    You could make a BTRFS snapshot right after install and keep that from disappearing. But this means when you need to reset, you downgrade tons of packages wich always causes problems with config files etc.

    Just like silverblue, the concept is to try to install everything through flatpak/distrobox and avoid adding anything unnecessary to the base, so that system updates can be snappy and unproblematic.

    As said in the other comment, I dont think this is specific to Atomic Fedora. For sure the long rpm-ostree updates kinda enforce that (they get way longer when layering packages) but rpm-ostree is way more stable than for example Ubuntu APT or Fedora DNF. So I think you should use Flatpak and Distrobox on the traditional distros, while Atomic Fedora is actually less critical.

    "Immutable" OpenSUSE is not any better than mutable OpenSUSE though, their package manager doesnt solve many problems with installing random RPMs to the base. So it needs Flatpaks etc more.

    I was really tired of opening my laptop, updating everything and then rebooting. I just want to open my pc, have all updates automatically applied in the background through systemd units so that the next time I boot, I have an updated system. No "updating" during next boot.

    This is all standard Fedora. Atomic Fedora updates in the background and reboots are as fast as normal ones.

    But there are some issues with just updating automatically:

    • using tons of data when connected to a phone hotspot
    • updating on high system load, causing freezes
    • updating on low battery

    I wrote about this here and uBlue addresses these issues in their ublue-update

    OpenSUSE doesnt mitigate this.

    boredsquirrel ,

    As far as I understood their package manager is just zypper with enforced snapshots.

    1. It is not layering, it is just installing like regular. There is no base, no image, just the base packages that are managed traditionally. This will just add another package and there is no way to revert it
    2. Updates are atomic, but they are not reproducible, as there is no real base. You cant just use rpm-ostree status, reset and install the layered packages, as there is no reset. There is no way to revert back to the currently shipped base OS. You can only revert back the snapshots that were created every update, so you could keep a snapshot of the fresh install, and that would be somewhat a reset, but reset to completely outdated packages, causing likely dotfile conflicts etc.
    3. The OS is always atomic and snapshots are enforced, changes have to be made to the next deployment / BTRFS snapshot and the live base system is read only afaik.
    4. There is no rebase. And Kalpa is officially unmaintained. And there are no other variants than the 2 :/
    5. No idea
    boredsquirrel , (edited )

    Inefficient data usage is a problem. Network connections arent free, there are people using metered networks, or with really bad bandwidth.

    I am really interested in improving this.

    I dont agree with "atomic distros are the future" as in my eyes Fedoras approach is the only good one really (and even that has tons of issues, see here).

    Some things need to be improved:

    • flatpak runtimes share tons of packages but each gets downloaded individually, even though they may be deduplicated locally
    • podman containers just for installing packages dont need a separate system, it would be perfectly fine if they would just use a symlinked or otherwise deduplicated base system.
    • rpm-ostree has no delta update support, but afaik Fedora neither

    So it may be worth the tradeoff for us both, but I definetly see a problem and I am also kinda tired of using podman containers for something they are not supposed to (system upgrades are impossible for example).

    I want to experiment with the "linking all the system binaries to a podman container", the flatpak stuff needs to be solved by them.

    boredsquirrel ,

    This is due to the fact that Kalpa is a traditionally package-managed OS. On image based Atomic Fedora there is a base image, and the overlays are always added on top.

    If these overlays are always the same, like ublues "hardware enablement" then it makes way more sense to use the base image and apply these changes once. Doing that workload once, minimizing randomness between users and doing unstable stuff like proprietary NVIDIA drivers, rpmfusion, custom kernels etc. on a single repo. The issues will occur there and can be fixed centrally.

    The slow process it not ostree, but doing the changes on every update. But tbh when updates are automatic it doesnt matter than much anymore.

    boredsquirrel ,

    Ublue does more

    • hardware enablement with nonfree packages Fedora cannot ship
    • experimental images
    • opinionated configurations
    boredsquirrel ,

    Updating and rebooting before using is basically just paranoia. And Atomic Fedora now has automatic updates (by default, was just a settings switch before).

    Note that automatic updates have many issues which ublue fixed in their ublue-update

    boredsquirrel ,
    1. Agree that this is not typical use
    2. But also agree that doing this is very slow and sometimes nice for testing
    3. But this is not about dnf but rpm-ostree, which is slower. Note though that there is an --apply-live setting to not need a reboot
    4. Distrobox / toolbox are intended for that, Distrobox is way better for UX. Not everything works here but most.
    boredsquirrel ,

    I also disagree with some Fedora devs that "development should be done in containers". This works well for apps, but results in duplication and does not allow editing the OS itself.

    boredsquirrel ,

    Snapshots are a lot more flexible. You can make any modifications to your system without issue.

    The issue is the lack of any versioning and control. It works "without issue" just as it works on traditional distros, it works until suddenly you have strange errors, devs tell you "I cant reproduce this here and btw modifying the base OS is not a supported use case" (it actually isnt) and as there is no way to revert the "issueless changes" you need to fix them manually or reinstall the OS.

    boredsquirrel , (edited )

    rpm-ostree --apply-live dosomething

    I havent tested that, but I also think nonatomic ostree is already really great and I want to try to only do that for some time.

    Note that this is will not create a snapshot afaik so if an update breaks, it breaks. But installing a package might be worth it.

    Edit: seems to only work for installs?

    boredsquirrel ,

    Yes I have. I think they do the same as OpenSUSE microOS basically.

    The live system is immutable, when updating they clone it to the other partition and run regular apt in there. (Not sure about that but I think). Same issue as on OpenSUSE [whatever they want to call these variants].

    It sounds like the thing Android is doing, but in detail it is way less secure. I only know of rollback prevention and signing, so an update needs to be an update and cannot downgrade components. This may not be available there but idk.

    And the entire boot process on any Linux distro is extremely insecure compared to Android/GrapheneOS on a Pixel.


    Their "apk package manager" is just a wrapper for Distrobox, not solving any fundamental problem. But Distrobox for sure is awesome for closing the gaps.

    I think uBlue with homebrew is doing something more sustainable here though, as homebrew is independent, well maintained (cross OS!) and does not rely on having a separate OS run in parallel. So if you imagine Fedora would only supply base packages in some future, a project like homebrew could take care of the rest.

    Also I couldnt even get the Debian version installed in a Qemu VM, same as with EndlessOS, so yeah so much about "alternative immutable distros".

    [Resolved] After updating through both APT and the Software Store, I can't play mp4 videos with VLC anymore. The screen goes blank for a second or two then the audio starts playing without the video..

    I'm using Debian 12, Ryzen 7 5700X processor, and Radeon HD 5450 graphics card. I have tried uninstalling and reinstalling VLC but it didn't resolve the issue. Here's an excerpt from the VLC's log file:...

    boredsquirrel ,

    Try Celluloid Flatpak. It is slim, perfectly packaged and uses MPV.

    Saves you a lot of troubles.

    boredsquirrel ,

    Very interesting, there is some proprietary "Terminal + Filesystem" app on windows that had this, what was it?

    Also, is X11 as secure as VNC or RDP? I mean it is likely used as much.

    And where to position moonlight and sunshine here?

    boredsquirrel ,

    Yes, MobaXTerm

    Thanks for the heads up! So both connection protocols use ssh, which is supposedly damn secure.

    Moonlight is supposed to way better for latency, so if it can be secured as well, may be a better VNC?

    boredsquirrel , (edited )

    BTRFS is not more performant than EXT4.

    I personally dont use any features of BTRFS manually though, as Fedora Kinoite does that for me.

    boredsquirrel ,

    But you can also just use BTRFS without any fancy setup and not use its features, it will still be faster.

    boredsquirrel ,

    My short BTRFS history

    1. Installed on a 1TB NVME
    2. used for 2 years
    3. Rebased my system a ton, used rpm-ostree a ton (which uses BTRFS for the snapshots I think?)
    4. Physically broke the SSD by bending (lol used a silicon cooler pad but it bent it) which resulted in hardware crashes
    5. With dd barely managed to get all the data onto a 1TB SATA SSD
    6. dd-ed the SATA SSD onto a 2TB NVME
    7. deleted and restored the MBR, resized the BTRFS partition to max, resized the BTRFS filesystem to max, balanced it

    Still works, never had a single failure

    boredsquirrel ,

    I never tested BTRFS on SSDs under 128GB or even HDDs, but never had a corrupted one.

    Those anecdotes are worth little so it would be best to have current data.

    One of the above points was that the claims are outdated, which would be really interesting to verify.

    Like, making a study with many different parameters

    • hdd, sata ssd, nvme ssd, emmc, etc.
    • size: 50-200MB, 1GB, 16GB, 128GB, 500GB, 4TB (from small embedded, to IOT, to usb flash drive, to smartphone, to laptop, to Server/Backup)
    • amount of usage: percentage filled, read/write per minute
    • BTRFS actions: snapshots, balance, defragment
    boredsquirrel ,

    I suppose by being more efficient, "using modern technology" (everything saving Google, Meta, Amazon etc. money and is thus extremely well funded, all server related stuff), is good for the environment.

    If something runs faster on the same hardware, it may use less energy. It may also just be restricted in hardware usage, like not using multithreading.

    Linux Distros shipping x86_64-v2 packages is a whole other problem...

    boredsquirrel ,

    Like, all of them... or would you be a bit more specific?

    Old CPUs are an okay use case, but targeting will literally remove all benefits in efficiency that were made in the last 14 or so years.

    My Thinkpad T430 has v3, and it is a 3rd gen intel. People honestly running hardware older than that are rare.

    For sure the hardware should be supported, but it is not the target audience and pulls the others down.

    boredsquirrel ,

    What do you think "being old" has to do with performance?

    Being tailored to NVMEs or SATA SSDs instead of to HDDs and similar. But I am not sure about which one would be better here.

    Phoronix Benchmark so we have something to look at

    BTRFS seems to be better at multithreading, being outperformed by F2FS (which I forgot to mention, it is used on Android and I would call that damn stable).

    Actually, F2FS seems to be a really good replacement for EXT4, being top in most tests, while having no journaling, while BTRFS in fact worked pretty badly!

    boredsquirrel ,

    No, and this is for sure an issue. Having different repos would increase fragmentation a lot.

    boredsquirrel ,

    Very interesting. I heard F2FS has no journalling, but afaik Fedora Atomic doesnt rely on it?

    It might be worth looking into, as it beat many tests.

    boredsquirrel ,

    Edit: BTRFS has advantages that likely make it better for me.

    It has compression and allows flexible partition sizes. The compression may explain the speed decreases.

    I'm thinking of buying a Lenovo Duet 3 for running linux. Which device would have better compatibility?

    There's two models - the Duet 3 which comes with a Snapdragon 7c Gen 2 @ 2.55 GHz CPU, and the 3i which comes with a Intel Celeron N4020. I would rather use the Duet 3, due to the cover, and since I am already familiar with the feel of the device due to having owned a Surface Pro 4, but I'd like to choose whichever works best...

    boredsquirrel ,

    8GB is enough but not nice. 12GB is my sweet spot for normal tasks, everything above is for virtual machines etc.

    boredsquirrel ,

    And they support Linux out of the Box.

    boredsquirrel ,

    This is not true at all. There are tons of Linux Distros running natively on ARM.

    Debian, Ubuntu, Fedora, etc.

    boredsquirrel ,

    If you are not techy stay away from Chromebooks. mrchromebox.tech offers custom firmware which allows you to run real googlefree Linux on them, but still.

    I havent found one that is worth the price. They are often unrepairable, have soldered everything and on purpose too low specs. Like 128GB of storage is rare, and that is a minimum for anything real. 16GB RAM is almost never available.

    boredsquirrel ,

    Really cool, use it sometimes but never understood it really. It is so useful to get strings from whatever file you want

    boredsquirrel ,

    So now we have Lapce, Cosmic-Edit, Helix (vim clone) and Zed, all in Rust. Nice!

    boredsquirrel ,

    What means "vim mappings"? I only ever used helix so I supposed it has the same key bindings as vim?

    boredsquirrel ,

    Interesting, Konsole has support now?

    Alacritty doesnt, so Cosmic-term also not. Lets see!

    boredsquirrel ,

    I think SDDM is mainly maintained by Plasma people? But I dont know.

    boredsquirrel ,

    How would this be done?

    boredsquirrel ,

    Flatpak doesnt handle that, this is an xdg-desktop-portal by your Desktop that is also used for other apps.

    boredsquirrel ,

    MTP totally sucks though, it is a pain in the a**.

    Would rather use Syncthing or localsend

    boredsquirrel ,

    Would be nice to have a date on that statement in the product description. Seems to be outdated?

    boredsquirrel ,

    Having only small experience with this I already know how painful it is to have PRs simply not merged forever.

    boredsquirrel ,

    I agree app indicators are a very strange concept, but the alternative is an app using an extension to place itself in the quicksettings or similar.

    Like: Syncthing, Nextcloud, VPN apps. How would they display their small info and sync status?

    boredsquirrel ,

    There literally was an implementation that was dropped, and I think it is clear that a PR for a better one would be dropped too.

    Instead, GNOME users can stare at an empty panel, while KDE Plasma saves screen space and still has a panel with apps and all needed infos.

    boredsquirrel ,

    On Android apps abuse the persistant notification for just that, while app indicators or a specific area to place those would be way better.

    I mostly mute the notifications as they are so annoying, but it is very bad to not have them too.

    boredsquirrel ,

    They dont need to, a Desktop could just use another compositor and the rest of the stuff but they often dont. wlroots is a project doing some general work, but most of the others dont.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • All magazines