[–] 3 points 5 days ago

The Qt 6.11 update quietly made a decent number of breaking changes and a good amount of apps (including the old Jellyfin Desktop app in this case) that have simply had the dependency version bumped on them have encountered a variety of breakages,

Something that might also be happening is that there are genuine patches in master branch for use with Qt 6.11, but the Flathub package is not pulling them as it is still tagged against v2.0.0. Seems either a proper release should really be tagged upstream or the Qt 6.11 bump patch should have never made it to public on the Flathub package.

  • source
  • [–] [S] 2 points 1 month ago* (2 children)

    Just to do a bit of sanity checking on my end and because I still have the dead KabelDirekt cable for reference, I chopped and dissected the cable for speculation. I am first shocked at how good of reviews such a cable can get for its construction choices. The outer ground is of good size, but both stereo channels use tiny 26 or 28 awg 10-strand copper, which is no wonder the thing failed in under a year. Everything in the cable appears to be regular stranded copper. The PVC sheath on this cable is about 4mm, same as the (presumably pvc sheath plus) braided Syncwire cable. KabelDirekt's comparable braided cable is about 5mm by comparison. The review distribution between the PVC KabelDirekt and Syncwire cables are nearly the same, which makes me wonder how bad a cable really has to be for the reviews to significantly dip.

  • source
  • parent
  • context
  • [–] [S] 1 point 1 month ago

    For me, being braided isn't a huge deal as the cable would be almost exclusively used at a desk with a slack holder. I so far have been picking PVC sheathed cables simply because they do have less sliding friction and the aforementioned lesser noise when the cable is moved, but I doubt braided would be a deal breaker for my use case.

  • source
  • parent
  • context
  • [–] [S] 1 point 1 month ago

    I definitely don't expect such a cable to legitimately last a lifetime. I'm simply getting tired of having to regularly go back into looking for something that should reasonably last at least 3-5 years of regular use or 5-8 years if it's a premium product.

    Unfortunately, my headphones (Philips SHP9500) only have a 3.5mm jack. To mod anything else in, I'd have to legitimately drill out the existing jack, which I'd really only want to do if the jack had already failed.

  • source
  • parent
  • context
  • [–] [S] 3 points 1 month ago (1 child)

    Definitely a good thing to keep in mind. Doing a bit of further research, depending on the composition of the tinsel wire, it's seems feasible to DIY a cable with soldered connections to 3.5mm male plugs, albeit with some extra material spent as practice to get technique, temperature, and time correct.

    Unless I happen to find a premade cable that is suitable for conversion out of old hardware, it definitely seems like actually sourcing woven tinsel wire in suitable thickness for a headphone cable is quite the challenge (for a reasonable price anyway).

    If nothing else, the Syncwire cable is cheap enough to be a good value, provided it does last a while.

  • source
  • parent
  • context
  •  

    I didn't think I'd ever get to the point of asking for this product specifically, but are there any recommendations for 3.5mm TRS male to male cables, suitable for headphones, available for purchase from mainland US, and preferably 10ft?

    In the past year, the original cable that came with my SHP9500's started to exhibit problems, and had to be replaced after ~5 years of regular use. This past year, I had replaced it with a cable from KabelDirekt, which failed in about 7 months. KabelDirekt's warranty handling simply refunded my purchase rather replace the broken cable, so I took it as a sign that they weren't confident in their products and to try a different company. I then went with a Monoprice cable, which I have gone through three of. None of the three so far have lasted more than 3 weeks, and Monoprice is asking to have the existing faulty cables returned via a rather inconvenient shipping provider before sending another.

    Right now, I have stolen my record player's RCA to 3.5mm cable and an RCA-3.5mm adapter, which is working for the time being. Unfortunately, it does seem that the manufacturer (Ugreen) has stopped selling audio cables however, nor do I really want to be stuck with an adapter chain off of my audio interface.

    [–] 3 points 1 month ago

    Not that I should even bother, but:

    If my recommendations reflect a common consensus in this community, then perhaps there is good reason they are popular, no? In my case, I personally know the person who runs the VPS I rent and do actively trust them. I know that situation isn't going to be the same for everyone, but if you don't fully trust your VPS provider, there's a reason TLS forwarding and ZTT solutions like Tailscale exist.

    And sorry my writing isn't to your expectations, I guess.

  • source
  • parent
  • context
  • [–] 1 point 1 month ago

    My use case has containers and reverse proxy all rootless on a given machine. TLS certs pulled at proxy level. I explicitly group small clusters of relevant services per machine. Authentik and other utilities live on one machine. Things like Jellyfin and Navidrome on another, etc.

    The real way to achieve the same using user isolation rather machine isolation (given you'd be having multiple reverse proxies on one machine) is to have a second layer reverse proxy with no TLS or anything, simply handling the routing to the then off-port HTTPS connections published at system level.

    For my public-facing stuff, the reverse proxy on my VPS does roughly the same thing, taking my HTTPS connections and either directly forwarding, or decrypting and rewriting the cert to a wildcard one I use if I need packet filtering or other tech for a given service. Having well-defined network ranges and reverse proxies being assigned static addresses (container-level networking or otherwise) helps significantly when working out your trusted proxies config at each layer.

  • source
  • parent
  • context
  • [–] 14 points 1 month ago (3 children)

    I have a few practices, technologies that I leverage across my systems, network for selfhosting.

    First, the principles I follow:

    • Least access — Limit exposure of ports, services to as limited an audience as possible.
    • Don't put all your eggs in one basket — Spread your service deployments out across different machines, or at least different users on the same machine. Group relevant services together as seen fit, but don't deploy everything in the same place.
    • Security through obscurity is bad — What I mean is make your process for deploying and maintaining applications easy to read and understand the context. Software versions, customizations, and other tweaks should be easy to find and understand.
    • Mind your secrets — Seriously, don't engage in practices that may lead to exposed secrets. Keep files that may have them out of your git repos. Read your logs before pasting them or feeding them to another application. If it can be done, automate secret deployments where possible.
    • Understand your tech — Learning stuff in the context of LAN is perfectly fine and I encourage doing so. For anything that you plan to bring to any wider network though, please do the recommended reading about each component you are using. Security mistakes often come from glossing over something that wasn't apparent, but was important. Yes, this will slow down your work to a crawl if you're used to just pulling Docker images and deploying at-will. I still recommend to take the hit in speed in order to do things as right as possible the first time.

    Now, onto the actual technologies and practices I use:

    First off, as hinted above, I make heavy use of containerized applications. OCI (commonly referred to as Docker) containers are a convenient way for developers to package their applications, but also offer some affordances in security if you leverage the tools well. I personally use Podman as my tool of choice for many reasons, but one of them being the relatively sane rootless setup that is ready to use out of the box. This means that can be started up at user-level (without root permissions and with user-level restrictions), which is great in case of an exploit to escape the sandbox occurs. Combine this with pairing relevant applications together on different users, and an actual semblance of a security model starts to form in mitigating the potential disaster from a rogue container. If you use multiple users on a system, make sure they are isolated users who should not be able to even read another user's files; don't give users free sudoers access. I also utilize multiple different machines for different processes, which works as well.

    Secondly, I utilize Quadlets, a way to write podman container, pod, network definitions as SystemD units, and be able to hook them in with other SystemD units. I love this approach for many reasons, including having declarative definitions of most of my deployment stack. Certainly makes redeployments, migration, and restoration a breeze when tracked with git. More importantly for security, an easy-to-read set of config files makes managing selfhosting significantly more predictable and boring, which is how it should be. Any question I might have about how something is setup I can find within a minute every time. Less guessing, less searching, more informed decisions; which is crucial to making less mistakes that could have security implications. Practically speaking, there are more than just Quadlets: Docker compose, Kubernetes definitions, Helm charts, and others all exist with their various strengths and weaknesses. Pick what works for you.

    With actually exposing stuff to the internet (or at least a broader network), I do limit my machines' reach where possible. I have the capability to, but do not directly port forward anything from my home router. I rent a small VPS with minimal latency to my location that I use as a forwarding proxy for public services. I have a wireguard tunnel on my home router to the VPS that I let access specific IP ranges that contain my static IP server IPs only, with firewall rules on the router to back the access grant in the tunnel config. From there, I forward traffic to the VPS's public IP with FirewallD on the edge, or have traffic sit behind a reverse proxy on said VPS.

    With most traffic though (especially with services I don't completely trust to leave exposed), I restrict who and what may gain access to said services. If the model works for you, Zero Trust Tunneling / Mesh Network solutions like Tailscale, Netbird, or Netmaker are of high recommendation. For many of these, they allow you to connect end-user devices and serving devices together over a dynamic Wireguard tunnel (or similar) to share services that normally wouldn't be as suitable sitting on the open internet. I personally run a selfhosted instance of Headscale which also sits on the edge VPS, and acts as my Tailscale control server and sole traffic relay for connections that can't be direct peer to peer. Most of my services sit behind the requirement of being in the virtual network, while some I configure dual-offering. I should note that using Tailscale and others that offer direct peer-to-peer will directly expose your devices' public IPs to others in the network that can interact.

    Lastly, I can note that while there have been many efforts with various solutions to try and make selfhosting as mindlessly easy as possible, I don't recommend running many of them for a very specific reason. Much like how I hate people using LLM chatbots in place of their own brains to try and solve problems, having some container management platform take the initial setup out of selfhosted applications and attempt to abstract away as much of finer details as possible can lead to a fast initial deployment, but certainly not a secure one long-term. I do believe there are many practices and details one should learn about their selfhosting setup (such as networking, firewalls, what each app depends on, how best to upgrade them, when to pin application versions, etc.). Having a platform take that away in the beginning will only lead to problems later down the line when those funny little details start to become more important. Only learning about those details when the problems start to occur becomes a much more monumental hurdle to cross than simply learning the details as you set things up for the first time.

    Final Notes

    This comment is quite large, even by my standards. Yet, I am sure I have missed something somewhere. I will be happy to reply to any specifics about either technology or practice if I missed anything.

  • source
  • [–] 19 points 1 month ago

    Generally, your auth provider (assuming setup correctly) should be one of the most secure components of your internet-exposed setup. That being said, vulnerabilities can and do occur. Adding a combination of Crowdsec, OWASP CRS, other ModSecurity rulesets, and/or fail2ban will add a degree of migitation of potential exploits by blacklisting known bad actors/active bad behavior.

    Above all, you should have a plan to keep aware of updates to your publicly-exposed software and be able to deploy those updates in a timely fashion.

  • source
  • [–] 2 points 1 month ago

    When I was going for a selfhosted mesh tunnel solution this year, I originally steered toward Netbird given that Tailscale (the client) is rather obtuse to connect with alternate control servers.

    I don't actively use Netbird, but rather did go with Headscale in the end. If you're satisfied with and your requirements for Netbird don't include anything that deviates from their setup scripts, I'd imagine your deployment would go fine. My requirements and my strong desire to have everything relevant in my selhost deployments be fully to mostly declarative, and be trackable via git had me finding out how incompatible Netbird is for me. I don't think I have seen an app more averse to being deployed declaratively, which as it turns out is likely the reason their deployment scripts exist in the first place.

    The there's the (at the time at least) really confusing and contradictory documentation that describe two different generations of potential deployment of the software. Good documentation is half of what makes software deployments maintainable, and Netbird had (and might still have) outright misleading documentation that will have you looping in circles attempting to figure out reasonably standard functionality like using external oidc for accounts.

  • source
  • parent
  • context
  •  

    cross-posted from: https://lemmy.zip/post/52686006

    Forewarning: I don't intend to respond to debates that have turned toxic in comments. Knowing how this topic can be, please don't aim create one.

    Context

    With the EoL of consumer Windows 10 recently, I have had a fair few friends and family that have moved over or are preparing to move to a Linux distro in the near future, with my guidance. As such, I wanted to gauge some of the community for what distros and editions (default DE's) that many are actually recommending for others, as well as ones that are recommended to avoid. In additional, I am curious what stipulations are tied to said recommendations (limitations, specific use-cases). In a lot of Lemmy and Reddit threads, Mastodon posts, and YouTube comment sections I have scoured, I have seen many recommendations, some that I currently strongly know why you would or wouldn't recommend something. If you care to read what I have to say, I also want to know why my choices do or don't hold up for use cases you've encountered. I have definitely not tried every hardware combination, distro, desktop environment, or other component, and want to know if I am missing anything from others' experience.

    My Own Criteria and Top Recommendations

    Wayland

    I have a few things that I largely see as important for a functional desktop distro that can be recommended for most, if not all use cases. The first is a Wayland-first desktop environment. After using Linux on my own computers for over 10 years, I have suffered through (especially on NVidia) dealing with X.Org and the often severe limitations that can arise. Ten years later on the biggest Wayland environments, we have a pretty firm lack of screen tearing (which leads to an experience that feels much smoother than X.Org or Windows ever did). We also have variable refresh rate support, different refresh rates on different monitors actually working correctly, HDR support, and even cromulent fractional scaling. For all of the faults with the fighting over FreeDesktop protocol specification for Wayland, most of everything that is needed is here, with certain exceptions like some applications missing global hotkeys, some applications sucking at screen capture, and a lack of applications being able to request positioning controls of their windows (primarily for multi-window applications like KiCAD). In which case, having a X.Org fallback environment is still useful for the more deal breaker problems in occasionally needed applications.

    KDE

    With that in mind, I think by-and-far that KDE's approach to desktop development has led to a project that is fairly reliable, yet almost completely uncompromising. KDE has made a lot of things work for "standard" desktop users (i.e. not power users that know how to work a terminal). While still being flexible for power users, and not lacking most of every feature that someone could want out of their environment and applications. Most of everything in KDE that at one time required some level of terminal use has been made into a graphical application.

    Viewing SystemD journals? There's an app for that. Viewing hardware utilization, temperatures, and process info? There's an app for that. Video editing? There's an app for that. Permission management for Flatpaks? There's a settings applet for that. Setting permanent mount points for new drives? There's an app for that. Connecting to your phone for wireless file transfer? There's an app for that.

    I could honestly go on that as far as completeness goes for a variety of the common and less common tasks. KDE covers a lot of different tasks to perform and works well with a wide variety of different applications for more specific tasks (photo editing, 3D modeling, CAD, game design, gaming, screen recording, note taking, office suites, audio editors, VOIP and web chat applications, etc.). KDE is by far an environment that doesn't assume much of anything about other applications, causing the least amount of issues compared to environments like GNOME or certain window managers. With all of what makes KDE what it is, I tend to lean heavily toward distros that have good support for the environment. Additionally, modern NVidia cards with the NVidia-open drivers seem to work quite well with KDE whereas on other environments may not be as seamless and reliable from what I have seen.

    Pipewire

    Another big aspect of that leads to my distro choice is what sound server is the default choice. Back when I started using Linux, it was mostly a field of ALSA + PulseAudio, a couple studio distros that ship ALSA + JACK, and some minimalist distros that were plain ALSA. For most use cases, it was easy to argue that PulseAudio added the right features to be usable for standard desktop and laptop PCs. Now we have Pipewire, which while not the default for every desktop-oriented distro, arguably should be the default experience new users are shipped. PulseAudio had and still has a lot of trouble with various audio devices where even plain ALSA would give less problems at the cost of usability. In many devices I have tested, devices that had problems with PulseAudio don't have these problems with Pipewire. A good portion of these devices include the integrated audio chipsets on various motherboards (RealTek audio mostly), which is a big deal as the motherboard audio outputs and inputs are very commonly used. Pipewire even has the benefit of being able to be interacted with both as PulseAudio and JACK, meaning that PulseAudio utilities and JACK utilities will still work quite well for the power users that want/need them.

    Minimal Required Terminal Usage

    One thing I look for in a distro + desktop environment is how much of the terminal is expected to be used. I have touched upon in it already in my preferred desktop recommendation, but overall most desktop-oriented distros aren't completely independent of the user needing to use a terminal. I think that the occasional oddball system setting or some straight-to-the-point diagnostic tool/script is fine, but requiring regular use for common applications is a bad idea. I personally use the terminal a lot, but a year before the Windows 10 EoL I really started getting a feel for how graphical applications are used in place of terminal applications and utilities, so that I have all of the relevant information for how to do common pain point tasks while using minimal to no terminal usage.

    In many cases, the stigma around Linux users needing to regularly use the terminal is mostly gone for many mainstream desktop-focused distros, and the only thing really holding that stigma for new users is every tutorial being written as generically as possible, rather than how to do a thing in different desktop environments. Many of the (more well-written) tutorials were written by people who want to quickly and efficiently solve the issue, even if that means using tools many users may not be comfortable with.

    Distro Hopping

    This is a short one, but I really dislike recommending something that I know that the user will likely want to jump away from in the future. Many distros have all since caught up in usability and ease-of-use to what used to be recommended as 'training-wheels' distros to the point where it seems that having to reinstall to a different distro and potentially learning a new desktop environment in a year or two might be doing more harm than good for the user who just wants to use their computer in the way they see fit. The only use case I could see is moreso recommending legacy distros for users on legacy hardware or distros with pre-installed and pre-configured proprietary drivers in the cases where it is too difficult to bootstrap the installation of said proprietary drivers after installing the core distro.

    Filesystem

    Finally, there is the lesser point of what default filesystem is used during installation. CoW filesystems like btrfs have become quite reliable, have very useful features (differential snapshots, subvolumes, checksumming). Particularly, my own setups for snapshots and checksumming have saved me from particularly bad file edits or from drive pre-failure (gradual failure). While I think ext4, xfs, and other filesystems are still perfectly fine choices currently, this is something that will weigh heavier toward filesystems like btrfs in time. Ext4 in particular isn't the most resilient to gradual drive failure, and I have in the past ended up with quietly corrupted files without much warning from the drive that ended up having a very short remaining life. If I weren't proactive in spotting and investigating the problem, I could have very well lost the full contents of that drive as SMART only start failing self-test very shortly before full drive failure. Meanwhile with my experience with pre-failure on BTRFS, a filesystem will happily go read-only if there a checksum failures in the filesystem, which can very easily point out that something has gone wrong and will either need maintenance or a drive swap. As more distros than just OpenSUSE actually implement some sort of competent snapshot feature as a default in installs, CoW filesystems will become more of a game-changer for regressions in updates, restoring mangled or deleted user files, etc.

    What I Currently Recommend

    I have a few choice picks for my current recommended distros that I personally recommend. For the primary use case of generic computing (light office usage, mostly web browsing, maybe a bit of photo editing) I will generally recommend an LTS distro, namely Debian or OpenSUSE Leap, with the KDE desktop. Both current versions of Debian and Leap include a version of Plasma 6 and have done a good job of being usable with minimal problems on such hardware.

    For more avid users (often what would be considered power users on Windows) or target hardware that is too new for a given LTS distro, distros like Fedora KDE Workstation and OpenSUSE Tumbleweed with KDE are my prime choices. Fedora can take a bit of extra setup and require a bit of terminal usage in said setup (Appstream data for RPMFusion, future kernel versions installing kernel-devel for out-of-tree modules, setting the nvidia-open flag for proprietary NVidia drivers). Overall, both work quite well. I tend to lean toward Fedora due to the 6-month point release with semi-rolling kernel and mid-cycle DE version refresh versus full-rolling of Tumbleweed. Tumbleweed does utilize btrfs snapshots with selection in the boot loader for easy rollback from any regressions in updates however, making the big downside of a rolling release less painful.

    Finally, for more gaming-focused use-cases, I have started recommending Bazzite recently. A Wayland-first immutable distro based on Fedora Kinoite with ready-made downloads for pre-installed proprietary drivers genuinely provides a painless experience for a gaming-focused environment. Installing any software that doesn't come packaged as a Flatpak can start to show the cracks in ease-of-install compared to a non-immutable distro. As such, the user's focus in primarily gaming and what can be done with applications with flatpak distribution is something that should be verified before recommending.

    What I Currently Recommend New Users Avoid

    • Manjaro (extensive track record for poor maintenance, cannot deliver what it aims to promise)
    • Ubuntu (poor 6 month point release QA, lower LTS release quality than its parent distro, Snap, Canonical's wasted efforts in canned projects)
    • Arch Linux (distro explicitly intended for tinkerers, explicitly expects reading release notes every update)
    • SteamOS (distro not intended for general usage, explicit hardware targets)
    • Pop! OS (one major incident of poor packaging, poor management of LTS release schedule, not Wayland-first (yet), no KDE default)
    • Linux Mint (not Wayland-first (yet), dropped KDE default)
    • Kali Linux, Parrot OS (pentest-focused niche distros even if there is a desktop installer variant)
     

    Forewarning: I don't intend to respond to debates that have turned toxic in comments. Knowing how this topic can be, please don't aim create one.

    Context

    With the EoL of consumer Windows 10 recently, I have had a fair few friends and family that have moved over or are preparing to move to a Linux distro in the near future, with my guidance. As such, I wanted to gauge some of the community for what distros and editions (default DE's) that many are actually recommending for others, as well as ones that are recommended to avoid. In additional, I am curious what stipulations are tied to said recommendations (limitations, specific use-cases). In a lot of Lemmy and Reddit threads, Mastodon posts, and YouTube comment sections I have scoured, I have seen many recommendations, some that I currently strongly know why you would or wouldn't recommend something. If you care to read what I have to say, I also want to know why my choices do or don't hold up for use cases you've encountered. I have definitely not tried every hardware combination, distro, desktop environment, or other component, and want to know if I am missing anything from others' experience.

    My Own Criteria and Top Recommendations

    Wayland

    I have a few things that I largely see as important for a functional desktop distro that can be recommended for most, if not all use cases. The first is a Wayland-first desktop environment. After using Linux on my own computers for over 10 years, I have suffered through (especially on NVidia) dealing with X.Org and the often severe limitations that can arise. Ten years later on the biggest Wayland environments, we have a pretty firm lack of screen tearing (which leads to an experience that feels much smoother than X.Org or Windows ever did). We also have variable refresh rate support, different refresh rates on different monitors actually working correctly, HDR support, and even cromulent fractional scaling. For all of the faults with the fighting over FreeDesktop protocol specification for Wayland, most of everything that is needed is here, with certain exceptions like some applications missing global hotkeys, some applications sucking at screen capture, and a lack of applications being able to request positioning controls of their windows (primarily for multi-window applications like KiCAD). In which case, having a X.Org fallback environment is still useful for the more deal breaker problems in occasionally needed applications.

    KDE

    With that in mind, I think by-and-far that KDE's approach to desktop development has led to a project that is fairly reliable, yet almost completely uncompromising. KDE has made a lot of things work for "standard" desktop users (i.e. not power users that know how to work a terminal). While still being flexible for power users, and not lacking most of every feature that someone could want out of their environment and applications. Most of everything in KDE that at one time required some level of terminal use has been made into a graphical application.

    Viewing SystemD journals? There's an app for that. Viewing hardware utilization, temperatures, and process info? There's an app for that. Video editing? There's an app for that. Permission management for Flatpaks? There's a settings applet for that. Setting permanent mount points for new drives? There's an app for that. Connecting to your phone for wireless file transfer? There's an app for that.

    I could honestly go on that as far as completeness goes for a variety of the common and less common tasks. KDE covers a lot of different tasks to perform and works well with a wide variety of different applications for more specific tasks (photo editing, 3D modeling, CAD, game design, gaming, screen recording, note taking, office suites, audio editors, VOIP and web chat applications, etc.). KDE is by far an environment that doesn't assume much of anything about other applications, causing the least amount of issues compared to environments like GNOME or certain window managers. With all of what makes KDE what it is, I tend to lean heavily toward distros that have good support for the environment. Additionally, modern NVidia cards with the NVidia-open drivers seem to work quite well with KDE whereas on other environments may not be as seamless and reliable from what I have seen.

    Pipewire

    Another big aspect of that leads to my distro choice is what sound server is the default choice. Back when I started using Linux, it was mostly a field of ALSA + PulseAudio, a couple studio distros that ship ALSA + JACK, and some minimalist distros that were plain ALSA. For most use cases, it was easy to argue that PulseAudio added the right features to be usable for standard desktop and laptop PCs. Now we have Pipewire, which while not the default for every desktop-oriented distro, arguably should be the default experience new users are shipped. PulseAudio had and still has a lot of trouble with various audio devices where even plain ALSA would give less problems at the cost of usability. In many devices I have tested, devices that had problems with PulseAudio don't have these problems with Pipewire. A good portion of these devices include the integrated audio chipsets on various motherboards (RealTek audio mostly), which is a big deal as the motherboard audio outputs and inputs are very commonly used. Pipewire even has the benefit of being able to be interacted with both as PulseAudio and JACK, meaning that PulseAudio utilities and JACK utilities will still work quite well for the power users that want/need them.

    Minimal Required Terminal Usage

    One thing I look for in a distro + desktop environment is how much of the terminal is expected to be used. I have touched upon in it already in my preferred desktop recommendation, but overall most desktop-oriented distros aren't completely independent of the user needing to use a terminal. I think that the occasional oddball system setting or some straight-to-the-point diagnostic tool/script is fine, but requiring regular use for common applications is a bad idea. I personally use the terminal a lot, but a year before the Windows 10 EoL I really started getting a feel for how graphical applications are used in place of terminal applications and utilities, so that I have all of the relevant information for how to do common pain point tasks while using minimal to no terminal usage.

    In many cases, the stigma around Linux users needing to regularly use the terminal is mostly gone for many mainstream desktop-focused distros, and the only thing really holding that stigma for new users is every tutorial being written as generically as possible, rather than how to do a thing in different desktop environments. Many of the (more well-written) tutorials were written by people who want to quickly and efficiently solve the issue, even if that means using tools many users may not be comfortable with.

    Distro Hopping

    This is a short one, but I really dislike recommending something that I know that the user will likely want to jump away from in the future. Many distros have all since caught up in usability and ease-of-use to what used to be recommended as 'training-wheels' distros to the point where it seems that having to reinstall to a different distro and potentially learning a new desktop environment in a year or two might be doing more harm than good for the user who just wants to use their computer in the way they see fit. The only use case I could see is moreso recommending legacy distros for users on legacy hardware or distros with pre-installed and pre-configured proprietary drivers in the cases where it is too difficult to bootstrap the installation of said proprietary drivers after installing the core distro.

    Filesystem

    Finally, there is the lesser point of what default filesystem is used during installation. CoW filesystems like btrfs have become quite reliable, have very useful features (differential snapshots, subvolumes, checksumming). Particularly, my own setups for snapshots and checksumming have saved me from particularly bad file edits or from drive pre-failure (gradual failure). While I think ext4, xfs, and other filesystems are still perfectly fine choices currently, this is something that will weigh heavier toward filesystems like btrfs in time. Ext4 in particular isn't the most resilient to gradual drive failure, and I have in the past ended up with quietly corrupted files without much warning from the drive that ended up having a very short remaining life. If I weren't proactive in spotting and investigating the problem, I could have very well lost the full contents of that drive as SMART only start failing self-test very shortly before full drive failure. Meanwhile with my experience with pre-failure on BTRFS, a filesystem will happily go read-only if there a checksum failures in the filesystem, which can very easily point out that something has gone wrong and will either need maintenance or a drive swap. As more distros than just OpenSUSE actually implement some sort of competent snapshot feature as a default in installs, CoW filesystems will become more of a game-changer for regressions in updates, restoring mangled or deleted user files, etc.

    What I Currently Recommend

    I have a few choice picks for my current recommended distros that I personally recommend. For the primary use case of generic computing (light office usage, mostly web browsing, maybe a bit of photo editing) I will generally recommend an LTS distro, namely Debian or OpenSUSE Leap, with the KDE desktop. Both current versions of Debian and Leap include a version of Plasma 6 and have done a good job of being usable with minimal problems on such hardware.

    For more avid users (often what would be considered power users on Windows) or target hardware that is too new for a given LTS distro, distros like Fedora KDE Workstation and OpenSUSE Tumbleweed with KDE are my prime choices. Fedora can take a bit of extra setup and require a bit of terminal usage in said setup (Appstream data for RPMFusion, future kernel versions installing kernel-devel for out-of-tree modules, setting the nvidia-open flag for proprietary NVidia drivers). Overall, both work quite well. I tend to lean toward Fedora due to the 6-month point release with semi-rolling kernel and mid-cycle DE version refresh versus full-rolling of Tumbleweed. Tumbleweed does utilize btrfs snapshots with selection in the boot loader for easy rollback from any regressions in updates however, making the big downside of a rolling release less painful.

    Finally, for more gaming-focused use-cases, I have started recommending Bazzite recently. A Wayland-first immutable distro based on Fedora Kinoite with ready-made downloads for pre-installed proprietary drivers genuinely provides a painless experience for a gaming-focused environment. Installing any software that doesn't come packaged as a Flatpak can start to show the cracks in ease-of-install compared to a non-immutable distro. As such, the user's focus in primarily gaming and what can be done with applications with flatpak distribution is something that should be verified before recommending.

    What I Currently Recommend New Users Avoid

    • Manjaro (extensive track record for poor maintenance, cannot deliver what it aims to promise)
    • Ubuntu (poor 6 month point release QA, lower LTS release quality than its parent distro, Snap, Canonical's wasted efforts in canned projects)
    • Arch Linux (distro explicitly intended for tinkerers, explicitly expects reading release notes every update)
    • SteamOS (distro not intended for general usage, explicit hardware targets)
    • Pop! OS (one major incident of poor packaging, poor management of LTS release schedule, not Wayland-first (yet), no KDE default)
    • Linux Mint (not Wayland-first (yet), dropped KDE default)
    • Kali Linux, Parrot OS (pentest-focused niche distros even if there is a desktop installer variant)
    view more: next ›