Come on, that’s literally just JPEG artefacting because it’s a meme and it’s been shared a bunch. There are so many fakes of this card out there, it’s not that far-fetched and it’s likely not a $10k+ card that was destroyed.

It does still have some issues, but it is being heavily worked on and has been for 12-18 months at this point. Has taken huge strides, and if you’re in the beta channel you’ll see lots of work being done.

There is, check out the Music Assistant add-on for Home Assistant.

Yeah honestly these feelings are so bloody valid after the way they’ve been used lately. It’s always good to be sure of these things.

Would you not consider signing a CLA (without remuneration) if it binds a project to releasing your code under an OSI license? The only way they could have done better I think is by specifying AGPL instead. I’m not trying to argue that all CLAs are good here, but I don’t think that when they achieve the goals of the free software movement, they should be treated with suspicion or derision.

Honestly, all of the recent light shone on CLAs is a great thing. But there are still valid reasons to maintain a unified copyright for a project. None of these projects would have been able to move to AGPL without having used a CLA for that purpose. It also allows enforcement of that license via things like litigation, because you can have one entity on the docket, instead of a thousand contributors all defending their copyright.

I think the correct course of action isn’t to avoid signing one, but to force projects to commit to the social contract of open source in writing. I think there’s also a discussion that no one has earnestly talked about. A contributor license agreement is a contract between two parties, and under contract laws both parties must materially benefit. “I will get x, and you will get y”. This is known as consideration, and courts will nullify contracts that only benefit one of the parties. The only consideration I think there is to be found in most of the CLAs that have been brought up lately, is basically “your code will be merged into the project and released under it”. They don’t specify the continuation of open source, but it’s heavily implied by the aforementioned social contract. So when someone like RHEL goes and closes their source, they’ve essentially changed that contract to “you will sign over your copyright to us, and we will exploit your labour for profit”. That is not consideration, and it calls into question the validity of every single CLA signed. I genuinely think there’s grounds for every RHEL contributor that signed one to form a class and sue, and I would love to see FSF or EFF organising and supporting that sort of effort.

Back to Element for a second though, as far as I can see, their new CLA is a valid contract, because it gives a right to the contributor, that their code will always be released under an OSI license. So if a successful suit was brought against someone like RHEL, or Hashicorp, we could see other projects scramble to repeat Element here. That would be, in my opinion, a very good thing for the free software movement.

Except both of the projects you just linked too have CLAs, which they updated on switching to AGPLv3. Both use them as a way to offer dual-licensing, so they can charge companies for an AGPL-exception by selling them a proprietary-licensed version, which then supports the FOSS-development. They both were also only able to change to AGPL because of already existing CLAs. At least in Element’s case though, they created a two-way commitment in their CLA:

Now, CLAs come in all shapes and sizes: some good and some bad. It’s critical to understand that our reason for requiring one here is to give us the right to sell AGPL exceptions: not to “do a Hashicorp” and switch to a non-FOSS licence in future. We’ve made this clear in the wording of the CLA (using a similar approach to Signal’s CLA) by committing to distributing contributions as FOSS under an OSI-approved licence – many thanks to those who gave feedback on the original announcement to suggest this. You can find the final CLA wording here, derived from the well-respected Apache Software Foundation CLA.

Here’s the specific text from the CLA:

Element shall be entitled to make Your Contribution available under Element’s proprietary software licence, provided that Element shall also make Your Contribution available under the terms of an OSl-approved open-source license.

I personally consider that a fairly reasonable term. Especially because they specified an OSI-approved license. Element are always going to be bound to that now. This is like the copyleft of contributor license agreements.

The dev of this developed Caddy? Hmm… at least there’s talent behind it. I’m a little worried about creating that sort of record, but this guy seems earnest in wanting to liberate personal data.

Oh cool, gonna install this in my Windows 10 VM under Linux :)

try 3d anything

blender runs natively on linux…

do agree about music tho, it’s still a huge area that needs work

edit: blender running on my legion go, under steam gamemode on bazzite (it’s available on steam):

Not trying to convince you, you have your reasons. However, Photoshop 2024 runs just fine under wine: https://forum.mattkc.com/viewtopic.php?t=336

I believe illustrator and premiere do as well. There’s also always running Windows in a VM. There are ways to have the Windows applications show within the Linux DE. It just might be worth experimenting with a dual boot if it’s something you want.

I’m sorry, did you just retroactively change the meaning of FOSS to “thoughts and feelings” so you could throw Apple under the bus?

That information is well over a decade out of date. I remember when VLC had those issues. In a rare capitulation for Apple, they adjusted their terms to allow copyleft licenses.

As far as “probably” causing FOSS devs to stay away from the platform. Like I said, most FOSS projects have an iOS app. Hell, Jellyfin now has several FOSS iOS apps. Most of the iOS Lemmy apps that are available are FOSS, heck some of those are even iOS-only.

Like, I’m sorry, but this is about facts and not just your feelings. You said before that the choice of Swift over Rust would “massively” affect FOSS contributions while providing zero evidence to back that up. Sure, you’re right, number of files doesn’t mean much, but at least I provided a fact.

My personal opinion is that most FOSS developers are put off by “yet another chromium fork”, and will flock to this project as a breath of fresh air, no matter whether it’s Swift or Rust.

Yeah, I don’t exactly think it’s particularly burdensome to have to rename your fork so that people don’t confuse it with the software you forked from. Without this restriction, FOSS projects would have absolutely zero recourse against bad actors. A non-FOSS competitor could just waltz in, fork their code and turn it into absolute hot garbage, convincing enough people that it’s the original project to make it all worth their while.

The OS can’t get to the point of loading cpu microcode without that outdated, embedded microcode. The reason it can persist is because there aren’t a lot of good ways to see what that UEFI microcode actually is once it’s installed. Plus, only the UEFI tells you that it has successfully updated itself. There is no other more authoritative system to verify that against. So the virus could just lie and say it’s gone and you would never know. Hence needing to treat it as the worst case scenario, that it never leaves.

pretty much give up on open-source contributions.

You do realise that most major FOSS projects have an iOS app, right? The post I was looking at before this was for a new jellyfin app, small individual dev, has an iOS beta out. For a comparison, there are 9.1 million files on github in Swift, and 11.3 million in Rust.

As well, as far as contributions, Swift was designed from the getgo to be incredibly approachable for novices. While Rust is notorious for being unapproachable. Like I get the anti-Apple circlejerk is strong, but Swift is licensed under Apache 2.0, it’s FOSS, so this argument is kind of ridiculous. Especially considering how much of Google’s FOSS just gets a free pass.

Hey, that’s really fair, thanks for being honest :)

Except that doesn’t at all explain the wider recall of 100 million units. Not every single one of those airbags were faulty. First of all, how could we know? Testing an airbag is a potentially dangerous thing to do, let alone on an enormous scale that would require under-qualified persons to run the tests. Secondly, it’s not a 100% failure rate. If it were, it would have been picked up far sooner than it would take to sell 100 million units. If it happened just as severely no matter the unit’s age, it would have been picked up during crash-testing. What actually happened was an analysis of statistical averages that showed a far higher rate of failure than there should have been.

The similarities to me come from a comparison to Schrödinger’s cat. In the airbag example, you don’t know if the unit in front of you is going yo fail until you “open the box” by crashing. With the AMD vulnerability, you don’t know if ur motherboard has been infected by any virus/worm/etc until a “crash” or other signs of suspicious behaviour.

In both cases, the solution to the vulnerability removes that uncertainty, allowing you to use the product to it’s original full extent.

Look at it this way, imagine if this vulnerability existed in the ECU/BCU of a self-driving capable car. At any point someone could bury a piece of code so deeply you can’t ever be sure it’s gone. Would you want to drive that car?

Sorry, I reread it and I understand now that you were referencing the AMD chip in a comparison. I guess I still would compare it most to the Takata airbag situation. You’re right that nothing happens on it’s own, but once you’ve “crashed the car” then it kind of is a lot like an airbag not going off. It infects your computer on a hardware level, and any future OS running off that motherboard is potentially vulnerable in a way that’s impossible to tell.

Once every 6hrs would only be 180GB. A script that does it every six hours, but then increases the frequency if it goes below a certain threshold, could work well. I guess it all depends on how accurate you need the data to be.

I’m aware. That’s why I pointed out, to the person that conflated the two, that they are different.