Re: [DNG] inferno and FlyingTux

2022-01-04 Thread Enrico Weigelt, metux IT consult



On 08.08.21 22:01, Steve Litt wrote:

Hendrik Boom said on Sat, 7 Aug 2021 17:20:58 -0400



So putting it on top of Android and then using Infirno apps might well
be a way to alleviate some of the Android non-interoperability,

-- hendrik


If all we're talking about is making apps for phones and tablets, why
not Kivy?

https://kivy.org/


FT's goal is not to develop apps, but build a new mobile OS, that scales
from small handhelds to desktops and servers.


--mtx






SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



--
---
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
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] inferno and FlyingTux

2022-01-04 Thread Enrico Weigelt, metux IT consult

On 07.08.21 23:20, Hendrik Boom wrote:


Inferno is the system I would have preferred Google used instead of
Android.


Ah, okay, that was a bit confusing ;-)

Actually, I'd like to see a combination of both Linux and Plan9
concepts - using the Linux kernel for all the HW stuff but extend
it to support Plan9'ish approaches (eg. mount-ns).

Much of it is already there, but still need to find a practical way
for having private mount namespaces as unprivileged user (w/o userns).
Already did some experimental implementations of /dev/cap*, srvfs, etc,
so we could design programs pretty much the plan9 way, but that's still
a longer way to go.


It isn't a candidate for FlyingTux virtualisation.
But it might be able to alleviate some of the frustrations
inherent in Android.


Not really, since the most problematic point with those devices is
kernel/driver support. When starting over with a completely new OS,
we'd have to start afresh with all these (usually completely
undocumented) devices. Using Linux as kernel IMHO still was the
best choice - but their userland is a crappy monster


I get it that there are better ways to have orovided the services Android
provides.  But creating a better system than Android using containers and
virtual machines is not going to eliminate the horrible constraints that
Google has foisted on the computing public by their Android system.
Without copatibility with Android and access to the Android app market,
it will not replace Android, not will it make it easy for those wishing
to escape Android still be interoperable with friends wo do use Android.


I don't intend to replace Android anytime soon - I'm trying to create a
Linux distro for mobile devices. Mobile here doesn't just refer to the
device itself, but also the applications (eg. easily moving around app
instances between devices, etc).

For now, FT is just a research project, unless many people join in, so
we can build something practically usable in the field.


And it does networking.  Just about every resource is modelled as a file,
and the file system naturally extends to other networked systems.


Yes, Plan9 already does this. For typical (existing) applications, I
don't see this a major issue when using containers anyways.
(don't have the resources to rewrite everything, eventhough I'd really
like to enjoy that).


So putting it on top of Android and then using Infirno apps might well
be a way to alleviate some of the Android non-interoperability,


But that wouldn't solve the major issues of Android - a huge, pretty 
unmaintainable and untrustworthy monster.



--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
i...@metux.net -- +49-151-27565287
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] inferno and FlyingTux

2021-08-08 Thread Steve Litt
Hendrik Boom said on Sat, 7 Aug 2021 17:20:58 -0400


>So putting it on top of Android and then using Infirno apps might well
>be a way to alleviate some of the Android non-interoperability,
>
>-- hendrik

If all we're talking about is making apps for phones and tablets, why
not Kivy?

https://kivy.org/

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] inferno and FlyingTux

2021-08-07 Thread Hendrik Boom
On Fri, Jul 30, 2021 at 02:49:32PM +0200, Enrico Weigelt, metux IT consult 
wrote:
> Hello folks,
> 
> 
> maybe a bit offtopic, but allow me to announce the FlyingTux project:
> 
> 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.
> 
> 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.

So I said, in another branch of this thread.
: Have a look at inferno. http://inferno-os.org/

Inferno is the system I would have preferred Google used instead of
Android.

It isn't a candidate for FlyingTux virtualisation.
But it might be able to alleviate some of the frustrations
inherent in Android.

> 
> 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.
> 
> Another key difference is moving common functionality (eg. various
> data sources, communication protocols, ...) out of the individual
> apps into generic services - and the binding between individual apps
> and actual services instances can be customized by the user (e.g. one
> can bind some apps to fake gps instead of the real one, separate address
> books or user directories, etc, etc).
> 
> Here's a more detailed description:
> 
> https://github.com/metux/flyingtux/blob/master/README
> 
> 
> Note that for now its very experimental and fast changing. Don't expect
> anything field-ready yet. But it's already good enought to isolate some
> common desktop apps like gimp, chrome, etc.

I get it that there are better ways to have orovided the services Android
provides.  But creating a better system than Android using containers and 
virtual machines is not going to eliminate the horrible constraints that
Google has foisted on the computing public by their Android system.
Without copatibility with Android and access to the Android app market,
it will not replace Android, not will it make it easy for those wishing
to escape Android still be interoperable with friends wo do use Android.

It's not that inferno is going to obviate these constraints either.
But inferno *has* been implemented in a way that works on Android
phones (though the mechanism may still leave something to be desired)
and also on top of Linux and on bare hardware.

And it does networking.  Just about every resource is modelled as a file,
and the file system naturally extends to other networked systems.

So putting it on top of Android and then using Infirno apps might well
be a way to alleviate some of the Android non-interoperability,

-- hendrik

> 
> 
> --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
> i...@metux.net -- +49-151-27565287
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng