• 0 Posts
  • 9 Comments
Joined 9 months ago
cake
Cake day: February 20th, 2024

help-circle


  • run on boot is easy if you run containers via systemd, if service is enabled it auto-starts on boot

    TIL, thank you for that insight!

    if disabled, than you start it manually.

    That’s the peculiar part; some of the containers I’ve had since I was on Silverblue, but back then they never autostarted on boot. Just (relatively) recently, since the rebase to Bluefin-dx, have I experienced that all of the containers -so even the ones that existed prior- autostart on boot.


  • podman does not autostart containers after boot. You have to manually start them, or write a start script. Or create a systemd unit for each of them.

    FWIW, I’m on Bluefin-dx (one of uBlue[1]'s images) and I’ve noticed that my containers autostart at boot since I’ve rebased from Silverblue to Bluefin-dx. Mind you; I’m not necessarily advocating for you to make the switch to Bluefin-dx, but it’s at least worth finding out how they’ve been able to achieve that and perhaps implement their ways for your own benefit.


    1. Which are mostly Fedora Atomic images with some QoL and thus SELinux, Podman (etc.) are just baked in as you would expect.

  • Same for me, with the addition of me being a people-pleaser. I already have to select which voice I listen to, since there are hundreds of different ones contradicting each other.

    Very commendable! I hope you can remain positive and optimistic. Unfortunately, I’ve stopped caring much for others’ opinions. I hope I’m wrong; but to me most people that engage in these topics somehow lack knowledge, are not very intelligent or just plain ill-informed/ misinformed and obnoxiously oblivious for how wrong they are. This doesn’t mean that others’ opinions/views are de facto wrong, but I try (as hard as it sometimes is) to assess/evaluate ideas based on their respective merit(s) rather than how often they’re voiced or how popular they are.

    Fedora Atomic has matured heavily, and I think it is perfectly usable, both in terms of reliability and availability.

    Absolutely. I find it hard to recommend other distros, unless something specific is sought after that’s either very hard or plain impossible to materialize/accomplish on Fedora Atomic.

    It’s just that it is quite different from other distros, especially when you want to install apps. For newcomers, just telling them to go into the software center and selecting the apps to install (via Flatpak) is perfectly enough. It only gets a bit more complicated when they want more and have to turn to the CLI (e.g. Distrobox).

    Paradigm shift for sure. Curiously, I’d argue the average Android/iOS-user should be fine with only resorting to the software storefront. So in a sense, non-Windows/Linux users might have it easier on Fedora Atomic 😅. Simply for not having (false) preconceived notions on how something should work/function.


  • Which one(s)

    Unsure if distrohopping the dualboot counts, but if it does, then the following was my path (note that after Fedora Silverblue was installed, it remained on the system; the two distros in between the two Silverblues were dualboots):

    Fedora Kinoite -> Fedora Silverblue -> EndeavourOS -> Nobara -> Fedora Silverblue

    why?

    I started with Fedora Kinoite after spending 1-2 weeks on gathering information on distros. During the research-phase, I learned what distros are, their components, how to analyze the differences between distros, which components are ultimately more beneficial for me and thus slowly but surely the distro that would suit me best started to take shape.

    My switch to Linux was on the basis of privacy concerns and Windows 10’s mishaps on my laptop were what pulled the trigger, which in retrospect were probably caused by hardware faults. Regardless, as privacy was my main concern, security became paramount; as there’s no privacy as long as access to your data is not secured off. Therefore Qubes OS, while not necessarily a Linux distro, would have been my first choice. But, unfortunately, my system wasn’t capable of running it.

    Therefore, I had to settle with something else. As my endgame is Qubes OS, I wasn’t very interested in getting into the nitty gritty of Linux for the virtue of hardening it. Instead, I opted to rely on a distro that would do the heavy lifting for me. Such a distro wouldn’t only have to be known for taking security very seriously, they also required an excellent track record. As such, I landed on Fedora, Kicksecure and openSUSE. Other projects that are known to take security seriously like Whonix and Tails aren’t suited for general use. Furthermore, they’re ideally used in conjunction with another system; Whonix as a VM and Tails accessed on a USB-stick whenever you require an amnesic operating system.

    Choosing between Fedora, Kicksecure and openSUSE was hard based on these criteria only. The third and final criteria to seal the deal was atomicity. Like I mentioned earlier, my laptop had issues; it could randomly turn off. So I needed a robust system that could handle such disturbances and not die in the process. This is where the aforementioned atomicity comes into play, this ensures that the system either updates or not; no in-between messed up state due to a power outage or whatsoever. At the time, only Fedora had a somewhat mature system capable of atomic upgrades; namely Kinoite and Silverblue. The differences between these two were about their respective desktop environments. I hadn’t experienced either of the two previously, but went initially for Kinoite for how KDE Plasma reminded me more of what I was already used to (i.e. Windows).

    Fedora Kinoite came with its sets of troubles. It was still a relatively young project; it was the first release in which it was officially supported. As I knew how easy Fedora’s Atomic distros made switching from one base to another, I just rebased to Fedora Silverblue with the rpm-ostree rebase fedora:fedora/35/x86_64/silverblue command and went on with my life 😜.

    After this came the honeymoon-phase and I was really positively surprised by how well everything was going. From all the things I had done for the sake of privacy, switching to Linux was (and still is) my favorite. But as I was ever expanding my Linux workflow to include everything I did on Windows, I happened to reach a (seemingly) insurmountable obstacle; Davinci Resolve. No matter what I did on Fedora Silverblue, it was always functioning less performant compared to Windows; which in retrospect seems to be related to the fact that Davinci Resolve requires a dedicated GPU on Linux (though some workarounds do exist). In hopes of resolving this issue, I tried to install Arch as a dualboot. As this was pre archinstall, this was a miserable experience. And after a few tries, I still wasn’t content with what I got and instead opted to install EndeavourOS.

    EndeavourOS was pretty cool. I already liked what I saw from Arch within Distrobox and EndeavourOS was able to deliver an excellent experience (at least initially). Davinci Resolve worked better here than it did in Fedora Silverblue. And it was overall a pretty snappy experience, so I returned to it occasionally for other things (like gaming) as well. Until…, one day…, it just stopped working 🤣. Perhaps I could have done a better job by installing Snapper/Timeshift, but I didn’t and didn’t care enough for it to reinstall…

    Of course, the departure of EndeavourOS did leave behind a void, so eventually I tried Nobara as I believed it might be capable to provide a similar experience. And I did like it, though not to the degree of EndeavourOS. Eventually this one also passed out 🤣.

    Currently, I’ve just dismissed the idea to run Davinci Resolve on Linux and I’m more happy ever since 😜. For better performance during gaming, I’ve since been resorting to bazzite-arch and Conty. While performance shouldn’t be as good as native CachyOS or other highly optimized gaming distributions, it’s more than fine as is and the sub 5% performance/fps I’m missing out on is not worth for how much more convenient my current setup is.

    FWIW, I do see myself utilizing Gentoo and NixOS in their designated qubes whenever the switch to Qubes OS occurs. But until then, I’m making the best out of Fedora Silverblue.


  • Thank you for your elaborate reply 😜!

    The guide is mainly meant for exact this kind of new users, who are perfectly fine with either Fedora or Mint. I excluded edge-cases, like QubesOS, completely on purpose, as this should be consisting of only 2 (or so) distros with different DEs. This should make 80% of exactly those post redundant. If someone wants a “non-normal” distro, they can still of course feel free to ask.

    I agree that it makes sense to start with tackling the problem in a way compliant with the 80/20 rule; i.e. 20 percent of the work to deal with 80 percent of the cases. I’m perhaps too much of a (wannabe) perfectionist/tryhard, which is why the process described in my previous post was a lot more involved and (perhaps) therefore more utopian/idealist than realistic. Perhaps I’ve even alluded to this a couple of times 😅.

    I thought about using Sozi as a tool to achieve that. I have to research tho how to make a website first. My idea was to keep the exact structure of the chart, but when you zoom in a lot to the distro, you get the description.

    Great idea! FWIW, perhaps an interactive map with pop-ups may be utilized to that effect. Though, there’s plenty to consider here and a lot of ways to do it justice. I trust in your capabilities to achieve that splendidly.

    I see VanillaOS as a great competitor to Mint, especially for people who want something of a managed and simple experience, while also being capable to do normal PC stuff. I see VOS 2 as “stable” enough in just a few weeks, there’s mainly only some polishing and fixing in newer under-the-hood stuff, but the surface-stuff is already fine.

    I haven’t installed the beta of its Orchid release yet. So, hopefully my gut feeling is just wrong. Ironically, the first time I installed a relatively immature version of an atomic distro (Fedora Kinoite, but like its first release (so Fedora 35 at the time)), it was a very bad experience and I rebased right away to Silverblue and haven’t look back since 🤣. Hopefully others will not be stung by VOS 2, like how I was stung by Kinoite.

    It’s mainly about preference, if one likes a simple UI or prefers traditional workflows. How can I make that more clear?

    By not naming any of the associated operating systems, but instead opt to distill their respective workflows in plain text. I’m very aware that this is pretty hard without spending way too many words on their descriptions. Therefore, perhaps it’s worth exploring if the ‘intended workflows’ of the different DEs might be (screen) captured and displayed as gifs. Obviously with the caveat that the ‘intended’ isn’t forced upon them and that they’re free to change them to better suit their needs.


  • First of all, I applaud your efforts. Making an all-encompassing guide/flowchart that is able to answer all kinds of needs that new users might have is hard and not done in just a few sittings. And it seems you’re willing to iterate a couple more times until you and the community are satisfied with the end result. That’s just awesome and highly commendable.

    As for my personal critique, perhaps it’s noteworthy that I’m not entirely satisfied with the current setup. I think the following would align better with my personal convictions on how I would assist friends and/or family with these matters:

    (long text)
    • Step 1: Hardware probe. So, somehow establishing what we are working with as this sets severe limitations to our options. Personally I would divide this in three groups:
      • potatoes; suited to run only distros like antix, puppy linux etc
      • old(er) devices; suited to run DEs like Lxqt, Lxde and perhaps even Xfce etc
      • ‘modern’ devices; suited to run DEs like Cinnamon, GNOME, KDE Plasma etc It’s of course important to note that someone with ‘modern’ hardware is absolutely free to run something like Xfce if they like its design choices (i.e. offering a very stable experience that’s unlikely to change for the sake of change). Furthermore, special attention would go out to hardware for which it’s known that it requires special attention (like Nvidia GPUs etc). This should result in picking distros that are better suited for running that hardware (like Pop!_OS and uBlue for Nvidia), but also distros that specifically target a piece of hardware; like what uBlue tries to do for Framework etc.
    • Step 2: Investigate their intended usage and what software they would rely on. Do they absolutely need Adobe’s Creative Suite? Well, then they should at least go for a dual boot or simply stay with Windows. The same would apply to any piece of software they might specifically need, but that simply does not work on Linux. Furthermore, their intended usage might be tied to their motivations for making the switch. Some of which would be: learning Linux, for Linux’ improved workflow for specific use cases (programming, workflow benefits related to the use of tiling WMs, pentesting etc), privacy, reviving old(er) hardware, free as in beer, freedom to tinker to their heart’s content, F(L)OSS ideology, transforming their hardware into a game console/HTPC/media-box, improved performance under some circumstances or just plain curiosity etc. Each use case comes with its accompanied set of viable distros. Of course, it’s very hard to be exhaustive here. Therefore, you’re absolutely forgiven for only focusing on some of the more common ones.
    • Step 3: Update cadence. Some people hate updates with their lifes, or only tolerate security ones. Others, simply want the latest and greatest at all times. Simultaneously, some may want said updates to occur automatically in the background, while others want deliberate control in that aspect. Lots of different distros exist with lots of different approaches to how updates are handled. As updates are our primary suspects whenever breakage occurs, it’s therefore vital that the update cadence is aligned with the user’s preferences. Hence a distro should be chosen accordingly.
    • Step 4: Priorities. Security vs convenience. Blank slate vs sane defaults. Control and responsibility vs ‘managed’. Learning platform vs consumption platform. Means to an end vs end in itself. Performance vs stability; these two aren’t mutually exclusive to each other, but helps in determining what the user finds important. Furthermore, ideally these should not be binary choices but allow steps in between the two ends. Finally, each of these choices should also be weighed against one another. Like, if someone highly values security over convenience and believes this choice is a lot more important to them than all of the others, then they should definitely consider Qubes OS for example. Similarly, other conclusions could be made based on a different evaluation etc.
    • Step 5: Desktop Environment. Based on the earlier questions, only a handful of distros should remain or perhaps it’s even somewhat expected that just a specific distro remains. Regardless, most distros allow different desktop environments to be installed and thus a choice should be made between the different available options. In the case of desktop environments, one should just try out the available ones until a decisive choice can be made. Switching later on is fine anyways.

    Having said all of that, whatever is mentioned above is a lot more involved than what you have currently. Therefore, I wouldn’t be surprised if you would deem most of it out of scope.

    Moving on to the actual critique:

    • While I (somewhat) understand why you’ve tried to tie one’s preferences in earlier used OSes to a potential desktop environment they might like, I do think that this might set new users up for false expectations. Therefore, I would propose to not even go there. If you want them to make a conscious choice on the desktop environment, then perhaps implore them to boot a live USB environment in which they can explore it themselves. The only important thing to note would be that in all cases customization is allowed and thus they shouldn’t necessarily abandon a DE for a minor issue as it’s most likely easily solvable.
    • If this gets good (and it certainly has the potential), then only the flowchart itself will be shared while the accompanied text might be disregarded. In hopes of ensuring that others also read the accompanied text, consider to either (somehow) include the text in the image of the flowchart or include a link to the text and ensure it’s easily found and one is somehow able to easily access the text through the link. This might even require a shortened custom url that redirects to the text. The exact specifics are obviously up to you though.
    • I can’t agree with the inclusion of both Pop!_OS and Vanilla OS. Don’t get me wrong, the potential is absolutely there. But both are currently in a major overhaul and need at least one or two proper releases to mature. Expecting new users to either start with the ‘abandoned’ old release which they might have to abandon themselves when they move over to the (eventually) matured new release or start with (at best) beta software that may come with a lot more trouble than worthwhile is IMO irresponsible.
    • I got a ton of smaller (personal) nitpicks, but most of those are related to scope and/or preconceived notions and therefore not worth mentioning here.