The right to repair. It’s going to require the ability to make changes to the software on the vehicle. At a minimum the ability to replace the public encryption keys used to communicate with the servers. The bootloader and software is probably locked behind signing keys; so you need to be able to disable or add your own keys. I doubt anyone has access to the full protocols used to communicate with the servers. So, the full technical standard need to be released (which is never going to happen) or reversed engineered through unencrypted traffic analysis and reverse engineering the software.

A good right to repair law could require some of that be releasable while the company is still active or all if the company goes belly up. IIRC there was a smaller EV company that went bankrupt and there was a concern that once the servers were shutdown the vehicles would be bricked. Not sure what happened in the end. In any case, cars as IOT is the stupidest idea ever created.

That depends. Are you looking at preserving the music without loss of information? Then you need to use a lossless format like flac. Formats like aac, mp3, opus can throw away information you’re less likely to hear to achieve better compression ratios. Flac can’t, so it needs more storage space to preserve the exact waveform.

You can use a lossy format if you want. On most consumer level equipment, you probably won’t notice a difference. However, if you start to notice artifacting in songs, you’ll need to go back to the originals to re-rip and encode.

There’s talk on the Linux kernel mailing list. The same person made recent contributions there.

Andrew (and anyone else), please do not take this code right now.

Until the backdooring of upstream xz[1] is fully understood, we should not accept any code from Jia Tan, Lasse Collin, or any other folks associated with tukaani.org. It appears the domain, or at least credentials associated with Jia Tan, have been used to create an obfuscated ssh server backdoor via the xz upstream releases since at least 5.6.0. Without extensive analysis, we should not take any associated code. It may be worth doing some retrospective analysis of past contributions as well…

Yet another example of why we need privacy laws with real teeth.

Do you mean Computer Fraud and Abuse Act (CFAA)?

Yeah, the first 2/3rds of the article covering Naomi Wu was worth a read, but that last 1/3rd… I get her argument, but she should have left that out to focus just on Naomi.

I honestly see this being a continued expectation to be a bigger issue. Two communities with the same name on different servers could be very different spaces. Giving users the ability to group them together homogenizes them in a way that is likely bad for the ecosystem overall.

I see the issue, but I still see the tradeoff as being worth it. Right now, if I want to browse technology commies I have to click into each one I’m subbed to. This means I’m going to go the to biggest one first, then second biggest, and so forth. This pretty much favors the big commies over the small ones because this is just annoying to the end user. Grouping gives those smaller ones a better chance of appearing in someone’s feed thus spreading out activity over a larger part of the lemmy fediverse.

There’s going to be ups and downs. I wouldn’t be too concerned right now.

I see the bigger problems being community discoverability, not being able to group communities together, and moderation tools.