Thank you so much for your insights!
throwawayish
joined 2 years ago
XY problem confirmed. Thank you OP!
There have been complaints in posts about people asking for advice on which disto to use, that there are too many such posts.
This is a legit concern.Thank you for trying to tackle this!
Provide users the tools to possibly answer the question themselves before creating a post.
Noble. And in its essence, it makes a lot of sense.
DistroChooser is a self-help tool for that purpose.
As a self-help tool it's very bad. Sorry*. I actually hoped that you would mention how it might be used as a basic requirement for anyone that asks which distro to use. The enforcement could be done with a bot which simply scans if any link to distrochooser is present in a post that remotely resembles one that asks for advice on which distro to use. I would actually even argue against this, but I think we might be able to reach an agreement on which questions are actually worth keeping around for further use...
- keep answering posts --> more complaints, possibly silent quitting of community
Honestly, this is better than to limit newbies to strictly stick to Distrochooser for asking which distro they should use π€£.
- write bot --> I ainβt got the time, maybe somebody has, dunno what the bot would do
I haven't got any experience with building a bot, but I suppose it works by scanning for words in posts. In that case, simply 'flagging' everything that contains the words "which" or "what" in combination with "distro(s)" or "distribution(s)" and ask them to refer their questions to a dedicated Lemmy community in which they can ask would already solve a lot.
- find alternative website --> I ainβt got the time
You don't have to find an alternative website. Nor write one yourself. As it stands, as far as I'm aware, there's simply nothing that satisfies the basic needs for this.
So what do I propose? Relegating these questions to their own dedicated Lemmy community is probably a great and easy solution. If something like a test/algorithm/flowchart/quiz/whatever has to be created, then that one might need substantial effort to get off the ground. However, perhaps comments like these might be helpful as a blueprint.
Sorry, I think I might have confused OmniOS with QubesOS.
π , but QubesOS isn't a derivative of OpenBSD either. It might have inspired some of its parts, but fundamentally it's a completely different beast.
ZFS is itself a security feature because of how well it guarantees the fidelity of your data.
Do you happen to know if this goes beyond what Btrfs(/Bcachefs) provides on the Linux side of things?
Honestly, I don't know if that's the case; I always got scared whenever I saw the prerequisites for Heads in combination with the strict list of supported hardware. FWIW, the NV41 that's used for enabling Heads on NovaCustom's device is included in the short list of supported hardware for Heads, while -unfortunately- the same doesn't apply to the StarBook. I would love to be proven wrong though!
Good question! However I think it's wise to concentrate on a particular word/phrase before actually answering your query.
In an immutable setup on Fedora (trying to main Bazzite) is the correct way to use zsh and oh my zsh as my main shell
Currently, it's not always clear if there even is a correct way of installing some of these (more) edge cases. Therefore, I wouldn't be surprised if you'd see 'seasoned' Fedora Atomic users that have all tackled these in very different ways while being satisfied with (not only) their own solutions (but also approve the respective solutions of their peers).
As for your query, I would say that starting to use Fedora Atomic and pointing out correctly some of the more common ways to install software while being aware of the ambiguity that exists with the chosen installation method for this specific piece of software is already very commendable. So I would like to congratulate you on that!
But, you shouldn't be afraid to stick to what's easy (aka don't allow good to be the enemy of perfect). If the extra time required for changing your base system doesn't bother you at all (which happens automatically in the background anyway), then layering it (thus installing with rpm-ostree) is probably the easiest method while protecting you from a lot of possible edge cases you might have to deal with otherwise. Traditionally, zsh (and other shells) were layered (thus installed with rpm-ostree) and uBlue itself included (perhaps still does) just commands to change root shell to zsh, fish etc. This might have changed in the last few weeks, but I think it should still be a safe bet. FWIW, I have never had any troubles pertaining to my zsh installation and any of its plugins (might as well link the managed zsh-config I rely on).
OpenBSD and its derivatives (like OmniOS)
First time hearing of OmniOS, thank you for mentioning it! EDIT: I just took a look at it and it doesn't seem to be based on OpenBSD, at least the one I could find seems to be a derivative of Solaris instead. Though, I might simply not have found what you referred to*.
because it of its security-oriented features, especially things like ZFS
Does OpenBSD's implementation of ZFS offer security features as well?
I would like to switch my daily driver, a Linux laptop, to OpenBSD so I can get used to using it as an administrator, but I worry about OpenBSD being able to support the laptop hardware, especially things like WiFi, BlueTooth, and managing the battery, screen dimming, laptop lid, and so on.
Do you think that using OpenBSD inside of a qube (from QubesOS) is perhaps something worth considering? Or don't you think there's any merit of doing this over the use of any virtualization software found on any other system?
I have another Linux computer with a Radeon graphics card which connects to my TV that my children use for video games, and watching streaming video, and I would like to switch this to OpenBSD as well but I worry that it will not be able to run Steam games very well.
From what I've read, running games on OpenBSD is a lot less mature compared to running games on Linux. Though, perhaps it's worth noting that cloud gaming solutions (like Google Stadia in the past) are known to work great on OpenBSD. Not sure if you would want that, though.
(On a more general note) I definitely agree that OpenBSD works wonderfully on the server side of things. But I've gotten skeptical over time to its feasibility as a desktop OS. Note that I'm well aware that OpenBSD's developers use it as their daily drivers, so I definitely recognize the possibility. However, when it's lacking features like Secure Boot (or any form of Trusted and/or Measured Boot for that matter), I just find it hard to justify putting it on something like a laptop that I carry around all the time. I hope that you can prove to me that my logic/understanding is flawed and that I should reconsider the use of OpenBSD as a desktop OS.
It has been my pleasure π!
Aight. I've changed the comment a bit π since. Perhaps it's more useful for you now π.
It seems as if the uBlue images ship the required OpenRazer kmod by default. Therefore, I would suggest you to take a look at those. You still need to follow some additional steps though π . Which might not be very intuitive... Thus, I propose the following: if you'll rebase to uBlue, you might as well rebase to Bazzite. After the rebase has been completed, the (post-)installation software should already give you the option (it's just a simple toggle) to install OpenRazer. The toggle is clearly visible in this frame.
If you perceive Bazzite as too opinionated for your taste, then perhaps you might opt to the following instead:
install-openrazer:
sudo wget https://download.opensuse.org/repositories/hardware:/razer/Fedora_$(rpm -E %fedora)/hardware:razer.repo -O /etc/yum.repos.d/hardware:razer.repo && \
ublue-update --wait && \
rpm-ostree install -y openrazer-meta razergenie && \
if ! grep -q "plugdev" /etc/group; then \
sudo bash -c 'grep "plugdev" /lib/group >> /etc/group' \
; fi && \
sudo usermod -a -G plugdev $USER && \
echo "Please reboot to apply needed changes."
Which should be the just-entry (and thus responsible) for whatever happens after the toggle is enabled*.
I will simply list a couple of the images^[1]^ I've used over time and provide some personal insights (in alphabetical order):
- Alpine; when I'm restricted in bandwidth and/or disk space. FWIW,
apkis even faster than whatever is found on Arch. - Arch; if I just need a certain package and can't be bothered to look up if it's available on any of the others. Yup, the AUR strikes yet again. Furthermore, if I'm troubleshooting and I find myself on the ArchWiki, then in order to prevent edge cases from happening and thus the provided solutions to not work on the non-Arch distrobox; I rely on the Arch distrobox. It doesn't hurt that
pacman(or any of the AUR helpers) are blazing fast. However, if I intend to rely on said AUR packages over longer periods of time, then I often do look for an alternative distrobox to grab the package from instead. While the AUR is excellent for the amount of packages it has, the security standards aren't the best. Thus, if you're security-conscious, then it's better to rely on AUR packages sparingly, unless you're willing to get into the nitty gritty and check how they're built, how the package is maintained and if its maintainer(s) is reliable. - Bazzite-Arch; my go-to for gaming.
- Fedora; as I'm already on Fedora Atomic, relying on Fedora distroboxes makes the most sense security-wise. Fedora is also known to take security very seriously themselves, so in general this is just very pleasant to rely on for security reasons. The only reason why one should not rely on Fedora for security reasons would be if they're already on something from openSUSE (like Aeon/Kalpa/Tumbleweed etc). In that case, going for an openSUSE distrobox makes more sense for security. Furthermore, if the package I need is one that's widely accessible, then I also rely on Fedora distroboxes. Lastly, currently, my development environments are all Fedora distroboxes. I might eventually change these to Wolfi distroboxes or simply rely on Nix, but that's still WIP for me.
- Ubuntu; I've had to rely on these a couple of times to use software that's known to target Ubuntu. Most recently it was with Matlab IIRC.
- Wolfi; For the security-conscious, this is probably the best choice. Unfortunately, I've only experimented with it so far without too much success. Thankfully, the Bluefin project has made some good use out of it. So I'll try to emulate their ways in the near future.
Notable mention goes out to Davincibox. Unfortunately my laptop doesn't have a dedicated GPU, so I can't make use of it. But it's something I'm keeping my eyes on.
NixOS is not a supported container distro, but I do have Nix installed through The Determinate Nix Installer. It's somewhat underutilized currently, though π .
- The images will be the toolbox ones if available.
Oh wow! This is excellent news! I hope they'll also provide other privacy/security related features like Heads, the removal of the camera and/or microphone modules, pre-installed privacy screen, tamper-evident screws and packaging.
view more: next βΊ
While I get why Linux Mint (with the Cinnamon DE) is regarded as a Windows-like, Pop!_OS is far from that. Furthermore, going from iOS to Android is arguably a smaller change than going from Windows to any Linux DE (so even the Cinnamon DE (on any distro)). Regardless, the Desktop Environment is the single most influential part of a distro to how you experience any distro. Therefore, if you actually want a new & fresh experience, then you should definitely check out DEs like Cinnamon, GNOME, KDE Plasma and Xfce^[1]^ on something like a Live USB (perhaps through the use of Ventoy). After you've experienced a bunch of DEs, you should have attained a better grasp of what you like and don't like.
While Distrochooser is cool and all, you shouldn't take it too seriously π . If possible, consider sharing your results on Distrochooser, that might at least provide us some pointers.