Choose style:

Author Topic: ...and here we go again  (Read 424 times)

0 Members and 1 Guest are viewing this topic.

Offline pin

  • Trusted User
  • Veteran
  • *****
  • Posts: 1823
  • Karma: 250
    • View Profile

Offline scifidude79

  • Global Moderator
  • Hero
  • *****
  • Posts: 4029
  • Karma: 863
    • View Profile
  • Peppermint version(s): Peppermint 9
Re: ...and here we go again
« Reply #1 on: June 14, 2019, 05:54:05 pm »
Not a surprise. No matter what was said afterward, the cat was out of the bag when they first said they were thinking of switching to snaps for everything. It makes sense that you'd start with a web browser, since those get updated a lot and they need to test the viability of the option.

**sigh**

So, I wonder what they're doing over at Debian these days....

Offline pin

  • Trusted User
  • Veteran
  • *****
  • Posts: 1823
  • Karma: 250
    • View Profile
Re: ...and here we go again
« Reply #2 on: June 15, 2019, 06:16:25 am »
 :'( Have to agree with you there... no surprise!
It seems this is indeed the path Ubuntu has chosen. It simply is just NOT the path I'm EVER going to follow, I already spend about 70% of my private computer time on NetBSD.

Offline PCNetSpec

  • Administrator
  • Hero
  • *****
  • Posts: 25309
  • Karma: 2793
  • "-rw-rw-rw-" .. The Number Of The Beast
    • View Profile
    • PCNetSpec
  • Peppermint version(s): Peppermint 8R, 9, and 9R
Re: ...and here we go again
« Reply #3 on: June 15, 2019, 09:09:28 am »
I think backporting this to the 18.04 LTS is a bit much .. anyone that signs up for 19.10 is signing up for this, but 18.04 users most certainly did NOT.

IMHO Ubuntu no longer own a distro post release, its users do, so they shouldn't change it .. 18.04 users didn't sign up for snaps, or any rolling release style changes.
WARNING: You are logged into reality as 'root' .. logging in as 'insane' is the only safe option.

Team Peppermint
PCNetSpec

Offline PCNetSpec

  • Administrator
  • Hero
  • *****
  • Posts: 25309
  • Karma: 2793
  • "-rw-rw-rw-" .. The Number Of The Beast
    • View Profile
    • PCNetSpec
  • Peppermint version(s): Peppermint 8R, 9, and 9R
Re: ...and here we go again
« Reply #4 on: June 15, 2019, 09:33:37 am »
For me, the only problems with snaps are

a) they're overly big .. kinda obvious because they come with everything they need, but this can be ignored as storage prices continue to fall (even SSD's) It can even be seen as a benefit .. when an app breaks, you fix that app, not the entire system which may break something else.

b) IMHO THEY'RE NOT READY YET, there are still technical issues to solve, such as (but not limited to) their inability to access system wide theming .. the common-gtk-themes snap thing has helped but it obviously won't help if you choose a theme that it doesn't contain .. I guess as a distro builder this isn't a major problem, we could just add our theme there as well, but themes (specially icon themes) can be MASSIVE so duplicating them again is going to add to ISO footprint in a BIG way.

c) My major problem with them .. it's not a technical one, it's a marketing one .. Ubuntu, STOP SELLING THEM AS UNIVERSAL AND FOR PROPRIETARY DEVS, far from encouraging proprietary software to come to Linux it's more likely to simply end up with software that currently HAS to provide the source code to get into the repos not bothering any more, it'll also likely end up with them being distributed from authors websites rather than a central repo and then suddenly we've lost the "many eyes" security model.

On a short note .. I watched a DW video where the Openshot developer saying how he hated having to package for many package formats and loved that he could now release as an appimage .. he then went on to say what he loved about Linux was that package dependencies for other software he used was all right there and available. It'd be interesting to see how he feels if every library his openshot depends on (so he includes in his appimage) is no longer available to him except as an appimage.
(it all sounded a bit .. it's great for me, but I haven't thought it through to its obvious conclusion .. where having to unpack libs from many other appimages ISN'T going to save time, and if the author of the libs chooses won't be possible at all)

[EDIT]

There's an easy solution to this .. snaps available from a default repo, and source code MUST be provided for them to get in .. kinda like where we are now .. other than that I can honestly see benefits to snaps (hell I liked DOS games when they were self contained), they're just not the ones being pushed in the marketing (some of those I see as definite negatives).

It's a marketing problem .. I mean in truth .debs could be provided all over the web and yet they're generally not, it's just that there appears to be an underlying message from the snap marketing machine that aims it squarely at proprietary and will be seen as an opportunity to release software following the 'Windows' method .. I mean all the major software houses bitched when Microsoft wanted to control the distribution channels via there 'Store', and it seems we're offering devs the opportunity to move in the opposite direction :-\
(which BTW I don't see attracting more devs, more as an opportunity for current devs to get lazy/dishonest .. if there's one thing you can say about launchpad, it's that it keeps devs honest by FORCING binaries to be compiled on the launchpad servers so the source code MUST be provided .. yes even for PPA's, there is no way to take shortcuts and include precompiled binaries, any binaries that are to be included in the final package MUST be built by the launchpad servers from the source that you upload and will be made available, it forces devs to provide the source code and to understand how build dependency against other packages already included in current versions of Ubuntu work)

Kendall once said to me "launchpad keeps package maintainers honest" .. it was a while before I fully understood what he meant, but it's true it forces you to understand what you're packaging for and not to take shortcuts .. and to me that's a GOOD thing (though sometimes a PITA) :)
« Last Edit: June 15, 2019, 10:02:50 am by PCNetSpec »
WARNING: You are logged into reality as 'root' .. logging in as 'insane' is the only safe option.

Team Peppermint
PCNetSpec

Offline pin

  • Trusted User
  • Veteran
  • *****
  • Posts: 1823
  • Karma: 250
    • View Profile
Re: ...and here we go again
« Reply #5 on: June 15, 2019, 02:57:34 pm »
That was a rather extensive list  :D
I would agree with most of it.
Yes, storage is getting cheaper, but isn't that the same excuse Windows/microsoft has always been banging on? Just look at the last endlessOS release, >16GB ISO  :o
(Just for comparisson, my BSD system is installed on a 30GB SSD... Also, my daughters Peppermint is running of a 60GB SSD)

Actually, isn't this snap/flatpak crap turning the whole thing more "windows like"?!

Accepting it, is just as natural as it was accepting systemd  :'(
« Last Edit: June 15, 2019, 03:01:24 pm by pin »

Offline PCNetSpec

  • Administrator
  • Hero
  • *****
  • Posts: 25309
  • Karma: 2793
  • "-rw-rw-rw-" .. The Number Of The Beast
    • View Profile
    • PCNetSpec
  • Peppermint version(s): Peppermint 8R, 9, and 9R
Re: ...and here we go again
« Reply #6 on: June 15, 2019, 03:25:24 pm »
Yes and no...

yes where marketing is concerned (and that MAY drive software distribution in the wrong direction).

no as far as technology and security .. in fact in some ways it's an improvement (if you can ignore disk space) .. personally I don't see disk space as a major problem, I don't mind having multiple libs if they're isolated and can be different versions .. your argument seems to suggest OS's shouldn't be bigger than a floppy even though disk space is WAY cheaper than it was back then and there are definitely benefits of having an OS larger than 1.44MB, or is your line in the sand somewhere larger than 1.44MB ?

I don't see it in the same light as systemd .. from my standpoint there's no feature creep here, it's not more complex, and it's not stamping on any principles (outside of introducing a risk of developer laziness that may or not come to pass but isn't really a snap 'feature' by design)
« Last Edit: June 15, 2019, 03:29:17 pm by PCNetSpec »
WARNING: You are logged into reality as 'root' .. logging in as 'insane' is the only safe option.

Team Peppermint
PCNetSpec

Offline pin

  • Trusted User
  • Veteran
  • *****
  • Posts: 1823
  • Karma: 250
    • View Profile
Re: ...and here we go again
« Reply #7 on: June 15, 2019, 03:55:56 pm »
The size of the OS is not the issue,...
I won't use it, period! The future will tell...

Offline stevesveryown

  • Member
  • ***
  • Posts: 218
  • Karma: 37
  • Peppermint Fan
    • View Profile
    • stevesveryown
  • Peppermint version(s): Peppermint 8, 9 & 10!!!!
Re: ...and here we go again
« Reply #8 on: June 16, 2019, 12:18:51 pm »
I know I have not had much success with snaps and flats, especially with file system access.  AppImages have been less problematic.  The idea is great for new users, makes it more simplified for them, but if they don't work 100% they are useless.

Offline rayzer

  • Jr. Member
  • **
  • Posts: 43
  • Karma: 7
  • New Forum User
    • View Profile
  • Peppermint version(s): 10
Re: ...and here we go again
« Reply #9 on: June 16, 2019, 12:40:53 pm »
appimages have been good of what ive tested so far, snaps and flatpaks i havent touched yet

Offline pin

  • Trusted User
  • Veteran
  • *****
  • Posts: 1823
  • Karma: 250
    • View Profile
Re: ...and here we go again
« Reply #10 on: June 17, 2019, 08:09:57 am »

Offline scifidude79

  • Global Moderator
  • Hero
  • *****
  • Posts: 4029
  • Karma: 863
    • View Profile
  • Peppermint version(s): Peppermint 9
Re: ...and here we go again
« Reply #11 on: June 17, 2019, 06:38:39 pm »
I'm a fan of "if it ain't broke, don't fix it." APT and .deb packages aren't broken, so why is Canonical trying to fix them? A lot of reader comments I saw said that they've tried Snaps and they're slower, take up more space and use more RAM than .deb packages.

The part that really bothers me is a point that PCNetSpec touched on. This isn't just planned for 19.10 and forward, they're going to implement this for 18.04 LTS. That's what Peppermint 9 and 10 are based on. I don't use Chromium, but this is just a test. If successful, the repositories will soon start filling up with snaps. And, it seems like they're trying to seamlessly transition from APT to Snap for stuff, so the update manager will just install it and you won't be sure what's being installed, if it's a normal .deb file or a Snap pack. As PCNetSpec said, we didn't sign up for this.

There's a good reason I keep testing non Ubuntu-based distributions. Stuff like this is the reason.

Offline PCNetSpec

  • Administrator
  • Hero
  • *****
  • Posts: 25309
  • Karma: 2793
  • "-rw-rw-rw-" .. The Number Of The Beast
    • View Profile
    • PCNetSpec
  • Peppermint version(s): Peppermint 8R, 9, and 9R
Re: ...and here we go again
« Reply #12 on: June 18, 2019, 09:42:20 am »
Seriously in PM11 I'm thinking of ditching gnome-software and snapd OOTB (though the user can still choose to install them).

Understand, I'm not against the technology in and of itself, but I do object to the way updating of snaps CANNOT (currently) be disabled (or even granularly scheduled) by the user/system admin .. I hate the "the developer knows best" and "you will be FORCED to accept updates whether you like it or not" way of thinking.

I get that Canonical are really pushing snaps as a fit for IoT devices, but developers DO NOT know what's best for MY system, and when things should happen .. I DO, end of story.
(worse still snapd will only allow you to reschedule updates a few times .. before it'll FORCE the update on you, possibly at a dangerously inopportune moment)

At least with Flatpak's updating is just a boot time service that can be disabled .. though even there it'd be nice to have more granular control than just off/on.

For reasons why forced updates aren't a good idea even ignoring the "my system is mine, stop telling me you know better" argument, and the frankly idiotic and majorly patronising stance the snap devs are taking on this, see here:
https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707

Until snaps allow the user/system admin (who's focus is on the reliability and well-being of the system as a whole) to decide what goes onto their systems and when, rather than the developer (who's focus is only on their app) I'm not sure I want to encourage their use.

Again, please understand if I decide to do this it should NOT be seen as a reflection on the snap technology itself (like anything else there are positives and negatives), it's simply about control .. Please Canonical, give control back to the system admin where it should be, if necessary do two separate versions of snapd (maybe snapd-iot, and snapd-pc), dev driven auto-updates make sense for IoT devices, not for PC's which should ALWAYS be admin driven.
« Last Edit: June 18, 2019, 10:06:05 am by PCNetSpec »
WARNING: You are logged into reality as 'root' .. logging in as 'insane' is the only safe option.

Team Peppermint
PCNetSpec

Offline Johan

  • Jr. Member
  • **
  • Posts: 59
  • Karma: 9
  • New Forum User
    • View Profile
  • Peppermint version(s): Peppermint 10
Re: ...and here we go again
« Reply #13 on: June 18, 2019, 10:43:34 am »
Maybe all sys admins can put up a petition for Canonical not to do this?
To Peppermint or not to Peppermint.

Offline PCNetSpec

  • Administrator
  • Hero
  • *****
  • Posts: 25309
  • Karma: 2793
  • "-rw-rw-rw-" .. The Number Of The Beast
    • View Profile
    • PCNetSpec
  • Peppermint version(s): Peppermint 8R, 9, and 9R
Re: ...and here we go again
« Reply #14 on: June 18, 2019, 11:02:43 am »
If you read that thread on the snapcraft forum I linked you'll see PLENTY of people have done just that .. you'll also likely come to the same conclusion as I that the snap developers have made their decision and are simply going ignore system admins and their way of thinking anyway.

(surprise, surprise, developers thinking developers should be in control)



BTW, when I say "sysadmins", I don't necessarily mean just serverroom and company/corporate system administrators .. YOU are a sysadmin of your own PC's, and YOU should have the final say on what goes on and when .. you should not be FORCED to hand ongoing system control to third parties just because you chose to use their app.

Sure, you can choose NOT to install their app, but snapd itself should not FORCE you to make that choice or relinquish control, control of YOUR system should ALWAYS be optional and at YOUR whim.

If you CHOOSE to blow up your system, you should be allowed to do so .. it's YOUR system.



Now like I said it may be different in the IoT role .. there I'd probably prefer forced auto/unattended updates rather than face millions of doorbells in a botnet.

Currently it feels to me a bit like Canonical are using desktop Linux users to alpha/beta test a packaging system they're gearing towards IoT without even offering the opportunity to tailor it to the PC .. probably because they're scared enough people would turn off updates, messing with their testing.

That's possibly why they say they may add the option to disable updates in the future (once their testing is done), but LTS users should NOT be forced to beta test for other Canonical projects (hence why I posted that this Chromium .deb to snap thing should NOT be backported to the 18.04 LTS Non Interim release).
« Last Edit: June 18, 2019, 02:20:34 pm by PCNetSpec »
WARNING: You are logged into reality as 'root' .. logging in as 'insane' is the only safe option.

Team Peppermint
PCNetSpec