Welcome!
Forum users

Current releases
--MX-23 release info here
--Migration information to MX-23 here
--antiX-23.1 (Arditi del Popolo) release info here

Important information
--If in starting your system it boots to an unwanted Desktop, right click desktop, then select leave and logout. At the
login screen there is a session chooser at the top of the screen.

News
-- MX Linux on social media: here
-- New Forum Features, Marking Solved and Referencing a User: here

Snap/Snappy... Flatpak & the future?

Message
Author
User avatar
richb
Administrator
Posts: 10306
Joined: Wed Jul 12, 2006 2:17 pm

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

#11 Post by richb »

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.

:eek:
Forum Rules
Guide - How to Ask for Help

richb Administrator
System: MX 23 KDE
AMD A8 7600 FM2+ CPU R7 Graphics, 16 GIG Mem. Three Samsung EVO SSD's 250 GB

skidoo
Posts: 753
Joined: Tue Sep 22, 2015 6:56 pm

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

#12 Post by skidoo »

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.
:hamster:
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
Ghost67
Posts: 79
Joined: Sat Sep 27, 2014 5:04 am

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

#13 Post by Ghost67 »

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

User avatar
manyroads
Posts: 2598
Joined: Sat Jun 30, 2018 6:33 pm

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

#14 Post by manyroads »

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,
Mark Rabideau - ManyRoads Genealogy -or- eirenicon llc. (geeky stuff)
i3wm, bspwm, hlwm, dwm, spectrwm ~ Linux #449130
"For every complex problem there is an answer that is clear, simple, and wrong." -- H. L. Mencken

Post Reply

Return to “General”