Ugh, that ending crossing the line, so close!
klangcola
KDE Maui does, but Microsoft Maui doesn't .
(Sorry, I know you were referring to Microsoft Maui, I was just annoyed at being reminded how Microsoft stole the name: https://www.phoronix.com/news/Microsoft-KDE-MAUI )
Another reason is when developing the Web version first. Draw.io is a good example, where we get a bonus desktop(electron) version "for free" though the product was developed as a web app.
Thanks for reminding me why Maui doesn't support Linux. I saw Maui mentioned in an earlier comment and was naffled why KDE would make something not working that doesn't work in Linux. It's because Microsoft stole the Maui name from KDE: https://www.phoronix.com/news/Microsoft-KDE-MAUI
Hardest issue would probably be financing, and motivation.
GPUs are expensive, electricity is expensive. All the current major LLMs are huge loss leaders for giant players with deep pockets. A distributed AI service would be by smaller players without the financing nor the motivation to upfront all the cost.
There is "folding@home" where you donate time on your hardware for scientific calculations, but that's quite different from donating time on your hardware to some random unknown stranger to generate AI cat images or summarise a news article.
Lemmy and Mastodon etc have a comparatively modest monetary (and energy/environmental) cost, and the benefit is building communities and bringing people together. For distributed AI the cost ( monetary and energy/environmental) is higher, and the benefit is limited.
Can attest that Folder Sync is excellent. I use it all day (in the background) for two-way sync (notes) and backup of photos videos etc
Though a small PSA on setting up:
I once set up a new share on a new phone with two-way sync, and the app decided to sync the (newer) empty directory to the server (i.e. delete everything) instead of pulling the files from the server to the phone.
Easy fix: Restore notes from backup (step 0: have backups in the first place), then do an initial 1-way sync from server to phone, then change the sync job to two-way.
The bit that's so perplexing is that in north America they are not "cars" but "light trucks" , yet they can be legally driven on a normal "car" driving licence.
Here "light trucks" are a separate, expensive, license, which is usually only taken for occupational reasons. Which is a good thing, since weight (and securing loads etc) has a massive impact on road safety.
3.5 tonns maximum total capacity right? Or net weight?
So a 3 tonne truck that can haul 1 tonne of goods for a total of 4 tonnes gross weight would be a need a truck license
AMD already spent a significant amount of effort implementing HDMI2.1 in their open driver in such a way that it would be compliment. The suits from HDMI consortium still said No.
https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected
AMD Linux engineers have spent months working with their legal team and evaluating all HDMI features to determine if/how they can be exposed in their open-source driver. AMD had code working internally and then the past few months were waiting on approval from the HDMI Forum... Sadly, the HDMI Forum has turned down AMD's request for open-source driver support.
AMD Linux engineer Alex Deucher commented on the ticket:
"The HDMI Forum has rejected our proposal unfortunately. At this time an open source HDMI 2.1 implementation is not possible without running afoul of the HDMI Forum requirements."
Are these trucks classified as cars or trucks in most EU country?
In Norway (EEA but not EU) they are trucks (due to weight and carry capacity), and require a C1 truck driving licence. Which helps keep the numbers low. Though there have been cases of importers downgrading the suspension to lower the maximum carry capacity to reclassify them so they can be driven on a normal car class B driving license.
For jpg's, no they will not get smaller. Maybe even a smidge bigger if you zip them. Usually not enough to make a practical difference.
Zip does generic lossless compression, meaning it can be extracted for a bit-perfect copy of the original. Very simplified it works by finding patterns repeating and replacing a long pattern with a short key, and storing an index to replace the keys with the original pattern on extraction.
Jpg's use lossy compression, meaning some detail is lost and can never be reproduced. Jpg is highly optimized to only drop details that don't matter much for human perception of the image.
Since jpg is already compressed, there will not be any repeating patterns (duplicate information) for the zip algorithm to find.
Schleswig-Holstein is shaking out to be such a good example of Proven Track Record ™️ for use of FOSS software in public administration, or any large organization really.
Anybody advocating for other public administrations to migrate can point loudly at Schleswig-Holstein that it's been done before and how to do it right. No more "that would never work" from the proprietary nay-sayers