Shuttleworth Says Snappy Won't Replace .deb Linux Package Files In Ubuntu 15.10

darthcamaro writes: Mark Shuttleworth, BDFL of Ubuntu is clearing the air about how Ubuntu will make use of .deb packages even in an era where it is moving to its own Snappy ('snaps') format of rapid updates. Fundamentally it's a chicken and egg issue. From the serverwatch article: "'We build Snappy out of the built deb, so we can't build Snappy unless we first build the deb,' Shuttleworth said. Going forward, Shuttleworth said that Ubuntu users will still get access to an archive of .deb packages. That said, for users of a Snappy Ubuntu-based system, the apt-get command no longer applies. However, Shuttleworth explained that on a Snappy-based system there will be a container that contains all the deb packages. 'The nice thing about Snappy is that it's completely worry-free updates,' Shuttleworth said."

Comments

why bother?

[Anonymous Coward]

The functionality will be built in to the next version of systemd.

Re:why bother?

[Anonymous Coward]

why is this modded troll?
Lennart the great mastermind has announced it on his blog: http://0pointer.net/blog/revis...

Re:why bother?

[Anonymous Coward]

Wow. Now i really am starting to get why people hate this guy.

Re: why bother?

[Anonymous Coward]

Pid eins is an anagram of iPenisd - now I understand...

Re:why bother?

[caseih]

Maybe you should actually read what he wrote before jumping on the hate bandwagon. He's absolutely right that for many years and applications traditional package systems fall down. That's not to say they aren't important. They are and will continue to be. But they have their limitations when it comes to fast moving software like libre office on a nice stable slow moving distro like the lts releases of Linux distros.

As a matter of fact docker is really one attempt to solve this problem. Coreos is based on this idea. Chromeos also eschews packages entirely. Now snappy.

And as experimental distros like snappy try things, new utilities will have to be created to manage the images. This is what Poettering is talking about. In the meantime you're free to not use any of this. It's just a bunch of ideas, many of which happen to be really good, and natural extensions of the traditional package model. It's exciting stuff.

Re:why bother?

[Eunuchswear]

Yes, how dare he develop software that people can use if they want to, the bastard.

Re:why bother?

[serviscope_minor]

No they don't fall down. I've heard this claim and it's frankly not true (or rather, true in a very very limited set of cases).

For first party packages (distro provided) it's business as usual: ubuntu seems to have no trouble tracking the latest firefox builds and there's a fresh deb available via apt-get update && apt-get upgrade in a very timely manner. Likewise there's the fresh and still LO packegs available depending on whether you want stability with timely security updates or bleeding edge.

So, demonstrable, fast moving packages are not a problem.

What about third party ones?

Basically it's the same. Add a PPA for the third party repo and it just works. Now, if the third partd dev doesn't want to keep up to date with system libraries which may change, then they might choose to ship their own .so files. That has the downside of not tracking security updates, but since linux package managers are the only system where arbitrary packages tend to get security updates to arbitrary libraries anyway all that does is lower the performance to that of every other OS on the planet.

And some programs do this: they provide a third party .deb or PPA and dump files in /opt/foo completely isolated from the system files in/usr. That works very well too.

One of the ways that packaging falls down traditionally is for multiple versions of the same package installed concurrently. Part of this is because some programs themselves are not build for that (e.g. expecting files in /etc), however most package can be persuaded otherwise and there are in fact package managers that solve this problem.

The other way is if a program needs a complex system relying on multiple non-default configured packages to be set up. At that point, it's often easier to ship an entire system image.

However, doing system images for everything seems a tad wasteful.

The other thing that is hapening is Zawinski's cascade of attention defecit teenagers. Yeah, I know packaging isn't perfect in general and deb is not perfect in a number of specific ways. But the people who want to dump everything and start afresh often seem to be quite unaware of teh state of the art. The results is that the new systems are usually better in some ways, but inevitably worse in a number of ways that the author didn't think of but have been hammered out and working well for 20 years in other systems.

It's sad because to someone who's around for a long time, software doesn't so much as advance as take an awful lot of steps sideways. You get big fat brand new shiny systems which just plain do a bad job of previously solved problems.

This seems to be the same: many of the reasons for doing away with packages are flat-out wrong which strongly implies that the people replacing packages don't really understand packages properly and are therefore likely to make a bunch of new mistakes which have previously been solved perfectly fine. So even if they solve some problems (I have no doubt they will), they'll also unsolve a bunch.

Re: why bother?

[vadim_t]

What are you on about?

$ cat /usr/local/bin/errtest.sh
#!/bin/bash
echo This is stdout
echo This is stderr 1>&2
 
$ cat /etc/systemd/system/errtest.service
[Unit]
Description=stderr test
 
[Service]
ExecStart=/usr/local/bin/errtest.sh
 
[Install]
WantedBy=multi-user.target
 
$ sudo systemctl start errtest
$ journalctl -u errtest
-- Logs begin at Thu 2015-03-05 22:42:26 CET, end at Mon 2015-09-07 14:40:56 CEST. --
Sep 07 14:39:23 gadget systemd[1]: Started stderr test.
Sep 07 14:39:23 gadget systemd[1]: Starting stderr test...
Sep 07 14:39:23 gadget errtest.sh[8971]: This is stdout
Sep 07 14:39:23 gadget errtest.sh[8971]: This is stderr

There's your stdout and stderr.

Re: why bother?

[vadim_t]

No, it is not. The string "forking" isn't anywhere in the man page for systemd on Red Hat. Considering Poettering works for Red Hat, that is a pretty big omission if you're right that it is the solution, and it isn't considering I have that in the unit file.

That's because the systemd manpage is about the main application. You want the systemd.service manpage.

Re:why bother?

[squiggleslash]

It's a troll because it's another pointless slam at systemd, which is entirely off-topic here.

And Pottering isn't announcing anything on his blog, he's discussing improvements he and other systemd developers think could be made to the way GNU/Linux software is distributed. That would make his comments slightly more on-topic here, given snappy is (apparently) a change to the way GNU/Linux software is distributed, but his comments don't directly relate to snappy and appear to be vague concepts.

Nor is there any suggestion that systemd is about to integrate a package manager or package management system replacement - he's obviously interested in how future software distribution systems might work with systemd, but that's not the same as proposing an actual system.

I'm guessing if the topic was diversity in IT, and you found Pottering wrote an article about the topic, you'd have suggested systemd is going to integrate actual black disabled lesbians (using some kind of mind-interface one assumes) into its next release. Right?

Re: why bother?

[lgw]

If something has worked fine for 30 years, why the fuck would you change it? Windows is the OS that pointlessly moves around all the administrative tools with every release; Linux is the OS that doesn't. That's not to say the OS can't change, but the new pieces must be backwards compatible with the basic system debugging techniques everyone knows. All it takes is software developers who don't actively hate their userbase and find joy in punishing them.

Re: why bother?

[vadim_t]

Actually no, it hasn't. sysv init has long been a pile of hacks on top of a pile of hacks. Ever tried to write a sysv service? It's really wonderful when a service refuses to come up because the pid file was left around for whatever reason, and some other program happens to be running under that pid.

For instance, the stderr thing this guy is complaining about was long a "feature" of sysv systems, where stderr could actually disappear into the void. Systemd actually makes things much better by ensuring stderr always gets saved.

As to why change logging, under systemd you can trivially ask for the messages for a particular service, or the messages from last boot, without having to figure out what to grep for, or having to setup syslogd beforehand to sort out your messages into separate files.

Re: why bother?

[vadim_t]

Actually it is a step forward.

In sysv land, this is the difference between letting a service fork by itself and using start-stop-daemon. If you take the later approach, start-stop-daemon will perform the daemonization task on behalf of the service. In such a case if it ever prints on stderr, it will be lost in the void, since it's no longer connected to any terminal. systemd actually will ensure it goes into the log.

Re: why bother?

[vadim_t]

You systemd haters are really hilarious.

Where else do you get to see somebody professing their love of the True Unix with Unix Philosophy, while repeatedly demonstrating ignorance of the very system they claim to love so much?

Allow me to impart a bit of education: some things have more than one manpage. For instance there's a manpage for both cron, and crontab, and Perl has a whole bunch of them. Any competent admin would know this and wouldn't be mystified by systemd having separate manpages for commandline tools and descriptions of unit files.

How?

[khasim]

"The nice thing about Snappy is that it's completely worry-free updates," Shuttleworth said.

I don't think it was the PACKAGE that caused people to worry about an update.

For example, Shuttleworth said that if there is a security vulnerability, like a Heartbleed flaw, the way Ubuntu fixes the issue is with a .deb package.

Isn't that an issue with the code itself?

The great thing about .deb packages was that the OFFICIAL ones underwent a lot of testing to try to catch problems BEFORE they were deployed. NOT because they were magical .deb packages.

Re:How?

[xtronics]

Exactly - it is almost if they were trying to give a bad name to OS software.

There are very good reasons that Debs act like they do - and even M$ is now adopting the repository approach (but of course if the code isn't open, it can't prevent bad things from happening).

One could make the argument that all software should be it's own blob - no dependencies because hardrive are now huge - but having 6 different versions running reduces the chance that someone else will be facing the same bug as you are - and making bugs less likely to get fixed. Exactly what happens in the proprietary world. ( I've seen software that depends on bugs to function ).

Snappy also adversely effects security - I'll let someone else explain why..

Re:How?

[0123456]

I've seen software that depends on bugs to function

Back in the 90s, I had to intentionally reproduce Microsoft bugs in my Windows drivers, or various apps that had never been run with non-Microsoft drivers would fall over...

But, yeah, let's make Linux do things the Windows way, so you have sixteen copies of different versions of zlib.dll spread across your disk, all with different security holes. Because you know it makes sense!

Re:How?

[phantomfive]

The great thing about .deb packages was that the OFFICIAL ones underwent a lot of testing to try to catch problems BEFORE they were deployed. NOT because they were magical .deb packages.

I think they are still standing on Debian's shoulders here, and their Snap files are being automatically created from based on the .debs. The main feature of a Snap file is it combines all the libraries in a single archive. All the dependencies, everything. It installs them locally, not for the whole system, kind of like an .app file on OSX.

If that seems like it would take a lot of disk space, Ubuntu is hoping disk deduplication will take care of that.

Re:How?

[Anonymous Coward]

All the dependencies, everything. It installs them locally, not for the whole system, kind of like an .app file on OSX.

So.. they install things in Linux containers (or namespaces) and then call it "snappy"? So why not just link everything statically?

Anyway, I don't get it. You can do that already. but you still need to get those apps to communicate with outside world, which means leaky containers at best.

Furthermore, in case of heartbleed, it would mean EVERY single application that uses OpenSSL would have to get rebuilt instead of just getting fixed library and rebooting.

Re:How?

[phantomfive]

You are right, but I don't know the answers to those questions.
I think there is definitely room in the Linux world for a self-contained App container. I don't think it's a good idea to make every package in your package management system self-contained, though.

The Linux community is destroying itself.

[Anonymous Coward]

As a long time Linux user, I'm dumbfounded by how the Linux community has basically turned on itself over the past 5 years.

It's not Microsoft, nor SCO, nor Apple, nor any other external entity that's destroying the usefulness and practicality of Linux. It's the Linux community, as a whole, that's doing this!

Systemd is the obvious example of this. Never have we seen a piece of software so divide and devastate the Linux ecosystem. Whatever small amount of convenience it may bring for the maintainers of Linux distros is more than offset by the many problems that systemd has caused the users of these distros. It doesn't matter if, say, the Debian maintainers' jobs are made easier if Debian itself suffers from reliability problems thanks to systemd that drive the most important Debian users over to FreeBSD.

But that's not the only example. We've seen the usability of Linux on desktops and workstations devastated by awful desktop environments like GNOME 3 and Unity. This mad rush to target "normal" users has been an utter disaster. No normal users have actually decided to use Linux due to these changes, but many long time Linux users have been forced to find alternatives.

If we go back 10 years, to 2005, I never would have expected Linux to be in such dire straits, and all due to problems that the Linux community has imposed on itself. It's really unbelievable how much harm the community has done to itself as of late.

Re:The Linux community is destroying itself.

[Anonymous Coward]

You, and people like you, exhibit the mentality and attitude that is responsible for the ongoing destruction of Linux.

Long time Linux users who use Linux for critical systems repeatedly describe the problems they've encountered with certain pieces of software, such as systemd and GNOME 3. Instead of listening to these users and trying to understand their problems, you and your ilk deny that these serious problems exist, and then attack these users for daring to mention these problems (by wrongly accusing them of "trolling", for example).

Treating users in such a horrible way never ends well. These users just won't put up with it. The most talented, experienced and knowledgeable Linux users have already moved to FreeBSD, or are in the process of doing so. These are the kinds of users who are needed the most by Linux; they're the ones who push for its adoption and use. Linux won't disappear all at once, of course, but a gradual decline is inevitable now that these critical users have been forced out.

We only need to look to Mozilla and Firefox to see what happens when users are treated like dirt. Firefox was once a very popular web browser, with well over 30% of the browser market. But then the Firefox developers stopped listening to what Firefox users wanted, and instead forced unwanted junk on Firefox's users. Even worse, the Firefox developers did not listen to the objections of Firefox's users to these unwanted changes. After several years of treating Firefox's users so poorly, we can see the awful results. Firefox is now under 10% of the market. The users who propelled Firefox to success have moved on to greener pastures, which even include modern versions of IE, as unbelievable as that may be. Now Firefox is seen as a joke browser, rather than the powerhouse that it once was, just a few years ago.

I sure hope that what we've seen happen to Firefox doesn't happen to Linux, but things aren't looking encouraging. There are just too many people like you, who are incapable of seeing the big picture, and more important, incapable of listening to the users of Linux. Not listening to these users and their concerns is perhaps the most harmful thing that can happen to Linux as a whole.

Re:The Linux community is destroying itself.

[Grishnakh]

I'm not sure it's "the community" that's to blame as much as certain large entities in the community (*cough* Red Hat *cough*).

First, about systemd. Exactly what "problems" has it caused the users? On a normal distro, it runs in the background and should be transparent. sysvinit was ancient, and not even Solaris (the last true UNIX) uses it, it switched to SMF ages ago. All the anti-systemd hysteria I've seen has only been about vague possibilities, or whining about "the one true UNIX philosophy" (which again, apparently real UNIX doesn't even follow), etc. Whereas the systemd supporters can actually point to real, tangible benefits. Now admittedly, at home I'm a longtime user of Linux Mint which still runs on upstart for the moment, but I've been using CentOS 7 machines at work and I haven't run into any problems there (except for fucking Gnome3, more on that later). systemd seems to me to work just fine.

However, with Gnome3 and Unity, you're exactly right. The two most powerful and influential distros (Fedora/RHEL and Ubuntu) both changed to awful DEs, which certainly can't be attractive to new users who aren't looking for something that's a complete sea-change from the UIs they're used to. By all rights, KDE should be the default DE: it's reasonably fast, it's pretty bug-free at this point (compared to Gnome3, which is full of bugs in my personal experience with CentOS7), it's full-featured, it's highly configurable to do whatever you want, whether you want it to be more like Windows or like MacOS, and it's a familiar paradigm. Yes, the "semantic desktop" stuff is useless, but it's actually turned off by default on many distros now I believe, and if not, it's easy to disable and simply ignore--I do. So why Linux distros are pushing minimalistic DEs, I dunno. But I'm certainly not the only one who doesn't like them: there's a reason Mint has become so popular, and so many people have switched to Cinnamon and MATE.

Honestly, the big misstep that started most of this crap was the founding of GNOME back in the late 90s, due to the licensing issue with Qt. They should have abandoned Gnome when Qt finally was released under the GPL, then we wouldn't have these issues now.

Re:The Linux community is destroying itself.

[Ol Olsoc]

systemd has already broken the kernel repeatedly, a decade of log collection and analysis tools that I personally use, decades of cross-platform tools, decades of network configuration tools, and now it's trying to replace "su" and "/etc" to create a "stateless Linux". I'm afraid that it's a system management tar baby, adhering to every system component that it touches and leaving them snarled in sticky debris that is difficult to wash off.

It has also made ancient aliens take over the congress, caused otherwise normal peoplr to massacre entire cities, and cancer in everyone. finally, tiny little boils that explode annd throw white hot magma on everyone in cows. systemd is the real cause of all those millions of acres of wildfires in Washington state.

Now tell me. It is apparent that you hate systemd with a white hot passion.

so why are you using it? You do not haev to use it, and if you aren't. what on earth are you bitching bout. I mean really?

ford versus chevy thing?

Re:The Linux community is destroying itself.

[Sarten-X]

Long time Linux users who use Linux for critical systems...

Oh hey, that's me.

...repeatedly describe the problems they've encountered with certain pieces of software, such as systemd and GNOME 3.

Well, yeah. I'm a cranky old fart.

Instead of listening to these users and trying to understand their problems, you and your ilk deny that these serious problems exist...

Now wait just one Turing-completing minute there!

The problems aren't serious. They don't break my critical systems, because I'm not going to be deploying systemd into production until I've tested it thoroughly. My old init scripts will get a wrapper or a rewrite to fit the new OS as needed, but the software interface won't change very much at all. Now, if you want a serious problem, find a vulnerability in a basic system utility, like bash or OpenSSH. Those problems are already out in the wild, deployed to production systems. When a new one of those problems is found, there's a notable increase in the use of profanity around my desk.

A new startup system, or a new package format, or a new thing that does this thing different than how the old thing did that thing... none of those bother me. I'll wait, running my old-but-stable critical systems, until you short-tempered folks settle on exactly what you want to do. I'll then work around whatever issues remain, because that's my job. I'm a sysadmin.

Re:The Linux community is destroying itself.

[Sarten-X]

I call FUD.

Apparently systemd only consumes log messages by default. If you're looking for forensic analysis or troubleshooting, you can turn on forwarding to a normal syslog service like rsyslog or syslog-ng.

Re:The Linux community is destroying itself.

[Grishnakh]

"KDE should be the default DE for everyone because I like it more"

No, it should be the default because it's highly configurable. Any distro can easily make a preferred configuration instead of making an all-new DE. Obviously, a lot of people hated Gnome3, which is exactly why both MATE and Cinnamon were created. I think it would have been easier if they had put that effort into re-skinning KDE.

"Software should have never been created, because having more choice in FOSS software is somehow bad for the Linux ecosystem."

Choice is fine, but there is a shortage of development resources, so it makes more sense to cooperate when possible.

Re:The Linux community is destroying itself.

[houstonbofh]

You have got to understand one thing : Linux is the playground of Red Hat. From top to bottom Red Hat does and the others follow or die. The idea that there is freedom in the open source movement is pure illusion. He who has control of the infrastructure components has control of linux. The other guys are just small fish. Even Ubuntu doesn't go anywhere without Debian, and Debian doesn't go anywhere without Red Hat.

Ironic that you post this in an article that is in no way about rpm... :) I think it is more about developers that have become user unfocused. The "We know what they want more then they do" mentality. That never works well.

Re:The Linux community is destroying itself.

[Billly Gates]

My theory

We saw this in Windows in 2006.

Vista scarred users soo much they freaking stuck with a 12 year old OS after Windows 7 cleansed all the messes of Vista. Some were happy to get Windows 7 and it had measurable marketshare from sites back on the RC days lol. The other half ... XP WORKS FINE!! CHANGE FOR THE SAKE OF CHANGE NA NA.. etc.

Well SystemD tried to be what Init failed to do on a modern system. Event driven Macbooks with startupD could sleep in one time zone and wake in another. :-) Init can't do that. You would need to put in statically every single thing that could possible happen scripted in. Also you would have thousands upon thousands of PIDs on startup too in a mess and I wonder why Unix admins think this should be a normal process?

FYI I am not a pro SystemD supporter at all!

I am just saying my point is Upstart in Ubuntu and SMF in Solaris were similar alternatives and were designed as ... get ready to be meant as an improvement over init. Event driven environments you can set for example a server going read-only if it detects a break in as an example with relative ease for a system administrator. I will state I am not a Unix administrator so I am not qualified to say SystemD is superior. My point is theory and mindsets of users.

So likewise Slashdotters are anxious when they hear improvements = change for the sake of change OMG I remember SystemD and Windows Vista NO even if it has nothing to do what so ever. The brains are trained and wired to resist change now after a bad experience.

But the dangers is like Windows 7 which in every way is superior to XP if you are stuck in Windows land still has holdouts and I see the same in Linux. IN FreeBSD land these users will resist any improvement because we know change is bad to some.

The community needs to get over this and realize change is sometimes necessary and if SystemD is the wrong solution to the problem. Make an alternative? Not say NOTHING WRONG WITH INIT and cover your ears and eyes and go nada nada.

A little background too the reason SystemD has no text output is for security and is a good practice. SMF does the same thing. If I were to r00t your server the first thing I will do is go to /var/logs and change them to hide my activity etc. It is like have passwords in text in /etc/password.d (I am dead serious on that one too!)

Re:The Linux community is destroying itself.

[tomhath]

I think it is more about developers that have become user unfocused. The "We know what they want more then they do" mentality. That never works well.

It works quite well *if* you have a very good designer/innovator. Steve Jobs was arguably the best ever at building a product people didn't know they wanted until they saw his version of it.

The problem is that very few people are good at design, and most are really, really bad. When that happens we have to wait until market forces play out and the design fails.

Re:The Linux community is destroying itself.

[Antique Geekmeister]

An appeal to ridicule is a logical fallacy: if it were an entertaining appeal to ridicule, it might be amusing, and I wouldn't expect pure logic on Slashdot. But please note that it doesn't address or even acknowledge a single one of the issues I mentioned. Many of those issues are architectural and core to systemd development.

And no, I don't "hate systemd with a white hot passion". It does a few things reasonably well, and there are some real benefits to getting faster boot times and kernel logging. The network integration is problematic, but shows some promise.

But systemd really needs to _stop_ trying to replace core system functions with yet another add-on module. And yes, it's trying to take on software packaging, as well.

Re:The Linux community is destroying itself.

[Sarten-X]

So how is that different from when the init script goes and fubars itself, or shits all over a log and you can't fix it? Or what about the kernel itself? What if your CPU is really a small explosive device, planted to sabotage your mission-critical systems? I guess you should go fire everyone who ever puts anything into mission-critical systems, because they might fail sometime.

I am not suggesting that critical failure is acceptable, but I do argue that the expertise, testing, and trust of a new system should all scale proportionally to how critical that system is.

If you absolutely cannot have any failure, your critical systems should be running on a nice mature and well-understood flavor of an old Linux or Unix, stripped down to the bare minimum of utilities and subsystems. It should be attended by top-tier admins, with round-the-clock monitoring and redundancy, and every piece (hardware and software) should have been tested for years before deployment. You should probably also replace the manager who put your company in this single-point-of-failure position as well.

At the other extreme, if a system doesn't matter much, it can be staffed by entry-level admins who can barely spell "Unix", running on the newest and shiniest hardware, and those admins should have the freedom to experiment with settings and configurations until the whole thing catches fire. Then they can fix it and do it again. By the time that new technology is ready to go into production, the admins are now experienced enough to understand the machine they're responsible for, and they should know how to configure it to avoid those critical failures.

Ultimately, you are trusting your production system to work consistently within required parameters. That trust is gained by having reliable testing conducted by people who understand the system. You should be hiring people who can build that understanding, not just those who agree with your prejudices.

Re:Wheres the hate like systemD?

[phantomfive]

This also doesn't follow the Unix philosophy.

What part of the Unix philosophy doesn't it follow?

Replaces a tool everyone is familiar with too

It is a package manager, competing with plenty of other package managers out there. If you use this instead of Yum, it's not going to affect which GUI you use.

Re:Wheres the hate like systemD?

[DeVilla]

As others have already pointer out, you are wrong for assuming this is like systemd, so I won't further beat that horse.

However I think it's foolish for Shuttleworth to go down this path. It's inevitable that systemd will start to require that it get's it's hooks into package management. Long story short, the way fixes are applies to systems is fundamentally broken. Whether it's because someone can't find a way to tell what needs to be restarted or can't impose a way to restart all services without down time or can't find a way to apply changes to all containers or whatever half thought out problem is the excuse, it's broken. And the only fix will be to bundle it into the logic of systemd. Amongst other things, a package format will need to be mandated because supporting multiple formats is stupid or hard or out-of-scope ... you name it.

No one has been able to oppse the systemd maintainers except the kernel developers when it comes users space interfaces. Canonical hasn't been able to stand its ground against these developers in the past. I doubt they will in the future either. Shuttleworth is creating another failure.

Scary Words

[pubwvj]

"completely worry-free updates"

Those are very scary words when ever someone utters them because they seem to fail to comprehend the fact that testing is not perfect. I have real work to do. When they F*sk my system with an update that fails and it loses my data or prevents me from working, just once, it can be a huge disaster for me. Multiply that times all the users. Not an issue for the developer. Completely worry-free updates. Not.

Re:Scary Words

[Gaygirlie]

When they F*sk my system with an update that fails and it loses my data or prevents me from working, just once, it can be a huge disaster for me.

But isn't that exactly what these Snappy - packages are meant to address? All the current data for the application is backed up, the update is applied, if something goes wrong the system rolls back to the state the package and its data was before the update was attempted. At least that's what it says on Ubuntu's website, I don't know anything else about this thing.

Famous Last Words

[JustAnotherOldGuy]

"The nice thing about Snappy is that it's completely worry-free updates"

Any time anyone says something is "completely worry-free", that's your cue to worry. Ask me how I know.

Re:Famous Last Words

[phantomfive]

Ask me how I know.

How do you know?

Re:My theory

[squiggleslash]

Can someone explain to me why an article on a serious change in Ubuntu that has zilch to do with systemd has been hijacked by the systemdaphobes?

Unlike systemd, this change actually appears to have significant negative repercussions, not "I'm not actually an old system admin but I pretend to be on Slashdot because I hated pulseaudio and by god I'm not going to let the author of that replace a crusty, unreliable, set of shell scripts and get away with it" type "trying to find excuses to bash it" type stuff, as we see with systemd, but real concerns about cross-distro compatibility, and change-for-change's sake.

So it'd be nice to have a discussion about it.

These seems to be a theme on Slashdot lately. People want to hijack barely related threads to discuss something that makes them hot under the collar. And, perhaps not surprisingly given the mentality needed to hijack unrelated discussions, it seems that the views they express are generally trollish and slimy.

Can you let us discuss Snappy? Please? It sounds like it has serious ramifications to me. Tell you what, if you STFU, I won't troll - and encourage other Ubuntu users to troll - the next systemd article. Deal?