It was proposed and implemented in 43 as it was noticeably becoming a problem around that point in time. Upstream Fedora does limit to three configs plus rescue in GRUB by default. Does (or at least did) Nobara stray away from this?

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.

Based on the information given in logs + the rest of the thread thus far, I'd assume the problem either lies in a kernel bug or the laptops' firmware, BIOS. The logs claim the system successfully going into S3 (deep) sleep. It's possible for the affected laptops to have broken S3 suspend behavior.

A few things that might be worth checking include seeing if other sleep modes (s2idle) are available and testing them, checking for BIOS updates, and checking for Linux/generic suspend options within the BIOS.

The main idea on a device running something like Graphene OS is that you are already in a state of using minimal, if not at all using Google Cloud services, including data backups. It's intended in tandem with modifications like GMS, GPS (if optionally installed into a given user, work profile) running as an unprivileged, permission-based application. If someone is taking their data privacy and security seriously enough to consider using a duress PIN and flashed their phone with something along the lines of Graphene OS, would they be likely to have heavy reliance to Google's Cloud offerings?

You're likely looking for this docs section for Caddy. The failure is the automated request to populate Caddy's root CA cert to the host system, but obviously failed as it doesn't have root permissions. As the docs state, if you intend to use the local HTTPS functionality of Caddy, you can manually run caddy trust privileged in order to populate the Caddy root CA cert manually. If you intend to disable the local HTTPS functionality (such as if you're running Caddy behind a http reverse proxy), you can ignore the mail message.

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.

To note, even if the claim of 'more cheaters than Linux players' at the end of lifecycle is true, it is a blatant lie by omission. I played Rust from 2016 til shortly after the game went out of Early Access. I stopped playing because Facepunch had completely ruined the Linux builds of the game by removing the long-standing OpenGL output and forcing the new (at the time to Unity) and completely untested Vulkan output as the only option on Linux. For anyone unfortunate enough to experience playing Rust at the end of its Linux run, the game would regularly have major graphical glitches and various rendering errors, including graphical artifacting that would be seizure inducing. If you are prone to epilepsy or otherwise sensitive to bright or flashing lights, please do not click this link. To note, the attached video is a mild case of what commonly happened when playing. That is, if the crashes and many hardware just no longer being able to launch the game properly didn't impede that.

Given all of that, I genuinely wouldn't be surprised if the only "people" running the Linux client were actually cheat bots because there is no way many people were actually still playing the absolute rugpull of a game toward the end of its life.

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.

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.

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.

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.

Referencing my comment in the other thread, Facepunch employees keep being disingenuous about this claim. Even if it is true, due to how unplayable Facepunch made the Linux build a short while before they axed it for "a rampant cheating problem", this claim does not have enough evidence. The linked comment goes into some more detail, but it is insane how much the developers keep doubling down on their disinformation.

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.

Revolt rebranded as Stoat and does have voice chat with discord-style hotseat channels available in beta. I still wouldn't recommend it yet due to client bugs, but it's getting there.

Realistically, any LTS distro from a netinstaller or minimal image that can use a kiosk compositor like cage. So, the usual suspects of Debian, OpenSUSE, AlmaLinux, RockyLinux (or a derivative of one if the native distro doesn't support Raspberry Pi). Then you just have cage open the browser of choice on startup (e.g. chromium --kiosk <url>) and you have a lightweight and relatively secure web kiosk.

If you take a look at it from the lens of distro maintainers, this would be an absolute nightmare. Distros package library versions, and currently tightly control the release of applications to given library versions. Allowing just any range of library versions for applications would loosen said requirement, but would require distros to then build and maintain a ton of versions of each library.

Flathub currently curbs this problem to a large extent by bundling explicit point release packages of common libraries, and expects the application to bundle uncommon ones themselves. This does mean that one cannot simply package an application without some thought put into the library versions used for release on Flathub still.

For distros, this style of packaging could somewhat be copied, but to little benefit. It would either be wasting time replicating congruence with an existing standard like Flathub's library bundles or do their own thing and further complicate things for developers wanting to get their app published to a distro's repos.

Overall, flatpaks make the process look a bit more seamless than things really are for developers and package maintainers. Flatpaks really only work as well as they do because everyone mostly agrees on adhering to the library packages published by Flathub. I don't really think adding even the sliding scale of library 'sets' for various distros would any benefit beyond what is currently done.

There does appear to be some level of curve within your bed mesh, but the skew of the bed definitely shows that the bed is not level across the X axis. If you have manual bed leveling, work on the adjustment across the X axis before taking new mesh samples. Mesh compensation will definitely do a decent job compensating for a skew even as large as four layers worth, but the dimensional accuracy of the bottom of your parts will take a good hit printing like that.

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

To be fair, D-Bus is a protocol. Proper documentation and standards is half of implementation. Without any well-defined standards, a protocol is essentially useless and/or lawless. While not every case of non-compliance is the fault of D-Bus, the general lax nature of how endpoints are intended to be defined as well as the incompleteness for the actual standards applications should adhere to is a significant factor for why many applications are the way they are. In addition to the severe security flaws in D-Bus, this could be written with extensions to the protocol, becoming a new standard. Though if the problems are as deeply rooted as they are, it's not entirely out of the question to create another standard that isn't D-Bus.

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.