So you’re considering the 22H2 builds et al. separate versions, I just consider them service packs. They come with the regular updates, and the user experience doesn’t significantly change. I couldn’t ever tell you what “build” of Windows 10 or 11 I was on, but I usually know pretty well which distro version I am on.

But I guess it’s true that they contain more feature updates than typical Linux updates.

I think you misunderstood. Windows 10 was released in 2015, and will have general support for all versions until October 2025. That’s 10 years.

The current version of Mint, 22.1, was released in January 2025, and will receive support until April 2029. That’s 4 years.

Had you installed the latest version of Mint in 2015, it would have been EOL in 2019. Had you installed Windows 10 in 2015, it would only be EOL later this year.

but when you explicitly state you are against it in the README of your project that is just wild

It’s called a dogwhistle: they’re letting other racist scumbags know that they are also racist scumbags and that their racist scumbag views are welcome, without saying anything overtly racist scumbag-y.

I use Arch myself (BTW :p), but I wouldn’t really recommend that for users who freshly migrated over from Windows.

Yes, there are ways to get extended support (on Windows too btw), but a thing that should also be kept in mind is that “support” only means security patches and bugfixes, and not feature upgrades. There is also no guaranteed continued hardware support, nor guaranteed support from third party applications. On Ubuntu there’s at least the HWE kernel, but that’s also limited in time.

It’s not criticism btw, it’s just worth mentioning that the support model on Linux looks a bit different than what you get with Windows, and users should generally be encouraged to keep up with the latest release of their chosen distribution.

True, but often the distributions have an upgrade plan (for free). In example you can install an Ubuntu LTS and upgrade 4 years later to the next major LTS release. However, sometimes this has problems, because so much time and changes are in between. This is for sure.

Yes you can and should upgrade, which is what I was trying to say really. It’s less set and forget as in “just let it update and it will keep on trucking for 10 years”.

There are distributions with longer support period. Debian comes to my mind. But I don’t know how long and there were 10 year supported distributions too.

I think only the enterprise distributions (RHEL etc) do 10 year support, but they are not very usable for a desktop system, and I can tell from experience you start to run into compatibility and support issues with software if you actually use it for that long.

Debian is ± 5 years by the way.

foot is such a lovely little program. It has everything I want for a terminal emulator: it launches instantly, it has zero lag, no fluff, excellent font rendering, excellent copy/paste handling, excellent compatibility, and it’s easily configurable and themable via a sensible, well documented config file.

TFW I realize I am a foot fetishist … 😮

If you install Linux Mint today, you’ll still be able to update it in october and beyond, for the foreseeable future

One caveat: Linux distributions, even LTS variants, usually have a shorter support period than Windows, after which you have to upgrade your distribution, which is much like doing a Windows upgrade.

A particular version of Linux Mint, the example you mentioned, is supported for 4 years, whereas Windows 10 was supported for 10 years.

Not really the same scenario. PCs that could run Windows 7 could usually upgrade to 10, people were just reluctant to do so, partly also because 8 and 8.1 were such disasters. Eventually, everyone just moved on.

Today, a lot of 10 users would upgrade to 11 if they could, but their older-but-still-fine hardware is simply being cut off from Windows support.

You can give me any file, and I can create a compression algorithm that reduces it to 1 bit. (*)

When you run out of characters, you simply create another 0 byte file to encode the rest.

Check mate, storage manufacturers.

I use Windows Terminal nowadays. It feels more clunky and slow than say, foot or kitty on Linux, but it’s functional.

Before, I used to use PuTTY for ssh sessions, it feels more fluid, but it needs a lot of configuring to get the terminal behavior just right, and the settings UI is really outdated. It also doesn’t support WSL (unless you run sshd on WSL and ssh into the system).

That reminds me … another annoying thing Google did was list my private jellyfin instance as a “deceptive site”, after it had uninvitedly crawled it.

A common issue it seems.

cgnat

Ew

What I used to do was: I put jellyfin behind an nginx reverse proxy, on a separate vhost (so on a unique domain). Then I added basic authentication (a htpasswd file) with an unguessable password on the whole domain. Then I added geoip firewall rules so that port 443 was only reachable from the country I was in. I live in small country, so this significantly limits exposure.

Downside of this approach: basic auth is annoying. The jellyfin client doesn’t like it … so I had to use a browser to stream.

Nowadays, I put all my services behind a wireguard VPN and I expose nothing else. Only issue I’ve had is when I was on vacation in a bnb and they used the same IP range as my home network :-|

This is how I found out Google harvests the URLs I visit through Chrome.

Got google bots trying to crawl deep links into a domain that I hadn’t published anywhere.

all you need is to get a static IP for your home network

Don’t even need a static IP. Dyndns is enough.

Ctrl + r to search previous commands

That’s a readline thing by the way, so it doesn’t just work in bash but also works with other cli applications that are compiled with readline support, for example virsh, psql, fdisk, …

For example, the octa-core Ryzen 7 9700X is much more efficient than the 7700X

This has been proven untrue by several reputable reviewers, like Gamers Nexus.

Most issues like these are recoverable manually, but Timeshift takes away most of the headache from the process.

You gain a lot more understanding from manually fixing entirely recoverable problems though. Something like Timeshift is more like a last resort sledgehammer tool.

I’ve always thought of dependencies as equivalent to dlls. Is that right?

Usually, but not always. Most of the times a dependency is a software library contained within a shared object file (a .so file), and that is indeed analogous to a dll.

A dependency can be other things as well though, like a specific program that a software package depends on being present. For example, the handbrake program to reencode videos will call ffmpeg under the hood. So naturally ffmpeg is a dependency.

Why is Linux so fiddley with dependencies?

I don’t think it is? I mean, software depending on external shared libraries isn’t exactly a Linux only concept, and if anything I think most Linux distros’ ways of handling dependencies are superior.

The main difference with Windows is that third party software tends to bring their own dlls for anything that’s not a standard part of Windows, which is wasteful because of duplication, and less secure because the included libraries may be out of date and contain known security holes.

On Linux, distributions usually have every library under the sun in their repositories, managed by the package manager and kept up to date by the maintainers. As long as you stick to software included with your distro, or software packages for your specific distro, dependencies should be resolved automatically by the package manager. For example: if you download the Google Chrome .deb file, and install it with apt-get, it will pull in all the dependencies it needs to run.

If you go outside of that, for example compiling software yourself, or downloading non-distro specific binaries, you will have to take care of dependencies yourself. Perhaps that’s what you mean with the fiddly bit.