That of course is your decision to make but a wise decision is difficult to make because it depends on knowing the consequences of not getting the update immediately.
I usually peruse the description of the change (the changelog) and if it gives a CVE number, follow the link to the CVE description - to decide whether to reboot immediately or leave it until the next normal reboot.
If it says “allows unauthenticated remote attacker to do arbitrary code execution with privilege escalation, being actively exploited in the wild” then I would say “reboot immediately”.
Perhaps best to put your comment here: livePatch service? if that is what you have in mind.
Does it actually enforce a reboot or merely give the user hassle about choosing to reboot now or reboot later?
Ubuntu seems to a) know which updates even require a restart and b) give the user the choice of now or later.
[quote=“antonis, post:37, topic:7723, full:true”]
But then how are the names Amber and Byzantium chosen. If they are always the same (Amber=stable
and Byzantium=rolling) the choice of names sounds strange. Why it is not “stable” and “rolling”.[/quote]
They appear to have chosen a rock theme for the names of their releases and are working their way through the alphabet for versions (I’m curious if Cobolt will be next) much like the tree theme for the phones (Aspen, Birch, Chestnut, etc)
Amber tracks the current Debian Stable (Buster), Byzantium tracks the current Debian Testing (Bullseye), there is currently nothing tracking Debian Unstable (Sid). With this said, I don’t consider Byzantium to be a rolling release, but rather the early adopter testing of the next release. This does get new features sooner but at the potential cost of some stability.
Based on what I’ve seen, Amber will retire with Buster, Byzantium will become “stable” with Bullseye, and there will be a new name for the next testing version…
True, this is speculation/a guess, but it is a guess based on observation and current evidence; as such, I think most will be able to follow my logic.
Arch is a rolling release, just to clarify things. And if things change, you will have to edit config files there too :-).
As for amber, byzantinum: only purism can say why they chose these specific names. But for debian and derivatives it is pretty common to give the various dists code names, such as wheezy, bullseye, or warty warthog :-). In Debian one has the choice of running a rolling release (testing, sid, byzantinum) or choosing a stable one (amber).
As for the “sans reboot” updates, this is completely orthogonal to the stable/rolling discussion. It is perfectly possible to update a computer (with basically the exception of the kernel unless one live-patches) while running. And this is typically done with servers. However on graphical desktops the system often recommends reboots: the reason is that processes that are running are not being updated even if the underlying files are being deleted and updated. So eg. when your graphical desktop has a security issue in xlib.so and and an update provides a newer xlib.so, the old one will still be used until the library is unloaded and reloaded. (google lsof DELETED to find out more about deleted but still opened files).
And as it is pretty tricky to find out which services need to be restarted in order to get rid of obsoleted but still opened files, and reopening these e.g. within the running graphical desktop might even be impossible, many desktop distributions simply recommend (or require) a reboot after something crucial has been updated.
So from what I read above PureOs does not roll as “automatic” as Arch. That is, there will be a new name in the future and we must wait for it to do the upgrade. That’s ok, I just wanted to understand how it is meant to work. It is a kind of “controlled rolling”.
Hard to say what happens in the future but the way this works on Ubuntu is that the change of “name” can be essentially automatic i.e. click “upgrade distribution” on the UI (and it will tell you when a new “name” is available i.e. that option is only presented when it is appropriate) and lo and behold it will change /etc/apt/sources.list as part of the update - or just click otherwise for normal updates, which will keep you on the same repos.
No, if byzantinum is used in the ‘sid’ sense, there will never have to be a name change. If byzantinum will at some point become a new ‘stable’, however, then yes one will have to change names to upgrade to the next one. So if you will ever have to change names depends on a policy by pureos that we don’t know yet.
Please note, this is an early release, it is meant for testing, not production.
And I see another one (regarding the ISOs):
Please note they are experimental at this point.
Just curious, will there be a point when Byzantium is more official/supported? Or will it always be more of a experimental/“do it at your own risk” type of thing?
For what it’s worth, I’ve been running Byzantium since November and the experience hasn’t been noticeably different from running Amber, aside from newer software. Any bugs I’ve encountered have been upstream bugs with GNOME 3.34, but Amber has upstream bugs too that were fixed in newer versions of GNOME.
aye, but it’s about the AMOUNT of bugs that have ALREADY been fixed or that are reported but have not been fixed yet …
there is a method called “heat” to up-vote bugs so that the higher priority ones are fixed first … not sure if this applies to the “testing” or only for “stable” … please somebody expand here …
Thanks for reporting your experience, I’m considering switching to Byzantium now. I would love to have newer versions, and can live with a few bugs in random software, the only thing I would dread is if things completely break (like boot issues). But I guess the advantage here is that PureOS is tested on Liberem’s hardware.
Byzantium is supported, we aim to fix bugs and ensure it is up to date and secure. But because it is a rolling release it is updated frequently and that brings more instability. Amber is less frequently updated and software has had a longer testing cycle by users and in production. At some point, and this will be announced in the future, likely next year, Byzantium will become our “stable” distro. Amber will become “old stable” (or even deprecated) and we’ll have a new rolling release.
Is there an advised path forward to move from Amber to Byzantium? Knowing at some point I will want to update, would it be better/easier to do sooner, or later; or won’t make much difference? Thanks again!
What I found strange recently was that there was no riot to install on byzantium. I had to install it from the debian package manually. Isn’t that strange?
I followed the steps in Pureos rolling release to upgrade to byzantium, but get the following errors during apt full-upgrade:
Err:1 https://repo.puri.sm/pureos byzantium/main amd64 libpango-1.0-0 amd64 1.42.4-8
404 Not Found [IP: 138.201.228.45 443]
Err:2 https://repo.puri.sm/pureos byzantium/main amd64 libpangoft2-1.0-0 amd64 1.42.4-8
404 Not Found [IP: 138.201.228.45 443]
Err:3 https://repo.puri.sm/pureos byzantium/main amd64 libpangocairo-1.0-0 amd64 1.42.4-8
404 Not Found [IP: 138.201.228.45 443]
Err:4 https://repo.puri.sm/pureos byzantium/main amd64 libpangoxft-1.0-0 amd64 1.42.4-8
404 Not Found [IP: 138.201.228.45 443]
Err:5 https://repo.puri.sm/pureos byzantium/main amd64 gir1.2-pango-1.0 amd64 1.42.4-8
404 Not Found [IP: 138.201.228.45 443]
Err:6 https://repo.puri.sm/pureos byzantium/main amd64 nautilus amd64 3.36.1-1
404 Not Found [IP: 138.201.228.45 443]
Err:7 https://repo.puri.sm/pureos byzantium/main amd64 libnautilus-extension1a amd64 3.36.1-1
404 Not Found [IP: 138.201.228.45 443]
Err:8 https://repo.puri.sm/pureos byzantium/main amd64 nautilus-data all 3.36.1-1
404 Not Found [IP: 138.201.228.45 443]
Err:9 https://repo.puri.sm/pureos byzantium/main amd64 libsrtp2-1 amd64 2.3.0-3
404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/p/pango1.0/libpango-1.0-0_1.42.4-8_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/p/pango1.0/libpangoft2-1.0-0_1.42.4-8_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/p/pango1.0/libpangocairo-1.0-0_1.42.4-8_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/p/pango1.0/libpangoxft-1.0-0_1.42.4-8_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/p/pango1.0/gir1.2-pango-1.0_1.42.4-8_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/n/nautilus/nautilus_3.36.1-1_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/n/nautilus/libnautilus-extension1a_3.36.1-1_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/n/nautilus/nautilus-data_3.36.1-1_all.deb 404 Not Found [IP: 138.201.228.45 443]
E: Failed to fetch https://repo.puri.sm/pureos/pool/main/libs/libsrtp2/libsrtp2-1_2.3.0-3_amd64.deb 404 Not Found [IP: 138.201.228.45 443]
It can’t continue after that. Anyone have an idea?
Edit: solved
then I would say “reboot immediately”.