A Look At The Most Promising Next-Gen Linux Software Update Mechanisms

[phoronix]

Phoronix: A Look At The Most Promising Next-Gen Linux Software Update Mechanisms

With traditional software package management solutions like APT and Yum showing their age and not adapting well to the embedded world and the slew of new areas for Linux like IoT, a new generation of atomic-based Linux software update solutions continue to be worked on. Matt Porter of the Konsulko Group is presenting at this week's Embedded Linux Conference Europe 2016 with a comparison of these update technologies...

http://www.phoronix.com/scan.php?page=news_item&px=ELC2016-Software-Updates

[Alliancemd]

It's nice that you can rollback. OSTree is nice, it is better, but they don't solve the problem that well.
I think Habitat solves the problem properly and it doesn't care about the distro you have. It's a static binary that has 1 single requirement: Linux Kernel 2.6+.
Their website: https://www.habitat.sh/
Here is for example how the GDB package looks like in Habitat: https://app.habitat.sh/#/pkgs/core/g...20160926185837
Pay attention how specific it is about it's dependencies. Full reuse between applications, while still being completely isolated when needed.

I understand that it does not have exactly the same goal as OSTree, but I don't see why it couldn't update your entire system.

[Steffo]

It would be cool, if modern package managers would be written in modern and more secure programming languages. Well, yes, one is writte in Go, but the rest still in C!
Hey guys, there is C++ 11, C++ 14 and rust, too!

[johanb]

It would be cool, if modern package managers would be written in modern and more secure programming languages. Well, yes, one is writte in Go, but the rest still in C!
Hey guys, there is C++ 11, C++ 14 and rust, too!

Newer != better

Also, C11 is a thing if you believe that newer is better.

[Nille]

It's a static binary that has 1 single requirement:

Why from one extreme to another one?

[starshipeleven]

Are those "atomic updates" like transactions that can be rolled back?

kinda
atomic in IT means that the operation is either successful 100% OR fails 100%.
You don't get silly situations where the operation fails in the middle of updating files/records and leaves the system/filesystem/database in an inconsistent state.

[kobblestown]

Why from one extreme to another one?

I imagine that when it's statically linked it cannot be screwed up by a borked library that it depends on.

[sdack]

"... similar to OSTree but does not require reboots to activate bundles."

I am beginning to wonder about RedHat's management when I read that they are in support of this. Call APT old, but not needing to reboot for 99% of all updates has always been a big win for me. I hate how Windows always wants to reboot and forces people to close running applications, to log back in and to start over. And here we have RedHat supporting just this kind of crap.

My picture of RedHat is changing and I'm hoping M$ is going to buy them up. I bet RedHat's management would be excited about the takeover and make them feel like a reboot.

[macemoneta]

"... similar to OSTree but does not require reboots to activate bundles."

I am beginning to wonder about RedHat's management when I read that they are in support of this. Call APT old, but not needing to reboot for 99% of all updates has always been a big win for me. I hate how Windows always wants to reboot and forces people to close running applications, to log back in and to start over. And here we have RedHat supporting just this kind of crap.

My picture of RedHat is changing and I'm hoping M$ is going to buy them up. I bet RedHat's management would be excited about the takeover and make them feel like a reboot.

As a commercial enterprise, Red Hat is worrying about the 1% of updates that do screw up. In order to make it bullet proof, they perform the update in a special pre-boot environment, since reboots only happen at scheduled maintenance. Desktop users are OK with something that works 99% of the time, so this doesn't apply to them.

[sdack]

kinda
atomic in IT means that the operation is either successful 100% OR fails 100%.
You don't get silly situations where the operation fails in the middle of updating files/records and leaves the system/filesystem/database in an inconsistent state.

That's not atomic what you are describing, but binary. Binary and digital are the words commonly used to describe an operation as having exactly two possible outcomes.

The word atomic depends entirely on the context in which it is being used in and usually, but not always, describes something as being whole, singular, complete or enclosed for example. It is really only a Greek work meaning "cannot be cut or divided". There is also no a guarantee that an author who uses the word knows about the word's origin and so it's meaning begins to drift. Traditionally have system calls such as read() and write() always been described as atomic operations, and they still are, yet can these be pre-empted and interrupted making them not so atomic as the word itself might indicate. Only within their context of being I/O operations do these give a guarantee on a certain behaviour.

It's then no different with package managers and the exact meaning of what atomic means for them depends on each package manager.

Funny though, last time we talked about package managers, could you not grasp how one can serialize update operations in order to interleave and stream them. And here you are talking all proud about atomic updates. Looks like you've levelled up. Congrats!