Canonical has announced a change in the packaging defaults for the various "flavours" like Kubuntu, Ubuntu MATE, Ubuntu Budgie and so on to exclude Flatpak and stick with Snap. Yes that's flavours, not flavors but also flavors in the announcement.
This is no doubt going to be a hot topic, because name me a more intense argument in the Linux world than packaging. While Flatpak has been gaining many fans lately, partly because it's included as the official way to install extra packages in Desktop Mode on the Steam Deck, Canonical are sticking to their own Snap.
So what's going on? In short: Ubuntu flavours will no longer have Flatpak enabled or setup by default. However, users can still do it themselves as they're not being removed from any repositories. It's all about the out of the box experience, with Canonical and the flavours now sticking to deb and snap to maintain their focus on what is actually properly supported by them and gets the most attention.
Users who have Flatpak installed won't see any changes, it's just the out of the box new-install experience as of April 2023, with the release of Ubuntu Lunar Lobster.
This is, after all, why we have different distributions isn't it? They're free to make whatever decisions they wish, and people who don't like it can go elsewhere, or just change the defaults to their liking — Linux is open and configurable unlike certain other systems. Do what you want.
So while it's going to be controversial, it's not exactly a big deal is it? Sort of. It's still making the desktop Linux experience quite messy, especially for newer users since there's no single way of installing things across different Linux distributions. You can't usually just point people to this thing and say get that, unless you first know the exact distribution they're on.
If you have thoughts you can comment on the announcement and let them know.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Now before people lose their cool over this, lets look at it from Canonical's perspective:
Canonical need to support their LTS versions of Ubuntu and the different flavors. That *includes* everything offered in the Snap store, since Snaps and the Snap store are officially supported.
Flatpaks are *not* officially supported, because Canonical doesn't run Flathub.
Flatpaks are not going away, they just aren't going to be officially supported (Use at your own risk sort of thing). Which is fine.
Ubuntu forks/spinoffs like Mint and Pop_OS will currently continue to support Flatpaks out of the box.
The flip side of the argument is that, if you don't want to be wrapped up in the Snap ecosystem, then Ubuntu and its flavors probably isn't going to be your Linux distro of choice anymore. Fortunately the Linux (and Ubuntu-based) ecosystem is rather large, and Ubuntu forks/spinoffs like Pop_OS and Mint are still a thing.
When discussing about these kind of things it's always the same vision Canonical doesn't share: Linux should develop into a platform, so it's *possible* to create software that will install and run on any Linux distribution if you know how to. But once again, no, Canonical works in the opposing direction. Śo, they don't want to support flathub? Fine, then don't add the repo, but the flatpak base software stack should be included on every desktop linux distro by default, there is no good argument against it.
0 Likes
I personally have no horse in this race, since I prefer tradicional packaging over Snap/Flatpack.I do too. Still have a smidge of an opinion about Snaps/Flatpaks though.
Also, since I'm not a Canonical hater, I also do not see any problem with this. Other distros don't promote Snap, so why Canonical had any obligation to support a competitor option?Is it really a "competitor option"? I don't think Flathub is maintained by some specific other distro company. My understanding of Flatpaks is that they are just an independent piece of software, like LibreOffice or something. If Canonical were to start considering the whole open source ecosystem to be "competition" they would have problems.
On the other hand, for every other distro, Snaps really are a "competitor option" since they're created and maintained by not just a particular distro, but by a for-profit corporation, and Snap as currently written works with just one repository, Canonical's. It probably would be do-able to change that, it's not like Snap stuff is closed source, but what's the motivation to bother? You'd have to fork it and maintain the fork because Canonical ain't gonna accept any patches to do that; it'd be a pain and a big controversy. So nobody else is ever going to seriously adopt Snaps, but any new distro has no problem including Flatpaks.
Basically, if Canonical's thinking about Snaps is just that they're a handy tool to be used by Canonical, then there's nothing wrong with their approach. If on the other hand they are imagining Snaps as a technology competing with Flatpaks and other packaging things in the broader Linux software ecosystem, they have kept them too closely attached to Canonical to be able to spread, and will fail.
Last edited by Purple Library Guy on 23 Feb 2023 at 4:21 pm UTC
7 Likes, Who?
If you're going to make that comment maybe it would have made more sense to be arguing with the person who actually mentioned Upstart . . .I'm not sure why Canonical doesn't want to have flatpak installed out of the box, but they sometimes do strange decisions, like Mir or Unity. Not bad projects but they were the only one using them and dropped them after some time.I'm not sure why people keep bashing Canonical of doing "bad" or "strange" decisions/projects all the time.
Upstart was there before anyone even heard about that second weird thing called systemd. But it is Canonical who is the bad guy yet again for choosing their own path?
Oh c'mon...
1 Likes, Who?
I love flatpak. I distro hopped for a year from ubuntu after they kept making it harder to use, and game on. Now I am on manjaro/arch/steamos. I use official packages when available, or install flatpak when it is not. Then it's AUR and SNAP as a last ditch effort.
1 Likes, Who?
I can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.
I wish that people would stop bringing up Upstart in discussions like these. Upstart predates systemd by 4 years and was at the time the best candidate to replace the ancient SysVinit which is why many, including Red Hat and Chromebooks, move over to Upstart.
The same is also true of snaps, Mir, and Unity. Snaps predate flatpaks and have features that flatpaks still lack. Wayland wasn't (and still isn't) a good choice for phones since it's for the desktop. There (still) isn't a convergent desktop environment that will work across phones, netbooks, tablets and the desktop, which was the aim of Unity.
Canonical's problem is that they want to push things forward but don't have Red Hat (IBM now) money.
4 Likes, Who?
Just Canonical being Canonical to be honest. It's usual game for them.
Lest we forget:
Wayland vs Mir
Unity vs Gnome
Upstart etc and so on
Really this is nothing new. Canonical has always made a product and project while excluding the other distributions in the design process just to avoid adding code upstream and then thrown their teddy out the cot when people don't use it.
Nothing to see here folks, move along
Give it a few years, they'll have flatpak again.
Last edited by BlackBloodRum on 23 Feb 2023 at 5:10 pm UTC
Lest we forget:
Wayland vs Mir
Unity vs Gnome
Upstart etc and so on
Really this is nothing new. Canonical has always made a product and project while excluding the other distributions in the design process just to avoid adding code upstream and then thrown their teddy out the cot when people don't use it.
Nothing to see here folks, move along
Give it a few years, they'll have flatpak again.
Last edited by BlackBloodRum on 23 Feb 2023 at 5:10 pm UTC
2 Likes, Who?
Just Canonical being Canonical to be honest. It's usual game for them.
Lest we forget:
Wayland vs Mir
Unity vs Gnome
Upstart etc and so on
Really this is nothing new. Canonical has always made a product and project while excluding the other distributions in the design process just to avoid adding code upstream and then thrown their teddy out the cot when people don't use it.
Nothing to see here folks, move along
Give it a few years, they'll have flatpak again.
I'm not hostile to that complany at all. In fact I'm thankful to that company, Ubuntu made me stay with Linux in the early 2000s, after several failed attempts with other distros. The first Ubuntu releases really were a lot more usable then anything I had tried before. My fascination for Linux made me look into game development. That made me cancel my PhD in molecular genetics and go for an entirely new career in IT and I'm still very happy with that decision.
Yet when I see them make another decision that shows they don't feel like agreeing to standards or being a part of the community, I will criticize that. They are still among the biggest distros and if they don't adhere to standards, they better have a good reason.
I don't see that reason here. For as long as I can think, Linux needed a way for 3rd partys to provide (e.g. closed source) applications directly to their users. Not to replace repos, but to make desktop linux a platform. Now here we finally are. No company can still say they can't provide software because of .deb, .rpm..., flatpak has proven it's worth. And now Canonical comes in and goes no, not with us. It's damn frustrating.
2 Likes, Who?
When discussing about these kind of things it's always the same vision Canonical doesn't share: Linux should develop into a platform, so it's *possible* to create software that will install and run on any Linux distribution if you know how to. But once again, no, Canonical works in the opposing direction. Śo, they don't want to support flathub? Fine, then don't add the repo, but the flatpak base software stack should be included on every desktop linux distro by default, there is no good argument against it.The one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.
That's as far as I'm going to defend Snap though. There's a LOT about it I do not like, and I actively avoid using Snaps whenever possible.
Canonical is drawing a line in the sand, and they have their reasons. That's their choice, and it's our choice whether we agree with it or not.
0 Likes
dziadulewicz 23 Feb 2023
Please read this response from a developer to understand this decision better. It makes perfect sense and no need to raise pitchforks yet again: https://discourse.ubuntu.com/t/ubuntu-flavor-packaging-defaults/34061/9
"As a developer, it might help to see a bit of the standpoint I have on this issue, as I actually agree with the decision to not include Flatpak by default. I may simply be reiterating what @kewisch has already said, but I don’t have to talk in “official language” so it might be a bit easier to swallow.
It may be easily overlooked, but one of the core features of Ubuntu is that package versions change very, very rarely. If at all possible, bug fixes are taken from the (openly viewable) source code of an application, carefully tweaked to make them compatible with an older version of the software, patched in, tested, and only then deployed. There are a few packages where this is impractical (Firefox for instance), and there are some closed-source packages in the Restricted repo that we can’t backport patches into since we don’t have the code. But for the most part, if you install an app into Ubuntu, that’s the app you get, and that will be the app you continue to use for the rest of that release’s lifespan.
This is a powerful feature since it makes Ubuntu unlikely to randomly break your important data as often as that other OS that you hear get a lot of grief from Linux geeks, but it also requires that Canonical and the Ubuntu community have near-total control over the software repository.
That’s only possible if Canonical actually has the necessary control.
Canonical does have total and complete control over the Ubuntu archive that apt uses. And Canonical has total and complete control over the Snap repository. If something goes wrong and Canonical must step it, they can.
But Canonical has zero control over the Flatpak repositories. They do not host a Flatpak repo of their own (Snap does the near-equivalent job), nor do they control Flathub or any of the other Flatpak repos (at least as far as I know). This means that if something goes awry with a Flatpak, the user is pretty much left to figure it out for themselves.
What’s worse, most of the Ubuntu flavors (and Ubuntu itself) provide free technical support via forums and IRC channels. Most of our users are using software from the Ubuntu repos or Snap Store and we are equipped to help them. We know what to expect from the software our users run and can give targeted and efficient advice on how to resolve issues. Some of us can even kick things into shape in the archives if there’s a legitimate problem with our packages, or we know who to talk to.
With Flatpaks, the situation is much more dismal from a technical support perspective. We have little-to-no clue what quirks the software vendor(s) will have introduced since we don’t work closely with them. We have no way to reach in and fix legitimate bugs aside from filing bug reports and hoping that they will be answered. We’re going to end up with frustrated support staff and even more frustrated users. And all because they didn’t know that if they clicked a particular button in their flavor’s app store, they would be downloading unsupported software.
Yuck. No thanks.
Ubuntu provides plenty enough software for most people in the apt archives and in the Snap Store. In the rare instances that someone needs a Flatpak, they have to go out of their way to enable Flatpak support, which gives them a clue that what they’re doing might not end well. If they enable Flatpak, install an app, it fails, and then they come ask for help, they’ll at least expect it when we say “sorry, we don’t support Flatpaks, that’s why they require extra steps to enable”. They’re exactly like PPAs from an Ubuntu support perspective. And I’m sure we can agree that providing official support for arbitrary PPAs is a bad idea.
That, in a nutshell, is why Canonical and the Ubuntu flavors have gone ahead and agreed to not include Flatpak on the default ISOs, at least as I understand it. As a regular supporter in the IRC channels and many of the Ubuntu-related forums, I heartily agree with this decision.
(For the record, I don’t hate Flatpaks, just like I don’t hate PPAs. In fact I have Flatpak enabled on my personal system and have nn app installed from Flathub that I use. I just don’t expect that the official Ubuntu support venues are going to help me if that app goes berzerk.)"
"As a developer, it might help to see a bit of the standpoint I have on this issue, as I actually agree with the decision to not include Flatpak by default. I may simply be reiterating what @kewisch has already said, but I don’t have to talk in “official language” so it might be a bit easier to swallow.
It may be easily overlooked, but one of the core features of Ubuntu is that package versions change very, very rarely. If at all possible, bug fixes are taken from the (openly viewable) source code of an application, carefully tweaked to make them compatible with an older version of the software, patched in, tested, and only then deployed. There are a few packages where this is impractical (Firefox for instance), and there are some closed-source packages in the Restricted repo that we can’t backport patches into since we don’t have the code. But for the most part, if you install an app into Ubuntu, that’s the app you get, and that will be the app you continue to use for the rest of that release’s lifespan.
This is a powerful feature since it makes Ubuntu unlikely to randomly break your important data as often as that other OS that you hear get a lot of grief from Linux geeks, but it also requires that Canonical and the Ubuntu community have near-total control over the software repository.
That’s only possible if Canonical actually has the necessary control.
Canonical does have total and complete control over the Ubuntu archive that apt uses. And Canonical has total and complete control over the Snap repository. If something goes wrong and Canonical must step it, they can.
But Canonical has zero control over the Flatpak repositories. They do not host a Flatpak repo of their own (Snap does the near-equivalent job), nor do they control Flathub or any of the other Flatpak repos (at least as far as I know). This means that if something goes awry with a Flatpak, the user is pretty much left to figure it out for themselves.
What’s worse, most of the Ubuntu flavors (and Ubuntu itself) provide free technical support via forums and IRC channels. Most of our users are using software from the Ubuntu repos or Snap Store and we are equipped to help them. We know what to expect from the software our users run and can give targeted and efficient advice on how to resolve issues. Some of us can even kick things into shape in the archives if there’s a legitimate problem with our packages, or we know who to talk to.
With Flatpaks, the situation is much more dismal from a technical support perspective. We have little-to-no clue what quirks the software vendor(s) will have introduced since we don’t work closely with them. We have no way to reach in and fix legitimate bugs aside from filing bug reports and hoping that they will be answered. We’re going to end up with frustrated support staff and even more frustrated users. And all because they didn’t know that if they clicked a particular button in their flavor’s app store, they would be downloading unsupported software.
Yuck. No thanks.
Ubuntu provides plenty enough software for most people in the apt archives and in the Snap Store. In the rare instances that someone needs a Flatpak, they have to go out of their way to enable Flatpak support, which gives them a clue that what they’re doing might not end well. If they enable Flatpak, install an app, it fails, and then they come ask for help, they’ll at least expect it when we say “sorry, we don’t support Flatpaks, that’s why they require extra steps to enable”. They’re exactly like PPAs from an Ubuntu support perspective. And I’m sure we can agree that providing official support for arbitrary PPAs is a bad idea.
That, in a nutshell, is why Canonical and the Ubuntu flavors have gone ahead and agreed to not include Flatpak on the default ISOs, at least as I understand it. As a regular supporter in the IRC channels and many of the Ubuntu-related forums, I heartily agree with this decision.
(For the record, I don’t hate Flatpaks, just like I don’t hate PPAs. In fact I have Flatpak enabled on my personal system and have nn app installed from Flathub that I use. I just don’t expect that the official Ubuntu support venues are going to help me if that app goes berzerk.)"
6 Likes, Who?
The one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.Um . . . I can kind of see how Flatpak might only work for userland software. And I can see how Flatpak itself might have only GUI-based installation software, and no CLI-based tool for installing Flatpaks. But I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.
Last edited by Purple Library Guy on 23 Feb 2023 at 7:05 pm UTC
1 Likes, Who?
I can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.
Except that this time around they are betting on the right horse. snap is more mature than flatpak (gives the user more granular control over permissions, can be used for cli apps, can be used for non-sandboxed apps, can be used with system services, etc), snapcraft is more mature than flathub (it takes me 10 minutes to update flatpak vs the less than a minute snap takes to update), and snap has much wider adoption from 3rd party app vendors.
1 Likes, Who?
But I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.If Flatpak supports CLI software, that would be welcome news to me.
I don't have a technical answer why it couldn't.
0 Likes
If they are betting on a horse at all, then I think it's the wrong one, not because of anything about the technology itself, but precisely because it is theirs. Their control, as I said in another comment, is too tight for it to get more widely adopted by other distros. And it seems they're quite open and clear about the importance to them of close control over the technology and packages built by it, as noted in the long developer quote posted by dziadulewicz. The only way Snaps become dominant is if Ubuntu grows and displaces the use of most other distros. And while there was a time when that seemed like it might happen, I feel that time has passed.I can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.
Except that this time around they are betting on the right horse. snap is more mature than flatpak (gives the user more granular control over permissions, can be used for cli apps, can be used for non-sandboxed apps, can be used with system services, etc), snapcraft is more mature than flathub (it takes me 10 minutes to update flatpak vs the less than a minute snap takes to update), and snap has much wider adoption from 3rd party app vendors.
But I'm not convinced Canonical are "betting on a horse" at all. Apparently, they want a technology they can tightly control so they can release tightly controlled packages that will allow them to maintain very high stability (again, as quoted in dziadulewicz's post on p 3 of this discussion). As long as they get to use it to do that, I'm not sure Canonical care if Snaps are adopted anywhere else. It's fair enough, although I don't entirely approve of the attitude, which might be OK for Ubuntu but seems like it will promote fragmentation of Linux and not strengthen the overall platform in the long term.
2 Likes, Who?
Well.. I know I'm the village idiot and all, but I'll try and explain it to as I knowThe one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.Um . . . I can kind of see how Flatpak might only work for userland software. And I can see how Flatpak itself might have only GUI-based installation software, and no CLI-based tool for installing Flatpaks. But I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.
1) You can manage and install flatpak applications via CLI without any GUI software, in fact that's how I always manage them
List of options, based on the output of: flatpak --help:
Usage:
flatpak [OPTION…] COMMAND
Builtin Commands:
Manage installed applications and runtimes
install Install an application or runtime
update Update an installed application or runtime
uninstall Uninstall an installed application or runtime
mask Mask out updates and automatic installation
pin Pin a runtime to prevent automatic removal
list List installed apps and/or runtimes
info Show info for installed app or runtime
history Show history
config Configure flatpak
repair Repair flatpak installation
create-usb Put applications or runtimes onto removable media
Find applications and runtimes
search Search for remote apps/runtimes
Manage running applications
run Run an application
override Override permissions for an application
make-current Specify default version to run
enter Enter the namespace of a running application
ps Enumerate running applications
kill Stop a running application
Manage file access
documents List exported files
document-export Grant an application access to a specific file
document-unexport Revoke access to a specific file
document-info Show information about a specific file
Manage dynamic permissions
permissions List permissions
permission-remove Remove item from permission store
permission-set Set permissions
permission-show Show app permissions
permission-reset Reset app permissions
Manage remote repositories
remotes List all configured remotes
remote-add Add a new remote repository (by URL)
remote-modify Modify properties of a configured remote
remote-delete Delete a configured remote
remote-ls List contents of a configured remote
remote-info Show information about a remote app or runtime
Build applications
build-init Initialise a directory for building
build Run a build command inside the build dir
build-finish Finish a build dir for export
build-export Export a build dir to a repository
build-bundle Create a bundle file from a ref in a local repository
build-import-bundle Import a bundle file
build-sign Sign an application or runtime
build-update-repo Update the summary file in a repository
build-commit-from Create new commit based on existing ref
repo Show information about a repo
Help Options:
-h, --help Show help options
Application Options:
--version Print version information and exit
--default-arch Print default arch and exit
--supported-arches Print supported arches and exit
--gl-drivers Print active gl drivers and exit
--installations Print paths for system installations and exit
--print-updated-env Print the updated environment needed to run flatpaks
--print-system-only Only include the system installation with --print-updated-env
-v, --verbose Show debug information, -vv for more detail
--ostree-verbose Show OSTree debug information
2) Technically you can access a flatpak applications CLI. It's a little complex. But it can be done.
For a CLI only application, you could in theory just do "flatpak run org.app.Command -o options" or stick an alias for this in your local rc file to just have "command -o options".
You can also access a shell within a flatpak applications sandbox by doing: "flatpak run --command=sh --devel org.app.Command" and so on.
Typically you'd only do this for debugging.
More on that here:
https://docs.flatpak.org/en/latest/debugging.html
3) Often the complaint is not that flatpak cannot do CLI-only applications but rather, flatpak can't be used to install some more deeper system applications, for example a system wide daemon.
And lastly, there's lots of FUD being spread about flatpak out there by people who don't know it, use it, or understand it.
2 Likes, Who?
I can't say I have a stake in this, but it's interesting to ponder that Ubuntu seems to have a habit of betting on the wrong horse, Mir and upstart, for example.
I wish that people would stop bringing up Upstart in discussions like these. Upstart predates systemd by 4 years and was at the time the best candidate to replace the ancient SysVinit which is why many, including Red Hat and Chromebooks, move over to Upstart.
The same is also true of snaps, Mir, and Unity. Snaps predate flatpaks and have features that flatpaks still lack. Wayland wasn't (and still isn't) a good choice for phones since it's for the desktop. There (still) isn't a convergent desktop environment that will work across phones, netbooks, tablets and the desktop, which was the aim of Unity.
Canonical's problem is that they want to push things forward but don't have Red Hat (IBM now) money.
And they did plan to use Wayland, and if I don't remember wrong they where about to be the first distro to use it (just like they where the first to use Pulse) but then they discovered that it wasn't fully functional yet so they moved that back and started to work on bringing Mir to the desktop instead.
People also tend to forget the sorry state of Gnome 3.0 when it was released that made every distro out there either keep using the old Gnome 2.0, switch to something else or create something new like MATE or Unity.
And now again people are up in arms because some variant of Ubuntu will not default install flatpack, while it will remain in repos so any one that wants it can install it. Sometimes our community is worse than The People's Front of Judea.
3 Likes, Who?
cameronbosch 23 Feb 2023
So while it's going to be controversial, it's not exactly a big deal is it?
For the intended audience of desktop Ubuntu editions, that actually will be. Most of those users won't think to install Flatpak, which means they'll get less apps and ones that open slower than Flatpaks.
That pretty much leaves me on KDE Arch-based distros for the foreseeable future. Kubuntu & Ubuntu Studio are now officially out of consideration.
0 Likes
pleasereadthemanual 23 Feb 2023
Is it really a "competitor option"? I don't think Flathub is maintained by some specific other distro company. My understanding of Flatpaks is that they are just an independent piece of software, like LibreOffice or something. If Canonical were to start considering the whole open source ecosystem to be "competition" they would have problems.I think there is a disconnect between your two arguments here. Libreoffice is shepherded by Collabora; they sell support/development services for it, so I don't think that's a great example. But also, businesses can sell services for free software (and sell free software on its own as Ardour does, though this is rarer), so doesn't it make sense that anybody who offers a service which competes for their market is a competitor, regardless of whether they're earning money from it? I mean, Amazon lost money for years so they could service more of the market than competing companies.
On the other hand, for every other distro, Snaps really are a "competitor option" since they're created and maintained by not just a particular distro, but by a for-profit corporation, and Snap as currently written works with just one repository, Canonical's.
And businesses can also sell competing services for the same software. Mumble is a great example of this. You'll see a lot of businesses offering Mumble servers.
I know there's a sense that free software organizations aren't competing with each other, and the fediverse is a good example of the collaboration that's possible between developers, but even if you aren't competing for profit, you can be competing for something else. Namely, funding. I seriously doubt anyone is going to consider funding Cinelerra-GG, because it has such a small slice of the market. Cinelerra got funding ~20 years ago when it was the only kid on the block, but Kdenlive, Olive, and Blender VSE are much more likely to get funding in these times because of their market share.
Even outside of free software, businesses will gleefully partner with companies in different industries for joint ventures, so cooperation and 'standing on the shoulders of giants' is not something unique to the free software community.
0 Likes
The only way Snaps become dominant is if Ubuntu grows and displaces the use of most other distros.
This is not necessarily true. Snaps are independent from Ubuntu. If you go to the snap store you'll see no Ubuntu branding there. Canonical is marketing snap as a Linux store, not as an Ubuntu store, much like Steam is a Linux gaming store regardless of which distro you're using. So, if people have no problem installing Steam, which is proprietary and tightly controlled by Valve, why would they have problem installing snap, which at least has an open source client?
4 Likes, Who?
stupid canonical being stupid.
who use package managers in 2023 anyway? we have steam!
seriously, shit like this will only harm canonical and linux in general, the only consistent way to install things on linux is using proprietary softwares like steam.
i think its time to find another distro, im tired of distro hopping, so i sticked with ubuntu for a while, but my patience have limits.
who use package managers in 2023 anyway? we have steam!
seriously, shit like this will only harm canonical and linux in general, the only consistent way to install things on linux is using proprietary softwares like steam.
i think its time to find another distro, im tired of distro hopping, so i sticked with ubuntu for a while, but my patience have limits.
1 Likes, Who?
ElectricPrism 24 Feb 2023
Free Vendor Lock? Pass.
Glad I dumped Ubuntu on my servers.
Last edited by ElectricPrism on 24 Feb 2023 at 2:23 am UTC
Glad I dumped Ubuntu on my servers.
Last edited by ElectricPrism on 24 Feb 2023 at 2:23 am UTC
0 Likes
Patreon
PayPal
An idiots guide to setting up Minecraft on Steam Deck / SteamOS with controller support
How to install extra software, apps and games on SteamOS and Steam Deck
See more from me