"There are other ways to lock down your system in Linux, which will leave it pretty much unhackable, such as signed binaries (the signature of binaries being checked with each execution), kernel and module signing, and a properly configured bootloader along with secure boot turned on"

This is an extension of exactly those mechanisms. The thing being addressed here is a huge gap in that security chain: currently if you're taking Secure Boot seriously, then nearly everything in the boot chain is signed...*except the initramfs*. Which can't be signed because it's generated locally on your machine. What is the initramfs? Well, it's an entire operating system in a box, basically, which gets run and does arbitrary stuff *defined within itself* on every boot.

So, uh...if everything in the boot chain is signed except the initramfs, how secure is boot? Answer: not very at all. That's why this effort exists.

I think if you take a step back, the overall debate about the whole effort to enable a truly secure boot on Linux is a 'hole hawg' problem: http://www.team.net/mjb/hawg.h... . People who hate all this stuff are Hole Hawg users. They reckon they know what they're doing (maybe they really do!), they don't think boot chain security is an issue for them, and every attempt to make it possible just smells funny to them because it's trying to achieve a thing they don't want.

But not everybody wants the Hole Hawg. IT admins, for instance, definitely don't want the people carrying around their company's sensitive data to have a Hole Hawg. They want that stuff safe. For those purposes, it really is important that we make it possible to have a truly secure boot environment on Linux (or at least one that's not wildly *less* secure than competing operating systems, which right now it kind of is).

I get that people worry this stuff will start out optional but somehow magically become compulsory. All I can say is there's really no reason for anyone to want that. It's plausible in the case of a proprietary monopoly OS that this feature comes with a handy side of control for the OS company, but that's much harder in the F/OSS world. If we somehow tried to make it so Fedora or RHEL didn't boot without all the secure boot features turned on (and why would we, anyway?), anyone could still create a clone which was the same thing but...without that. I also can't see really any benefit we'd get from requiring that. And you can note that Fedora and RHEL have supported Secure Boot for about a decade as of this point, and we certainly aren't requiring that that be enabled.

We're aiming for next Tuesday, but we might not quite hit the deadline; we've had some technical issues with the volcano in the underground lair...

He probably did. Quite a lot of Red Hatters have a story about getting an email from Jim out of the blue asking for help with some crazy-ass nerd project he's working on. He once mailed me asking about getting the out-of-tree Poulsbo drivers working (which is something I was messing around with at the time) for some funky device he was trying to get Fedora running on.

He's not a full-time engineer or anything, but he's as much of a tinkerer as many /. readers. That was one of the things that got him hired as CEO, he was already tinkering around with Linux when he was at Delta.

"Red Hat created Systemd. It is their baby. They are not going to abandon it."

This isn't true, though. We would happily abandon it if something better for our purposes showed up. We've other things written by Red Hat for superior alternatives before; sometimes the alternatives were RH projects, sometimes not. Jim even said this in his answer.

Exactly. I certainly buy that a lot of people don't really have a lot of need for a desktop/laptop PC any more. But those of us who do, probably don't really want the same interface on it as we want on our phones. We might want access to some of the same *stuff*, but that doesn't mean we want to use the exact same desktop/app stack.

I was simplifying. *I* would actually have bought an Ubuntu phone or tablet like a shot if one with decent enough specs, LTE, and some kind of working Whatsapp support showed up. But you, me, and the other F/OSS nuts are more or less a rounding error in the cellphone/tablet market. So read "no-one" as "almost no-one" if you like - the strategy depended on establishing themselves as at least a viable player in the mainstream cellphone/tablet market in at least *some* significant geo, and this was clearly just not happening. No major manufacturer wanted Ubuntu on its devices, and the sales for the minor devices they managed to ship through arcane channels were more or less the built-in F/OSS nerd market and nothing beyond it.

Well, sure, but GNOME is the only officially-supported desktop on RHEL (unless we're supporting KDE these days, I never can keep track - but at most it's those two). You can install whatever other desktop you like on it, but RH won't support it. So if you actually want commercial support for your desktop deployments from RH, MATE (and Cinnamon etc. etc. etc.) aren't in the running.

Of course they'll dump Mir. There's literally no reason to keep spending money on building it any more.

"Shuttleworth talks about the market picking it, but did it?"

That's not what he's talking about, there. He's talking about the *cellphone and tablet* market. No-one wanted to sell Ubuntu phones or tablets and no-one wanted to buy 'em. Canonical's entire strategy for the last several years has been this 'convergence' idea that people would want to run the same OS on their phone, tablet and computer. This does not appear to have panned out in the slightest. That's the market failure he's talking about.

There is virtually no desktop Linux "market", because almost no-one pays for it. Red Hat and SUSE are probably the only companies managing to sell enough "Linux desktops" to produce an amount of money worth talking about, and even there it's very much a niche business.

The lines in question are actually quoted from Betanews. I still can't decide how sincerely they're meant. :P

No, he's probably talking about 'Classic Mode', which is an alternative interface provided by gnome-shell that looks more like a Win98 / GNOME 2-style desktop. It exists more or less entirely because some Red Hat desktop customers (yes, we have some!) wanted to update to RHEL 7 but wanted a more 'classic' desktop UI.

https://access.redhat.com/docu...

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.

in what way did it not?

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.