Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Debian Red Hat Software Software Ubuntu Linux

Fedora QA Lead Pans Canonical 'Propaganda' On Snap Apps (happyassassin.net) 170

Long-time Slashdot reader JImbob0i0 shares a scathing article by Red Hat's Fedora QA "community monkey"/senior QA engineer on Canonical's announcement about their application delivery mechanism "snap"... ...and how it's going to unite all distributions and kill apt and rpm! This is, to put it diplomatically, a heaping pile of steaming bullshit... The press release and the stories together give you the strong impression that this thing called Snappy is going to be the cross-distribution future of application delivery, and it's all ready for use today and lots of major distributions are buying into it... The stories have headlines like "Adios apt and yum? Ubuntu's snap apps are coming to distros everywhere" and "Snap Packages Become Universal Binary Format for All GNU/Linux Distributions"...

Now, does Snappy actually have the cross-distribution buy-in that the press release claims (but never outright states) that it has? No... The sum total of communication between Canonical and Fedora before the release of this press release was that they mailed us asking about the process of packaging snappy for Fedora, and we told them about the main packaging process and COPR. They certainly did not in any way inform Fedora that they were going to send out a press release strongly implying that Fedora, along with every other distro in the world, was now a happy traveler on the Snappy bandwagon... They just decided to send out a wildly misleading press release and actively encourage the specialist press to report that Snappy was all set to take over the world and everyone was super happy with that.

This discussion has been archived. No new comments can be posted.

Fedora QA Lead Pans Canonical 'Propaganda' On Snap Apps

Comments Filter:
  • by BenJeremy ( 181303 ) on Saturday June 18, 2016 @03:47PM (#52344353)

    Until everybody learns to play well together, Linux and other great open source projects will continue to be fractious tech that people will, rightfully so, find hard to take seriously.

    Maybe both sides are right, maybe neither side is... but as long as people take sides, draw those battle lines, polarize the issues to extreme levels, open source projects can never mature (indeed, maturity is a word we can not associate with such feuds). Compromise and communication seems to never be considered.

    That's not to say it can't be done, but the types of personalities that stand in the forefront of Linux, for example, seem very bull-headed - obsessed that their way is right, and never willing to accept constructive criticism or the possibility that there may be a better way of doing things.

    • by SocietyoftheFist ( 316444 ) on Saturday June 18, 2016 @03:51PM (#52344373)

      Ummm, where you been the last 20 years? Linux is a data center operating system, lots of money being made off of it that way. There is a free UNIX that isn't fractured, and is making its maintainer good money on desktop hardware and it isn't Linux.

      • Yep, exactly. Linux works great in places where:

        a) A company curates and customizes a specific version of it for a specific purpose (Android, TiVo, Synology, etc)
        b) The OS doesn't matter so much, since it provides standardized services (e.g. web servers)
        c) The free price gives it a huge advantage in mass deployments on commodity hardware (data centers)

        The fractured nature of Linux also isn't as much of a problem if the source you plan to use is free and open, so can simply be compiled to work with the targ

    • by Anonymous Coward

      Scuttleworth was an asshole before he even got into Linux, and if you had stopped to think for one second before proceeding to try to smear "Linux" with the asshole-brush, you've have realized that Larry Ellison, Steve Jobs, Steve Ballmer and even that stinkning little hypocrite Bill Gates are all the same. Snakes and assholes, the whole bunch. "Linux" isn't even a factor.

    • by Anonymous Coward

      That driving assholish personality is the reason we have FOSS. Everything can't be a hug fest. FOSS is so large that everybody will never learn to play well with everyone, it's also large enough that many already do play well together.

    • by AdamWill ( 604569 ) on Saturday June 18, 2016 @07:55PM (#52345183) Homepage

      Almost everybody is already pretty capable of working together. Did you know, fr'instance, that I've spent the majority of my working time for the last year working on Fedora's deployment of openQA - which is a (very nice) system written by SUSE engineers? We now regularly make commits to upstream openQA, the SUSE folks have been fantastic about working with us, and other distributions have been expressing interest in and experimenting with using openQA - and have been welcomed by both SUSE and RH/Fedora folks.

      Canonical is the one player who is *always* pulling this kind of bullshit. Do you think a good way to kick off the process of playing well together with the other distributions is to issue a press release - and hold a press call - strongly giving the impression that their system is mature and ready for deployment, and that all the other distributions have already bought into it, when neither of these things is remotely true? Does that seem like a good way to engender good will and collaboration with the other distributions, to you? No. It's an attempt to strongarm the community into accepting your system by hoodwinking the press into giving it so much of a push it looks like a fait accompli. Why would any other distributor feel particularly happy about that?

      Have you noticed that *not a single other distributor* pulls this kind of crap? It's always and only Canonical. We don't do it - however much someone may or may not dislike systemd for instance, we didn't build a half-assed Ubuntu package for it then issue a press release saying "Systemd Is Coming To Ubuntu", did we? SUSE don't do it. Arch don't do it. Elementary don't do it. Debian certainly don't do it. *No-one* but Canonical does it. Have you noticed how whenever this stuff happens, it always seems to involve Canonical?

      When the SUSE folks built a PoC of openQA testing Fedora, they didn't issue a press release saying 'Our Awesome Test System Is Coming To All Distributions!" Nope. They contacted us in a super nice and friendly way and said hey, maybe you'd like to take this and run with it. And so we did! And now we're collaborating. *that's* how you build cross-distribution collaboration. Not by issuing bullshit press releases first and sending out ridiculous requests for people to come to your Snappy development sprint a day later, after the backlash blows up in your face. (Yes, they actually did this. The invitation goes out of its way to say that the whole team "including Mark Shuttleworth" will be there, as if we're all going to fall over ourselves like a bunch of starstruck teenagers or something. No, they didn't ask other distributions to come to some kind of neutral discussion about application bundling formats, they just asked us to come to their previously-arranged Snappy development sprint.)

      • Which sounds really interesting and plausible until you admit in another post that you work for Red Hat and are a big SystemD/Potterling supporter. So what you're really saying is that it's only OK when it's Red Hat leading the Linux community around by the nose. It's Linux: "Be reasonable, do it my way" is a way of life.
    • Mmm... bull-headed you say? Heh! Interesting choice of words :p
  • An open source project is claiming that it is going to be successful and widely adopted... so?
    • It's claiming that it already *is*. And that it is "enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device", when it currently does nothing of the sort, because confinement is disabled on other distributions and cannot work effectively on X11 (which is still the default for every major distribution) in any case. That's a direct quote from the press release - note *present* tense. It does not say Snappy will some day "work perfectly and securely on any L

  • I wonder if snap is coming to Windows? It would be great to install snap packages regardless of OS since Ubuntu is coming to Windows 10 anniversary update

  • Redhat's strategy (Score:4, Insightful)

    by phantomfive ( 622387 ) on Saturday June 18, 2016 @04:11PM (#52344443) Journal
    This quote show's Redhat's strategy fairly well:

    Flatpak’s (Redhat's preferred alternative to Snap) developers have been communicating with technical conference presentations and blog posts and trying to build a dialog with application developers and distributors

    That explains how systemd worked, too. Systemd talked a lot with the people who write startup scripts, at both redhat and debian. They tried to be responsive to their concerns, and give them what they wanted, which is why systemD succeeded.

    Just as notable is who is missing from the dialog: the actual users. Which explains why systemd made startup-script writers happy, and a bunch of users upset.

    • by Kjella ( 173770 )

      That explains how systemd worked, too. Systemd talked a lot with the people who write startup scripts, at both redhat and debian. They tried to be responsive to their concerns, and give them what they wanted, which is why systemD succeeded. Just as notable is who is missing from the dialog: the actual users. Which explains why systemd made startup-script writers happy, and a bunch of users upset.

      But do (non-paying, non-contributing) users really matter? Debian has their "do-ocracy", those who do the job decide what to do and how to do it. Linus has been saying much the same about the kernel:

      Jim Zemlin: Let's look a level deeper at the social interaction because open source is often described as this sort of democratizing process that, you know, everyone has a say, there's this grand consensus, but at the end of the day, needs to be some sort of decisiveness when it comes to making decisions. How do you deal with that?

      Linus Torvalds: Well, I mean, it's really not a democracy at all and some people call it a meritocracy which is not necessarily correct either. It's - I have a policy that he who does the code gets to decide, which basically boils down to there's a - it's very easy to complain and talk about issues and it's also easy for me to say, 'You should solve it this way.'

      But at the end of the day, the only thing that matters is actual code and the technology itself and the people who are not willing to step up and write that code, they can comment on it and they can say it should be done this way or that way or they won't, but in the end their voice doesn't matter. The only thing that matters is code.

      And it turns out people are lazy, so most people are much happier just arguing and quite often you only have one set of - one example code and there's not a lot of real choice there. You - there's not a lot of people who are competent enough to really do kernel programming and also not lazy enough that they actually get the job done.

      As an end user, I've certainly had situations which pretty much amounts to "we don't give a shit", "you got what you paid for" and "if you don't like it, do it yourself". If application developers and system administrators get a taste of their own sour medicine, maybe they'll figure out what I did - your voice i

      • There is a big difference between "your voice is worthless" and "the final decision is done by people who actually can do the job". Some contributors actually go way beyond the call of duty to help users. But their power isn't unlimited and tradeoffs must be made. Some users want sub-optimal or impractical decisions to be made, often decisions that would screw other users. And once they fail to make things go their way to everyone else's detriment they declare themselves "voiceless" and "powerless". But the
      • Along those lines, I remember when Apple stopped using Samba (because of GPL3) I asked Andrew Tridgell if he was sad to lose users and marketshare. He said, "They weren't really contributing back code anyway, so it's not an issue." For Tridge, the project is what matters, not the raw number of users. He would enjoy working on it even if there were very few users.

        On the other hand, Samba is a solid, portable, excellent project. As for me, I've been writing my own critique of systemd, looking at the benefi [slashdot.org]
  • Fuckin hypocrites. RH/Fedora is the outfit that gave us Poettering of PulseAudio and systemd infamy. And *they* think they're gonna call out anyone else after those debacles? Methinks they doth protest too much... somebody needs to go over to RH and tell them to STFU.

    • Re: (Score:3, Insightful)

      by AdamWill ( 604569 )

      Last time I checked, Lennart wasn't grown in a Red Hat lab. I don't think we have that technology yet. He was working on PulseAudio before we hired him. We gave Lennart a pay cheque; he comes up with the ideas on his own. ;)

      However much you dislike PA and systemd - and feel free to dislike 'em as much as you want, it's a free world - they achieved their positions honestly. We did not build half-assed PA and systemd packages for a few other distributions then issue self-congratulatory press releases about ho

    • Re:Hypocrites (Score:5, Insightful)

      by thegarbz ( 1787294 ) on Sunday June 19, 2016 @02:53AM (#52346029)

      What debacle?

      Ubuntu releases snappy on their distribution, claims success around the world despite no one agreeing to it.
      Redhat releases systemd and pulseaudio on their distribution, everyone around the world adopts it.

      I can see which one is the debacle here. Oh and you think a couple of whining users matter? hahahahaha

  • How is a package manage cross platform when they don't even know how to package apps for a Fedora distribution yet? One would think, possibly, that questions of how and where to put apps and their dependencies in the various filesystems would be the first thing you find out, no? Or does it just chuck everything into opt?
    • Not /opt ... /snap actually ...

      If you install it you'll see you get a 'Core' Ubuntu system in /snap/something-or-other and then overlayed on that is the snap in /snap/app-of-some-kind

      So basically they use a not-quite-namespace (pivot-root to be precise) with no container tech to do a "super chroot" (via pivot-root) into an minimal Ubuntu installation to run the app overlayed on that ...

  • Apart from the toxicity, aren't they likely to melt when you put them on the hob?

  • by Anonymous Coward

    I read the article (I know, I know) and Adam's rant seems to be completely unconnected to Canonical's announcement earlier this week. He seems to be ranting about headlines he's read in _response_ to Canonical's announcement and not what the developers are actually saying.

    Adam is countering claims that rpm and deb packages are dead, but Canonical doesn't seem to have any such plans. He's countering the idea snap packages have universal support, but Canonical does not apepar to be saying they have, only that

    • by AdamWill ( 604569 ) on Saturday June 18, 2016 @08:16PM (#52345273) Homepage

      Did you actually try reading my post? Like, the bits with direct quotes from the Canonical press release?

      Here, here's an easy one. The very first sentence of the press release claims Snappy is "enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device". *Present* tense. The claim is that it does this right now.

      This is patently and demonstrably false. The snappy packages for Fedora are built with confinement disabled, and the installation instructions tell you to disable SELinux to use snappy. Thus the whole supposed 'security' feature of snappy itself is inactive (the snaps are not confined, they have full system access), and using snappy requires to to *significantly decrease* the security of the whole system (not just the snaps you're running).

      Not to mention that meaningful confinement of X11 apps is impossible, and all major distributions still use X11 by default. This is why no-one is running around telling everyone they should use Flatpak right now. I presume it's also why Canonical engineers haven't been running around telling everyone to use Snappy right now. Canonical's PR department appears to have no such qualms, however.

      So. There's a nice easy one for you. But for the advanced class - Canonical PR are not a bunch of idiots. They know exactly what they're *doing* when they issue a press release with a lot of key words and phrases carefully arranged in extremely ambiguous ways. You can bet your bottom dollar they were not shocked and amazed when all these stories came out saying that Snappy was now the agreed-upon universal app distribution system and apt and rpm would be dead any minute now. (Or if they were, it was in the "I'm shocked, shocked to find that gambling is going on in here!" sense of the word). They knew exactly what they were doing. Have you seen 'em running around issuing clarifications, fr'instance? No? Hmm, wonder why that is. It's fairly apparent from the articles that *were* published that Canonical held a press call to go with the press release; do you suppose they were carefully correcting the assumptions of journalists on said press call? Hmm? Doesn't look like it, does it?

  • Watching the folks who brought us systemd argue with the ones who are bringing is snap gives me warm fuzziest.
  • by Anonymous Coward on Saturday June 18, 2016 @05:13PM (#52344697)

    Mandatory XKCD: https://xkcd.com/927/

    It's the absolute truth of everything, as shown by the past DECADES of various standardization attempts.

    Meanwhile, the concept of snaps is broken and WRONG. The reason is quite simple. Let's take OpenSSL for example. A lot of software uses it, links to it. In a snap-only world, if you had a dozen snaps on your computer that used OpenSSL, each and every one would have to update their packages INDEPENDENTLY. You have zero control over your computer. You cannot pre-empt, you cannot patch before the upstream does, you're at the mercy of that huge blob becoming available for each snap.

    And NOTHING stops closed-source commercial software vendors from shipping their software with BUNDLED libs, and/or statically linked, right now. Except one little thing. They don't care about less than 1% of the user base. Case in point: Steam.

    So there is absolutely NOTHING in snaps, no benefit whatsoever, over the existing delivery methods. You want a centralized app container for all your distros? Tarballs. You can tarball your bundled and/or statically build application if that's what you want, even today. And guess what, EVERY *nix operating system on the planet supports those.

    And good luck with the isolation/containerization part, until all the distros agree which one to use. LXC, LXD, docker format, rocket format, next-container-wonder-du-jour.

    • So what if the binary tar ball does the same thing as the snappy snap? Just ignore new features in the snap, right?
      What if you unpack shit all over the place in /usr and are unable to clean it up. Yea after years of experience you'll maybe not do that but making software hard to install and untrackable just to please you is silly.

      Getting some place to list the installed software (both CLI and GUI), with a version number, an uninstall button and a shortcut created in the start menu is better than nothing at

    • by DarkOx ( 621550 )

      I agree I think the next 2 years or so will prove the likes of SNAP and docker to be about the worst thing to happen to computer security since Windows came on the seen.

      I have every confidence that hacking Linux systems is going to become shooting fish in a barrel. Exploit some obsolete lib -> get shell -> run precanned generic container escape code and get root.

  • They do this all the time. Hardly worthy of a response although I am glad to see a clarification regarding RH and snap. The lack of communication is amusing. However, let's not forget Red Hat *cough* systemd *cough*, spits on floor.
  • by AdamWill ( 604569 ) on Saturday June 18, 2016 @08:33PM (#52345307) Homepage

    For the record, Slashdot, while I *am* an RH employee and a Fedora QA team member, this was a personal post, as the first words of it explicitly claim. It's not posted on behalf of Fedora or RH and does not reflect the official position of either RH or Fedora.

    • I give you a lot of credit for sticking up for yourself and/or RH here since obviously not everyone agrees :)

      That said, its just my opinion that RH pointing the finger at Cannonical is a bit of the pot calling the kettle black, since RH has also caused its own share of grief especially among smaller users.

      Disclaimer/qualifications: Everyday desktop RH user from v.5 all the way up to FC14. I now split my time between slackware and LFS. I understand the business need for the enterprise approach and features b

      • -- forgot to add, IMHO Redhat's best releases *ever* were in the 6.2 thru 7.x series.

      • Re:Personal post (Score:5, Informative)

        by AdamWill ( 604569 ) on Saturday June 18, 2016 @09:08PM (#52345399) Homepage

        Well. You may not see it this way, but to me there's a rather big difference. Usually when people talk about RH 'causing grief' and 'UNIX design philosophy' (sigh, if I had a nickel for every time...) they're talking systemd. Yes? Well, sure. Lennart wrote systemd, RH is fairly solidly behind it these days (though note it wasn't at first - Lennart had to sell systemd inside RH about as hard as he had to sell it anywhere else), and quite a lot of people don't like it.

        Fine, it's a free world. But that's ultimately a technical argument. We didn't put systemd under an RH CLA. We didn't issue press releases prematurely declaring that it was taking over the free world. It's a freedesktop.org project, you don't have to sign your soul over to RH to use or work on it, it has plenty of non-RH contributors, and it got integrated into non-RH distros through their usual processes for feature review.

        I don't usually actually have any problems with Canonical's engineers, or their projects, believe it or not. Of course there's the whole Wayland/Mir mess, but that's kind of an exception (and even there the main problem is down to management, not engineering). The stuff I don't like from Canonical invariably comes from management and/or PR, and (again purely my personal opinion) ultimately derives from Mark and his poor-man's-Steve-Jobs complex.

        I don't have any particular problems with Snappy as a technology. Heck, a couple of things about it might be better than Flatpak (I don't know either system in much depth, just broad overviews and the specifics I dug into for this kerfuffle). From a purely technical viewpoint - if you ignore the publicity, and the problematic influence of snappy being under the Canonical CLA and the server end being a black box - it's perfectly possible Snappy could turn out to be the best answer to this particular question. It's certainly not a Wayland/Mir situation - Snappy and Flatpak both have fairly complex histories and predecessors, but whichever way you cut it, they've been around about as long as each other.

        The issue I have is specifically with *this press release about snappy*, and more specifically with the way it vastly overstates snappy's current capabilities, and the way it strongly implies that snappy already has substantial cross-distro buy-in. Taken together - and if you look at the stories that came out of it, which Canonical PR *certainly* was not ignorant about, especially given there was a press call - this comes off as an attempt to effectively pre-empt the whole process of building consensus around a solution by giving Snappy such a strong press push that everyone just has to fall in line behind it, regardless of the fact it's not remotely *done* yet and there are other options that have already been trying to build support the right way.

  • by Lirodon ( 2847623 ) on Sunday June 19, 2016 @12:52AM (#52345833)
    Only the client portion is free software. It only works with a proprietary, Canonical-run package repository. Canonical does not offer source code for the server aspect, and thus, does not offer the ability to create third-party servers. The entire system is subject to Canonical's walled garden.
    • I've seen this reported elsewhere too. Is this really true? If so, that's a complete showstopper.

  • Let's me start by saying that when you want to run a game, you're more pragmatic and the political/philosophical/meta-technical issues take a second or third seat. I.e. even if snap packages are "evil" game users want to play the game, and Steam is a bit evil for someone who played in the DOS / Windows 95 days (or 8/16bit before that) when you didn't have to log in to some tracking platform each and every time. It's still praised a lot still.

    Games are distributed as .deb etc. packages, binaries or Steam. Th

    • by DarkOx ( 621550 )

      A second technical reason that prevents even me from running games included in the distro or distributed as .deb : I can't install a 600MB game or smaller at all, that's more than there's free space on the / partition

      So to clarify, you don't want to use sane package management and would prefer to basically spray software all over the place like the Windows drive letter model because you can't mange your storage effectively? Look first off it 2016, you don't have a good excuse for not have 600MB free on a volume especially root.

      Second you should be using some kind of pooled storage. In fact just about everyone should. You should also be using a file system that handles that well. Severs with specific performance need

      • As it is, distroes default to ext4 and users can use a small boot drive (low end SSD, eMMC, very old hard drive..) or do the basic separation between / and /home on a single drive. I advocate for joes and grandmas and everything in between. You might as well talk of ghetto SANs or hypervisor desktop rigs. I could network boot an iSCSI volume from a ZFS file server afterall, after spending a few hundreds on a tiny PC and a couple 2.5" drives.

Garbage In -- Gospel Out.

Working...