I believe it's mostly drawing tablet support in Qt and in turn porting to Qt6 that's holding native Wayland builds back.

For the most part, you won't be able to escape Unix-like paradigms when using Unix-like systems. Notably, users have to exist in some form. You don't necessarily need to give them passwords for the frontend signage, but they need to exist. The shortlist of setting up cage would be:

• install your favorite server distro of choice
• Have a rootless, sudoless user available to use
• install cage and your app(s) of choice
• Add autologin for the user and edit the user's BASH profile to autolaunch cage
• Attend to any other backend setup (remote access, only allowing tty1 to exist, etc.)
• reboot

It's not quite a few clicks, but this can in contrast also be fully automated trivially if it's something you need to setup more than once.

Just note that with Bambu printers about past data collection practices and their in general mid to atrocious after-sales support. If this doesn't deter you, then go ahead and get one.

I do a lot of my functional parts in ABS, ASA though printing such material may be difficult on an open-air machine. The two obvious choices will generally be PLA or PETG. PLA is one of the most common printed materials, and is fairly balanced in material strength. PETG parts are more likely to permanently deform heavily before fully snapping, as well as they have a but more temperature resistance than PLA. Additionally most PETG plastics hold up decently well to UV, often making them more suitable for parts that need to be outdoors.

PLA takes not much consideration on surface to print, as most printers come with a smooth PEI build sheet by default. It will however need more cooling than printing with PETG at equivalent speeds. If you use a PEI sheet for PETG, make sure it is textured. You will destroy a smooth sheet if it doesn't have some kind of release coating to lower its adhesive properties to PETG.

There is no guarantee for spools of filament to actually arrive dry, so a filament dryer isn't a bad idea. I don't have any particular recommendations for a good filament dryer. I have a Filadryer S2 from Sunlu, but am not impressed by it.

For multi-monitor: use Wayland. For 2.5Gbps Ethernet NICs, they never work properly on any system in regard to performance, but I presume you are referencing the subpar Realtek NICs not connecting? Depending on the distro, you likely won't have the driver and/or firmware package preinstalled to make it work.

Depending on version and if modded with content mods, you can easily expect Minecraft to utilize a significant portion memory more than what you give for its heap. Java processes have a statically / dynamically (with bounds) allocated heap from system memory as well as memory used in the stack of the process. Additionally Minecraft might show using more memory in some process monitors due to any external shared libraries being utilized by the application.

My recommendation: don't allocate more memory to the game than you need to run it without noticeable stutters from garbage collection. If you are running modded Minecraft, one or more mods might be causing stack-related memory leaks (or just being large and complex enough to genuinely require large amounts of memory. We might be able to get a better picture if you shared your launch arguments, game version, total system memory, memory used by the game in the process monitor you are using (and modlist if applicable).

In general, it's also a good idea to setup and enable ZRAM and disable Swap if in use.

It doesn't currently allow for concurrent execution of EXE files, but that's a good idea. I'll see about implementing it.

Tbf to cloud sync, nothing is stopping you from using your own backup/restore service with your drm-free titles compared to the other features that Galaxy offers.

GOG has DRM for many titles: see Galaxy. As I understand it, it isn't as pervasive as Steam, but is necessary if you want multiplayer on many titles or care about extras like achievements.

Beyond the article being ancient at this point (in terms of AOSP and Android development lifetime), Stallman's argument boils down to the same talking points of Free Software purism.

To the first real point being transformed here: Android is not GNU/Linux because it does not contain much of the GNU Project's software. While it's correct to claim it's not GNU/Linux, how does it not make it Linux still? Is Alpine Linux not considered "Linux" because it doesn't contain GNU? Please elaborate on this point of Linux being Linux because it has GNU.

To the second point of including proprietary drivers, firmware, and appplications: we once again meet the questionable argument of transforming an OS to something else. Points are made that Android doesn't fit the GNU ideals due to its usage and inclusion of proprietary kernel modules, firmware, and userland applications. These are valid points to be made in that these additions muddy the aspect of Android (as packaged by Google and major smartphone manufacturers) being truly free software. However the same can be said about traditional "GNU/Linux distributions". Any device running on x86 (Intel, AMD) will be subject to needing proprietary firmware in order to function with that firmware having a higher control level than the kernel itself, just as Android would. There is also the note that while it is less necessary now to have a functioning desktop, a good portion of hardware (NVidia, Broadcom, Intel, etc.) require proprietary kernel modules and/or userland drivers in order to have full functionality that the average user may want. Finally, there is proprietary applications as well. Some Linux desktops include proprietary applications like Spotify, Steam, Google Chrome by default. Are we really to also exclude an overwhelming majority of the biggest Linux distros as Linux as well being that they include proprietary software or rely on proprietary code in some fashion? GNU itself lists very few distros as GNU-approved.

To note, AOSP does have a different userland environment than your standard Linux distro running X11 or Wayland. That is by far the best reason I could think of to classify Android as a different category of 'Linux' from say Debian, Fedora, OpenSUSE, Arch, Gentoo, Slackware, and others. However, AOSP is still capable of running with no proprietary userland software and can even be made to still run cli applications as well as run an X11 server that is capable of launching familiar desktop Linux applications. I really think that the arbitrary exclusion of Android from being Linux by virtue that RMS doesn't think it fits with GNU ideals is silly. If there are better arguments to be said for why Android (especially AOSP) shouldn't be seen as Linux with a different userland ecosystem rather than not Linux entirely, I'd love to see them. However, I remain unconvinced so far.

A few things Fedora centers itself around:

• Wayland-oriented Workstations
• SELinux support OOTB
• BTRFS as default filesystem
• General attitude toward using close to bleeding edge packages as defaults
• Package order of Fedora rpm repos, Fedora Flatpak -> RPMFusion, Flathub -> copr -> external installation
• Immutable variants of Fedora exist for the major desktops

Fedora generally prides itself on being a Wayland-focused and oriented workstation distro. There is still active support for desktop environments/window managers that run on Xorg, but you should consider moving toward a Wayland-supporting environment (Gnome, KDE, Sway, Hyprland).

SELinux (a Mandatory Access Control system) is enabled by default and has pretuned policies installed that should support most use cases out of the box. SEApplet is a useful utility to find active SELinux denials in case an application is getting permission denied issues for seemingly no reason.

If you intend to use BTRFS as your filesystem of choice and want to utilize it to its fullest (encrypted partitions, subvolume encryption, automatic snapshots), it is best to read up how BTRFS and subvolumes work before partitioning so that your subvolumes will be correct the first time. It can be tedious to edit subvolumes, move their contents, and remount portions of the filesystem after they have already been populated.

I'm sure you're used to how things on Arch with bleeding edge works, and understand that on Arch you should always read patch notes before updating. Generally, updates on Fedora are fine to just push through. It is worth generally reading what is new when performing system upgrades to a new version of Fedora, I have noticed occasionally in over five years of usage the first target release of a new version of Fedora can sometimes have breakages that tend to get fixed within the next couple of weeks. There is extensive testing for system upgrades that can be openly viewed, but the testing doesn't always catch everything before a new release.

By default, the best way to grab packages on Fedora is from the official repos or from the Fedora Flatpaks. Barring that or if you aren't satisfied by a default package for whatever reason (some stuff in default repos doesn't have ffmpeg support or others due to codec licensing issues), you can add the second-party RPMFusion repos or add Flathub to grab additional or alternative packages as well. If those avenues fail, you might be able to find someone maintaining the package you need or want to test on Copr, which is essentially like Ubuntu's Launchpad PPA platform. Barring all else, you could manually install a given application externally, though obviously this typically isn't the best solution in most cases. Some cases where you might want RPMFusion packages are for things like audacity-freeworld, which includes proper ffmpeg support for Audacity. This package comes from rpmfusion-free. Or you might want something like akmod-nvidia to install the proprietary NVidia drivers or steam to install Steam. These packages come from rpmfusion-nonfree. Also, if you are not familiar with Flatpak, it might be worth becoming familiar with how it works (Flatseal is an excellent application that lets you modify how certain Flatpaks are sandboxed).

Immutable variants of Fedora (Silverblue, Kinoite, Sway Atomic, Budgie Atomic) also exist and provide an immutable base image that won't typically get modified across boots. Most of the custom user installation of programs is intended to be installed via Flatpaks (Fedora or Flathub) or through using toolboxes to create sandboxed environments for certain workflows. If you absolutely need to rebase the system image with extra utilities, rpm-ostree is available to modify the system package selection, though this method is not recommended to just be used to install everything (needless rebasing of the immutable image defeats the point of using an immutable distro). Obviously these spins aren't for everyone, but are there for those who want to use them.

Could you elaborate on this? As someone who uses SystemD extensively on workstations and servers for spawning and managing both system-level and user-level services, I do find minimal issues overall with SystemD minus some certain functionalities such as socket spawning/respawning.

Of course some of default SystemD's housekeeping services do suck and I replace them with others. I would like to see the ability to just remove those services outright from my systems as separate packages since they do remain useless, but it isn't that big of an issue.

Not the same person, but I greatly enjoy my (now second) Pebble classic for several reasons, which I imagine some are shared between Starayo.

• Always-on Display
• Week-long battery life
• High contrast display that can be read easily in low light as well as in direct sunlight
• Simple notifications support, with quick canned replies
• physical button navigation that make the watch easy to use without needing to look at it
• Isn't obscenely large
• quick launch application shortcuts from holding side buttons
• simple media playback control that is responsive
• Doesn't attempt to be another smartphone, but rather as a local companion to your existing smartphone (doesn't thrive on individual apps, but rather companion apps to complement smartphone usage)
• Customizable and relatively simple to write applications and watchfaces for.

Unfortunately for me, fossil's watches do not match up. Looking at the gen 6, still uses an ill-suited AMOLED display that is bound to have poor contrast in direct sunlight unless the brightness is cranked so far that it will blow through the battery. Even then, the average battery life on the gen 6 is atrocious compared to most Pebble models as many reports say it can make it through one day. I'm sure by now, WearOS devices have worked out some of the kinks to make them easier and faster to use, though I am not sold on needing a personal assistant in order to do basic tasks (as Fossil markets their gen 6 smartwatch; I do doubt that this is necessary for general function).

Also, this might be controversial, but I personally feel that a device that has Bluetooth and is intended to communicate with a device that is often within ten feet of it really doesn't need to waste resources and probably become more of a privacy nightmare by including Wi-Fi, LTE, and other data communication methods (beside NFC). Furthermore, pretty much every WearOS device I have seen has had a struggle to keep battery life for more than a couple days, and everyone deems that devices that can should be praised for whatever reason. Seeing as my ancient smartwatch that does most of what these newer watches do yet can effortlessly hold a six day battery life at worst, I seriously question why newer watches that have so much compromise and are incredibly misguided as to what a complementary wearable should be are what are being developed. Not to mention that the Pebble classic on launch was $99 USD whereas one can easily find $400+ smartwatches that still have way too much compromise in comparison.