That depends a lot on how the license gets interpreted and how license violations are handled by the local law. The argument for why the end user cannot do anything about GPL violation is that the violated contract is between upstream and the "bad" developer - the upstream project gave the bad developer access to their source code under the condition that the license stays the same. You as the end user only get exposed to the bad developer's license, so you can't do anything. It's the upstream who must force them to extend a proper license to you.

However there was also a case recently where the FSF argued that this interpretation / handling of the situation is against the spirit of GPL and I think they won, so... Yeah, it's just unclear. Which is normal for legal texts (IMHO intentionally, but I'm not here to rag on lawyers, so I'll leave it at that).

While I agree with your view (at least when it comes to firmware, especially given that hardware that doesn't require a firmware upload on boot generally just has the very same proprietary firmware on a built-in memory, so the only difference is that you don't get to even touch the software running on it), the point of this project is to remove non-libre components from coreboot/libreboot.

It doesn't differentiate itself from upstream in any other way, so if it fails to do the one thing it was made to do, then that's in fact a newsworthy fact.

To be fair, giving a company that's been failing to get themed icons to work on Android for almost four years now less than a month to make a significant change to a core part of their software is... quite weird?

Like, the EU usually gives companies at least half a year to comply with smaller demands than this, because companies with such a huge bureaucracy load wouldn't even be able to change an app logo in such a short amount of time.

I don't think it supports displaying HDR at all? The GitHub issue regarding HDR is still open and it definitely doesn't switch to HDR mode when I open HDR photos with it.

The hardware supported it ever since adaptive charging was introduced, so that's not surprising.

The work profile seems like a better place for that, and it was available since Android 5

I do not know of any such dongle, but I'd like to ask you a question if you don't mind: are you looking for a dongle with open-source firmware, or would a dongle that has its (proprietary) firmware stored in some onboard memory be acceptable?

The second option wouldn't require you to install any proprietary firmware on your computer, but you'd still rely on the proprietary firmware for the device to run. And it might also exist, unlike a dongle with FOSS firmware.

new Pixel

Pixel 6 Pro, Pixel 7 Pro, Pixel 8 Pro, Pixel 9 Pro, Pixel 9 Pro XL and both Folds. Not the base variants, and especially not the a series. Just in case anyone actually wondered.

The bigger issue is that you can only cast from the tablet to the phone, not the other way around, at least if the Feature Drop page is to be believed

Soon, you can easily transfer media from your Pixel Tablet to your Pixel phone with the new casting feature coming in the next few weeks. All you have to do is bring your phone close to your tablet and what you’re playing on Spotify or YouTube music will seamlessly move over without the extra steps of tapping the cast icon.

Maybe developers will finally start implementing predictive back now that it's not hidden behind developer options. It's kinda nice when you can just peek at where the app wants to take you when you go back, and it currently ironically tends to be implemented only by apps that already have decently made navigation.

Also private space seems nice, finally a way to use the work profile sandbox natively without having to install third party apps that pretend to be work profile managers.

I know this isn't Reddit, but r/peopleliveincities... When 90% of desktop users use Windows, it's going to both be the most targeted by malware developers and have the highest chance of being operated by someone who doesn't understand enough about computers to recognize that the shiny calculator app that just popped up after visiting a very legit Nigerian prince's crowdfunding page probably shouldn't need admin access.

And speaking of user error, I'm willing to bet that basic security practices like using full disk encryption, SecureBoot, some MAC layer (provided by antivirus on Windows, AppArmor/SELinux on Linux) and regularly applying security updates are way more common over in the Windows land - if I was in a situation where there was one completely randomly selected Windows PC and one also completely randomly selected Linux PC, and my life depended on being able to gain access to either of them (some kind of really messed up Saw trap? idk), I would definitely bet my life on the Linux one being misconfigured.

Don't get me wrong, Linux can make for a very secure and private OS, but most installs most definitely cannot be described as such - just look at the popularity of random unverified PPAs on Ubuntu derivatives or AUR packages on Arch.

The biggest friction point for me is the fact that files can only cross the work profile boundary by using the Android's share sheet (or with cloud storage, I guess), and some apps (cough cough Meta crap) didn't like it when you shared a file they couldn't directly access with them. I didn't encounter any such issues recently though.

If you pause the work profile (there's a button in the launcher to do that), all apps in it get killed and their icons and widgets in the launcher get grayed out. If you tap a grayed out icon, you get a dialog asking you if you want to unpause work apps. I think there are ways to automate pausing, but I don't use anything like that and literally only have the pause/unpause button as a toggle for the intrusive apps.

I wonder if Private Space apps can be turned off the same way work apps can. If so, I could ditch Island and stop abusing the work profile as a way to implement a light battery saver.

A reasonable build of the kernel optimized for virtualization won't take more than a few tens of megabytes of RAM (and it will have support for memory ballooning, so the virtualized kernel will give the memory it doesn't need back to the host), and the userspace will need to be separate anyway due to how different Android is to normal Linux distros.

Containers are nice when you want to run dozens of separate services on the same server or want to get the benefits of infrastructure as code, but in this case they would provide minimal benefits at the cost of having no way of loading any kernel modules not built into whatever ancient kernel version your SoC manufacturer decided you have to use on your phone. Also, container escape vulnerabilities are still a bit more common than full VM escape, so this is also good for security on top of being more useful.

box86/box64, and there's also FEX-emu which is used by the Asahi Linux project (Linux on Apple Silicon macbooks).

It is for their non-flagship devices - those were always kinda left behind with software support.

Both? It's pretty well explained in the rest of the text (you don't even have to click a link)

It was up to the Commission, which has exclusive powers to set the bloc's commercial policy, to break the gridlock and ensure the duties go through.

The European Commission made the decision after the member countries failed to agree on how to proceed.

What error? It gave you a string of tokens that seemed likely according to its training data. That's all it does.

If you ask it what color is the sky, it will tell you it's blue not because it knows that's true, but because these words "fit together". Pretty much the only way to avoid this issue is to put some kind of filter in front of the LLM which will try to catch prompts that are known to produce unwanted results, and silently replace your prompt with something like "say: sorry, I don't know".

I'm being very reductive here, but that's the principle of how these things work - the LLMs are not capable of determining the truthfulness of their responses.

OK, cool. Just remember that the only entity who can sue in this situation is Microsoft (because when you contribute code to VS Code, you must sign a CLA that says you give Microsoft full perpetual rights to distribute your code under any license they wish - it is Microsoft who then "graciously" releases your code under a copy left license while also building their proprietary version of VS Code using it).

And Microsoft cannot use the code if it gets released under a copyleft license - that wouldn't allow them to build their proprietary build with it. So the only one who can do anything has less than zero (because it would improve only the FOSS forks, which are meant to be inferior) interest in making these guys publish the source code as proper FOSS.

No, they are just in violation of the original license. That doesn't mean they have to comply with it by properly open sourcing the project. Generally it's also OK to just delete everything.

There were plenty of cases where commercial software included open source stuff in a way that violated its license, and the accepted way to fix the license violation was for the software/hardware vendor to stop using the violated project going forward. Usually they don't even have to for example scrub old firmware downloads that improperly included FOSS bits.

I'm a very casual Pixel Dungeon player and have never played Experienced Pixel Dungeon (might give the final version a try but I suspect it's not very noob friendly), but I'd still like to say kudos to you for handling the project's end so well - so many projects end up simply abandoned or even deleted without warning. And you've brought it up to date with upstream for one last time, that's also awesome from you. Just sucks to hear that you didn't enjoy working on it.

Anyway, good luck with whatever you end up doing