Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

Snap/Snappy... Flatpak & the future?

User avatar
Posts: 17504
Joined: Wed Jul 12, 2006 2:17 pm

Re: Snap/Snappy... Flatpak & the future?

#11 Post by richb » Wed Nov 21, 2018 12:55 pm

Other than a 2 second thought about it philosophically, I hope the devs do not spend too many brain cells on a hypothetical snap/flatpack takeover. Certainly not at this time.

Forum Rules
Guide - How to Ask for Help

SSD Production: MX 17.1
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB, 350 GB HD

Forum Regular
Forum Regular
Posts: 915
Joined: Tue Sep 22, 2015 6:56 pm

Re: Snap/Snappy... Flatpak & the future?

#12 Post by skidoo » Wed Nov 21, 2018 4:06 pm

ManyRoads, there's no risk of "takeover". Regardless of XYZpak's existence, or potential prevalence, source code availability for each open source application is assured.

In the status quo we already have quite a few applications that aren't "packaged for debian9" by the application author(s). Historically, teams of packagers comprising the central (parent) linux distributions have handled packaging... but they're increasingly hard-pressed to keep pace as the number of software titles blossoms. So, we can expect the trend of distro-agnostic packaging to increase and probably, especially in the case of large/complex applications (or suites), we should expect evolution toward distribution/use of full containerized (VM + stack + application) appliances.
For smaller programs, many authors are increasingly dodging the burden imposed by packaging administrivia, instead hosting project files in a git repository and utilizing clientside wget operations to retrieve updates directly from the project's git repository. Elsewhere, I've scrutinized the "is this safe?" aspect of this model yet, ultimately I believe the direct, author-to-consumer, distribution model is probably both beneficial and necessary. Example: SparkyLinux provides a "Control Center" app, analogous to antiX Control Center... but instead of repackaging the sparkyCC app (and await apt update, client-side) in order to distribute each incremental update (new/revised task-specific items displayed in the CC app), a daemon handles automatic retrieval of updates, retrieved directly from the project's github repository.

User avatar
Forum Novice
Forum  Novice
Posts: 60
Joined: Sat Sep 27, 2014 5:04 am

Re: Snap/Snappy... Flatpak & the future?

#13 Post by Ghost67 » Wed Nov 21, 2018 6:19 pm

After ten years running GNU/Linux I'm not a fan of non-curated self contained software, be it a Snap, Flatpack, App-image or whatever. The same went for PPA's on the 'buntus and AUR stuff on Arch. I want my software direct from the repos or not at all. If that means running older software I'm happy to do it as long as it works. There is too much opportunity for hacks, general maliciousness and/or incompetent code otherwise.
Cheers! G67
'Quo, quo scelesti ruitis?'

User avatar
Forum Regular
Forum Regular
Posts: 214
Joined: Sat Jun 30, 2018 6:33 pm

Re: Snap/Snappy... Flatpak & the future?

#14 Post by manyroads » Wed Nov 21, 2018 7:15 pm

Actually a take-over is the last of my worries. Keeping things clean, 'together', up-to-date and usable is more my bias.

I agree curation is a big deal with software , perhaps even more so when the install sets are "containerized & genericized" and then left to languish in some online, publicly accessible library. Making certain that the snaps/flatpaks are current and adhere to ‘acceptable’ security practices is a big deal. I assume we need to rely on the snap/flatpak provider, ie. Fedora/IBM; Ubuntu; whomever to provide the quality/ security checks.

Simply stated, users need to be aware of the quality and rigors provided to ensure the quality of their snaps/flatpaks/etc.

It's really not all that different than a user’s responsibility regarding software accepted/ used from AUR/ ppas, etc.
Pax vobiscum,
ManyRoads (Mark Rabideau)
MX-18b1_x64 Continuum
Platform: Dell Latitude E5470
CPU: Dual Core Intel i5-6300U (-MT MCP-)
Mem: 8GB SSD: 978.09 GiB
Reg. Linux User #449130

Post Reply

Return to “General”