When are we getting updates? No updates for 2 and half month for a security focused laptop is kind of a shame.
Newbie votes stable.please. Make it to difficult and i won’t have any hair.
We have continued to update PureOS and there are many updates coming into the system. We also have been working to bring in a new security repo which will receive attention from both upstream and from PureOS directly. In addition, the focus will be on stable systems, so this particular suite is not a rolling release but a stable release. It is designed to receive fewer updates and updates that address security and bug fixes. The suite’s name is Amber.
We also will be providing a rolling release, so now everyone will have the choice of either a rolling release or a stable release. These new releases are still undergoing work, but I mention them here because they’re getting close to being ready for testing in our community. I’ve currently been testing them both but only in a container. We need to do some more testing on actual Librem Hardware before wider release. We want a roll out that is very smooth for our users but allow the more adventurous to jump to a rolling release as soon as possible.
I’ll try and update our progress here daily.
For me as a longtime computer user that is great news. My problem was, that it was not trasparent what is going on. I think with my expierience i could be one of the adwenturous usres.
Makes it sense to still use the landing-repository, as I do?
I think it is better to use one of the color repos - either green, or when it’s available, amber.
I have already mentioned I would like more stability, but I have to say that I get nervous when I read about security updates being needed and I do not see them. I always check Buster first to see what is being done there, and then PureOS.
Here is a recent example: I do not use it, but VLC has been in the security news lately. (PureOS does install some plug-ins automatically, according to apt list.) I noticed that PureOS still has not been updated to VLC 3.8 even though Buster has.
Stable or not, timely security updates are mandatory, regardless.
Why such non-descriptive (nonsense) repo names?
I mean choosing between something like either “time/semesterly tested”, “testing” or “experimental” software packages seems more straight forward. (Even as long as this is a global selection of a “suite”, not yet a per package channel, as with the nix or guix package managers.)
The pureos release will be the same for x86 and for the librem5?
We arrange PureOS into “suites” called ‘green’ and ‘amber’. We do this so that we can collate packages for different devices and to have different policies for packages. For example, the ‘amber’ suite (naming is arbitrary) is going track stable updates. We have a different suite for the Librem 5 though it is the same OS. The reason we have a different suite is because we have different hardware on the phone - the phone is ARM v8 while the laptop uses x86 architecture. We’re also using a kernel device tree specific to our device and we need to accompanying kernel and toolchain to go with it.
Naming is only arbitrary for computers, for us it could be much better understandable if you provide some information within the name.
As it seems, the “amber” suite could really be called more precisely time-tested, if it contains software packages in versions that tuck along over time, under their individual schedules (instead of say “semesterly tested”). A longer description: Upstream stable releases in packages that build successfully, and have been tested to work. (Also accommodates for cases in which the apt system is not able to install or upgrade the dependencies required for a newer available release.)
I definitely would vote for a rolling release… I’ve always used rolling releases and have never had an issue with them, with a stable releases I constantly have to compile my own software as the versions in the repo are extremely old. For servers/public hosts though I would understand why stable would be a good choice.
I’m happy to hear that rolling will still be an option, it seems like that would be the best idea, having multiple choices such as debian. I personally think the names are good, and it seems to keep in line with other distros, using codewords etc. I’ve always been able to keep track of versions and stable/testing repos based on names like debian’s (stretch, buster, sid, etc.).
I am hoping the rolling release will be made closer to debian’s unstable repo however, as from what I understand the testing suite is frozen for periods of time. I’m not 100% sure if it’s related as I haven’t looked into it much, but the only update I’ve seen in a few weeks has been purebrowser.
Oh, I think I see where there might have been a misunderstanding with what I meant.
It’s that with a rolling release the name of it would not have to change anymore.
I think it would therefore make sense to give the rolling release a good descriptive name as well, instead of arbitrary release names. Not “stable” obviously. Using “stable” is also not so good to name “long term support” LTS releases, as “stable” is easily mixed up with runtime stability, and kind of suggests instability for other releases.
So, there could be three names describing the package state and release process:
experimental / testing / time-tested (rolling “stable release” versions from upstream)
If there are further, more static, long term support releases, these could be named for example:
LTS 2020-26, LTS 2025-31 etc.
I see what you’re saying. I can see how that could be helpful in certain situations.
I’ve noticed today that the base-files update just changed my apt sources.list and switched everyone over to amber. I see that this suite has many ‘security updates’ that aren’t available in green. I’m not sure whats going on, does this mean the packages in green are currently not secure? Is it safe to upgrade the packages with the ‘security upgrades’ if I am planning on staying with a rolling release?
I am wondering now if amber will be prioritized over the rolling release…
I see a lot of high priority security updates that aren’t available in green
We’re merely changing the distribution suite name from green to amber and we’re adding an additional security and update suite. These suites will receive extra security attention.
There will be a new rolling release announced soon which one can switch to if one prefers.
I see that makes sense, good to hear, thank you.
Gives better delta and (from my experience) is better protected from circular dependencies.
I have never managed to update properly/seamlessly release-to-release, starting from redhat4 (yes, 1996). But never had problems with arch (even recovering several years old image and running pacman -Syu on it).
I think PureOS rolling could be rebased on a tested and tried rolling Debian-derivative: Kali. They do a bunch of the testing already.
I have been critical of the update process and slow security updates.
As a “former” developer, I can guess it was a time-consuming, difficult effort to create these different releases. Thanks to the Purism staff for trying to please all of us!