If you need new drivers then Debian is not the easiest distro. I love Debian but I do occasionally consider distro-hopping again to get some complex things working (like ROCm).

I do think Debian is an excellent starting place, though. If it suits you, great! If not, you’ll have a better idea of what you need to look for going forward. Hopping distros isn’t the end of the world, after all.

If you want cutting edge, don’t use Mint. But that’s not their focus at all. Mint is for people who just want their computer to work with minimal hassle.

These don’t seem like competing needs. When I think “just work with minimal hassle”, I don’t think “I need to restrict myself to outdated hardware”.

I’m perfectly happy running old packages in general. I’m still on Plasma 5, and it works just as well as it did last year. But that’s a matter of features, not compatibility. Old is fine; broken is not.

Depends on the specifics. My high-end MacBook Pro uses active cooling, but in practice it almost never comes on. It’s wayyyyy more efficient than the previous Intel gen.

A week or two ago, I accidentally left a Python process running using 100% of a single core. I didn’t even notice for several hours, until it ate up all my RAM. On on Intel laptop the fan would’ve let me know in like two minutes.

I don’t think Qualcomm’s actually caught up to Apple yet, but it’s getting close. It’s good to see more competition.

BTRFS also supports deduplication, but not automatically. duperemove will do it and you can set it up on a cron task if you want.

That would be a somewhat valid argument if Snaps “just worked” any better than Flatpaks. That has not been my experience.

Given the choice between an open standard and a proprietary one, the proprietary one damn well better have meaningful technological advantages. I don’t see that with Snaps. All I see is a company pouring effort into a system whose only value is that they are pouring effort into it. They should put that effort into something better.

Granted, it’s been a few years since I used Ubuntu and Snaps. Perhaps things have improved. It was nothing but headaches for me. A curse upon whoever decided to package apps that obviously require full file system access as Snaps. “User-friendly”, indeed.

From an enterprise/server perspective, when what you’re really paying for is first-party support, I guess Snaps make more sense. But again, that effort could be put toward something more useful.

What’s this? A software app store?

It’s ironic how on Linux, my distro’s app repository is always my first stop when looking for software, while on Mac or Windows it’s my last resort.

Commercialized app stores are full of spam, and Microsoft and Apple both decided that app store apps should not have the full capabilities of normal apps. It’s the exact opposite on Linux.

Thanks for the recommendation! I was looking at the Fedora family since AMD officially supports RHEL 9. Hadn’t gotten as far as to figure out how well that transfers to Fedora and its derivatives. Good to hear that it works.

If you’re only testing on one set of hardware, it isn’t going to tell the whole story. The results might be very different on an AMD vs Nvidia GPU, or even on a brand-new vs 1-3 generation old GPU.

Probably the most important thing for gaming is driver support and ease of installation. This sometimes runs directly counter to other general-purpose needs.

I’m still on the hunt for a distro where everything I need is easy to install. I don’t think any exist, primarily because GPU drivers suuuuuuuck, especially when you need CUDA or ROCm to work.

This is the great thing about open source. It benefits everyone. Any good idea that does not have significant drawbacks should get broad adoption. And that’s generally how it plays out.

Reputations live on for many years (decades, even) after they are justified.

Emulation.

Definitely going to incur a performance hit relative to native code, but in principle it could be perfectly good. It’s not like the GPU is running x86 code in the first place. On macOS, Apple provides Rosetta to run x86 Mac apps, and it’s very, very good. Not sure how FEX compares.

Correct.

Batteries will still lose charge very slowly, so at some point the battery controller will top itself back up. This is nothing to worry about, and I’m not sure macOS (or Linux) will every display the true charge level of a battery. I believe there is some wiggle room built in at the firmware level.

When MacBooks are plugged in, they get their power from the charger. They are not simultaneously draining and charging the battery in general, unless they need more power than the charger can provide (unlikely unless you are using a charger with lower wattage than the official charger that came with your laptop).

I was not able to find an official source on this from a quick search, but if I remember correctly, this should be true for any moderately recent MacBook. Maybe any MacBook at all, since they only started making “MacBooks” in 2006 and then tech hasn’t changed much since then.

Personally, I leave my MBP plugged in during use whenever possible, and I typically unplug it at the end of the day. You don’t need to unplug it, but hey, it’s a good idea to unplug anything that doesn’t need to be plugged in, just to save power.

OP must have it set to the lowest compression level. All levels are lossless, but higher compression levels are smaller, at the expense of increased encoding time. Should be half the size or less in general.

This is my plan A. I’ll only go to plan B if something goes wrong — which has happened to me a couple times. I tried to upgrade Ubuntu (LTS, I forget which version) years ago, but it failed hard. I still don’t know why. It wasn’t something I could figure out in half an hour, and it wasn’t worth investing more time than that.

Come to think of it, it’s possible all my upgrade woes came down to Nvidia drivers. It was a common problem on Suse (TW), to the point where I pinned my kernel version to avoid the frequent headaches. I’ll try a rolling distro again when I switch to AMD, maybe.

Obligatory xkcd: https://xkcd.com/243/

There will be more diversity in software and distros

I wish, but I doubt it. If we get to the point where there is a mass migration from Windows to Linux, it will almost certainly be concentrated into one or maybe two big distros. Probably Ubuntu.

Today, most proprietary software vendors only support Ubuntu and RHEL. Look at AMD. The ROCm installer supports Ubuntu 22.04, RHEL 9, and SLES. That’s it. Not even modern versions of Ubuntu. And it’s extremely ornery about dependencies. Python 3.8 or 3.10 required! No 3.9! No 3.11! Trying to get it to install on any modern Debian-based distro is the ninth circle of Dependency Hell.

Gotcha. Typically lowercase b=bit and uppercase B=Byte, but it’s hard to tell what people mean sometimes, especially in casual posts.

Come to think of it, I messed up the capitalization too. Should be a capital M for mega.

1mbps is awfully low for 1080. Or did you mean megabyte rather than megabit?

Even if they were trustworthy, nothing lasts forever.

Does anyone seriously think Google Play Movies or whatever they call it is going to be around in 50 years? Audible? Spotify?

Unlikely.

I grew up with access to books that were printed before my parents were even born. I doubt your grandkids will be able to say the same. Not if you buy into DRM-infected ecosystems and vendor lock-in, anyway.

The only consolation is that pirates are always one step ahead. But I wouldn’t want to count on that remaining true in 50 years either.

I remember a lot of KDE hate up until Gnome 3, which was controversial, to say the least. It mirrored old-school Mac hate, with a lot of invalid arguments parroted by people who never took time to learn it (or more to the point, to unlearn what they came from).

I’ve swapped between Gnome and KDE a bunch of times, and it hasn’t really made a difference to me in many years. There was a time when running apps built for one on the other was a painful experience either way. Nowadays my DE choice doesn’t really influence my application choices.