On 05.08.21 12:55, Arnt Karlsen wrote:

Hi folks,


sorry for being too busy for replying so long ...

>> It's an build/runtime infrastructure for running desktop and mobile
>> applications in containers and build an entirely container-based
>> mobile OS based on it.
>
> ..I like the https://www.qubes-os.org/ approach, but not
> their use of systemd nor of rpm.
> Do we do something similar here?

the only similarity between the two is that applications are sandboxed
(and it linux-based, of course).

FT uses containers, instead of VMs.

The general idea is making application containers as small as possible.
For that, we don't use fixed images (like class docker), but deploy
from package management, just the actually needed packages (eg. don't
wanna have dozens of useless gl drivers).

>> The primary motivation is my long frustration about the monstreaus and
>> practically unmaintainable Android, which also still lacks lots of
>> common management abilities we know from the GNU/Linux world.
>
> .."wonder why Google designed it that way." ;oD

maybe for making it as complicated as possible, so opensource looses
its primary value ? ;-P

>> In some ways, FT can be seen as an conceptional combination of
>> containers (docker, k8s, etc) and apps (android, etc). One major
>> difference is that also the app images are based on some defined
>> distro base (for start, just alpine, others to follow later) and the
>> images are created on the host, based on host specific settings like
>> hw setups (eg. automatically deploys the right mesa drivers). In
>> future steps some packages of the app distro base (called 'osbase#
>> here) will be replaced or customized, in order to provide better
>> integration with the ecosystem and strip unneeded stuff.
>
> ..which means an early step will be trim down the basic (net-install?)
> images we have, as far down as possible, and build app, vm etc images
> upon those stripped down base images.

actually, a bit more low level: we use a (almost) standard distro and
install just the really needed packages.

For now, just implemented apk backend, since alpine is the smallest
ready-to-use package based distro I'm aware of. (haven't tried, but
deb probably would be much bigger).

> I guess we also want a bare bare metal hypervisor of some sort. ;o)

That's not planned (yet). I've got several use cases (or installation
types) in mind:

a) ontop of classic linux distro: use it similar to snap etc
b) as a pure os for larger devices
c) as a pure os for small mobile devies

For case b we'd have a really minimal base distro, just what's needed
to bring up a console or graphical display.

For case c we'd have a device-customized base distro (at least we'd
need customized bootloader and kernel)

> ..this means we can set up e.g. chromium in throw-away-after-use
> containers? Or stick new stuff with lib conflicts in containers?
> Etc?

Yes, that's one of the use cases (category a).

> ..I see no .deb package? Pretty soon we'll need debug packages
> to shake out bugs.

It's not packaged yet - too early, needs more time to mature bevor
packaging makes sense. Just clone the git repo and run it from there.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@??? -- +49-151-27565287