The editing of config files is a one-off process to change from Amber (stable) to Byzantium (rolling) i.e. change from one repos to another.
In either case, Amber or Byzantium, no further action is required on the part of the user in order to see updates automatically as they become available. Regardless of repos, the same apt commands will apply whatever updates are available using the command line when explicitly requested if the user prefers that.
The difference between Amber and Byzantium will be in
a) the relative timing of updates if both repos get the same update, and
b) the scope of updates - Amber will typically only get bug fixes including security fixes on a day to day basis
Ah, thanks. That is great. So any time I can now upgrade my system. 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”. This is what confused me. I thought I had to expect another code name in the future.
I’m asking about “sans reboot” updates for PureOS. Why do I have to enter my encryption password twice and my login password once to update an app that isn’t even running?
My comment about MX Linux was simply to indicate that other distros don’t demand instant reboots, even though some updates, such as kernel updates, won’t take effect until a reboot (thanks, Jeremiah).
I shutdown my Purism laptop every couple of days, I can wait for a kernel update, or reboot manually. But don’t force reboots to update a library I don’t even use.
Politely now, I ask “Could we have “sans reboot” updates in PureOS like some other distros do?”
Understanding that this doesn’t require rolling releases. (MX Linux is a point release distro.)
Just go into the terminal and type sudo apt update
and sudo apt upgrade
This will update all packages that can be updated and not force a reboot. It will tell you if a reboot is needed for an update to take effect if needed.
The reason the graphical updater requires a reboot for updates is that it is considered “safer” and/or “cleaner” to update packages in a specific environment designed for updates.
I think you need to refer that question to Purism. I could speculate but in this case I don’t think speculation from me is helpful, particularly as it might relate to whether these names will always remain the same in the future.
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.
then I would say “reboot immediately”.