fossisfun

Actually it is the same story with TLS 1.3 and TLS 1.2. A bunch of sites still doesn't support TLS 1.3 (e. g. arstechnica.com, startpage.com) and some of them only support TLS 1.2 with RSA (e. g. startpage.com).

You can try this yourself in Firefox by disabling ciphers (search for security.ssl3 in about:config) or by setting the minimum TLS version to 1.3 (security.tls.version.min = 4 in about:config).

They aren't as natural. E. g. you have to swipe the same direction to open or close the window overview, whereas with GNOME the animation actually follows the direction your fingers are swiping. But they at least reliably trigger the action you want to execute.

Since Plasma doesn't have dynamic workspaces, I use it completely differently than GNOME anyways. E. g. I don't make use of workspaces and use minimise instead. Therefore touchpad gestures on Plasma are much less relevant to me than on GNOME at the moment.

In my opinion Plasma has gotten much better with the last couple of releases. Around 5.21 the defaults actually got pretty good and since 5.24 Wayland support is quite good, on par with GNOME in my opinion.

After using GNOME Shell for a decade I have recently switched to Plasma 5.27 on my desktop due to its VRR support (I have two 170 Hz QHD monitors). A couple of weeks later I also moved my laptops to Plasma, even though I wanted to keep GNOME on them, since Plasma has gotten so nice!

Just wanted to give a heads-up in case you haven't tried Plasma in the last couple of years. ;) But especially if you rely on dynamic workspaces and don't want to adapt your workflow (like I did when I switched to Plasma), there's just no alternative to GNOME and it has gotten really polished and nice as well.

Linux Mint nowadays supports release upgrades, but you have to follow their blog to know when a new major Mint release is out and you have to manually install mintupgrade and do the upgrade.

So it is definitely not caused by technical constraints, as Mint has implemented the difficult part (providing and testing an upgrade path) already. Notifying the user about a new release upgrade shouldn't be too difficult? E. g. in the most simple form you could probably preinstall a package that does nothing at first, but receives an update once the next Mint release is out to send a notification to the user to inform about a new Mint release.

When it comes to elementary OS, I think they could support in-place upgrades, as they properly use metapackages (unlike Mint, which marks most packages as manually installed and doesn't really utilise automatically installed packages and metapackages in a way that you would expect on a Ubuntu-based distro), but they probably don't want to allocate / don't have the resources to test an official upgrade path.

But again, I don't understand why it is so difficult for elementary OS to at least provide a simple notification to the user that a new version is out. Even if the users have to reinstall, it is critical to inform them that their OS is about to become end of life. You know, people do things like online banking on their computers ...

It's the first thing I check with every distribution and if it doesn't have an EOL / upgrade notification, it is immediately out.

It misses one important choice: "I want to get notified of new releases of the operating system and want to have a graphical upgrade path."

Otherwise people just run their no longer supported OS until something stops working (I've seen this countless times ...), as very few people follow blog posts or social media feeds of their operating system.

This rules out lots of supposedly "beginner friendly" distributions, such as elementary OS or Linux Mint, as they don't notify users about the availability of a new distribution release. Elementary OS doesn't even offer in-place upgrades and requires a reinstallation.

Your're right, ideally wear reduction should probably be done by the display itself. But considering how little manufacuters often care about OS-agnostic approaches, it might be necessary to have software workarounds?

Variable refresh rate (VRR), HDR, OLED (e. g. I'd like the panel to become grey and move items around a bit to lessen burn-in) all involve GNOME for hardware support.

Outside of that the toolkit's file picker is used, as the system doesn't seem to provide one (via the portal), so the only reasonable fallback is to show the file picker that you know is there, which is the one of the application's toolkit.

but you are writing documentation for scripts?

No, I document my installations with scripts, so that I am able to install multiple computers the same way.

how would that impact your configuration?

It impacts my documentation. If, for example, gsettings set org.gnome.software allow-update false no longer works, because they changed the key from allow-update to updates-allowed, then my documentation no longer works correctly. Same when new technology is introduced, e. g. a switch from Pulseaudio to Pipewire. With a rolling release distribution these changes can happen at any time, whereas with a fixed release these changes only occur when a new release of the distribution is made and I upgrade to it.

I don't have the time to continously track these changes and modify my documentation accordingly. Therefore I appreciate it if people bundle all those changes for me into one single distribution upgrade and write release notes with a changelog. Then I can spend a day reading the release notes, adjust the documentation, apply the upgrade on all devices and then move on for the next couple of months/years.

which as nothing to do with rolling release or distributions.

I tried to explain to you why I dislike rolling release distributions. That's why I tried to give you one example where a fixed release distribution is more suitable in my opinion.

I understand that these things might not matter to you, if you only have one computer (or so) to maintain at home or maintaining home computers is your hobby. But I have four personal computers and multiple devices from the family to maintain and system administration is no longer my hobby ...

I've used Arch Linux and openSUSE Tumbleweed in the past and I have been using Linux for over 10 years ...

With each new version of an application there's the change that configuration files or functionality changes. Packages might even get replaced with others.

You would be surprised how much changes between Ubuntu LTS versions ... My archived Ubuntu installation script had lots of if-statements for different versions of Ubuntu, since stuff got moved around. Such things can be as simple as gsettings schemas (keys might get renamed), but even these minor changes make documentation and therefore reproducable reinstallations troublesome.

With a fixed release all these changes are nicely bundled in one large upgrade every couple of months/years, which makes it easy to document and to plan when to do the upgrade.

I can't stand rolling releases (for personal use) and I never recommend them to anyone. To me it feels like being in drift sand.

I need fixed releases to test my documentation (shell scripts) against something. With a rolling release those scripts can break at any time, unless you read the changelog of every package update.

But I also want and use fully automatic updates, so reading changelogs for every update would be the direct opposite of what I am looking for in an OS. I am ok with reading release notes every couple of months for a distribution upgrade though.

I want my systems to be reproducible and that's impossible with ~~drift sand~~ rolling releases. In my opinion Fedora or Ubuntu have a decent release cycle, I would never consider Arch or Tumbleweed or Solus.