Brilliant stuff. We need independence from Valve as much as Valve needs independence from Windows. This will only benefit all of us in the long run
Brilliant stuff. We need independence from Valve as much as Valve needs independence from Windows. This will only benefit all of us in the long run
Hi dad, I’m Brazil 💪😟💪
They sent people to his house
I’m Brazil
motherfucker had goons sicced on him
np! o7
rarbg mirrors are simply rehosting the database. You were even able to download and self host it for a while. Not sure if the tracker is able to accept new torrents though, I’m not really knowledgeable on how trackers work
We need colour! light themes aren’t meant to blind us!
Spotube uses the Spotify API for playlists but YouTube PipeAPI and other sources for music streaming.
Size isn’t an issue imo. Applications are bulky for many more reasons than their packaging formats.
Interesting, didn’t know it was feasible to make the distribution open.
That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.
Nothing in theory makes that an issue of flatpaks and snap, just that both rely on different means to interact with the host system that have been woefully slow to implement. If enough protocols are developed a flatpak or snap should be as capable as a native app with the safety benefits for free.
Honestly if not for the convoluted Linux FS layout, debs would be pretty serviceable and aren’t really different to the Windows solution. The fs layout makes installations way too fickle to clashing with other applications.
That and dependency hell, which distros should have never been allowed to touch beyond the core dependencies required to get your desktop running.
Nothing necessarily at the tech level. They’re more capable than Appimages or flatpaks to the point that you can use it to build a reproducible system hardened against tampering or defective updates.
The downside is that it’s controlled entirely by canonical, has limited abilities (if any?) for hosting storefronts/packages outside of their ecosystem, and said ecosystem is insecure and has already allowed multiple waves of malicious apps to reach end users because of poor moderation of listings masquerading as legitimate versions.
Canonical has also been increasingly hostile to flatpaks - removing it from Ubuntu and derivatives by default to push users towards snap.
The whole loopfs thing is just an annoyance, but the aggressive posturing by canonical as well as the closed nature of the storefront that has led to malicious attacks on end users is enough to give it more than a few haters.
I much prefer our modern package format solutions:
Yup. Some are pretty advanced now.
I’m joining the war on us Vs them
on the side of them
this is very cool.
one of the main issues with a lot of alternate kernels is the driver support. even a really impressive project like Redox is kinda limited to the hardware the maintainers can get their hands on.
Would this support that?
Lemmy dot world definitely doesn’t circlejerk, no siree.
Appreciate the detailed info here. Honestly does sound like Docker is the way to do it properly.
thanks for the info! :)
True, though for most game/graphics developers you’re never interfacing directly with the graphics API, you’ll let your chosen engine/library do the heavy lifting.
It does have the downsides of increasing the barrier to entry for custom/bespoke engines but those edge cases seem to be covered well by DXVK.
It’s a VPN thing. I have a work VPN that gives me the same error on piped API front ends like piped.video
If I use my regular device without a VPN the alt front ends work fine.