View Single Post
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#154
Originally Posted by jukk View Post
I've many times wondered why not software releases could be handled like in a linux distro. Just push new versions of packages into the repo and let users upgrade.
Even if you consider the slightly different usecase - a deskstop/laptop vs a mobile device you use for call/take photos/send SMS/as an alarm/email/etc. and possibly less technical users for mobile devices than normal PCs. So the mobile device breaking due to software update can be more serious and the user could be less likely to fix the issue.

But "update everything any time" is far from clear cut even in normal Linux distros.

For example in Fedora, there are quidelines what types of package updates are allowed for a stable release (currently Fedora 28) and even then all packages have to pass a community QA process before they reach the repositories.

For this reason many core components (GCC, Gnome, Python, GCC, glibc, etc.) are only receiving bug fixes for a stable Fedora release and major updates only go to users via new stable release, like the upcoming Fedora 29, so that major bugs and integration issues can be worked out before peoples machines break.

Still, what I think is definitely wrong at the moment is that even critical security updates are bundled with feature updates on Sailfish OS. Those should get out as soon as possible, not being possibly blocked for weeks by bugs in feature work.

And what about the future ?

The atomic/silverblue project looks like a good candidate for addressing many of these and other issues.

You basically have an immutable base system tracked by ostree that you can update atomically and even keep more than two different versions and switch between them as needed. All this is also deduplicated, so you are storing only the changes, not multiple copies of rootfs.

As for applications, they live in containers (Flatpacks in case of Silverblue) that are sandboxed from the base system and should not break when the base system is updated.

Note that this would also fix many of the Jolla Store API issues, as the application containers/Flatpacks would share a number of runtimes instead of using libraries from the base system directly. So this way you could update libraries and available API separately for apps and base system, without breaking the other in the process.

You could also have more than one application runtime available at the same time (say Qt 5.6 based, Qt 5.9 based, Nemo/Glacier based, etc.) making it possible to run unmodified older applications while making new APIs and libraries (possibly with breaking changes) available to new/updated applications.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 7 Users Say Thank You to MartinK For This Useful Post: