I’m not sure how this is in any way different from android? Android is free software they use to restrict the computing they devices they sell to push more ads and junkware. This is just a different one. Amazon sucks, so I don’t see what move they could make that could be seen as positive. Just don’t buy their garbage devices.
So despite the desire for one, Vega won’t be an Android-killer, won’t bring an influx of big name apps to benefit regular Linux distros, nor see Amazon do something crazy cool like create its own Linux tablet UI.
You know how much overhead Electron apps are? Well, here’s React Native! Enjoy all the annoyances of mobile development with the ugliest that is React!
It actually works pretty great, it genuinely does compile to native code pretty well. The js code just drives - everything visual or I/O is native, so it’s faster than you’d think
Idk if I’m the only person who thinks this, but I feel like React has gotten worse over the last couple of major versions. Not only does the code look a lot messier when you use their new syntax, but the end result seems unreliable. Facebook is barely even usable now. Their history management is laughable, and it’ll drop you out of the site randomly when using the back buttons. I used to think React was really neat, but I’m not a big fan anymore. There’s too much re-engineering for problems that were solved decades ago.
If you like it, then use it. There’s no point in jumping every time some new framework comes out. Most of them don’t last. I have used React off and on since it came out, and I personally don’t like how the syntax has changed. My personal website is React and doesn’t have any browser history issues. Idk what’s up with Facebook history management. I guess they just don’t care very much because they’re too busy trying to gobble up data.
React is having the same problems Angular had, and jQuery had. New ECMAscript features make formerly complex things easier, and JS frameworks adapt.
Lots of solutions. But as more edge cases start to show up, they continue to add more and more little things that shape the language into more different variants.
Many of the changes are pretty good. But New devs will go, “Why are there 7 ways to do this React thing?” And that adds to the noise.
Again, that’s not a React problem. It’s just coding in general. PHP also had a “damn you ugly” phase. But unlike PHP, I don’t think React (and most JS frameworks of today) will continue to be as popular as some hot new JS framework in 2027-2030 sweeps the landscape.
And PHP will still be chugging along. lol. It’s weird that React syntax went from being fairly pretty, and structured, to looking like a plate of spaghetti. Usually languages and frameworks go the other direction.
I love how PHP 7 looks, and PHP 8 only continues to improve.
Totally agree. React is going backwards. Vue is so attractive. Heck, I’m even starting to rebuild react apps in Web components because react is getting weird.
This is a big issue with Snap. It may be like Flatpak, allowing devs to set their own dependencies for ALL distros, but its poor uptake outside of Ubuntu’s ecosystem means that it’s no different to yet another distro repackaging system.
Flatpak, or even Nixpkgs, are the future because they allow devs to have control over the distribution of their software. Snap being such a closed ecosystem in comparison only means it will replicate many of the problems we’ve found with traditional (re)packaging systems.
I can’t speak for Flatpak as I haven’t tried it but nixpkgs are beautiful to work with and configuration of my system has become completely reproducible in a clean format.
As a dev, you can just distribute a nixpkg with whatever build tool inside. That beats the current system of “native” packages where your software is repacked and then maintained by half a dozen teams for different distros that use different dependencies and update cadences.
Bottles has gone as far as to demand its fedora package be removed and now shows a warning if you’re not using the flatpak version because repackers just don’t properly test all their software (how can they? there are thousands of apps in these repos!)
nix is a “native” packaging format. Apps are compiled for your host OS and run in that environment with no restrictions, for better or worse.
Flatpaks are containers. They provide a virtual OS to the application such as the file system, and accessing host OS features is done through “portals” which just means you can give/revoke the ability of the app to access your host OS resources such as networking, file access etc.
Flatpaks are therefore much safer in theory. But Nix packages are lower overhead, and can interact like any built-in software binary that you’d have when you spin up a fresh install of, say, debian.
Nix packages are harder to use IMO thanks to their poor documentation and lack of GUI package manager support (not that it’s impossible, just that it’s been a niche system for most of its life) and since most people are accustomed to flatpaks and their permissions system (and the fact it comes preinstalled on most distros) so flatpak is still pretty ubiquitous, even for NIxOS users
Snaps were designed to solve dependency hell, get modern software, security, among other issues. If it weren’t for the fact Flatpak does a better job, many more people would be praising Snap.
It’s good that Canonical is trying to make the desktop better. It would be better if they focused their efforts elsewhere.
I run all headless Linux machines, and snapd always managed to show up somehow. It’s got shared lib dependencies so that shit like Firefox would be installed and have snap mount points on my machine. Just a bunch of useless noisy garbage on a headless machine. I finally solved the problem by switching to Debian.
I don’t care what flatpak does or does not do, IMHO snap sucks objectively.
Flatpak is intended for end-user graphical applications, not many terminal applications are packaged by Flatpak so it makes sense why it wouldn’t show up. Snap IIRC was first intended for their embedded system.
Amazon can’t make TVs or ereades without filling them to the brim with ads and spyware like the greedy shits they are, I dont want to think about how screwed up their OS would be. As much as I sneer at Microsoft and windows BS as a snobby Linux user I get the impression amazon would be way worse and make Ol Gatey boy say ‘have a little class, would you?’
If anything, it’ll be a thing where amazon ends up close sourcing the code/parts that they create after forking whatever OS they decide. That, or they’ll just close source the entire codebase 100% before release without any regard or repercussions.
it won’t take long for someone to build a Wamazon Linux distro with all the features and none of the crap.
I don’t know what “features” Amazon would include that aren’t somehow directly tied into their store and ease of shopping…aka “crap.” It’s not like they would build a better video/audio driver or something. It would all just be more…advertising and analytics, probably on a cheap platform as hardware has never been their largest source of income, to include Kindles (AWS is, last I checked). Strip those two out of their build and we have essentially an untouched kernel lol, at least that’s how I see it happening.
Ubuntu used to get a lot of undeserved hate but lately the hate feels deserved. Ubuntu has been the face of the usable desktop Linux for a long time and they just keep tripping over themselves every time they try to move forward.
Their intentions are usually good. A lot of things they propose usually end up being adopted by the community at large (just not their implementation). They seem to just yank everyone’s chain a little too hard in the direction we’re eventually going to go and we all resent them for that.
Off the top of my head, there was Upstart (init system), there was unity (desktop), and now snaps (containerized packaging). All of these were good ideas but implemented poorly and with a general lack of support from the community. In almost each case in the past what’s happened is that once they run out of developers who champion the tech, they eventually get onboard with whatever Debian and Rhel are doing once they were caught up and settled.
Valve’s lack of interest in maintaining the snap makes sense. The development on the Ubuntu platform is very opinionated in a way where the developers of the software (valve) really want nothing to do with Canonicals snaps.
On another note: my favorite thing about the Ubuntu server was LXD + ZFS integration. Both have been snapified. It was incredibly useful and stable. Stephane Graber has forked the project now into INCUS. It looks very promising.
This might be an unpopular opinion but I really don’t get this trend of wanting to containerized just about everything, it feels like a FOTM rather than doing something that makes sense.
I mean, containers are fantastic tools and can help solve compatibility problems and make things more secure, especially on servers, but putting everything into containers on the desktop doesn’t make any sense to me.
One of the big advantages Linux always had over Windows is shared components, so packages are much smaller and updating the whole system is way faster, if every single application comes with its own stuff (like it does on Windows) you lose that advantage.
Ubuntu’s obsession with snaps is one of the reasons I stopped using it years ago, I don’t want containers forced upon me, I want to be free to decide if/when to use them (I prefer flatpack and appimage).
Debian derivatives that don’t “reinvent the wheel” is the way to go for me, I’ve been using Linux MX on my gaming desktop and LMDE on laptop for years and I couldn’t be happier, no problem whatsoever with Steam either.
Shared components work brilliantly in a fantasy world where nothing uses new features of a library or depends on bug fixes in new versions of a library, and no library ever has releases with regressions or updates that change the API. That’s not the case, though, so often there’ll exist no single version of a dependency that makes all the software on your machine actually compile and be minimally buggy. If you’re lucky, downstream packagers will make different packages for different versions of things they know cause this kind of problem so they can be installed side by side, or maintain a collection of patches to create a version that makes everything work even though no actual release would, but sometimes they do things like remove version range checks from CMake so things build, but don’t even end up running.
Shared containers work beautifully for a lot of things, though, many programs aren’t all that sensitive either. Making snaps for the tricky ones makes sense. Having snaps for all of them is ridiculous.
I can count the software requiring repo-pins on one hand on my desktop. For those, snaps make sense, replacing the need for any pins. Snaps are less confusing than pins. IMO.
It reminds me of Python programming, with requirements pinned to version ranges. Some dev-teams forget, and their apps won’t work out of the box. Sometimes, software still works ten years later, if they only use the most common arguments and commands from the packages.
I agree with a lot of your points but I do think containers a great solution.
I’ve been a really big fan of Universal Blue lately. It presents a strong argument for containerizing everything. Your core is immutable and atomic which makes upgrades seamless. User land lives in a container and just gets layered back on top afterwards.
I do think the idea behind snap isn’t all about pushing the Linux platform as such forward, but to specifically gain a market advantage to Ubuntu.
Why else is finding documentation for changing the default store so difficult? And I don’t think you can even have multiple “repositories” there–quite unlike all other Linux packaging systems out there. (Corrections welcome!)
These tentacular megacorporations are a problem. Amazon is OK as a merchant, MS as an OS developer, Google as a search engine… If they do vertical integration the market is corrupted.
Vertical integration is when you control the entire product, in consumer electronics Apple is the gold standard; they make the software, hardware, and processors then integrate them into iPhones and macBooks. Tesla is a good example in the automotive space, their goal with the mega-factories is "raw materials in, cars out" and they work to build as many of the parts themselves as possible.
Alternately Microsoft just makes a good enough OS that runs on good enough hardware from commodity vendors, so you get good enough computers. Most auto makers buy good enough components from 2nd and 3rd tier suppliers and integrate them into good enough cars.
That is a great explanation of what vertical integration is. I am not sure I see why it is inherently bad.
I guess a large vertically integrated option could make it hard for alternatives to compete. That is more of a monopoly problem than a vertical integration issue though.
I do agree with interoperability requirements though. I see nothing wrong with Apple offering a fully vertically integrated product. The issue is when I cannot run my own OS on the hardware, my own apps on their OS, or interact with hardware from other vendors.
But that’s exactly the problem. If the company is kind about it, or forced to play nice by effective regulation, there’s no issue. But if there’s no regulation and the company wants to, it tends towards monopolistic tendencies. And there’s nothing that incentivizes a company to play nice forever, in fact they’re incentivized to maximize profit. So Vertical Integration is bad without being checked.
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
This would ensure security, as well as a proper functioning flatpak/snap and also all feedback would be directed to the Dev.
I’ve never liked the fact that Canonical and whoever can make Snaps and Flatpaks of other people’s software. There is zero security guarantee, zero guarantee they’ll update it and zero guarantee it will work.
Just because Snap and Flatpak exist doesn’t mean just anyone should be able to just make them.
If Valve only chooses to make a deb then so be it! It’s their product!
The problem is that 3rd parties are doing the packaging both on Snap and Flatpak whereas if they had followed proper security practice ONLY THE REAL DEV should ever be allowed to package their app as a Flatpak or Snap.
Says who? If it were the case, Linux would either be a nightmare of fragmentation or become centralised on one distribution. Distros need to be able to package their own software, and these are kind of like distributions. Also since we’re talking about proprietary software here, is it really any better security practice if the “real dev” packages it or somebody else, they both could contain malicious code.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
The distros should stick to packaging their repo apps and leave the Snap/FlatPak tech as an alternative to the original dev if they decide they want to use that.
We can’t have Bob from nowhere packaging Valve, then not updating it or patching it because he doesn’t have time. Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.
It’s crazy. This is what causes fragmentation. Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
Valve are not going to put malicious code on their app. Neither is VLC or any other FOSS developer.
How would you know that? It’s not like it’s something that doesn’t happen.
Or 5 Bob’s all doing the same thing with 5 copies of Valve on the Store.
It’s crazy. This is what causes fragmentation.
I don’t know what snaps are like but that’s clearly a non-existent problem on Flathub.
Flathub should vet every app and if you are not the dev of the app, you may not host it on Flathub. You’re still welcome to make a Flatpak for home use on your own pc but not for wide distribution.
I don’t know why you feel like there’s permission involved. You don’t have to use Flathub, therefore Flathub can have what ever policies it likes. Users can set up a different flatpak repo if there’s a need.
That’s not my point. I use Flathub but I try to only use verified apps which were packaged by the actual dev.
I’d rather get a deb from the official dev than a flatpak from flathub packaged by someone who is essentially anonymous and could easily inject malicious code.
If you think the dev himself could inject malicious code in the official app, then you should be super aware that an anonymous Joe can too, and is far more likely to.
Anyway flatpak ideally was supposed to save Devs the work of packaging for every distro so it makes sense that the real actual verified dev of the app would package the flatpak/snap himself
The official Developer of the app. E.g. the official dev of Blender is blender.org. The flatpak people give them a line of code to embed in their website and they use that to verify that the dev really is blender.org and not a malicious actor.
How so? How does ensuring they only the real dev of the app is also the only one allowed to package it hurt desktop adoption.
It’s very easy to enforce. Flathub need to verify the identity of the person submitting the Flatpak to make sure it’s the app’s dev uploading it and not Joe Smith or nsa.gov…
Good luck getting all the developers to rewrite their apps. The only reason you had any apps was because it was based on Android so it was little to no effort to port. Going plain ol’ embedded Linux is basically the death knell of your developer story. Source: been there, had no third party apps, switched to Android
Oh man PWA as a replace to traditional apps have been promised for a while. On one hand the promise of write once run anywhere on the other less ability to lock down your app from your users (good for us, but not popular in the mobile space at the moment)
You’re likely thinking KaiOS. They are still contributing what is required under MPL-2.0 but the rest is proprietary. KaiOS 3.x finally got off of a browser from 2016 as the base, but very few have upgraded their apps to be compatible (the tweaks were minor) & others have used it as a reminder that they were still ‘supporting’ a platform like whoever is maintaining or using that WhatsApp thing for chat.
There’s also Capyloon built from B2G, but it’s still early on & is targeting touch phones, instead of feature phones.
It would be nice to see it around IMO since it’d just be another enhancement to progressive web applications & JavaScript is a better target than Java or Swift.
PWAs are great if they’re written well, especially if they allow offline access.
There’s platforms like React Native where the apps are native on each platform (they use native UI widgets). You can’t just run the same code, but you can reuse probably 90-95% of code across platforms.
omgubuntu.co.uk
Top