torios team mailing list archive

[Israel Dahl <israeldahl@xxxxxxxxx>]

Hi both Paul and Laura,
(inlines)
On 7/21/20 12:06 PM, Paul Sutton wrote:
> (snip) [old hardware support]
I think we should continue to support as much as we can
> I think, if we are going to reach out to projects such as puppy Linux,
> we should all reach out to these hardware and software projects and
> figure out what the target architecture is.
If we target getting small distro apps centralized, and perhaps
collaborative we could do more than targeting hardware (is what I am
getting from Laura)
> Raspberry Pi is now 64bit with 8gb ram,  the processor can support up to
> 16,  so there may be a 16gb raspberry Pi at some point (not sure).
>
> I can see it just getting harder to support i386 / 32 bit architecture
> with anything going forward.
Yeah, so lets focus on the operating system, if we cannot control
upstream kernel choices.  Lets support it until we cannot.  I think
going forward we need to at least think mobile application support
(build in screen size adjustment).  This way if it runs on a 5 inch
screen it works, even if it isn't a mobile device.
> Ideally we can collaborate with other projects so that small developer
> teams get more support and help from each other.
This is the main thing, and we need someway to generate impact to the
entire community.  How do we excite everyone else to work together?
> If there is a desire to use Cryptdrive then I can setup a team and start
> adding some of the ideas presented here to that, so for example
>
> Hardware ia64 arm
> related projects e.g puppy
> related libraries e.g those mentioned below
>
> otherwise we will have 100s of e-mails each with little bits of info and
> it will take hours to find what that oddly named library was called or
> weather we agreed to contact x project or not, and the outcome of doing so.
We could modify the titles, but yeah I get it
> I am not proposing we stop using e-mail this would be to help us keep
> track of everything.
>
> Paul
>
> On 21/07/2020 16:34, ml@xxxxxxxxxxxx wrote:
>> On Tue, July 21, 2020 7:24 am, Israel Dahl wrote:
>>> My main question is going to be, what architectures?
>>>
>>>
>>> Mobile is the newest low-spec ubiquitous computer everyone uses.  How do
>>> we support cheap computing easiest?  Mobile, is pretty much the only answer
>>> to that.  And most mobile OS are not focused on low-spec.
>> Also, most mobile solutions (such as Android) are for arm processors not
>> x86.  That would mean two copies of everything to support both platforms. 
>> Even in the mobile market, they're switching to 64 bit.  Google is pushing
>> to drop support for 32 bit and is no longer creating llvm cross-compilers
>> 32 bit for Linux systems that build Android tools.  So, it'll be just as
>> hard to support low end arm systems as is it is to support low end x86
>> systems.
This is why I am thinking we need help from other distros.  For example,
Purism is involved in upstream with GTK and Debian, so their packages
are for all arch.  If we get to upstream things, we can upstream to all
distros, and all implementations.  For example, Zenity works on mobile
devices, so a bash script approach (like we use) would work for mobile,
as long as we choose to support small screen size.
>> I could see us trying to leverage the Android-x86 project or libhybris and
>> use some of the Android apps that will run on x86 machines.  That would
>> give us access to more apps/applications.  I don't think dropping support
>> for x86 and moving to arm is the best solution for supporting older
>> machines at this point in time.  Supporting both platforms is going to
>> complicate things a great deal as well.
I think Libertine does this for ARM linux, as well.  I don't really want
Android apps, personally.  I want all the tiny distros working together
to make cross tiny distro solutions we can all use.  i.e. lots of
compiler options, and lots of toolkit choices, probably.
>> We can either support old computers well or low resource mobile devices
>> and devices like Raspberry Pi well.  It would be very hard to split
>> resources and support both.  They have different needs and constraints.
Both need small apps, so if we focus on apps that work on small screens,
we do not duplicate our work.  Then if you plug in the device, the
screen size will adapt, and so will our apps.
>>
>>> What about compiling a mobile OS using musl (postmarketOS for example),
>>> or perhaps figuring out a way to get a really low-spec WM that works with
>>> Weston working as a good phone/tablet/laptop/desktop UI?
>> So that would probably be WIO at this point ( https://wio-project.org/ )
>> as far as the windowing goes.

I've thought Sway might be the way forward, too...

https://swaywm.org/

>>
>> This project is already doing what you've mentioned minus the mobile support:
>> https://github.com/tpimh/nenuzhnix
>> They're using musl and Wayland.  I mentioned WIO and they're looking into
>> that as well.
They are interesting, but I want to stay away from BSD components if
possible, just as my own position mind you.
>> I'm guessing postmarketOS isn't going to be a good project to try to get
>> involved with because I haven't had any luck contacting the developers
>> about it.
Purism, and ubports would be good if we go that route, and Pine
(Pinephone, Pinetab, etc..) would be a good option, too.
>> I have e-mailed the developer of nenuzhnix before.  I think
>> he'd be welcome to sharing resources.
See what he thinks of our ideas!
>> There are also some Puppy Linux distro developers that are working with
>> musl.  I think they're concentrating on trying to get tinyxlib working
>> instead of Wayland though.
Yeah, same issue with things like JWM...
>> Do we want to go with Wayland or do we want to go with a tiny X server
>> (like TinyCore Linux and a few of the Puppy spins)?

I want to have roadmaps for both, and make toolkit choices that can
support either.  Doesn't SDL work fine on Wayland?

I would like this to scale well.  It would be nice to have minimal
hardware, as well as extreme hardware run the OS, just like minimal DE,
and full bling DE experiences as well.

>>   I was looking at some
>> of the tiny X ports and xserver-xsdl (used by Android apps).  There's an
>> interesting port of K-Drive (part of Xorg) that works on top of SDL.  If
>> we could build that successfully, SDL2 works with KMS and it could handle
>> low level functionality like keyboard/mouse/video support.

If the small distros get together I think the collaborative effort would
go leaps and bounds to solve our common issues.  A simple GUI toolkit
could be probably written by you and technosaurus over @ puppy, and
accept command line arguments for scripting (he's things like it before
with lots of little examples).

>>   Then we
>> wouldn't have to worry about maintaining that part of things with Xorg
>> once X Server development stops.
I am for this
>>   As mentioned, the other way to go is
>> Wayland and a project like WIO.  Most popular GUI frameworks will have
>> support for X11 or Wayland at least for now.  One last option is nano-x
>> instead of X or Wayland.  It'll be interesting to see what happens with
>> BSD systems and what they choose since they can't adopt Wayland as easily
>> as a Linux system.
>>
>> I guess I've raised more questions than answers.  What does everyone else
>> think?  What's our target audience?  Which processors (x86, arm, 64 bit,
>> 32 bit, etc.) do we want to support?  Which processors do we have access
>> to (old computers, old laptops, old Android tablets, Raspberry Pis, etc.)?
>>  What do we want our desktop environment to look like (Wayland, Xorg,
>> KDrive, nano-x, framebuffer, maybe something like Jide had, something else
>> altogether)?
>>
>>
This is why we should target everything all at once together.  Target
all computers with scripts using adaptive dialogs (like zenity, perhaps
gtk-dialog could use libhandy as well, if modified), or using compiled
code that we upstream (no PPAs, or private repos).  Work with all tiny
distros together to centralizze our common work.  The hardest part about
tinydistros is the need to constantly reinvent the wheel, since you
simply can't find the programs that already exist that you need.

We need a central collaboration hub for tiny distros.  This way we can
work together on common projects, instead of writing so many similar
programs (even the tiny scripts to turn off the computer or change volume)

-- 
Regards,
 Israel