This is ridiculous
|
Author | Content |
---|---|
AwesomeTux Jun 16, 2016 10:34 PM EDT |
So their idea is to simply abandon the superior repository and dynamically linked library approach in favor of the horribly flawed Windows and Mac approach? So your telling me that I will need to have a different version of the SDL library for every application I install that uses it, multiple PNG, JSON, Cairo, Clutter, etc, etc libraries of potentially different versions, that are each potentially vulnerable in some way at different times, and that all would have to update individually from each other. This is the way it's done on Windows, and that is horrible. I wouldn't be able to simply update one vulnerable OpenSSL library, I would have to update every application that had it's own OpenSSL library at it's own version bundled with it. I assume these Snap packages could also potentially include the normal system libraries too, like GTK+, glibc, bash, SystemD... Linux itself. What a scary thought that someone would be able to package their application with their own "enhanced" versions of important system libraries... think encryption libraries that they've added backdoors to, filesystem libraries with buffer overflow bugs or something else stupid like that. And how exactly is this idea any different than AppImage? |
penguinist Jun 16, 2016 11:33 PM EDT |
We Linux users really have it great with the repository idea. We get guaranteed consistency and a measure of quality control. Just think of those poor Windows minions who have to hunt the Internet for a setup.exe file for the program they want. What's the number one virus delivery vehicle for Windows users? Answer: setup.exe |
BernardSwiss Jun 17, 2016 3:18 AM EDT |
Huh. I can't help thinking... Is this, perhaps, what really "inspired" the recent Brian Lunduke story, posted earlier this week? |
nmset Jun 17, 2016 7:38 AM EDT |
>What a scary thought... "enhanced" versions of important system libraries... ... I think you've hit the major point that leaves me uneasy with this approach. Also, sandboxed or not, it still requires root priviliges to install, doesn't smell good. Let's hope distros don't slide to the point of *replacing* application packages with snaps. This comes from the mobile world, it doesn't mean it becomes a must on the desktop. Again the new hammer and the nail well known saying, just too bad. |
dotmatrix Jun 17, 2016 9:42 AM EDT |
I thought the Linux Standard Base was supposed to fix all the infighting and library confusion. However, there were/are problems since RH decided that what was good for them was what was good everyone. I guess it's Canonical's time to try to take over the world. Personally, I greatly dislike the prospect of removing system libraries. Code reuse helps keep the installed programs small and is easier to maintain. It seems to me that "Snaps" is going to create broken libraries, code drift, and overall loss of code quality. And, the library security updates will be the responsibility of the application developer... Good luck getting application developers to always and properly apply security patches to all libraries included in the directory tree. |
flufferbeer Jun 17, 2016 12:19 PM EDT |
@nmset + others, >> I think you've hit the major point that leaves me uneasy with this approach. Also, sandboxed or not, it still requires root priviliges to install, doesn't smell good. >> Let's hope distros don't slide to the point of *replacing* application packages with snaps. This comes from the mobile world, it doesn't mean it becomes a must on the desktop. Again the new hammer and the nail well known saying, just too bad. Yeah, and $huttleworthtoomuch's overpromotion of Snaps seems TOO much like the old M$ Bully Ballmer's infamous "Developers, Developers, Developers,..." song-and-dance number! And that's in addition to the encroachingEEE-like optional--->mandatory incorporation of Snaps into 1rst) all Baboon2-based distros, 2nd) into all Debian-based non-Baboon2 .deb distros, 3rd) all rpm-based distros, 4th) all the rest of the major (and minor) distros!! 2c |
jdixon Jun 17, 2016 2:14 PM EDT |
Well, the real question raised by this is: Will this be what finally makes Clem snap and move Mint to a full Debian base? |
seatex Jun 17, 2016 3:23 PM EDT |
> Well, the real question raised by this is: Will this be what finally makes Clem snap and move Mint to a full Debian base? I would just LOVE to see that happen! But, base it on Devuan, and free it from systemd as well. Edit: Oops, I forgot Clem left systemd out of the last LMDE released. So maybe work with Devuan devs, perhaps. |
jdixon Jun 17, 2016 4:24 PM EDT |
> But, base it on Devuan I could go for that. :) |
skelband Jun 17, 2016 5:21 PM EDT |
> But, base it on Devuan Put me down for that one. |
BernardSwiss Jun 17, 2016 8:15 PM EDT |
>> But, base it on Devuan > I could go for that. :) Ditto |
cybertao Jun 17, 2016 11:29 PM EDT |
This isn't a new concept, and not the first time Canonical have approached it. The advantages of Snap packages apply to proprietary software. It might be another alternative for containers which are still popular. I'd expect it to be business as usual for people who don't want to run proprietary applications or a container framework. |
BernardSwiss Jun 18, 2016 1:38 AM EDT |
Some people will think that Snap is a wonderful idea, because it *solves* the "problem" of installing random applications onto Linux systems just like one would install software onto Windows. But other people think that Snap is a terrible idea, because it "solves" the "problem" of installing random applications onto Linux systems just like one would install software onto Windows. |
750 Jun 18, 2016 2:56 AM EDT |
Frankly this, and the Gnome/Freedesktop developed (or should i say Red Hat developed?) XDG-app/Flatpak format throws the baby out with the bathwater. If they really wanted to fix things, they could have checked out what Nix/Guix or Gobolinux is alrady doing. And that is to put each package into its own branch of the directory tree, such that you can have multiple version of GTK or whatever sitting side by side, and be used by whatever software wants it. The problem spot for third parties packaging DEBs and RPMs have been, and continue to be, the rigidity of the package managers. You can't have a deb of GTK x.0 and x.1 installed at the same time, unless the distro maintainers play musical chairs with the package names (naming one gtk0 and another gtk1 for example). But that in turn complicates dependencies. Also, appimage may well be the superior solution for third parties anyways. As there you get a single file that is executable that will quietly loop mount the file and run its content. With both snap and flatpak you need a manager installed, much as with existing packaging formats. Frankly what we are watching is a generation of web devs taking over linux userspace plumbing, and thinking they can solve everything by applying their web mentality and hammers to everything. Its going to get uglier before it gets saner, at least on the bigger distros. |
jdixon Jun 18, 2016 8:09 AM EDT |
> You can't have a deb of GTK x.0 and x.1 installed at the same time, Any app can be statically compiled. |
penguinist Jun 18, 2016 9:45 AM EDT |
I'm seeing this as a degradation and weakening of the robust Linux repository concept that continues to serve us so well. This is a migration in the direction of "app stores" and "windows setup.exe", and is a direction that I feel needs to be resisted. Isn't it interesting that this initiative comes from Canonical shortly after they hop in bed with Microsoft. |
flufferbeer Jun 19, 2016 10:44 AM EDT |
@penguinist, > Isn't it interesting that this initiative comes from Canonical shortly after they hop in bed with Microsoft. Certainly suspicious at that. $huttleworth2much and the Baboontu Fanbois (NOT the name of a band!) are ALREADY talking up Snaps as if its complete use is a fait accompli. Besides bringing over to the Dark Side as many developers a$ they can afford, what ELSE will CanUBeComical do next? Maybe bring over Red Hat's Lennart Poettering of systemd infamy to assist with the final solution of eliminating at least as many .deb packages as they can get away with doing?? 2 more c's |
seatex Jun 19, 2016 11:07 AM EDT |
> $huttleworth2much and the Baboontu Fanbois (NOT the name of a band!) are ALREADY talking up Snaps as if its complete use is a fait accompli. Well, it worked for systemd. They obviously are trying the same tactic. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!