They probably fear that the failed Windows mobile lineup tainted the brand name for the product’s target demographic.

I gave it a Google and saw what changes they have made, and it definitely explains the new feel. Frame timing is waaay better and the frame rate is more stable. They moved from a OpenGL implementation to a Vulkan one, from my understanding. I had to adjust my mouse sensitivity too, so they made some changes there as well.

32-bit programs can’t use as much memory as 64-bit programs. Being able to use more memory means less loading from the disk. 64-bit also tends to be more optimized these days as most systems have moved to it already. In this case, I had no idea TF2 was still 32-bit.

Call me out if I’m wrong, but my Deck is noticeably snappier after this update. TF2 is also smoother, which is weird considering the game hasn’t changed visually at all. Not even an update notice of anything major.

The problem is they keep breaking in-home streaming to/from the Deck. My Mac has a significantly more GPU oomph so there are some games I’d like to play streamed, but streaming hasn’t worked in either direction since last year.

Don’t give them ideas 😂

If Canonical and RedHat weren’t backing different horses (Snap vs Flatpak), I could see the app containerization system coming under systemD as well fairly soon. The Cosmic DE project uses functionality from systemD to overlay changes onto the system that are reversible, so that alpha versions of Cosmic can be tested without permanently changing the base system. Imagine apps shipping on whatever container runtime, and dynamically overlaying system-level changes as needed for things that tap into the host system via systemd-sysext.

A lot (and I mean a lot) of criticism can be leveled at systemD. One of the upsides of it becoming popular is the standardization of much of things from the developers’ perspective. It’s easier to target multiple distros when you can rely on systemD’s single implementation of the feature. Over the next decade, I forsee systemD eating more and more of the userspace, until you are only left with managing the differences between DEs and which display server they are using. We’re already headed towards immutable base systems with apps shipping with their own dependencies, which we reduce the differences between distros even further.

“hello system” is pretty nice to look at, and has some Mac-isms I find helpful. FreeBSD has a new release recently, so maybe Nomad or GhostBSD could be worth trying. You’ll find FreeBSD is a lot more “consistent” compared to Linux, but be prepared for random hardware to not work.

Honestly it isn’t. Support for anything front-end related is way more sparse compared to Linux.

Man I wish FreeBSD hadn’t fallen to the wayside. It’s really cohesive and feels put together in a way not Linux distro ever has.

Good. Stop locking game content behind increasingly high paywalls. It used to be when you paid $60 for a game you got something that could stand on its own. Now if you aren’t getting the GOTY you’re getting half a product.

Valve can go into the negative selling Decks, something that their competitors can’t reasonably do because they will get money from Steam store sales made on the Deck. I for one went from buying 3-4 games a year to like a dozen because it’s been so convenient.

Haha Mint was my first distro! I wiped Windows 7 and installed Mint, then quickly learned that a tarball is in fact more work than an exe. Good times and a great learning experience! Back then it was the only thing not slow, ugly, or wildly unfamiliar.

I admire your gusto! I think it’s doable, and you can definitely pull it off if you want to. To replace MD5 and implement signatures you need to do the following, as a high level overview:

Extend dpkg to know what SHA2 is, and reliably detect it. (maybe measure hash length or specifying a new version using the control file?)

dpkg must also know what a signature is. More on that below.

Providing automatic/mandatory signing will require code to handle PKI as well as a place to store the signing information. I would do it by signing the two archives found within Deb packages, then placing information about the signing in the top-level of the package. Existing tools need to be able to ignore or handle whatever you implement as a rule of thumb.

Note that this is just my approach and maybe you can do better.

I also recommended looking into https://lists.debian.org/debian-dpkg/2001/03/msg00024.html. This is the thread I mentioned earlier, in which package signatures were discussed and ultimately turned down. Maybe the easiest approach is to re-implement what the contributor was trying to do back then, but with modern code and standards? If you want more resources, including my presentation on the topic to HackCFL and CitrusSec, let me know. I am here for whatever technical assistance or industry contacts I can provide. The white paper might be done in a month, minus peer review. I’m very busy and so is he. Good luck in any case!

To save you some effort, they do not consider it a priority to fix. Code was attempted to merge that would make package signatures the default, but it was removed because it “was a waste of cpu cycles” when “md5 and the https was just as good”. I’m not kidding, you can find the whole conversation in the Debian mailing archives. So instead I’m going to make it known how dumb it is, and encourage people to use something else.

In theory (whitepaper is still being written), if you MITM the connection to the APT mirror it’s using you can also carry out the attack over the network by injecting it into the package on the fly. Cert pinning might be a blocker, but local (LAN) package mirrors might still be valid attack targets. Enterprises often use MITM certs for things like DLP and packet inspection we might be able to leverage at least.

The use of MD5 becomes a bigger issue when paired with the lack of package signatures. You can inject code into a package and find a colliding digest absurdly fast. I and a friend from Threatlocker created a Metasploit module to use Deb packages for local privesc based on the concept. If it touches the filesystem outside of the APT cache it becomes a vector.

Did they ever make good on this plan?

RPM must accept SHA-1 hashes and DSA keys for Fedora 38, ideally with a deprecation warning that it will be disabled in F39.

And MD5 for package integrity checking, and not using per-package PKI signatures.