Ah yes, did mess up looking at the specs table for bitrate modes. Correcting root comment for anyone else who views this thread.

You will need either an Intel discrete GPU or NVidia GPU if you want to use HDMI 2.1 to render at 8k@60. The Intel discrete GPUs have physical hardware that convert to HDMI and Nvidia uses proprietary drivers. If you can use displayport, any GPU (AMD, Intel, Nvidia) supporting displayport 1.4 is suitable for up to 8k@31 (limited to 8bpc). A displayport 2.0-capable card with a cable suitable for UHBR 13.5 should be able to handle 60 hz (8bpc) or a UHBR 20-rated cable capable of 60 hz at 10bpc.

It depends a bit on perspective and use-case, really. A flatpak’d application can be a fully-featured (all dependencies bundled) package in order to be portable. However, most flatpaks you might commonly encounter don’t quite do this. A good portion of the libraries may be distributed in common runtime packages. This will be the case if you use flatpaks from Flathub or Fedora. There still can be bundled libraries with vulnerabilities, but in many cases, there are basic dependencies from external, common library sets.

As far as varying dependency versions, a developer may be on a host with either newer or older dependencies than expected by the user, but as long as the developer’s application (and any unique libraries) are compiled against a common runtime as previously mentioned, it does make distribution to a wide variety of distros (LTS, 6-month, and rolling alike) relatively easy.

In comparison to OCI images (the kind of images that make up Docker, Podman, and a good portion of Kubernetes container images), flatpaks are a bit less extreme. Flatpaks contain much the same kind of files and structure that a standard distro package would, but simply get sandboxed into their own environment (via bubblewrap). Additionally, flatpaks don’t necessarily need system-level access for installation and usage (full userland confinement). It heavily depends on host environment and configuration, but typically OCI containers are a full, minimal, immutable filesystem structure run in a virtual environment. Not quite a virtual machine, as (in Linux anyway) they are run on the host (almost always in a sandbox) without extensive virtualization capabilities being needed. The general difference in security capabilities depends on the differences in sandboxing between a flatpak behind bubblewrap and an OCI container’s runtime sandboxing. There is also the notion with OCI containers being able to run as virtualized users, including root. With OCI containers that can obtain root access and a flaw in the sandboxing of say Docker in its standard rootful mode could allow for root level processes in the sandbox to act upon the host.

From what I can think of in comparison, there is the big problem with Flatpak in that it really isn’t suitable for packaging command-line applications: only GUI applications and libraries. OCI container images are often tailored for running web apps and other persistent CLI applications

As far as KDE vs. GNOME is concerned: KDE contains a lot of customizable features as an expectation and thus has great support for a wide array of customization. Both KDE and GNOME are extensible, with third-party extensions to extend or change functionality available. What makes GNOME less customizable, albeit supporting stylesheets and extensions, both are not expected to be used in any form (outside of defaults provided via Adwaita), and neither do many independent apps written in GTK3, GTK4. GNOME offers fairly minimal customization options without resorting to GNOME Tweaks, third-party extensions, and unsupported customized themes: all things that can break GNOME as while the customization does exist, the developers don’t embrace it and have no expectation to not break it with any update.

KDE has had ICC support implemented for a while now in Wayland. The necessary protocol for ICC support/color management in Wayland recently got merged, so the next release of many popular compositors (plasma 6.3 for KDE) will be protocol-compliant.

Without getting into more outright malicious possibilities as I don’t use Windows and cannot inspect how the application behaves on the platform, you could have things as simple like:

• EA didn’t see Linux users as profitable enough to support long-term
• EA/Respawn wanted an attempt to garner good will from the community by dropping support for a minority platform

It’s funny how EA is attributing their statistic to something can be strongly disproven. When looking at the given statistic they provided, they don’t specify the raw count of cheaters banned, but simply the rate. Even giving the generous assumption that EA’s statistics aren’t significantly flawed, they show an alleged large drop in cheaters bottoming out in the week of Nov. 4, 2024, before starting to rise up again. Does something else coincide with the rate of cheaters dropping in the week of Nov. 4? There is in fact something that does. Season 23 was released the fifth with a large spike of players being brought into the game. Without a more comprehensive statistic graph over several months, it looks like EA is trying to just capitalize on the fact that a large influx of players joining the game will drop the rates of cheaters momentarily, and then passing it off as evidence that Linux cheating was rampant. Quite disingenuous.

I’m not really sure I can support using DNT headers currently. Some good points were made about alongside GPC, DNT being legally recognized for GDPR requests in some countries. I live in the US outside of California, and don’t closely follow along to the nuances of either CCPA or GDPR, so correct me if I get something wrong. Given the list of websites in a comment that respect DNT, the notion that DNT is voluntary to handle, and how many websites use to harm users instead (further fingerprinting data points), I don’t see why Mozilla should be keeping around DNT for the time being.

Yes, the fingerprinting metric for DNT may not be that unique of a data point if a given user isn’t using content blocking extensions and other browser-hardening techniques. It still is however a data point often masked to follow the herd in order to minimize fingerprinting in territories where user privacy isn’t enforced by law. If law actually demanded respect to user privacy, I think DNT could work. As it stands though, it really doesn’t seem like DNT is well-ingrained in law.

Given the list of sites you listed, I only recognize two websites on the list that claim to support DNT. Perhaps a majority of these sites are from smaller organizations and/or based in the EU? On top, this is only what the sites’ privacy policies claim, no? How many of these sites are actively proven to respect DNT beyond claiming that they do?

It really seems like DNT is still considered way too optional for websites to handle and respect. The best way for this to change is for the GDPR to recognize proper DNT handling as mandatory for sites to be compliant in the EU. Furthermore (unlikely to happen anytime soon but would be helpful) is for the US to gain similar privacy laws at the country-level that also defines enforcement.

There is just about zero reason I think nicely asking website admins to monitor and add support for DNT. Given that a majority of the problem with violations isn’t with the smallest of independent websites, but those run by larger businesses, I doubt simple activism will work. If just activism for respecting the privacy of users actually did something, I feel like in ~15 years Do Not Track headers would have shown meaningful progress. The only way going forward is deliberate user-enforced destruction of available tracking points granted to websites or law that dictates when and how websites may track users: be it GPC, DNT, or something else. Only when a consensus is being reached should Mozilla and browsers prepare to support the enforced feature.

EDIT: re-reading the list of websites claiming support for DNT, I found a second website I recognize.

Certainly a failure but at least it wouldn’t actually be as harmful as it reads, given / is a directory and the assumption you’re not root.

A majority of the Linux-native titles I have played work well. It’s only a handful of titles that have blatant neglect or malice from the developers, publishers that don’t work fully. Dying Light looks to fall under neglect as it doesn’t seem to have been updated (except for the inclusion of DLCs) beyond the 2015 build of the game, and seems to be stuck in a console-ready graphics preset.

I started playing Dying Light for the first time recently. Compared to the Windows version, it looks like Techland completely abandoned the Linux native version of the game. Is this update fixing the Linux native version to be on par with Windows?

You’re not referring to this satire article by chance?

What makes Nextcloud unreliable for your use case? I’ve used the calendar (caldav) functionality for years without issue in sync.

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.

The heated bed is coupled to a thermistor. I’d argue controlling the temperature in order to not accidentally overheat parts of the phone is a step above a hair dryer.

The worst gotchas and limitations I have seen building my own self-host stack with ipv6 in mind has been individual support by bespoke projects more so system infrastructure. As soon as you get into containerized environments, things can get difficult. Podman has been a pain point with networking and ipv6, though newer versions have become more manageable. The most problems I have seen is dealing with various OCI containers and their subpar implementations of ipv6 support.

You’d think with how long ipv6 has been around, we’d see better adoption from container maintainers, but I suppose the existence of ipv6 in a world originally built on ipv4 is a similar issue of adoption likewise to Linux and Windows as a workstation. Ultimately, if self-rolling everything in your network stack down to the servers, ipv6 is easy to integrate. The more one offloads in the setup to preconfigured and/or specialized tools, the more I have seen ipv6 support fall to the wayside, at least in terms of software.

Not to mention hardware support and networking capabilities provided by an ISP. My current residential ISP only provides ipv4 behind cgnat to the consumer. To even test my services on ipv6, I need to run a VPN connection tunneling ipv6 traffic to an endpoint beyond my ISP.

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.

Before going any further to adjust your Z offset and other factors to tune for better bed adhesion, you should probably adjust your bed to actually be level as well as ensure (seeing that you only have one z lead screw?) that the X axis frame isn’t sagging on the side not containing your Z lead screw. Once you’ve got those factors sorted out, you should check your probe repeatability and then set your Z offset accordingly.

Bed adhesion even with proper, clean first layers can be a pain depending on the bed surface, material being printed, how clean the bed is of oils and other contaminants, how hot the material is being extruded, and how hot the bed is among other factors. While using a bed mesh will greatly help to account for off-zero unevenness in your bed surface, you really shouldn’t use it to compensate for uneven bed leveling (especially when it looks like you are nearing more than 0.5 mm in unevenness).

To diagnose other print issues, it will be helpful to see a picture showcasing the problems described in a failed print.

As a side note, it is somewhat difficult to read your Klipper config file without using view source as it is being markdown formatted. You can negate it by using three graves on the lines above and below it so that it is wrapped in a ‘code block’ and isn’t formatted.

```
Some code
  eeeee
  fffff
```

Turns into

Some code
  eeeee
  fffff

As the original issues over on MySQL forums suggested, using DBeaver or other similar software rather than SQL Workbench is the best option. You unfortunately seem to be locked into using a keychain solution if you want to use SQL Workbench.