Announcing Ubuntu Core, with snappy transactional updates
markshuttleworth.com
markshuttleworth.com
That being said, at a glance Ubuntu Core looks like it might be better for the simplicity it brings to the table. It looks like it's making the images based of regular Ubuntu behind the scenes [2], but isolating everything for you and making things a lot more atomic. In short, it's a lot less foreign of a system than Nix.
Those are my general thoughts. I haven't actually used either of them, but Nix has captured my attention in the past for the problems it claims to solve.
[1] http://nixos.org/nix/ [2] https://news.ycombinator.com/item?id=8724049
I really look fwd to playing with UbuCore.
Agreed that this could be very cool.
It's these simple solutions that make me tick :)
I like that a lot, too. It's a great example of taking a step back, examining a problem from a different perspective, and coming up with a better, simpler solution than the current state of the art.
Edit: I ask because I understand it's a package manager so I find comparisons to other package managers, but not to provisioning systems
Basically Nix obsoletes much of Puppet&co, to the extend that you probably want to go without it.
On top of that Nix also provides great means for deployment.
Maybe there's a way to convert or bootstrap any Linux OS into a NixOps-compatible distro. But I didn't see anything.
For example, let's say package A v1.0 is using some dependency B v3.0:
B v3.0 --> A v1.0
B v3.0 --> A v1.0
B v3.1
B v3.0 --> A v1.0
B v3.1 --> A v1.0
B v3.0 --> A v1.0 --> chris-profile-1
B v3.1 --> A v1.0 --> chris-profile-2
To get two machines into the same state (the use-case of Puppet and friends), we just need to install the same profile package on each. There's a Linux distro called NixOS which uses Nix to manage all of its packages and configuration.
In fact, since we can install multiple profile packages side-by-side, we can use profiles as a poor man's container. They don't offer strong protection, eg. in a shared hosting environment, but from a sysadmin perspective they give us some of the non-interference advantages (eg. no dependency hell, since there are no package conflicts or version-unification difficulties).
If we want a stronger containment system we can use NixOps, which gives Nix packages a Vagrant-like ability to provision and spin-up real or virtual machines, EC2 instances, etc. For example, we might have a "DB server" package.
If we want to orchestrate these services, we can turn them into Nix packages using DisNix; then we can have packages like "Load Balancer" which depends on "Web Server", which in turn depends on "Users DB".
I have to admit I've not used NixOps or DisNix, but I do use NixOS as my main OS and have grown to love it :)
I recommend copypasta-ing this to an FAQ associated with Nix!
I think that for package installation and rollback, a simple model like that proposed by DJ Bernstein with slashpackage http://cr.yp.to/slashpackage.html seems to accomplish the same goals but with much less complexity.
* Transactional updates across instances: Let's say I have app, web, db, and some other roles of servers. How can I ensure all coordinating sets of instances to get updated altogether or not? For example, I don't want my app servers end up with a previous version of postgres adapter while my database is already updated.
* Memory requirements: does the approach increase the total memory requirements?
* Security: do we need to rely on a 3rd party for updates or can we still compile or own subcomponents? ( We had to in recent bash vulnerabilities)
* Security: If every image sits with its own copies and versions of each subcomponent, do we end up having to prepare a permutation of different images to ensure all is fine?
* Updates: Does it make integrators get lazier and end up with a lot of obsolete or non-improved versions of many subcomponents?
* Architecture: Do we give up the idea of reusable shared building blocks at this level of abstraction (sub-instance)?
* This seems like it would be coordinated by fleet, mesos, kubernetes. If I recall, some of these would allow you to direct new connections to new instances. For databases where clustering requires more sophisticated upgrades, it might have to be manually rolled/scheduled, but could probably be scripted with these.
* Memory requirements: Generally yes, but the thought process is that by having a read-only filesystem for most data, deduplicating filesystems (BRTFS, ZFS) can reduce your memory and storage requirements.
* Security is the toughest nut to crack. You're right, if a package incorporates BASH as a simple shell to run exec against, then you end up dependent on the app provider to use that. Likewise, openssh, libc, other libraries seem like you could get stuck with whatever the app developer has packaged. Alternatively, it looks like if there is a security fix, it should be easy to handroll your own temporary version by unpacking a package, dropping in a new lib, and repackaging. Hopefully they're not pushing for static compilation (which would defeat my argument on memory as well.)
* Updates: Yes, but the same problem happens when everyone has long dependency chains. Instead of laziness, it becomes a hurdle to overcome to get people to up their constraints and incorporate fixes. At least this way, every app developer can ship what works for them.
* Architecture: The reusable component aspect would likely shift closer to compiler/build process. e.g.: Look at how Cabal for Haskell and Cargo for Rust work (and occasionally, fail to work.) I think the goal would be to have reliable, repeatable builds using components managed by something else, using repositories of source code/binaries to build against.
This is getting into a pretty tangential discussion, but I'd be surprised if there are net memory savings from deduplication. Disk yes, but the dedup process itself has significant memory overhead (both in memory usage, and memory accesses), which would need to be offset to have a net win. At least on ZFS, it's usually recommended to turn it on only for large-RAM servers where the saving in disk space (and/or reduction in uncached disk access) is worth allocating the memory to it.
BTRFS currently only supports offline, and I believe the current state of ZFS is only online. A curious situation, but I imagine ZFS will eventually support offline dedupe and with that, the memory requirements will fall in terms of what needs to be cached.
And memory usage would decrease, because offline dedupe on read-only files reduces duplication in cache. Even memory-only deduplication would be sufficient. I'm not sure if zswap/zram/zcache support it, but it seems like a worthwhile feature.
It's often overlooked, but Android devices are really low system administration high availability Linux systems. That they work as well as they do is kind of crazy, and a lot of it is down to the application packaging and isolation mechanism. This Canonical stuff is going to generate a lot of noise, but it is the way forward.
Ultimately between this, containerization and virtualization, we're witnessing the death of the whole dll concept long after dll-hell became a thing.
Low maintenance partially because they are functionally very limited ( much of what the kernel and userspace can do is locked-out) and partially because the mission-critical stuff lives in seldom-updated firmware.
High availability... Given how often 'reboot your phone' or ' clear the app data' is given as advice?
I just don't see many parallels with server environments.
The partitions that get updating are completely separate from user data. This myth keeps spreading for some reason though...
The only time user data gets wiped is when unlocking the bootloader which is a very valid security feature in order to prevent bootkits and data theft. It gives big clear warnings to backup your data before doing so.
Mine Samsung S4 mini reboots by itself once in a few days. Hadn't bothered to catch the reasons. And it surely knows how to hang itself for half a minute when doing large app updates or otherwise IO-heavy operations.
A limited functionality device that services a specific purpose, if we were to take it to the world of the web, would be a webservice.
If you were having a problem with one of your puppet&co managed web servers on some cloud host, would you: a. perform root cause analysis. b. redeploy the entire machine because fuck it, you have your recipes or whatever and spinning up a new instance is a super cheap operation.
That's what I read into when I think about the grandparent.
Pretty much every device out there has multiple known security holes and they're not getting updated.
What was your point exactly in that respect?
I think this snappy scheme of Ubuntu might actually be what Android should have had from the start. It seems like it work in the embedded space when you don't want a traditional package manager.
Just because a few phone vendors stop pushing out updates after a period of time after launching the phone doesn't mean that Android doesn't support it. This might have been a valid criticism about years ago. But one that should be aimed at vendors and not Android.
Regarding vendor support, Google launched an initiative called "Compatibility Program" which every vendor must now agree to. Part of the agreement means they are required to support OTA updates if they plan to use the Android OS.
https://source.android.com/compatibility/overview.html
So I don't know what you're basing this off of?
All of which could be fixed with something like Snappy where the OS component that is improved could be pulled OTA by the customer.
The meta discussion is that customer cannot do that because a handset maker has no way of reasoning about how changes to a component of the system will affect all handsets out there, and so new versions of android sit in all-or-nothing testing limbo at the handset QA lab.
I know for a fact (because I've created my own ROM) that Android's OTA system is fully capable of updating single components. And the update the user downloads is not the entire ~200mb Android ROM, it could be a small 1mb zip file that only updates a specific library. For example a security release updating only OpenSSL.
Why Google doesn't do this and prefers using a point release system - instead of rolling releases - is a complicated question. One that I'd be curious to hear the reasoning for.
One UX consideration is that the users need to reboot their phone since the OTA update writes to the /boot partition and then triggers a reboot into recovery mode. Then recovery mode will automatically install the new update (preserving all user data) then boots back into the OS. This would be annoying to users if they had to do it often.
But the same behavior exists for any OS updates on OSX, linux, etc.
It's not a viable method for updating generic servers however. An update system needs to do a lot more than just swap out a file. You need to know about dependencies, restart services etc. It's also important for real world usage to be able to skip one update for one reason or another.
It could be interesting for single purpose Docker containers which can be restarted at will.
Yes, the Android ecosystem has an update problem. But that problem is largely due to external companies and not a technical limitation of Android.
So what OTA updates do you mean? If you mean stock Android updates removing root access...then that is exactly the expected behavior. Root is considered a security hazard and not supported by ASOP. As it should be.
I find it hilarious when people who use ROMs complain about how hard it is to modify the OS then complain about lack of security updates in the same thread. Bootloader locks and read-only filesystems are there for a very good reason.
perhaps we're talking past each other... because you seemed to miss my point... phones don't update single packages as updates are available like a typical linux distro would.
See my other comment, Android's OTA system is fully capable of updating single components. The downloads can be patch releases and not full images. Google actually recommends that vendors do this, over pushing full ROMs.
Vendors often don't do it because they are lazy or for logistical reasons. But it doesn't mean they can't.
That's a device/vendor choice, not Android as a whole.
> and when SELinux went into enforcing mode
On my stock rom it was in Permissive mode, as it is now on Cyanogenmod.
> Google is attempting to help protect users from bootkits/rootkits which has a side-effect of making modding harder
This is generally not Google's doing, it's the device manufacturers/carriers. And it's not always in the name of end-user security... which far too often abandon any updates on 1 year old devices.
> See my other comment, Android's OTA system is fully capable of updating single components
But it's not really. It's just downloading a zip file and extracting it. There is not 'apt-get' or 'yum update' functionality built into Android, and there probably can't be due to how custom every rom (even stock from the manufacturer/carrier) is. I would love it if my phone could do a "yum update" like thing and just yank down individual components as soon as they are available... but that's not reality unfortunately. When users do get updates, it's usually months after they were discovered to be at risk for some exploit due to carrier bureaucracy.
> Google actually recommends that vendors do this, over pushing full ROMs.
Mostly in the name of saving bandwidth for data capped users.
> Vendors often don't do it because they are lazy or for logistical reasons. But it doesn't mean they can't.
I think we agree here, but for different reasons.
However my busybox updater app does run in the background and does update busybox as needed automatically. Same with my su updater. So I suppose parts of my android are indeed auto-patched without my noticing.
/beingargumentative :)
By all conceivable notions, no.
My devices restart for system updates and that's pretty much it.
I'll eventually have to replace the hard disks - I have seen SCSI to CF and SCSI to SDCard adapters that may do the trick.
"you have no way to even specify them and each application has to bundle them all..."
Yeah, I think you're confusing a dependency free heaven for a dependency mess.
I'm not sure from this article how Snappy actually works. Are they repackaging everything they need for Snappy?
https://anonscm.debian.org/viewvc/secure-testing/data/embedd...
Lots of these have colourful/active security histories (esp. poppler, zlib, pcre, libpng...)
Or if you want to do it yourself:
1) brew install qemu # and prepare to wait!
2) qemu-img convert -O raw ubuntu-core-alpha-01.img ubuntu-core-alpha-01.raw
3) VBoxManage convertfromraw ubuntu-core-alpha-01.raw ubuntu-core-alpha-01.vdi
qemu-img convert -f raw -O vmdk ubuntu-core-alpha-01.img ubuntu-core-alpha-01.vmdk
https://hostr.co/86EDIcFMF7QH for the lazy ;)
(Guest additions was trickier than usual).
"An Atomic Host is a lean operating system designed to run Docker containers, built from upstream CentOS, Fedora, or Red Hat Enterprise Linux RPMs. It provides all the benefits of the upstream distribution, plus the ability to perform atomic upgrades and rollbacks"
The surprising thing is that you cannot run Snappy on Docker - but perhaps there is the whole inception like thing going on there. Docker -> Snappy -> Docker -> Snappy.....
bzr: no longer in active development.
Landscape: very well established.
Mir: not really a wide-reaching project (AFAICT). It fits in between existing well-defined APIs (a handful of toolkits on one side, and hardware on the other), and can be implemented fairly independently by a separate team.
That doesn't leave very much to "spread themselves so thin". It comes down to spreading over two main areas: client devices, and cloud.
With client devices, it makes sense to cover multiple form factors with a single code base. That's Unity 8 across phones, tablets, etc. That's not spreading out to me; it's just being smart about code re-use.
With cloud, it makes sense to look at Openstack on the host and transactional updates on the guest. That's hardly "thin".
Dropping bzr from active development is surely an illustration of how "spreading themselves so thin" exactly what Canonical is not doing?
Naming a pile of buzzwords doesn't by itself provide any evidence of your claim. Especially when some of these are flat out wrong because they (quite publicly) aren't under active development any more.
> seeing what sticks
Upstart remains excellent and nothing else existed at the time. It preceded systemd by a large margin. bzr is much the same. It pre-dates git.
In [1], Jelmer Vernooij writes: "Some people claimed Bazaar did not have many community contributions, and was entirely developed inside of Canonical's walled garden. The irony of that was that while it is true that a large part of Bazaar was written by Canonical employees, that was mostly because Canonical had been hiring people who were contributing to Bazaar - most of which would then ended up working on other code inside of Canonical."
It isn't so much that Canonical conceives of a project and goes off on its own direction; more that Canonical ends up hiring community members who are already contributing, who then make decisions they would have made anyway but with Canonical hats on, and larger community less aware of the details attribute this to some kind of secret internal Canonical policy decision.
I think that neither of these were about "seeing what sticks", since at the time they were conceived there weren't any other clear alternatives. And nothing else in your list is yet unstuck, so that hardly demonstrates that this is some kind of policy here.
Disclosure: I work for Canonical (but here I speak for myself, not for Canonical).
[1]: https://www.stationary-traveller.eu/pages/bzr-a-retrospectiv...
But doesn't it still need to be supported for 5 more years because of 14.04 LTS?
In addition, it's still the default for ChromeOS and not much interest has been expressed in a switch. Anything new on that frontier?
Sure it does. I'm not familiar with the details, but I believe that Upstart development was primarily one person prior to the decision to switch to systemd. Supporting existing stable releases surely requires far less. So it's hardly an onerous burden.
There is also the question of supporting packages that integrate with Upstart (eg. via Upstart init script), so this involves some more work as we'll be supporting packages that use Upstart (in 14.04) as well as systemd (from Vivid, if we complete the switch this cycle).
But I still don't think it's so much work as to be considered a contributing factor in "spreading themselves so thin". It's not even close.
> In addition, it's still the default for ChromeOS and not much interest has been expressed in a switch. Anything new on that frontier?
No idea, sorry. Not my department. I know that Upstart is pretty solid though, with particularly high quality code and comprehensive test coverage. There aren't any major feature gaps either, apart from extra new stuff that you may or may not want. So I don't see much of a problem in continuing to use it for a while yet. I expect it to bitrot slower than an average project.
Smartphones? Ubuntu Phone. Also Ubuntu for Android Smart TV boxes? Ubuntu TV AWS? OpenStack CoreOS? Ubuntu Core DVCS? Bzr Windows 8 Metro mode? Unity
The problem is most of these don't do their jobs well. I think they'd be much much better off focusing on one or two rather than attacking on so many fronts. I still use Ubuntu on the server but everyone I know has moved off ubuntu on desktop for OS X, mainly because of how slowly Unity has improved.
What's left unannounced? Ubuntu VR. Ubuntu watch. Ubuntu Glass. Ubuntu Play. Ubuntu Search . Ubuntu taxi? Ubuntu bnb? Ubuntu drive (again), Ubuntu Robot? Ubuntu drone? Ubuntu.js?
Edit: As a power Ubuntu user, I wish Ubuntu gets more concentrated on certain products rather than lose energy on multiple fronts.
juju isn't really config management.. its orchestration, and its been around since before that was cool (4yrs). thankfully orchestration is in revival mode as the hot thing in devops is containers which obviate a good portion of the install side of config management, and leaving discovery, provisioning, resource management, etc around.
maas is standalone.. and is pretty cool imo, as a an api for controlling baremetal machines (ipmi, libvirt, pxe, etc) with cross os support and used on everything from super computers to intel nucs.
It's a lot more than configuration management. It's coordinating multiple machines across a cloud (public or private) - we call it "orchestration". It's not just "install this software on this machine", but "install this service (may be multiple packages of software) on N machines that are dynamically allocated from the cloud, hook it up dynamically to this other service on M other machines, and scale it all up and down." All with just a few trivial commands from the user. The GUI is just a tiny piece that tries to communicate the enormity of what Juju is doing behind the scenes.
With a few drag and drops on the GUI or a few commands on the CLI, you can deploy an entire openstack onto your hardware in minutes instead of hours or days. You can configure a highly available web front end, connect it to a highly available database cluster, with log collection and monitoring... again, this is something you can set up in minutes, not days.
Juju uses puppet and chef etc to configure machines - that's what those tools are good at. But Juju is at a higher level - connecting the machines together into services, and connecting the services together into an application.
Here's a post about deploying a fully functional Hortonworks Hadoop cluster in less time than it takes to go to get a cup of coffee at the local coffee shop: http://www.bigdatachat.net/when-amir-met-juju/
ubuntu@localhost:~$ snappy versions
Part Tag Installed Available Fingerprint Active
ubuntu-core edge 141 - 7f068cb4fa876c *
docker edge 1.3.2.007 - b1f2f85e77adab *Sort of, ish. When things actually get copied to the filesystem, if the process crashes or fails during that time, (a) it could cause a state where the system might not be able to boot, and (b) they tend to complain loudly and require manual assistance. This isn't great for embedded or even mass consumer systems.
I'm really glad Linux is finally moving beyond the curse of apt-get. I wrote a framework a long time ago for building distro-neutral binary installer/package hybrids and eventually walked away ... back then Ubuntu was brand new and Shuttleworth was even warm to the idea, but the old guard he had to deal with hated the idea. Other distributors were even worse. They had all bought into the idea that the way Linux managed software was awesome and superior to every other OS, even as new operating systems were designed and shipped that universally did not use it.
The notes are still around afaict: https://wiki.ubuntu.com/AutopackageIntegration
It was written in thousands of lines of bash because back then, I had used some random distro that didn't have Python installed out of the box so I became convinced that only bash would be compatible enough. No clue if that perception was actually right - Python would probably have worked well enough. The GUI was in C/GTK. Some of the binary compatibility tools were an unholy mix of bash, C and assembler :)
closer to...
"changing a fundamental building block needs to solve a user problem" (and there are multiple kinds of users involved). :-)
> 'Read-only' is also redundant, as everything owned by root is basically read only.
Much of the core system runs as root, though, and can change system state that you then have to manage (with backups, careful handling of this state during upgrades, etc).
I back up / on the systems that I really care about. This is why. If / is read-only and only comes from an image, then I don't have to; I only need to make sure I have my image, and back up the parts of the filesystem that can change, which is far more limited.
This has been part of the kernel and Ubuntu for a while but this new workflow changes this up a bit.
The only mention of security is the use of user-space AppArmor MAC and sandboxing but no mention of whether image-based updates can support updating a block signature.
>You can run systems as canaries, getting updates ahead of other identical systems to see if they cause unexpected problems. You can roll updates back, because each version is a complete, independent image.
I can't be the only one that sees a hypervisor (cloud host), virtual machine and docker containers, 3 layers for what? For ease of use?
So you have more infrastructure to monitor/keep updated etc for that same software/service which you used to run on the machine that is now the hypervisor/cloud host? For which again you need more resources, as even though the layers might be efficient, they still require resources.
Why would one want to keep old stuff around? With minor naming differences, creates room for a mistakes too. "oh wait no we should have started version 201401018 instead of 2014010218"
I don't see any benefit over physical machines with some proper thinking before upgrading, preparations.
But, should we really consider debian packages obsolete? IMHO apt-get begin-transaction,rollback,commit commands would be great to have too - I would love them even if I'm required to convert all filesystems to btrfs or ZFS, and keep one or more snapshots.
Its gotten better since the days I was mucking about with hpux ignite to make sure all the systems were running the same software/libraries.
But there are still a lot of complex inter-dependencies of the base OS and the Apps running on top of it. It would be great to decouple the two, but I'm a little skeptical that these updates still won't require some testing of software running on them before deploying.
Or are the linux libraries stable enough that these migrations are easier now?
That's exactly what's happening. You don't have to use this new stuff. If you want to continue doing things the traditional way, you can continue doing so.
> ...as new options to apt-get...
This isn't technically feasible IMHO, as somebody who has hacked on apt-get code. apt-get and dpkg work quite fundamentally differently, at package level. Snappy works on full system image level. It necessarily must be a separate thing.
> ...push the whole thing up to Debian so they can benefit too?
This might well be possible in the future, but it needs adoption at the system and image publication level, rather than just as features in a few Debian packages. It's a very fundamental paradigm shift. This is something that Ubuntu's development model excels at, and the sort of change that only happens in Debian at a glacial pace and with a team willing to put a huge effort behind it. But the code is Free Software and is already available; it would just need the political will and the integration effort. So while I'd like it to happen, I'm not sure that it will, just because of both the technical effort and politics involved. I'd be happy to be proved wrong, though.
That way clients can see the exact changes at https://github.com/Webconverger/webc and even roll back or use branches. Not to mention enjoying all the other git compatible tooling.
Also after skimming through http://www.ubuntu.com/cloud/tools/snappy (A snappy tour of Ubuntu Core!) it seems that snappy duplicates some of the functionality of Docker.
I will be very pleased with getting the first of these, though the way it's handled, it looks like we get all three. The important thing, though, is having larger transactions (update tools X, Y, and Z at once or fail), and it looks like it should be possible to do this.
That should change within the hour, as I'm in the process of installing Ubuntu Core on my lappy.
I don't feel saying them as either bad or good compared to Nix. Until you try a system, there's little to say only from the theory.
We'll see how Ubuntu Core with snappy performs, and this question will be more relevant in a few months.
Nix is not perfect but certainly has a long story maintaining this kind of packaging.
"vagrant init therealmarv/ubuntu-core"
[edit] FWIW, my task list this morning has "build custom base 14.04 image from ubuntu core".
I have asked on askubuntu a while ago, [1] and noone brought up this.
[1] Where do I start to create my own Ubuntu derivative? http://askubuntu.com/questions/483002/where-do-i-start-to-cr...
disclaimer: I work for Canonical, but not on anything at all related to this, though I do really love the sound of it.
Anyway, kudos to the Ubuntu team. I even like the customization of the Search bar.
It looks like "windows way" - instead of solving dll-hell problem we would make "images" and restore them when a system is crashed.
But this will not solve dependency-hell problem, because it is about standardized, well-defined, stable interfaces (like BSDs or Plan9 are trying to maintain), not file systems or VMs.
Worst pitch analogy ever. You mean 2 years late to the party if at all? The reason the iPhone works so good is that carries have nothing to do with the phone.
> "The Snappy project develops libsnappy, a download library based on libcurl. It will support metalinks and segmented downloading. The emphasis is on simplicity and lightness, while providing fast and robust download capabilities"
Does Snappy use ceph?
It would be ultra-cool if I use Ubuntu Core as my server, build a particular configuration that I'm happy with and in a single click is transformed into a Docker package that I can deploy to dozens of machines.
All the people that want what is "traditionally considered Linux" why don't they go and use a traditional Linux?
They idea is that a lot of what "traditionally is considered Linux" (and UNIX) is decades old, designed before the current era of multicore/cheap SSDs/mobile devices/wireless connectivity/laptops/multi-TB filesystems at home/hi-dpi composite visuals/touch interaction/unicode everywhere/etc etc, and is not the be all end all of how an OS should be, nor the pinaccle of OS design...
When I started using Linux, there was no package management, glibc was nowhere to be found, there was no "/proc", and so on.
Linux has changed drastically on a semi-yearly basis for well over 20 years, and many of the distributions have changed in vastly different ways.
Packaging systems being one of the things that have diverged the most widely over the years.