Notices


Reply
Thread Tools
Community Council | Posts: 4,442 | Thanked: 11,089 times | Joined on May 2012 @ Southerrn Finland
#151
Originally Posted by nieldk View Post
version is 1.16.10 - but that doesnt say whats fixed or not
https://github.com/sailfishos/sailfi...270d577135af4e
__________________
Dave999: Meateo balloons. What’s so special with em? Is it a ballon?
 

The Following 3 Users Say Thank You to juiceme For This Useful Post:
Posts: 78 | Thanked: 323 times | Joined on Jul 2012 @ Finland
#152
I've installed 2.2.1.23 without problems (Xperia X). I remember jolla have similarly in the past released intermediate versions without officially announcing them. I'm not sure about the purpose, though.

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.
 

The Following 6 Users Say Thank You to jukk For This Useful Post:
nthn's Avatar
Posts: 649 | Thanked: 2,364 times | Joined on Jun 2014
#153
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.
That makes sense, but in practice most users would simply stop updating, because you can't see any differences if every day you get a different package to update. "Another update, really? And nothing changed!" What's more is that nearly all of the packages included in a regular OS update would still require you to restart your device for them to install and start safely.

On top of that, it's easier for Jolla to push out batches of updated packages as they only need to test them once, all at the same time.

I'm not sure if it would be feasible to have a system where combined updates could be pushed to all users, but 'power users' could just zypper dup at any time as if they were using a rolling distribution (I'll coin 'Sailfish Wave' for that one).
 

The Following 4 Users Say Thank You to nthn For This Useful Post:
Posts: 1,495 | Thanked: 7,161 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:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 02:13.