If I remember correctly they do have rollback, at least in openSUSE Aeon (the immutable version based on Tumbleweed) . It just using btrfs snapshots
If I remember correctly they do have rollback, at least in openSUSE Aeon (the immutable version based on Tumbleweed) . It just using btrfs snapshots
Not really. He isn’t just assosiated to the hyperland community, he is the leader of it and some if the offending stuff came directly from him.
The FDO was just warning him that if this type of behavior happened again, they wouldn’t be working with him anymore and he decided to throw a tamper tantrum. If this is how he reacts to “please don’t behave like a piece of s*** in the future”, why would the FDO even try to work with him? It’s just not worth the trouble.
This isn’t a new package manager, Fedora is already using dnf. This is just the next version of their current package manager.
PackageKit isn’t a package manager in the same sense as what I meant. It’s more like a one level above “front end” to be able to manage different package managers with the same program. This means that “Software Stores” that use packagekit like Gnome Software or KDE Discover will work on most Linux system with whatever package manager is used in the backend. For example on a Fedora Workstation, packagekit makes it possible to install, update and manage both rpm installed through dnf, Flatpaks and if I wanted, Snaps, while on a Debian based system it would be able to manage your apt stuff, or on Arch packages installed through pacman for example. But from what I heard this also makes it a somewhat clunky and slow piece of software that has become kind of clunky and hard to maintain over the years, so its also an interesting question whether Cosmic is going to use it.
I just realized that I haven’t read any infos about the package manager that Cosmic is going to use. Is it going to be build on top of Ubuntu like Pop!OS and use apt? Are the apps going to be served by the package manager or as Flatpaks? If the later, it could be interesting to public them on the Flathub Beta remote when they reach that stage.
Man this Missinformationen is hard to squash. Yes Flatpaks absolutely share libraries. These are called runtimes and are shared between all the Flatpak apps that use the same version of it. You will only get more than one version of a given runtime if some apps need this other version. For most runtimes that I know of, most only have 2 currently maintained versions, so I almost never get more than that on my system (and when I do, app devs tend to update their apps shortly after so that they’re using a maintained runtime). For example on my system where I mostly use GTK apps, I only have two versions of the Gnome runtime (44 and 45). And even when you have more than one version of a runtime, they get deduplicated, so even runtimes share parts between them.
If you’re interested here is an article about it.
As other have pointed out, saying that “no dependencies are shared” is a very missinformed take, given that sharing dependencies as runtimes is an integral part of Flatpak’s structure. But what makes it even funnier and more obvious that you don’t know what your talking about, is that you than cite Nix as something you “vastly prefer” when Nix actually deals with dependencies in a very similar way to Flatpak. From the official site:
You can have multiple versions or variants of a package installed at the same time. This is especially important when different applications have dependencies on different versions of the same package — it prevents the “DLL hell”.
In both Flatpak and Nix, apps will only download a different version of a dependency when they need it. This ensure that, instead of breaking, the app will work the same on any system (be it an old stable Debian or a bleeding edge Arch system), without requiring devs to create monkey patches that they have to maintain as things evolve. It has the potential to immensely reduce the burden on app devs and maintainers, and make it a lot easier to make apps for Linux.
By the way, if you guys are interested here is a talk comparing Appimages Snaps and Flatpaks by Richard Brown, one the devs at Suse, a big contributer to openSuse and the guy who spearheaded the Desktop variante of MicroOS (the immutable openSuse Tumbleweed).
He isn’t to keen on appimages either because of a miriad of technical issues.
And they explained why this opinion is kind of silly.
“I will not listen to anything this person has to say, because I don’t like a small and inconsequential part of their presentation” is not a great opinion to begin with, even ignoring the fact that this presentation might be necessary to reach a meaningful audience.
I’m going to assume you’re not doing this maliciously, as not all of those features and infos are easily discoverable so here are a few infos you might be interested in:
As for the statement “I’m not on mobile, this is a desktop”, I’m not sure what you mean. You do know that you can use just start typing in the overview to search for an app, file, settings, etc (what appears in the search can be edited in the settings)? Maybe I missunderstand what you mean, but I don’t see how the overview is in anyway something from “mobile”. In my opinion, the overview where you can manage your workspaces , open apps and quickly search and open new app, is the best thing Gnome made and is the reason why I and many other use it on Desktop. And if that is not for you, you can recreate a traditional desktop with extensions (Dash to Panel and Arc menu for example) or use KDE or Cinnamon, which are both amazing in their own right and perfected the traditional desktop.
It’s hilarious how, despite KDE apps being broken on every DE that isn’t plasma, people will still find a way to blame Gnome for it.
Contrarily to KDE, Gnome has managed to make sure that libadwaita apps look and work just like they’re supposed to and how its shown on the screenshot in the app store. You might not like the theme, but at least you knew what to expect before downloading, whatever distro you are on.
It’s great that KDE finally managed to fix their app so that they come with everything it need to function properly. People might be able to use them now on other DEs.