Because they’re objectively better on a desktop.

Your compositor should control the window - if the poorly implemented client hangs, you can just click the server-side close button a couple times and get the “shall I force close this?” popup

The only reason for CSD is touch interfaces on small screens. In that case, you still need some other interface to handle misbehaving applications, but they tend to be harder to use, e.g. the removal of home/back buttons on Android

Edit: If you’re trying to improve on SSD, you could consider some model where the client can register some actions it would like to have displayed to the compositor, and the compositor can relay clicks back to the client. In this scheme, the compositor still owns the title bar, but the client can request special decorations

They’re using the new SOCAMM standard, which current consumer hardware can’t use.

It’s a different physical interface.

Whether it will end up coming to consumer grade motherboards… 🤷‍♂️

but so far I’ve been right about everything

Ffs. Why are the dumbest people the most overconfident.

There seems to be some inverse relation between confidence and intelligence…

They’ve only been working on it for 11 years now…

https://www.reddit.com/r/linuxmasterrace/comments/2jbnry/gog_officially_confirm_their_galaxy_client_for/

If you’re really going down that route, you need to also remember that even the C programmed Linux Kernel is highly OOP

Interestingly, yours is so much easier to read than theirs.

Are there people who think systemd is a badly implemented stack of Legos, who also think things like snap, flatpak, docker, and Wayland are solid bricks…?

Fractional scaling w/ HiDPI displays, especially when the monitors are different resolutions, works so much better in Wayland than X11

Hey, the last one is great.

Now when I get asked “what do you think about Copilot,” I can just say, “I prefer LibreOffice”

Forgejo is a fork of gitea, because gitea was heading to the GitLab model

Then you are using a feature phone, or a standard Android/iOS device with their tools preinstalled

If you try to use it with a free operating system, it’s not possible.

Here are the instructions for installing the bridge code on Graphene: https://grapheneos.org/usage#esim-support

From the phone manufacturer, it’s fewer traces and less mechanical design work.

From the carrier side, it requires you to have their spyware installed to register the Sim

From a user perspective, someone can’t just steal your Sim and put it in another phone

That really is how these companies think.

I’ve seen car companies selling $100,000+ cars sweating over whether we use a $0.10 more expensive part that would last 3x longer than the cheaper one

I think it’s common for the antennas to contain both GPS and LTE. I think the fuse would power the whole fin?

On the head unit side, they’re generally separate cables

That’s what most? cars used for a long time (there is also GENIVI)

Many manufacturers are switching to Android as the base OS so they can just hire app developers rather than developers that know other UI toolkits

On most cars, it’s probably easier to unplug it on the head unit side. They’re generally designed to be accessed for repair

Still longer, but at least just use

apt upgrade --update

Bindings have been getting added to the Linux kernel so drivers can theoretically be written in Rust

Android has moved its IPC mechanism, Binder, over to Rust

As a listener, if a band I like is touring within 2 hours of where I live, I go see them live and get a shirt

I hope that’s helping them more than whether I listen to a scraped digital copy or not

The high-res one also removes all the shadows, I assume the upscaling algorithm believed they were blur