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.

This is a perfectly reasonable point of view, sure. Do you think the best way for a company to try to achieve unification behind their system is - before holding any meaningful discussions with other distributions - to issue a press release massively overstating their system's current capabilities and heavily implying it has already *achieved* unification? Don't you think it might be better to, oh, I don't know, actually talk to other distributions and try to achieve some sort of consensus? And be honest about what their system is currently actually capable of, and the challenges involved in making it a truly viable cross-platform solution?

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.

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?

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 how great they were and how PA and systemd were now the universal standard for everything.

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 Linux desktop". It says it does so right now. This is patently *not true*.

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.)

The summary seems to get this a bit garbled, so here's an executive summary:

* This is simply about the support status of upgrades across more than one Fedora release* It's not about making any major technical / design changes to any software* It's certainly not about removing anything that is currently possible* Right now, upgrades across more than one release are technically possible, but until recently were not really tested and not necessarily considered 'supported'* We're now testing upgrades across two releases, and they tend to work pretty well, so we're considering making them more 'supported'

"What if I want to KickStart a Desktop machine and don't want it to be a live image?"

Use Server. The Server network install image is the canonical thing to use for non-live installs of any kind, basically use it just as you'd use the netinst.iso in previous releases.

We're aware this sounds a bit weird, sorry about that. I can give you the *extremely* long version if you like, but the short version is that when it came to actually *implementing* the Product stuff there were the kinds of 'oh, so that doesn't quite work the way we thought it would' moments you'd expect in making such a significant change to an existing distro with existing release engineering tooling.

The upshot of one of them was that having Product-ish network install images turned out to be basically impossible to do, and after a while of banging our heads on trying to fix it we figured, you know what, we don't really need them anyway. Given how the practical implementation of the Products turned out for F21 at least, we can just have a single network install that can deploy anything, just like we did before.

Unfortunately by that point it wasn't really practical to try and set up some kind of new/old tree to build it out of and give it generic branding, so the story for F21 is: for anything like that, use Server. Use the 'Server' network install image for doing any kind of non-live deployment - the only 'Server' things about it are the visual branding and the fact that it *defaults* to the Server package set, but you can successfully deploy any Product or non-Product package set from it, it's functionally little different from the F20 generic network install image.

The Server/ tree on the mirrors is also the canonical source of things like the PXE boot kernel/initramfs, and the fedup upgrade initramfs.

Again, this obviously isn't optimal design, it's just kinda how things worked out in the F21 timeframe (there are some really boring release engineering considerations behind it all that I can explain if you're having trouble sleeping). For F22, all being well, it'll be cleaned up.

The 'Fedora' DVD wasn't actually an 'Everything' DVD, for the record. The repo tree called Everything has literally every package in it but is not 'composed', i.e. it doesn't have installer images and we can't build release media out of it. It still exists for F21. The Fedora repo tree in previous releases (it doesn't exist in F21) was what the DVD and netinst images were built out of. It didn't contain all packages, it contained the set of packages that was chosen to go on the DVD media - substantially fewer than are in the Everything tree.

The 'Fedora' generic DVD image was dropped as part of the whole Product-ization approach, basically the idea being there's a Product image or live spin for most use cases, and install via the Server netinst covers other cases. The specific case of 'I want to do an offline install with a custom package set that's covered by the old Fedora DVD package set but not the new Server DVD package set' is lost with this change, yep, we're sorry about that - ultimately to make a significant change like Products *something* had to be lost, and that's one of the things that was. The Fedora/ tree in the repos doesn't exist any more because its purpose was to build the Fedora DVD image.

Choosing the Server product on upgrade will install the Server packages, including its firewall configuration and Cockpit, because...that's Server. If you just want to keep the existing packages you have installed, choose 'nonproduct'. You can remove Cockpit if you don't want it.