Pixels have better security features than Samsung and doesn't prevent you from using third party OSes.

More details here: https://grapheneos.org/faq#recommended-devices

That was a combination of the Steam client being a piece of trash (incredible complexity and technical debt*) and COSMIC. COSMIC is quite buggy when it comes to Xwayland. I've had plenty of issues where I close a Xwayland window, but a ghost of the window remains.

• the Steam Client runs on a combination of Ubuntu 12.04 LTS and Debian 12 libraries. It has a combination of their old VGUI code and newer Chromium GUI. It remains 32-bit and only supports X11.

That's part of what I mean. Snap could be so much more interesting and useful if not for Canonical doing stuff like only allowing one store and slacking on proper support for non-AppArmor distros.

One of the more bizarre experiences I've had is that a Canonical employee packaged a version of a Minecraft launcher. It was absolutely garbage, didn't even start. The first thing that comes to mind is that snap is just garbage. But for fun, I made my own package of it, and it just worked perfectly. Which just leaves me the question of why a Canonical employee who works on snap can't create a good snap package.

There's also the weird fact that Ubuntu dropped the ball with its core24 runtime. For some reason, Canonical's own snaps stuck to core22 up until this month. Like, why wouldn't they upgrade to their latest runtime? If there was an issue with it, why has it been broken for 2 years? Doesn't inspire trust.

Snap as a technology is so interesting and more versatile than other formats. It's just unfortunate that Canonical is in charge of the project, they've made some baffling decisions and continue to shoot themselves in the foot.

It's right. While Fedora is a community project, Red Hat does hold a special place in it as its corporate sponsor. For example, the Fedora Project Leader position must be held by a Red Hat employee.

I can understand MIT being an issue in some cases. For example, VSCode is a proprietary fork of the MIT open-source Code. If Microsoft wanted, they could stop publishing the MIT open source version. Of course that code would still exist as MIT, but development would slow down without Microsoft.

But I don't see uutils being MIT as an issue. It's primary goal is to be compatible with GNU coreutils. You can't really rug pull a project with a goal like that. And permissively licensed utils have been around thanks to BSD and it's never been an issue. You don't see companies like Apple using proprietary forked versions as benefit. The "value" they add is higher up the tech stack with their own truly proprietary stuff or open stuff that encourages lock-in to its ecosystem, like Swift.

Flatpak cannot access the host GPU drivers, so there are runtimes for NVIDIA drivers.

What they are referring to is that the driver version on the host must match the driver version installed as a flatpak runtime. Otherwise, you may get graphical issues and crashes.

Ubuntu being shit for personal users is all but new (Who wants 2 year old software?

A lot of people. From a snap I maintain:

So not only are some people fine with 2 year old software, they're choosing to use 4 year old software more often than 6 month old software (granted in this second case, you can argue it's because Ubuntu promotes the LTS as the main version).

And with community maintained distros like Debian and Fedora, you kinda get the best of both worlds. You have a mostly community distro that doesn't have corporate interests pushed on it, but have a corporation paying developers to work on it because it's in their interest to.

Not sure how I feel about this "distroless" pattern. It's interesting to be able to get components directly from upstreams from like Gnome, but it makes certain tasks more difficult.

The lack of any distro packages to fall back on when flatpak, distrobox, appimages, and brew fails is simply annoying. I've experienced this multiple times.

• When I would flash OSes on my Pixel, I couldn't use flatpak/distrobox/brew. I would either have to (1) overlay a browser and ADB tools, (2) overlay ADB and maybe use an Appimage browser, or (3) boot into a traditional distro like Debian that has an unrestricted browser. Distroless has no recourse for me here.
• Using sshfs: installing sshfs from brew or distrobox would not work without host configuration changes made by overlaying sshfs. Distroless has no distro package to fall back on
• Using tailscale: tailscale from brew didn't work. Had to fall back on distro package. Distroless would fail me here, but in this case, I believe Jorge preinstalls it. So simply adopt all of Jorge's tastes and applications and you'll be fine...
• No upstream Steam support since there's no rpmfusion or official valve package to use, you'd have to use something like the unoffical Steam flatpak

While I love Fedora Atomic and atomic distros in general, I constantly feel like they do not think things through. They made the system harder to break, but with severely limited (if you use them the way you're encouraged to, like no layering). They then address these gaps one by one with more and more solutions that are imperfect and that do not fit all needs.

• Flatpak is good for GUI apps, but not CLI.
• Brew is good for CLI stuff, but does funky PATH things that could break host OS at times (and as mentioned, did not work for sshfs or tailscale for me). KDE Linux initially promoted Brew, but then later recommended not using it at all due to its PATH shenanigans
• Distrobox is good if you need distro packages, but the containerization has limitations with desktop integration and more complex tasks, like I mentioned with flashing OSes on my Pixel.

At least with Fedora Atomic (and containerfiles with bootc stuff), I can get a robust system, seamless OS upgrades, and install any packages that do not work well as flatpaks/distrobox/appimages.

Any program that takes in input has a greater chance of bugs that may result in security vulnerabilities. And I should hope that a text editor can take inputs...

Though unlike Gnome Web, this the performance is actually good despite being an early beta.

The scrolling performance using a mouse in Gnome Web just sucks, it's choppy and inconsistent. Though it does feel okay when using a touchpad.

My real surprise is that this supports Linux and more specifically Wayland.

Packagekit mainly.

It also helps if you just focus on a single package format. The Snap Store's performance is great, though I have seen some baffling QA issues with it (like categories showing up like "Devel..."). There's also that store that Universal Blue is pushing, forget what it's called.

My concern lies squarely with the 8GB of RAM. MacOS has great swapping implementation, but swap is not magic.

Inevitably, the OS and applications will get heavier, requiring more swap and therefore more disk reads and writes.

8GB on phones isn’t bad as iOS and Android are designed to freeze and kill background apps quickly. As an app developer, it’s something you design around. But on a desktop, that’s not an option, apps should only be frozen and killed at the last moment to avoid locking up the OS.

I’d be more comfortable buying an older/used M1 Mac with 16GB of RAM. And given that Neo and M1 are roughly comparable, they should hopefully be supported for the same length of time.

SSD is still supported, just tested Spotify and Flathub's Electron test app in a VM with Plasma.

MacOS is UNIX, but is not the best implementation of UNIX.

The UNIX tools it ships are extremely old. For example, it comes with GNU Screen, which I was using but was having same strange issues with. It turned out it uses a version from 2006... so I had to brew install a modern version.

And I'm personally not the biggest fan of MacOS. It's certainly better than Windows thanks to Apple mostly treating the user with basic respect (no ads), but the desktop/window manager is just super quirky. No other desktop, whether it be Windows or any desktop on Linux behaves quite like it. They tend to only adopt the nicer features while keeping a UX that feels closer to Windows. For example, MacOS quirky/unique in doing

• Requiring a click to activate a window (with no option to change this behavior)
• Fullscreening a window moves it to its own space
• Closing an app's window does not close the app itself for the majority of apps
  • Perhaps not the biggest deal if the goal is app startup speed for heavily used apps, but unnecessary for rarely used apps and clutters the dock)
  • Also can be quite annoying since it will drag you to the last space you used the app on
• Minimized windows show on dock as previews
  • Not that of an idea, but strange since you now have two ways to bring the app back: clicking on the app icon itself or the minimized preview

That's misleading, there was a significant outlier. Gnome was on average slower, but not that much slower.

That's unlikely. It's far more likely that they are at the top simply because they are more popular.

The only exception to this rule is the higher end 13th/14th gen Intel chips, which really do have a crashing problem.

Arch is quite an old distro and extremely popular. Valve could have chosen any distro, but settled on Arch.