I don’t think we would be throwing USB-C away completelly, because it even became mandated by law in EU with the goal of trying to slow down the rate at which people generate trash by getting new cables and power bricks for every new generation of connectors.

But I agree that at the very least there should be a clear labeling mandated by consumer protection laws as well… it’s a nightmare and a scenario that opens the door for a lot of scams… this is even made worse by the fact that nowadays you can even have malicious software running inside of the connector of a cable plugged into an extremely capable port without realizing it, messing up with your device even though the only thing you wanted was to charge it.

I have something like this myself, it’s useful for knowing the power delivery, but I’m not sure if that really helps when it comes to determining the speed of the data transmission that the cable/port is capable of, or other features like displayport support, or which version of USB4 it might be supporting (I believe they have the same power delivery, even though the transfer speed is double).

This one is p2p: https://github.com/schlagmichdoch/PairDrop (or just try it in https://pairdrop.net/ )

But that also means that you need to keep the page open while the other device downloads.

Another p2p alternative is using webtorrent: https://instant.io/

Code being visible is not very useful if you can’t distribute it, extend it, expand it and improve it.

It’s meant in the sense of “underwhelming” (as shown by the follow-up comment the article references). It’s not incompatible to be surprised at how capable AI is (ie. being “impressed”) and at the same time be also unwilling to pay the costs / repercussions and want to ban / regulate it.

In this context, being deeply unimpressed with something is equivalent to calling that something “irrelevant” / “incapable”. If AI was no more impressive than it was before the LLM boom then there wouldn’t have been such a reaction against it to begin with. If anything, people being now opposed to modern AI is proof of how impactful AI has become.

Yea, but he’s (intentionally?) misrepresenting things… people are not “unimpressed” by AI, what they are is not interested in MS “agentic OS”, these are not the same things.

It’s irresponsible to hand in control of your machine to an AI integrated that deeply into the OS, particularly when it’s designed to be tethered to the network and it’s privately owned and managed by human entrepreneurs that do have the company’s interests as first and main priority.

It’s unclear what you are trying to say. The question was what would switching license do. There’s 2 scenarios: 1) either Google is really not doing changes in ffmpeg source internally right now …or 2) they are in fact making changes to it internally (perhaps for encoding with their own codecs, etc.) which they are not releasing back to the public (since the code is LGPL, and not AGPL)

With situation 1, they can simply continue using ffmpeg, even if it were to switch to AGPL. They would have no need/obligation to release anything, whether they decide to fund development or not. The way I see it, only if it’s situation 2, will Google be affected by a license change. However, if the use they make of ffmpeg is just to have their own encoder program for use with specific codecs, they might as well decide to stop using ffmpeg for this purpose instead and have their own program to work with their encoders. Most of the encoding work is already being done in the encoding libraries separately released (like libaom, which Google licensed under BSD-2).

But even in the rare case of Google having made changes that (after license change) they would suddenly decide to be willing to share with the community despite having not done so before… the whole problem with this bug-reporting mess is that most of the issues reported by the automated tools aren’t something really that impactful/important, they are things that even Google would not really be that interested to fix… (why would Google need to fix a codec that only affects a videogame cinematic from 1995?). These reports are just the result of automated & indiscriminated AI analysis, slop.

AGPL is more “copyleft”, but not really more “permissive”, in the sense that AGPL adds the extra requirement of forcing server admins to provide the sourcecode to the users of any service that internally makes use of AGPL code.

It plugs a loophole of the other GPL licenses that allows companies to not share any custom modifications as long as they don’t directly share the binaries (they can offer a service using internally modified binaries, but as long as they don’t distribute the binaries themselves they don’t have to share the source code from those modifications running on their private servers, even if they are GPL).

However, I don’t think a license change would really solve this particular bug-reporting trouble. Most likely Google has not patched these vulnerabilities internally either, or at least the biggest chunk of them (since most of them are apparently edge cases that would most likely not apply to Google’s services anyway).

Sounds like a prioritization issue. They could configure the git bots to automatically flags all these as “AI-reported” and filter them out from their TODO, considering them low priority by default, unless/until someone starts commenting on the ticket and bringing it up to their attention / legitimizing it.

EDIT: ok, I just read about the 90-days policy… I feel then the problem is not the reporting, but the further actions Google plans based on an automated tool that seems to be inadequate to judge the severity of each issue.

Sure, but if it wasn’t triaged why consider it “medium impact”? I feel when tight on resources, it’s best to default to “low priority” for all issues whose effect (ie. to the end-user, or to the software depending on it) isn’t clearly scoped and explained by the reporter. If the reporters (or those affected) have not done the job to make it easy to quickly see why it’s important to have this fixed then it’s probably not so important for them to have it fixed. Some projects even have bots that automatically close issues whenever there has not been activity for a certain time (though I’d prefer labeling it / categorizing as “low engagement” or something so it can be filtered out when swamped, instead of simply closing it).

About “public confidence”, I feel that this would rather be “misplaced confidence” if it’s based on a number that is “massaged” to hide issues. Also this is an open source project we are talking about, there isn’t an investment fund behind it or a need for people to have absolute loyalty or blind trust. The code is objectively there, the trust should never be blind. If there wasn’t a long list of reports I’d be more suspicious of a project as popular, frequently updated & ubiquitous as ffmpeg. Specially if they are (allegedly) not triaged. Anyone who decides to choose ffmpeg based on the number of issues open without actually investigating from their end how relevant that number actually is… well… they can go look for a different software.

I agree… I mean they are not forced to fix the issues, if the issue is obscure and not many people are affected, then there’s no reason why they can’t just mark it as “patches welcome” and leave it there. I feel this is a problem in the policy the project might have for prioritization, not really a problem in QA / issue report.

For context:

The latest episode was sparked after a Google AI agent found an especially obscure bug in FFmpeg. How obscure? This “medium impact issue in ffmpeg,” which the FFmpeg developers did patch, is “an issue with decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.”

To me, the problem shouldn’t be the report, but categorizing it as “medium impact” if they think fixing it isn’t “a valuable use of an assembly programmer’s time”.

Also:

the former maintainer of libxml2 […] recently resigned from maintaining libxml2 because he had to “spend several hours each week dealing with security issues reported by third parties. Most of these issues aren’t critical, but it’s still a lot of work.

Would it be truely better if the issues wouldn’t be reported? what’s the difference between the issue not being reported and the issue not being fixed because it’s not seen as a priority?

Is the database publicly accessible somewhere? is it limited to an extension or can we simply browse it?

This looks like it could work better if developed in the open / collaboratively. Though from their FAQ it looks like they are still working in some open source platform:

Our wonderful devs are currently working on an open-source website to replace and improve our current and temporary platform.

In the meantime, we will continue to add and verify European brands to the database.

Yes! I mean, blame those who post AI-generated translations as if they were their own, or blame the AI scrappers that use those poorly generated pages for training, but it makes no sense to blame Wikipedia when the only thing they have done is just exist there and offer a platform for knowledge sharing.

In fact, this problem is hardly exclusive to Wikipedia, every platform with crowdsourced content is in some level susceptible to AI poisoning which ultimately ends up feeding other AIs, the loop exists in all platforms. Though I understand wanting to highlight particularly the risk of endangered languages being more vulnerable to this, since they have less content available to them so the AI models have a smaller dataset which makes them worse and more sensible to bad data.

And even if they did somehow manage to get permission to switch the license, all previous versions would still be open in perpetuity so a fork would come easily. Immich source isn’t only open, and not only GPL… but AGPL-3.0 which is as copyleft as you can get.

Yes, last time I tried Revolt it looked shamelessly like Discord’s UI.

I feel that if they just wanted an app with the look and feel of discord, it would have made more sense to make a matrix (or maybe xmpp) client with the look and feel of discord. I honestly don’t see much value in yet another protocol if the only distinctive feature is in the look & feel of the UI. Specially if they are not designing the stack in a way that is at least as good as those other options from a security, privacy, feature extensibility and decentralization standpoint.

Did they work on developing new web standards to unlock that potential on the web?

Back then HTMLv5 wasn’t even a thing, there was no concept of video/microphone/gyroscope/gps access for webapps, notifications, web workers, web sockets, offline PWA webapps, etc. It was not a viable idea unless they actually were to invest big. They weren’t so committed. In Firefox OS even the dialer was a webapp, Mozilla brought forth a lot of innovative APIs to make it possible, many of which are in use today even after the OS was discontinued. And nowadays you even have things like Webassembly that allows you to code it in C or whatever low level language you want.

I feel Apple has always been more interested in their own ecosystem. Opening the web to have the same level of potential as the native apps from their walled garden goes against that strategy, so I don’t believe they were really serious about that approach, it’s always been more interesting for them to prioritize their native apps.

I wonder if resurrecting Firefox OS might still be an option. It was such an interesting idea having the webapps be first citizens.

There’s the KaiOS fork, but the direction is not really the same since it’s more targeted to low power keypad-based phones… and I believe they replaced much of the Gonk layer with a very stripped down low level Android base which isnt fully open source… maybe if they coordinated with the LibrePhone project and some hw manufacturers (like EU-based Nokia) we’d get a fully free stack.

I think it makes sense to choose a phone that’s freer than most phones as a start, then fill up the gaps to make it fully free. As things are all phones have blobs (even non-Android ones).

I expect non-Android linux mobile OSes can also benefit from the reverse engineered firmware.

What should be the highest priority in terms of being able to use a fully FOSS phone? I feel we already have FOSS alternatives for most things that make the phone usable.

Perhaps free hardware might be top, but the S in FSF is Software and being able to avoid non-free software would be close 2nd, imho.

I expect it’s a combination of all the above in some sense. They state they want to build on LineageOS (an Android variant) and replace its binary blobs, I expect the result would be a new custom ROM targeting specific compatible hardware with the goal of ultimately supporting usable phones working on fully Free Software.

What it’s not is the creation of a libre hardware phone. I don’t think they are working on hardware, at least not anytime soon. Also if by “Linux phones” you mean non-Android based, that’s not necessarily a requirement (given that they mention LineageOS), but I expect regardless the kernel will be Linux without the blobs and it’s entirely possible that they add support for installing their firmware on those “Linux phones”.

I do kinda wish they’d focus on stuff that has a way bigger user impact 😅

The thing is that technically we already have fully usable FOSS software at that user level. Using for example LineageOS with F-droid as the only app store already gets you there. Whereas, ensuring your phone is not spying you or having some malicious functionality on the hardware/driver level is something that currently is simply not possible.

The FSF has always been doing the thankless job of championing for the things that are harder and less rewarding to do, but that will advance software freedom most for those who do seek it. Even when that thing is not necessarily the most popular/mainstream. I feel this has more of an impact in software freedom than, say, if they were to reinvent the wheel just to have their brand attached to it, and/or provide a slightly different UI to do the same thing other FOSS software already does.