Thanks for the recap. Yeah I think I was more or less aware of most of those bits. I guess I didn’t get to the conclusion. 😅 Also I think they handled Justin Roiland’s issues fairly unambiguously. Assuming he was a bastard, I didn’t skip a beat watching the Justin-free season.

I know it’s officially not cool to like Rick and Morty anymore

I’m sorry what?

Ad views.

Sounds like Chrome’s Privacy Sandbox.

A big company eh? They’re about 20 times smaller than Red Hat. They very much depend on Debian and the larger FOSS community to get their OS built.

I’ve been on this train since 2004 and I’ve been paying attention. Not all but a lot of the flak they’ve been getting over the years has been based on misinformation and ignorance. But trying to get things objective and correct doesn’t make for a good flame war.

I can’t believe people construed the lack of this feature in a brand new software as bad Canonical want to kill deb! It’s a brand new software. Features need work. Either go and write them or wait for someone else to do it.

It’s beautiful. I assume they’ll dump the kernel oops log if there’s any.

What a beautiful bastard!

Stock AOSP shipped on Pixel.

Done. 🥰

Using an Al-less desktop may be akin to hand copying books after the printing press revolution.

Or perhaps not.

Doubt

Oh yeah, I meant for the workers, since it’s constantly being sold to us as beneficial.

People should look into the history of banana trade for context. It’s a fascinating example of how capitalism has gone awry before.

The Debian community not already maintains a Chromium fork. How much does that cost?

The human time needed should grow with the number of patches that need to be applied to the upstream code base, because some will fail now and then. This is what I refer to as “fatness” of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work. Testing is done by the users as it always has been in Debian and its derivatives. You’re referring to a few full-time developers and I simply don’t see the need. Maybe I’m missing something obvious. 😅

It depends on how fat the fork is. While I haven’t worked on Blink, as a developer who works on other people’s very large codebases, including one from Google, I disagree. There are free tools for build automation. That’ll take care of being up-to-date with upstream in terms of security. Patching things can be done using conflict-minimizing strategies. I used to work at an Android OEM and I’ve seen it done with great success. Thinking of Blink specifically, there have been lots of forks during its WebKit days. If I remember correctly there are also thin forks of Firefox maintained by some open source developers. This is all to support thay I don’t think it’s that big of a deal. Especially if most of it is rebranding and restoring some deprecated or deleted functionality. Could be wrong. I think we’ll see, because I have a feeling the cost of maintaining a Chromium fork could be cheaper than patching apps to work well on Firefox. Some corpos might even pitch in. Not to mention that it isn’t at all obvious for how long Firefox will be developed by Mozilla. If they drop the ball at some point we’ll be faced with implementing new features in Firefox vs patching features of Chromium. ⚖️

Why not all? Add SFTP (file transfer over SSH) to the mix if needed.

Run 4 passes of Memtest86+ on it. 🥹

When it comes to open source software, market choices aren’t nearly as necessary because new ones can be created at will and very low cost by forking. But in the abstract thech companies are definitely not interested in choices. Choices don’t maximize profits.

If the labor abuse stops Shein becomes impossible. Unfortunately there’s money in allowing it.