I think the biggest one in recent (past year) would have been the upgrade tree to nvidia-open, which would break 10-series and older support without changing package on affected systems. Definitely a lot of the more recent breakages are not large-scale problems, but they do still exist.

As has been noted in the ArchWiki that is expected to be read by users, one should always check for package-related news before upgrading their Arch system. This is because package changes and breakages that require user intervention do occur, and ignoring them can sometimes leave a broken system. Arch isn’t really hard after getting over the bootstrap hurdle, but simply requires more upkeep effort than most point release distros would.

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.

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.

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.).

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.

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.

Coming back and checking the values file posted. Not sure why your authentik block won’t get used in your values file. Your current issue of non-starting is likely the Authentik server container starting successfully, but failing liveness while waiting for the worker container(s) that is definitely not spooling up with your current configuration.

Something to denote about Authentik itself that won’t be well-explained by the quickstart for the Helm chart itself is that Authentik is split into two containers: server and worker. For most environment variabless and mounted secrets, both the server and worker definitions should have them applied. The chart tends to handle most of the essential shared stuff in the authentik block to prevent the duplication, but secrets will likely need to be mounted for both volumes if using file or env references in the shared config, as well as most env overrides will need to be applied for both.

In my case I’m running an external Postgres DB and external cache plus a handful of other settings. As such, I have a decently sized values file. All of the env vars I was looking for in my case are provided in the chart, so I didn’t need to set any directly, but just through their counterparts in the values file.

I don’t use ArgoCD in my case, so I couldn’t really say if it would affect your deployment strategy in any way.

When I did my authentik setup through helm chart a while back, the only real problems I had were with learning blueprints and not so much with getting Authentik to do its thing.

The main things you should be checking given a liveliness probe failure is kubectl -n <namespace> describe pod <podname> to check the reason for failure. Additionally, kubectl logs -p -n <namespace> <podname> [container]. Will get you logs of the last run of the pod that has already failed, rather than the current run that may be soon to fail. Those two commands should point you pretty directly where your chart config has gone wrong. I can likely help as well if you are unsure what you are looking at.

Additionally, once you get things working, please go back and usw secrets properly with the chart. Authentik lets you sub many values for env vars or files, which combined with mounting secrets is how you can use them.

Iproute2 definitely does write things a bit compact. ip address show and shorthands state the routed local address space (192.168.1.x/24) and the actual /32 address (192.168.1.214) you are assigned as one unit. Additionally, it shows the broadcast address for the space. Ironically, ip route show may genuinely give you less confusing information, clearly splitting the actual route and showing your straight IPv4 address as src.

Typically in firewalling, you’d use /32 to target a singular IPv4 host. This is analogous to using /128 for IPv6 hosts. You can absolutely use /24, /16, /8, or any other mask really if you need to target a range of IP addresses for a rule to apply to. Technically, /32 is a range itself, just with a size of 1. There are CIDR calculators available to play around and see what different CIDR masks actually target.

The routing and firewalling is a bit different in terms of why certain CIDR masks are used. For the router, the /24 suffix is usually defined for itself on the LAN interface to denote the address space it may send route information to, and what addresses are controlled by the device. Almost certainly, (unless using a lower CIDR range and actually handing out /24 blocks to subsequent routers,) you are granting /32 IPv4 addresses to your devices from your router.

For your system firewall, 192.168.1.135/24 is identical to 192.168.1.0/24 as they are the same address space. You’re simply allowing from a subnet of hosts to accept from. Given the /24 mask is 255.255.255.0, it does not matter what the last number of the IPv4 address is, but the lowest possible number to match the mask is standard form. Without knowing what rule(s) specifically is being applied, I couldn’t tell you if your firewall rules are something that would affect hostname resolution of other hosts from your system or not.

In addition to the other reply on the fundamentals of why not in general, maybe we don’t recommend daily driving one of DHH’s pet projects.

If anyone is out of the loop of who DHH is, tons of people have covered the topic but I think Niccolò Venerandi has quite comprehensive and digestible coverage. If anyone cares to read or watch Nicco’s coverage.

1 + 2:

There’s not much involved in burning an ISO to a flash drive, booting from it, and installing typically. It is different in booting from one on a Mac. If you have an M-series Mac, you will be restricted mainly to anything with the experimental Asahi Linux kernel. If you have an Intel-based Mac, you should generally be good to go. Whenever booting a Linux installer, you’ll generally be able to check out the system before installing. It’s a good time to check things like backlight brightness and wireless capabilities are working out of the box on your distro of choice.

Accessing the boot menu on a Mac

3:

OpenSUSE Tumbleweed and Fedora are generally good picks. I recommend going for KDE unless you have a strong preference for how GNOME works. As good as the distros are, I generally recommend staying away from distros like Linux Mint (for now) as their implementation of the newer display system called Wayland is not yet complete for Cinnamon. Desktops like KDE and GNOME have functional implementations and will overall provide a solid experience.

4:

You’ll see mixed opinions all over the place with this. Personally, I do sit in the GrapheneOS camp at this point. If you don’t want to purchase a secondhand Google phone, I’d wait and see for the partnered device that GrapheneOS devs are in works with a currently undisclosed manufacturer on.

I’ll repeat the core points the GrapheneOS devs drone on about other Android OSP distributions, but without the hyperbole the devs constantly put in. Yes, e/OS does generally have security problems, some of which stem from the use of microG, and how microG just has to function on the device. It is a trade-off in security for some privacy gained. If you really don’t need anything of Google Play Services at all, you could always go for straight LineageOS without any Google services package installed at that point.

5:

By all means, older laptops can definitely still be functional for lighter or alternative tasks. Even if it’s not a good workstation anymore, could be fun to experiment with. Older phones (especially Android devices) really do have a set lifespan that I’d recommend to stop using them as daily drivers. When the manufacturers stop supporting them, they can be horrifically vulnerable devices as exploits are found over time. You might still get use out of it though without using its networking capabilities. It likely still has functional storage, screen, cameras, etc. If you’re lucky, you might be able to play around with straight Linux projects like PostmarketOS.

For new stuff, Linux-centric vendors can be nice (though a lot of them seem to just rebadge Clevo laptops with a decent markup) as a guarantee of good hardware support. Most business laptops make for good Linux laptops. I personally bought a Framework 13 a few years back and that’s my primary laptop. Though if you want to stay away from United States-based projects, your initial choices are probably a good fit. Additionally, you might lean more toward OpenSUSE than Fedora as well in the same principle.

My set of recommendations:

RPMFusion is recommended to add to your system. It’s the best way to use Steam, certain drivers (nvidia, v4l2loopback, etc.) as needed.

SELinux is present, but the default policy sets are unlikely to impede your usage. The SELinux applet (seapplet) is a useful tool for diagnosing on the very rare chance you’re finding permission denied somewhere that cannot otherwise be explained.

If you pull most of your software as flatpaks from Flathub already, your day-to-day experience won’t be much different from Debian.

Fedora’s equivalent to LTS releases would be the downstream LTS releases provided by Redhat, RockyLinux, AlmaLinux, and others. They don’t have the same package sets as base fedora, and may need extra repositories to get some of the less essential, but ‘core’ software back. Ultimately not much of a reason to run them on a desktop workstation for personal use.

Upgrading is pretty seamless. It’s as easy as graphical updates now or otherwise using the system upgrade module in dnf. I generally have the policy of waiting 2-4 weeks for any minor bugs that made it into a new release to settle. I have been expediting my upgrades for the past few releases in order to catch bugs before friends and family upgrade their machines and haven’t found any large problems regardless.

Fedora doesn’t inherently expect a system to upgrade forever without maintenance, with 5 years being a typical target for things that may break. With that said, it is good to read the release notes before upgrading to the next edition, as there can rarely be something (like the recent recommendation and changed default for a larger /boot partition) that may require maintenance on a long-term system before upgrading. That said, you do have time to hold off on upgrading the distro, as the general lifetime of each release is ~13 months, giving 1 month overlap into a release two releases ahead. For instance, Fedora 43 will still be maintained up to a month into Fedora 45’s release.

Video capabilities aren’t currently enabled on the main instance. According to commenters in the meta issue, it is (mostly?) implemented and if you are selfhosting a Stoat server instance, you can enable it for that instance.

It does depend on the connection type, but the general rule is not completely, barring some connection types like DSL. Given it sounds like you have Fiber, DOCSIS, or similar; you likely fall under the general rule. That said, you can absolutely tune and test above the typical 10-15% safety margin many guides start with without actually incurring any noticeable bufferbloat. The 10-15% is usually a good value for ISPs that fluctuate heavily in available babdwidth to the customer, but for more consistent connections (or for those that overrate high enough that the bandwidth fluctuations sit out of range for what the customer is actually paying for), you can absolutely get much closer to your rated connection speed, if not meeting or even passing it.

The general process is to tune one value at the time (starting with the bandwidth allocations for your pipes), apply the changes, noting the previous value, and performing a bufferbloat test with Waveform’s or others’ testing tools. Optionally, (this will drastically slow down the process, but can be worth it) one should actually hammer the network with actual load for a good few hours while testing some real-world applications that are sensitive to bufferbloat. Doing this between tweaked values will help expose how stable or unstable your ISP’s connection truly is over time.

Yeah, not having cake sqm is the one thing that will probably kill Opnsense as a choice for some people. That’s not to say you cannot get excellent results with fq_codel, because you absolutely can (I actively use both OpenWRT and OPNSense on different network applications personally). It is definitely more work to get good results though. OPNSense’s wireguard support has been excellent for a number of years now, and it’s exclusively what I use for tunneling in a VPC I rent.

If you’re particularly constricted on host hardware and need a lightweight router to manage multiple other VMs on said host, I could definitely see the benefits of running a minimal OpenWRT over OPNSense in that case.

I mean, the mini PCs don’t come with a managed switch, and often without good wireless connectivity that most home routers will come equipped with. So in total with Wi-Fi APs and a decent switch, definitely more than €100 in total.

Also unrelated, but if you’re running a x86 system with gigabytes of RAM, why not run Opnsense at that point?

Looking up the router, it was allegedly produced in 2024, according to the OpenWRT wiki. Barring any outliers, OpenWRT generally only sunsets hardware when a new version has higher hardware requirements than is provided by a device. The supported devices page lists out the hard requirements as well as recommendations. Currently 8 MiB flash storage is the minimum, with 16+ MiB recommended (for additional functions, user addons, etc.). 64 MiB is the minimum RAM target, with 128+ MiB recommended. According to the router’s wiki page, your chosen router exceeds both recommended requirements. Overall, the router should be suitable for a good while not barring any severe hardware or bootloader-level exploitable vulnerabilities are discovered with the device. There is no explicit date of when your router will no longer be supported, but you can check the history of the supported devices page to get the general trend of when OpenWRT bumps up the minimum requirements. For instance, it was just 4/8+ MiB flash storage and 32/64+ MiB RAM in early 2017.

Depending on what you want to do with the router, getting something with more RAM and a stronger CPU could be beneficial for various tasks (e.g. adblock-fast, cake sqm, etc.). Definitely do research on what you want your router to do though before choosing to go with higher specs or not.