Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Traditional package management systems already use transactional updates, and have checksums, so you have the same reliability now; these updates just roll them out without version numbers. 'Read-only' is also redundant, as everything owned by root is basically read only.

View on HN

One problem with traditional package management is with maintainer script failures, which then leave the packaging system in a broken state. As the bug database shows, this is not uncommon.

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

> Traditional package management systems already use transactional updates

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.

Worse, if an app is updated whilst it's running, it can cause arbitrary crashes and data corruption.

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.

Hey you're the autopackage guy!

The notes are still around afaict: https://wiki.ubuntu.com/AutopackageIntegration

Hah, that brings back some memories! 2005?! Yes, it must have been around a decade ago now.

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

Hello again! Hope you like the snappy story, sorry it took us a while to JFDI :)

I do like it! Best of luck with the project! :)

Not so much "the old guard he had to deal with hated the idea" and "bought into the idea that the way Linux managed software was awesome and superior", but...

closer to...

"changing a fundamental building block needs to solve a user problem" (and there are multiple kinds of users involved). :-)

That's true. I'd be happy to learn how snappy is immune to random system failure, I just didn't see it in the write-up; need to research it more.

They have versions. Also, easy rollback.

    ubuntu@localhost:~$ snappy versions
    Part         Tag   Installed  Available  Fingerprint      Active
    ubuntu-core  edge  141        -          7f068cb4fa876c  *
    docker       edge  1.3.2.007  -          b1f2f85e77adab  *

I the "read only" bits refer to them dropping the update into a new place, rather than overwrite existing files. This makes rollbacks fairly simple, as the old version is still sitting there.

Reply on news.ycombinator.com