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

Security: Open Source Security Podcast, Screwed Drivers, and Voting Machines

  • Open Source Security Podcast: Episode 157 - Backdoors and snake oil in our cryptography

    Josh and Kurt talk about snakeoil cryptography at Black Hat and the new backdoored cryptography fight. Both of these problems will be with us for a very long time. These are fights worth fighting because it's the right thing to do.

  • Screwed Drivers – Signed, Sealed, Delivered

    Our analysis found that the problem of insecure drivers is widespread, affecting more than 40 drivers from at least 20 different vendors – including every major BIOS vendor, as well as hardware vendors like ASUS, Toshiba, NVIDIA, and Huawei. However, the widespread nature of these vulnerabilities highlights a more fundamental issue – all the vulnerable drivers we discovered have been certified by Microsoft. Since the presence of a vulnerable driver on a device can provide a user (or attacker) with improperly elevated privileges, we have engaged Microsoft to support solutions to better protect against this class of vulnerabilities, such as blacklisting known bad drivers.

  • Most states still aren’t set to audit paper ballots in 2020

    Despite some progress on voting security since 2016, most states in the US aren’t set to require an audit of paper ballots in the November 2020 election, according to a new report out this week from the Brennan Center for Justice.

    The report notes that experts and government officials have spent years recommending states adopt verifiable paper ballots for elections, but a handful still use electronic methods potentially vulnerable to cyberattacks. In 2016, 14 states used paperless machines, although the number today is 11, and the report estimates that no more than eight will use them in the 2020 election.

Linux Candy: WallGen – image generator tool

Who loves eye candy? Don’t be shy — you can raise both hands!! Linux Candy is a new series of articles covering interesting eye candy software. We’re only going to feature open-source software in this series. I’m not going to harp on about the tired proverb “All work and no play makes Jack a dull boy”. But there’s a certain element of truth here. If you spend all day coding neural networks, mastering a new programming language, sit in meetings feeling bored witless, you’ll need some relief at the end of the day. And what better way by making your desktop environment a bit more memorable. Let’s start our candy adventure with WallGen. It’s a small command-line utility that generates HQ poly wallpapers with only a few text arguments for inputs. Depending on these arguments, you can create shape-based patterns, randomly filled surfaces, and even image-based patterns. Read more

Richard Brown: Changing of the Guard

After six years on the openSUSE Board and five as its Chairperson, I have decided to step down as Chair of the openSUSE Board effective today, August 19. This has been a very difficult decision for me to make, with reasons that are diverse, interlinked, and personal. Some of the key factors that led me to make this step include the time required to do the job properly, and the length of time I’ve served. Five years is more than twice as long as any of my predecessors. The time required to do the role properly has increased and I now find it impossible to balance the demands of the role with the requirements of my primary role as a developer in SUSE, and with what I wish to achieve outside of work and community. As difficult as it is to step back from something I’ve enjoyed doing for so long, I am looking forward to achieving a better balance between work, community, and life in general. Serving as member and chair of the openSUSE Board has been an absolute pleasure and highly rewarding. Meeting and communicating with members of the project as well as championing the cause of openSUSE has been a joyous part of my life that I know I will miss going forward. openSUSE won’t get rid of me entirely. While I do intend to step back from any governance topics, I will still be working at SUSE in the Future Technology Team. Following SUSE’s Open Source policy, we do a lot in openSUSE. I am especially looking forward to being able to focus on Kubic & MicroOS much more than I have been lately. As I’m sure it’s likely to be a question, I wish to make it crystal clear that my decision has nothing to do with the Board’s ongoing efforts to form an independent openSUSE Foundation. The Board’s decision to form a Foundation had my complete backing as Chairperson, and will continue to have as a regular openSUSE contributor. I have absolute confidence in the openSUSE Board; Indeed, I don’t think I would be able to make this decision at this time if I wasn’t certain that I was leaving openSUSE in good hands. On that note, SUSE has appointed Gerald Pfeifer as my replacement as Chair. Gerald is SUSE’s EMEA-based CTO, with a long history as a Tumbleweed user, an active openSUSE Member, and upstream contributor/maintainer in projects like GCC and Wine. Read more

An introduction to bpftrace for Linux

Bpftrace is a new open source tracer for Linux for analyzing production performance problems and troubleshooting software. Its users and contributors include Netflix, Facebook, Red Hat, Shopify, and others, and it was created by Alastair Robertson, a talented UK-based developer who has won various coding competitions. Linux already has many performance tools, but they are often counter-based and have limited visibility. For example, iostat(1) or a monitoring agent may tell you your average disk latency, but not the distribution of this latency. Distributions can reveal multiple modes or outliers, either of which may be the real cause of your performance problems. Bpftrace is suited for this kind of analysis: decomposing metrics into distributions or per-event logs and creating new metrics for visibility into blind spots. Read more