4 ms·

> Traditional package management systems already use transactional updates Sort of, ish. When things actually get copied to the filesystem, if the process cras

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

mike_hearn 12y ago
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.
- jcastro 12y ago
  Hey you're the autopackage guy! The notes are still around afaict: https://wiki.ubuntu.com/AutopackageIntegration https://wiki.ubuntu.com/AutopackageIntegration
  - mike_hearn 12y ago
    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 :)
- markshuttle 12y ago
  Hello again! Hope you like the snappy story, sorry it took us a while to JFDI :)
  - deleted 12y ago
    [deleted]
  - mike_hearn 12y ago
    I do like it! Best of luck with the project! :)
- jdub 12y ago
  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). :-)
sre_ops 12y ago
This is a solution in search of a problem. Systems are not and will never be 100% reliable. This means that at any time you need to deal with a possibility of a corruption of executables. So update is nothing else than -> fail out the system -> perform update -> validate system -> insert a system into the workflow. What we have here is a pile of companies that need to be relevant with their square wheels so they are coming up with all kind of ways to make their wheel diamond shaped.
peterwwillis 12y ago
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.

mike_hearn 12y ago

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.

jcastro 12y ago
Hey you're the autopackage guy! The notes are still around afaict: https://wiki.ubuntu.com/AutopackageIntegration https://wiki.ubuntu.com/AutopackageIntegration
- mike_hearn 12y ago
  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 :)
markshuttle 12y ago
Hello again! Hope you like the snappy story, sorry it took us a while to JFDI :)
- deleted 12y ago
  [deleted]
- mike_hearn 12y ago
  I do like it! Best of luck with the project! :)
jdub 12y ago
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). :-)

sre_ops 12y ago

This is a solution in search of a problem. Systems are not and will never be 100% reliable. This means that at any time you need to deal with a possibility of a corruption of executables. So update is nothing else than -> fail out the system -> perform update -> validate system -> insert a system into the workflow. What we have here is a pile of companies that need to be relevant with their square wheels so they are coming up with all kind of ways to make their wheel diamond shaped.

peterwwillis 12y ago

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.