jrgd

joined 1 year ago
[–] jrgd@lemmy.zip 4 points 4 days ago* (last edited 3 days ago) (1 children)

Adding to compatibility notes, it does seem that with the 2015 A1502's there won't be anything major in poor compatibility, beside the webcam not working out of the box. Found someone who documented their experience heavily tuning their Fedora install on their 2015 A1502. The author kitted out their Mac with a new SSD and better Wi-Fi card, which is worth mentioning. Some of the information is straight up helpful for even a standard A1502. Common stuff like installing the RPMFusion libva driver, EasyEffects equalizer presets, TLP are generally good ideas.

Mbpfan is also a good idea, but it looks like the package got dropped on 44 from a missing maintainer. May be recommended to install 43 for now if going with Fedora. I pulled the package source and built it on my computer, and it seems to work. Unfortunately I don't have an actual Macbook to test it on. ~~I'll see about getting a COPR repo for it available soon, so that the package can be easily tested.~~

I have a Copr repo available (jrgd/mbpfan) for unofficial packages on Fedora 44.

Some stuff, like disabling mitigations, throttled, and installing the FacetimeHD drivers are not stuff I'd really recommend. You can still go with any of these noting the caveats listed for each tweak. The FacetimeHD drivers are required for getting the webcam to work, so going through the hassle of getting those drivers to behave or just not having a built-in webcam is a choice to make.

[–] jrgd@lemmy.zip 5 points 4 days ago (3 children)

Probably your best bet for something similar in vein to MacOS would be any distro that ships with GNOME. Ubuntu, Fedora, Debian, OpenSUSE Tumbleweed all either ship explicitly with GNOME or have them as options within their live installers.

If you know which model and spec your Macbook is, I could give better compatibility insights. In short, the Broadcom chips used for Wi-Fi, Bluetooth in the 2014-2015 Macbooks used to be quite problematic for many Linux distros, but I do believe the in-tree bcm43xx driver in the kernel should handle them well enough nowadays. Depending on exact year and spec, your Macbook may come with an NVidia GPU, which will require additional post-installation steps to install the proprietary drivers on many distros. As it isn't the primary display device on those models, there shouldn't be too many issues in getting the cards to function and render offloading to work.

Ubuntu discourse

Ubuntu is not really spyware as people may claim it to be. The main spyware claim comes from two sources: the 14 year old once-integration for Amazon services that Ubuntu shipped around the 12.10 point release and that Ubuntu does utilize more telemetry than other distros.

Often though, it's not a recommended distro anymore for many reasons. One primary one is that Ubuntu used to be seen as user-friendly and had a lot of community forum posts to document how to use it. Nowadays, most major distros have caught up and surpassed Ubuntu in usability and reliability, and Ubuntu's once-positive of forum posts largely tend to clog up being able to find useful information when a problem does occur because of how out-of-date many of those forum posts that still show up in search results are.

Another big reason is Ubuntu is not recommended is Canonical's (the company the makes Ubuntu) makes regular missteps and often falls on the wrong side of development for progress of the Linux desktop. See Unity desktop, Mir, Upstart, and the current misstep of Snaps. Canonical has also additionally put less effort into keeping that once-polished experience the Ubuntu desktop had and moved a lot of their effort into their server offerings. There have been relatively recent Ubuntu LTS desktop releases that have shipped with some baffling and often showstopping bugs that should have been release blockers. It's to a point where the QC of releases is often worse than what is found on 6-month point release and even many rolling release distros to where many don't recommend Ubuntu anymore.

[–] jrgd@lemmy.zip 14 points 5 days ago

Based on OP's edit, that looks correct. Unless OP checks the topology and can make the claim that drives from the main chipset are the slow ones, secondary chipset drives will tend to perform slower, and the ASMedia ASM1061 has several reports online of poor to trash performance compared to baseline.

Best bet if the full performance is necessary out of every drive would be finding a decent quality PCI-E SATA III riser card that doesn't use a known flawed driver chip rather use the two 'extra' ports on the motherboard.

[–] jrgd@lemmy.zip 1 points 1 week ago* (last edited 6 days ago)

You can absolutely swap the primary boot entry in the BIOS by hand, but as mentioned, GRUB can be made to show an entry for Windows 10 upon normal boot. You can select that entry rather than swap the primary target in the BIOS, which will be a time saver when switching OS. Some configuration to get GRUB to pick it up will likely need to be done however.

For that to work, one needs to uncomment a line in /etc/default/grub (#GRUB_DISABLE_OS_PROBER=false becomes GRUB_DISABLE_OS_PROBER=false). If the line simply isn't present in /etc/default/grub, just add it at the bottom.

For GPT, EFI installationsOn modern (EFI, GPT) systems, there is specifically one partition you will need to persistently mount from the Windows drive through fstab, being the Windows EFI partition. It does not matter particularly where it is mounted, as long as it is out of the way (a mount point like /windows is fine). You'll have to create an empty directory preferably somewhere under / and owned by root, and then add the Windows EFI partition as a line to /etc/fstab. The command line utilities lsblk and blkid can help to determine the disk partition layout and the EFI partition's UUID. The 'Disks' utility installed by default in Mint can also do this, and may be easier.

Before touching your /etc/fstab file, make a copy of it. The resulting line added to /etc/fstab will look roughly like UUID=ABCD-1234 /windows vfat umask=0077,nofail 0 2, replacing the ABCD-1234 with the actual UUID and /windows with the actual desired mount point, if different. Running mount -a with sudo is highly recommended after touching the fstab file to verify that everything is correct. The command should complete with no errors. If it errors, revert your /etc/fstab to the copied version. Rebooting with a broken fstab file can leave your system unbootable.

Finally, for systems like Linux Mint, run update-grub with sudo to rebuild the bootloader entries. With os-prober enabled in /etc/default/gruband the Windows EFI partition mounted if relevant, update-grub should show a warning about os-prober being enabled and among other entries, an entry for Windows 10 should be present. As long as the Windows drive continues to be installed in the system, a boot entry should be available next to your Linux Mint and bios entry options in GRUB going forward.

[–] jrgd@lemmy.zip 8 points 1 week ago* (last edited 1 week ago) (7 children)

Generally, if they are fully on separate drives, things should be fine. When going to install Windows for the dual boot, physically unplug or uninstall the Linux drive. After Windows is installed and can boot, you can then reinstall the Linux drive.

On the Linux side, you may need to trigger a rebuild for GRUB or your preferred bootloader to get the appropriate Windows 10 entry to show in the boot menu. Some distros may need extra configuration to get this to work. Don't attempt to automount any partitions from the Windows 10 side and don't generally try to mount them unless necessary. The only exception to this is if using EFI partitions, then that partition will need to be mounted for GRUB to see it.

Also highly recommended to block Windows 10 from connecting to any network if possible, as it is end of life (unless using ESU releases).


EDIT: Somewhat incorrect information in regard to EFI partitions, missing GRUB configuration related to distro

[–] jrgd@lemmy.zip 3 points 3 weeks ago

Originally when I started the move to Linux in 2015, I did it because Windows 10 was wholly incompatible with my ISP. I lived through dial-up, HEO satellite, HSPA, LTE, fixed wireless, and currently fiber. During the period with dealing with HEO satellite, every provider at the time in the US (WildBlue/Exede/Viasat, Hughesnet) had alright speeds at best paired with a very aggressive soft monthly data cap (10 GB, eventually 26GB in like 2018), that would revert the speed capabilities back to 32-96kbps. Upgrading from Windows 7 to Windows 10 was largely a mistake for many reasons, but one of them was the sheer frequency, size, and aggressive nature of how Windows 10 tried to download and apply updates automatically. Windows 10's frequent auto updates would easily eat several gigabytes each month of the tiny data cap. The rest of the amount of idle networking Windows 10 did also didn't help during throttled periods, eating up most of the bandwidth available from just one workstation. Knowing that Windows 10 wouldn't be another Windows 8 and that Microsoft would go forward with 10, I decided to seriously look into alternatives.

Eleven years later, I have virtually no restrictions in hardware nor networking. Despite that, I still use Linux exclusively. Nowadays, there is little to no compromise in using a Linux-based system for many general tasks. Certain niches vary in usability on Linux, especially if the niche is cemented in certain proprietary software. Modern Linux-based systems (both distro and desktop environment) are just more polished than the experience to be had on Windows 10 or Windows 11. Many common frustrations when using Windows (device driver installation, printers, drawing tablets, HDR, system updates, software updates, system maintenance, lack of dark patterns, error message clarity, etc.) are things that a modern Linux system deals with a lot less, to a lesser extent, or just not at all. After spending many years learning both Windows and Linux, Linux systems are just more functional and easier to use.

[–] jrgd@lemmy.zip 25 points 1 month ago (1 children)

Using the AUR largely expects users to understand the basics of shell/BASH scripts, which is what a PKGBUILD is. The most obvious source to check is what URL(s) the PKGBUILD is pulling in for a package's source(s). Are these URLs sourced from official or otherwise trusted sources for the application or component (such as from the app author's download site or their git forge)? Does the PKGBUILD make any claims of what is being downloaded and does the target URL's contents match that? If either of these checks fail, it's best to avoid that package.

Additionally, does the PKGBUILD attempt to do things like obfuscate data such as URLs or tokens for downloading? Does it attempt to recklessly delete or modify files/directories (rm -rf, other recursive functions)? Does the PKGBUILD make use of any arbitrary execution statements such as exec or spawning subshells? If any of these check true, the package should seriously be revised before attempting to install it. System-level software installs on Linux systems should never be complicated enough to need fancy execution techniques nor reckless file management.

[–] jrgd@lemmy.zip 4 points 2 months ago* (last edited 2 months ago)

Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn't recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you're best to take the compose file and write it out to Quadlet unit(s).

Other differences not mentioned can include:

  • Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as localhost, 127.0.0.1, or ::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures.
  • Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you're not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
  • Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
  • Podman by default won't shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the docker.io/ prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor.
  • Podman can optionally let you auto-update containers based on the release tag specified for the container.
  • Because of Podman's integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).
[–] jrgd@lemmy.zip 16 points 2 months ago (4 children)

Might take a little bit of effort to do a conversion if you're locked into explicitly how Docker interacts with OCI containers, but over in the Podman camp you have two options.

  • Cockpit with the Podman containers interface: a graphical web-based solution for managing podman containers and the rest of the system.
  • Podman Quadlets: a config file-based way to manage Podman containers, volumes, pods, networks with custom SystemD units. Great if you want to version control your deployments.

Other than that, the more usable solutions I've tried of graphical Docker container management interfaces would be the ones in Unraid and Proxmox, though those solutions may not be suitable depending on your use case and have their own caveats to be aware of.

[–] jrgd@lemmy.zip 3 points 2 months ago

If Google kills AOSP, a lot more than just GrapheneOS will stop being able to exist lest some entity maintains a fork that diverges from Google's path. Vendors that aren't shipping in line with Play Services and the rest of the ecosystem as well as LineageOS and other custom ROM development teams will suffer as well.

This kind of decision would essentially kill adoption of Android in a good number of countries within a few years as well as be the end of Android adoption for anyone that cares about security and/or privacy. Yes, It would either kill or put a large burden upon GrapheneOS as a project, but that is also true for so many other projects in the ecosystem. If the developers shutter their AOSP usage due to upstream abandonment, the users will likely follow in the same pattern.

[–] jrgd@lemmy.zip 4 points 3 months ago* (last edited 3 months ago) (1 children)

It's probably not a case for everyone due to the obvious limitations, but I primarily use KeepassXC from my main workstation. I have backup scripts that periodically run for my user on said workstation that capture my Keepass database among other user files and backup to external storage, cloud storage as dictated.

For my laptops, mobile devices; I periodically push the database from either the main workstation or pull from a backup to these devices. I do not write new entries from these devices in order to avoid having to handle writeback to the main instance of my Keepass db. This can be done, but inherently starts to hinge on needing network access all the time to ensure an up-to-date copy of the DB is present as well as being explicitly a single-user db to prevent a syncing protocol from accidentally writing over new entries from any given device. Obviously, if network sync and the potential for multi-user is important to you, continue using Bitwarden. It is a perfectly fine solution.

[–] jrgd@lemmy.zip 17 points 3 months ago (5 children)

I'll list a few of my regularly-used tools, both CLI and GUI.

CLI:

  • ncdu: An interactive TUI variant of du, for tracing disk usage across targeted directories.
  • podman: An alternative runtime to Docker that is arguably just better at this point. Can handle rootless containers with ease, works with SELinux, can handle Docker compose files with add-on tool podman-compose, can automatically update containers intelligently, can integrate well with SystemD, and more.
  • mtr: Another network tool. Effectively traces network routes to a given IP. Great for diagnosing faults in latency or major packet loss.
  • ffmpeg: A very complicated, but powerful tool for converting, manipulating video and audio files in all sorts of ways. FFMpeg can essentially be the answer to any 'do X to Y file' question.

GUI:

  • Kdenlive: A powerful video editor developed by KDE. For free and open source, it is impressive how little you can't do when editing videos with this tool. A bit buggy at times, but has gotten significantly more reliable over years.
  • Handbrake: A FFMpeg frontend that allows for mass transcodes of video files based on created profiles. Great for archiving, finalizing videos down for web upload, or just converting content to a more efficient format. Specializes in lossy/destructive operations.
  • LosslessCut: A FFMpeg frontend that allows for trimming videos, stripping and/or exporting tracks from videos, editing mkv metadata, editing video chapters, and any other lossless/non-destructive operations that can be done on video files.
  • Subtitle Composer: An outright semi-professional-grade subtitle editor developed by KDE. Supports and can convert between pretty much any subtitle format you might encounter. Great for creating, editing, timing, and translating subtitles for videos.
  • KeepassXC: My password manager of choice. Has browser autofill integration, though requires some holepunch work to function with Flatpak browsers. Explicitly is based on local files. Does not rely on cloud providers.
  • Limo, R2Modman: Native mod-managers that allow for modding various Steam games (native and Proton) on Linux.
  • Blender: A powerful 3D editor. Capable of hard and soft 3D modeling, character rigging, animation, material creation and UV mapping, compositing and rendering. Pretty much an all-in-one tool for 3D art and design.
  • FreeCAD: A somewhat daunting, but functional 3D CAD software. Has received a lot of recent (~3 years) patches to improve on a lot of long-standing pain points in the software.
 

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 ›