maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   SailfishOS (https://talk.maemo.org/forumdisplay.php?f=52)
-   -   2.2.1.18 Nurmonjoki (https://talk.maemo.org/showthread.php?t=100455)

juiceme 2018-10-03 08:29

Re: 2.2.1.18 Nurmonjoki
 
Quote:

Originally Posted by nieldk (Post 1549097)
version is 1.16.10 - but that doesnt say whats fixed or not

https://github.com/sailfishos/sailfi...270d577135af4e

jukk 2018-10-04 11:28

Re: 2.2.1.18 Nurmonjoki
 
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.

nthn 2018-10-05 12:40

Re: 2.2.1.18 Nurmonjoki
 
Quote:

Originally Posted by jukk (Post 1549120)
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).

MartinK 2018-10-05 14:11

Re: 2.2.1.18 Nurmonjoki
 
Quote:

Originally Posted by jukk (Post 1549120)
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.


All times are GMT. The time now is 12:03.

vBulletin® Version 3.8.8