[PureOS] Let's stablize PureoS Green

[Jeremiah C. Foster]

Sorry for top-posting (I'll move back to inline after this little PSA)
and for changing the format back to text but text and inline comments
read better for those who use text based mail clients like mutt which I
and others use regularly.

On Wed, 2019-03-20 at 14:10 +0100, Tobias Bernard wrote:
> To add my perspective:
> I fully agree with Francois' vision. What we need long-term is
> - a user-facing OS that is stable, but which receives timely updates
> to UX-relevant parts of the stack (primarily GNOME and its
> dependencies, but probably also popular browsers, and a few other
> apps and developer tools). We don't want to split our OS in two for
> enterprise/consumer, as it would have very problematic effects on the
> developer ecosystem and the cohesion of the platform (e.g. apps
> designed for the fresher consumer version might not work on the
> enterprise one).
> - a way to do integration testing with in-development parts of the
> stack (primarily GNOME and things we need for the phone). Ideally,
> this would always have nightly versions of the entire GNOME platform
> throughout the development cycle. Most likely we'd need to do this in
> close collaboration with some GNOME people.

I'd like to see if we can't discuss this with GNOME. Integration and
release cadence really could be better coordinated with Debian I feel
especially given that the current GNOME Foundation director is a DD,
but perhaps there's work behind the scenes going on already that I
don't know about.

> 
> Regarding the current choice between Debian stable and testing: We
> can't go with Debian stable, unless we find a way to get up-to-date
> versions of GNOME and all its dependecies on top of that.

We have to go with Debian stable. Debian testing has presented too many
obstacles to stability. We have an obligation to ship stable software
to our customers.


>  I have a hunch that this isn't easily possible, but it's hardly my
> area of expertise :)

I think it is entirely possible to backport GNOME 3.32 and ensure
flatpak works with the lastest GNOME software. In fact, on my PureOS
green system I'm running what will become Debian stable with GNOME 3.32
runtime and apps via flatpak;

$ lsb_release -a
Distributor ID:	PureOS
Description:	PureOS GNU/Linux 8
Release:	8
Codename:	green

$ flatpak update
        ID                        Arch   Branch Op Remote  Download
 1. [✓] org.gnome.Platform        x86_64 3.32   u  flathub 88.8 kB /
433.8 MB
 2. [✓] org.gnome.Platform.Locale x86_64 3.32   i  flathub 17.0 kB /
222.6 MB
 3. [✓] org.gnome.Lollypop.Locale x86_64 stable u  flathub  1.0 kB /
467.9 kB
 4. [✓] org.gnome.Geary.Locale    x86_64 stable u  flathub  1.0 kB /
4.1 MB

> Continuing with Debian testing seems like the more sustainable route
> short-term, though we still need to figure out how to get up-to-date
> GNOME during freeze periods,

Will flatpak work? It works for me here.

>  such as the current one. Since other Debian-based distributions,
> such as Ubuntu are going to do this as well, it seems at least
> theoretically doable.
> Longer-term I'd be interested in exploring alternative options, such
> as rebasing the OS on Endless OS, Ubuntu, or Fedora Silverblue, all
> of which have different, potentially interesting solutions to this
> problem. 

1. Endless and Silverblue both use OSTree. OSTree is good, but it is
*very* different from Debian's traditional model. 

a) Endless is designed to be used in places that have slow internet,
they preload much of the OS, including content
b) Endless is based on Debian with a kernel from Ubuntu, neither of
those distros are certified by FSF as "free"
c) Endless and SilverBlue provides the OS as a single immutable
deliverable, users do not have fine control of what is on the OS
d) SilverBlue is "for container-focused workflows, this variant
of Fedora Workstation targets developer communities"

2. Ubuntu is built by Canonical and is ~80% based on Debian. While they
fork some things (Mir) they often find that its not worth it to fork
(upstart). They recompile their packages adding ubuntu to their rebuilt
packages (much the way we add pureos to our pureos packages, though we
have very few), and the consequence of adding the 'ubuntu' string means
that they have a trademark claim on derivatives. I don't think PureOS
should be subject to capricious trademark claims so I wouldn't
personally recommend Ubuntu as the base for PureOS. 

It's possible that a deb-ostree-builder based OS with kernel, Pureboot
and middleware might be a good base for a flatpak'ed Desktop like
GNOME. But I've only experimented with this and it needs more research.
Its unlikely that something like that would be ready by the time we
need to make the decision of stable vs. testing.


> Sooner or later we'll want to go in a fully containerized direction a
> la Silverblue, so this might be good to factor into the decision we
> take now.

Perhaps you're right. This certainly is a trend (Project Atomic,
SilverBlue, Endless, Clear Linux, etc.) but that is not a reason to
adopt it merely because it's trendy. I like the isolation of containers
but I don't like the bloated runtimes and the duplicate runtimes, that
is a security nightmare. 

Cheers,

Jeremiah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190320/403c7ea4/attachment.sig>