Language Selection

English French German Italian Portuguese Spanish

A Merge Proposal to ‘Drop Snap Support’ from GNOME Software Hints at Deeper Divisions

Filed under
GNU
Linux
GNOME
Ubuntu

As you probably know, Ubuntu Software, the default software app Ubuntu ship with, is based on GNOME Software. It’s mostly the same app save for a few Snap-specific tweaks (which we’ve mentioned before) and shipping with the Snap plugin by default.

In short, the “Snap” support it offers isn’t particularly egregious or wide-reaching.

But word on the street is that Ubuntu is prepping a brand new app store exclusively tailored to Snap apps for use in a future release (but separate from the Snap’d Snap Store snap)

This has made some devs who work on GNOME Software a little …twitchy.

Kalev Lember, the dev behind the merge request to nuke the 4000 or so lines of Snap support in GNOME Software, explains:-

“Ubuntu is switching to a new snap-store app for installing and removing snaps. This commit drops the snap backend from gnome-software to avoid maintenance overhead.”

Reasonable. Why should they shoulder the burden of working around Snap-specific code if Ubuntu, the only distro making use of it, don’t plan to use it longterm?

Read more

More on this feud

  • GNOME Software Moving Forward With Disabling Snap Plugin

    While currently Ubuntu makes use of GNOME Software as their "software center" (or "app store") with Snap integration, as we wrote about recently Canonical has begun writing their own Snap Store. Given this and that they don't plan to use GNOME Software in Ubuntu 20.04 LTS and thus have taken their developers away from working on the upstream support, GNOME developers are planning to disable the Snap plug-in for GNOME Software.

  • Heads up: No more snap plugin in gnome-software

    In Fedora 31 I'll be disabling the snap plugin from GNOME Software. It's never been enabled in RHEL and so this change only affects Fedora. It's also not installed by default and so this change should only affect a few people. It's also not really a FutureFeature, it's a RemovalOfFeature but I'm happy to write something for the process and release notes if required. Recently Canonical decided that they are not going to be installing gnome-software in the next LTS, preferring instead to ship a "Snap Store by Canonical" rather than GNOME Software. The new Snap store will obviously not support Flatpaks (or packages, or even firmware updates for that matter). The developers currently assigned to work on gnome-software have been reassigned to work on Snap Store, and I'm not confident they'll be able to keep both the old and new codebases in the air at the same time.

  • EFF Celebrating 29th Birthday with $20 Membership, Linode Launches New GPU-Optimized Cloud Computing Instances, Syncthing 1.2.0 Released, Kali Linux Now Available for RPi 4 and GNOME Devs to Disable Snap Plugin for GNOME Software

    GNOME developers plan to disable the Snap plugin for GNOME Software, as Canonical has started creating its own Snap Store and won't be using GNOME Software in Ubuntu 20.04 LTS. According to Phoronix, "Canonical's in-development Snap Store will obviously be focused just on their own Snap effort and not supporting the likes of Flatpak. Due to the likelihood that the GNOME Software Snap plug-in will quickly suffer from bit-rot and pose a maintenance burden to GNOME developers with little to no return, it's certainly reasonable that they would at least disable this plug-in."

On it goes

  • Fedora is ‘Disabling’ the Snap Plugin for GNOME Software

    The Snap plugin for GNOME Software is being ‘disabled’ in Fedora 31, the distro’s next major release.

    Red Hat’s Richard Hughes announced the change on the Fedora developer mailing list, citing various issues with the plugins QA and long-term usefulness.

    Neal Gompa, who maintains the Snap package in Fedora, says the decision has “blindsided” him.

    So why is Fedora doing this?

    Well, code quality and concerns about the impact the plugin has on the overall GNOME Software user experience are cited:

Fedora To Disable Snap Plugin For GNOME Software

  • Fedora To Disable Snap Plugin For GNOME Software

    We recently saw a merge proposal from Canonical to replace gnome-software snap with their own Snap Store. Along the similar lines, Red Hat’s Richard Hughes has announced that Fedora will disable snap plugin for GNOME Software. His announcement comes just a day after this.

    Fedora will disable the snap plugin in its next major update release, according to Hughes. He mentions that the existing snap plugin is not very well tested and it causes general UX of GNOME software to degrade.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Open source technology, enabling innovation

One of the most exciting projects to come out of the open source revolution is Kubernetes, a tool helping companies running their software on cloud services. It enables them to get the most out of the processing power they’re paying for by identifying machines that are being underutilised. So, if the software detects that a machine is not being optimised, it will load it up with another task so it’s working as hard as it can. Read more

Forbes Raves Upcoming Linux Desktop will enclose Windows 10 and macOS

Forbes senior employee Jason Evangelho dedicated an entire article to an upcoming update for a Sino-domestic Linux distribution: If you haven't paid attention to a bit of Linux desktop distribution called Deepin, it's time to put it on your radar. Remember that Huawei Deepin chose to ship on their MateBook laptop lineup. Remember that Deepin Cloud Sync (for system settings) is a great, progressive feature that every Linux distro must use. Remember that the retractable control center from the future looks like something sexy and sensible. But looking at 2020, Deepin is absolutely breathtaking. This is without a doubt the nicest desktop environment I have ever seen … For me, the UX is more intuitive and pleasant than macOS and Windows 10. And luckily a quick setting can also transform Deepin into the traditional Windows or macOS desktop paradigm's that you are already familiar with. Hell, even the installer is a relief. Read more Also: Differences between Windows and Linux operating systems. The fundamental differences that are worth knowing

[libre-riscv-dev] power pc

So as you know, the RISCV Foundation is seriously impeding progress. There
is huge momentum around RISCV itself, however as far as open *innovation*
is concerned, the sheer arrogance of the Foundation in failing to respect
the combination of Libre goals and business objectives has us completely
isolated from key critical resources such as the closed secret lists and
wiki.

We cannot even get access to documentation explaining how to propose new
extensions.

I have been considering for some time to reach out to MIPS and PowerPC.
Yesterday I wrote to the OpenPower Foundation and was really surprised and
delighted to hear back from Hugh Blemings, whom I worked with over 20 years
ago.

I outlined some conditions (no NDAs, open mailing lists, use of
Certification Marks and Compliance Suites) and he replied back that this
was pretty much along the lines of what they were planning.

I will have a chat with him some time, in the meantime I found the spec:

https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0

It is eeenooormous, however Hugh reassures me that they want to break it
into sections.

Why would we even consider this?

The lesson from RISCV is really clear: if the ISA is set up as a cartel,
Libre innovation is not welcome.

If we had a goal to just *implement* a *pre existing* Extension, there
would be no problem.

It is the fact that we wish to implement entirely new extensions, for CPU
and GPU *and* VPU purposes, but not as a separate processor (which would be
classified as "custom") that is the "problem".

So starting at page 1146, we need to work out how to shoe horn a ton of
stuff into the ISA, as well as fit 16 bit compressed in as well.

L.
Read more Also: Libre RISC-V Open-Source Effort Now Looking At POWER Instead Of RISC-V

Calamares grabs onto things

I’ve been working on Calamares, the Universal Linux Installer, for a little over two years – following up in the role Teo started. It’s used by Neon (for the dev version, not the user version) and Manjaro and lots of other Linux distributions. I’ve typically called it an installer for boutique distro’s, as opposed to the Big Five. Well, Debian 11 has plans. And lubuntu uses it as well (and has for over six months). Those seem pretty big. Read more