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:
rust Vs c drama getting out of hand
I think (aka speculate) that the fact that Windows is the largest OS plays into the fact that Linux-Mac compatibility isn’t more developed.
I bet some 90% of desktop software is available on Windows (even many core KDE are on Windows!) so targeting them brings most Apple apps onto Linux “for free”. Especially since Apple’s insistence on trying to make Metal a thing hurts gaming support, which is a big driver behind Linux compatibility development.
The few applications that MacOS has over both Linux and Windows are usually so embedded into the Apple ecosystem that you’re not getting much by porting them anyway. iTunes? The App Store? Garage Band? Probably doesn’t help that many of those apps also use Apple’s own UI framework which isn’t really portable.
However, stuff not designed to live in Apple land like Teams for Mac or Adobe CC might be more possible. But still far too few applications to necessitate the effort to bring them over.
Pop is the only one that really ever makes any reference to windows in its marketing. I’m more talking about distros like Zorin which are targeting public sector orgs and windows users by bundling windows compatibility apps and features into the ISO.
The other examples definitely do also target “new users” which of course means Windows users too, but they aren’t explicitly tying their distros to Windows software compatibility the same way some are.
I did some reading in AV1 and it’s derivative formats - are they any more accessible to Linux than HEVC/H265? Fedora IIRC removed support for them and a few other codecs out of the box over some patent concerns or something.
Fucking hell you could cut the Reddit-tier snark with a knife.
BSD is more binary compatible than Windows. The fact there’s less MacOS ports on Linux seems to me like a lack of resources, but if you have a reason beyond 🤓☝️ then I’m genuinely interested.
MacOS still ships x86 builds, and most software either provides binaries for both platforms or some kind of universal/hybrid binary. Still a few years before that becomes an issue.
At some point an ARM->x86 translation layer is going to be needed too, regardless. It’s not long until ARM becomes popular enough to make it necessary to translate both ways.
Yup. Same issue will plague all Windows-alternative distros. Unless serious work is done to fix Microsoft 365 and Adobe creative cloud, there’s genuinely little benefit trying to claim Linux is an alternative for all but a minority of people.
That, or we can work on improving the alternatives to those apps. GIMP, Inkscape, and OnlyOffice are on a spectrum of laughably bad to just-about-comparable to their proprietary counterparts.
I don’t think it’s an insurmountable issue: I think there’s more we could do to bring Apple software to Linux (using a BSD-based kernel means a lot less complexity!) and with it the few applications that currently don’t play well with WINE.
Thing is, none of those advantages are real either, compared to a public database and API. Steam’s inventory API already maintains items beyond the lifetime of games, AND you can use items across other games. You can’t manipulate the Inventory of other games but I bet if there was demand (there isn’t) this could be implemented easily.
Google’s involvement is weird, not for any conspiracy reasons but because the chromium team previously cancelled JPEG-XL.
Genuinely surprised when I see people running mail servers without issue. I suppose getting in relatively early means you’re not immediately sent to junk mail lists by the big players.
the crew on the Ship of Theseus would like a word with you. Because if you strip out every subsystem and replace them with a different language, everyone would still call it Linux and it would still work as Linux.
Linux isn’t “a bunch of C code” it’s an API, an ABI, and a bunch of drivers bundled into a monorepo.
Rust’s memory safety is at compile-time. Java relies on a virtual machine and garbage collector. Nothing wrong with that approach but there’s a reason Rust is used in kernels and Java is used in userspace apps.
As an aside, the DRM and its support for the supposedly superior-on-linux AMD-powered devices is atrocious. I’ve had my laptop since January and it’s a model from 2023, but it still regularly has mega display corruption from memory mismanagement that might be improved from a certain language feature not offered in C.
DRM in this context (as mentioned by the other comment) is the interface between the userspace graphics drivers (Mesa, Nouveau, Nvidia etc.) and your graphics devices. It handles pretty much everything for rendering from displays to power management and memory synchronization, in a cooperative way that stops crashes due to race conditions, memory corruption etc.
Size isn’t an issue imo. Applications are bulky for many more reasons than their packaging formats.