torios team mailing list archive

[ml@xxxxxxxxxxxx]

On Mon, July 6, 2020 8:42 am, Israel Dahl wrote:
> I would like to see FLTK begin to work on other things beside X11.  What
> do you think about use here?  I think being able to consider the eventual
> mobile device trash heap will need repurposed, and those types of devices
> AFAIK benefit from these modern, different types (wayland,
> mir, proprietary, etc.....)

Was going to ask if we were interested in going with FLTK 1.4.x or
sticking with FLTK 1.3.x.  1.4.x is making it easier to port to other
platforms besides X.  A Wayland backend is one option that they're
considering (and some work has been done on it).  An SDL backend is
another possible option and SDL will work with Wayland.  1.4.x is still a
work in progress and still beta though.  I've tried rebuilding some
programs that work on 1.3.3 using 1.4 and haven't had any real issues.  I
also sent in a patch to include part of the Oxy theme that another
developer wrote.  That's now incorporated in FLTK 1.4.x.

One nice thing with FLTK is that it works with nano-x so it will port to
any device nano-x works on.  There is a recent port of nano-x that works
with SDL as backend, so theoretically, SDL could be built for Wayland,
nano-x could be built with that and FLTK will work on top of it.  Not sure
about usability, but it's an option that might be worth investigating.

Some of the distributions supporting older machines appear to be working
on option like tinyxlib or a KDrive (X Windows) based option rather than
going to Wayland.  That might be an alternative as well.  Also, you can
run an X server in an instance under Wayland.

> I've also recently begun seriously thinking about Rust, instead of
> shell/python or C-like languages. 

Rust has been getting a lot of attention.  Personally, I plan on sticking
with C mainly for portability and backward compatibility reasons.

> Is SDL the fastest?  Is there a way to make an easier end-user library
> for applications?  You are a really good programmer, and know a lot of
> optimizations, so I think you would be ideal to write some type of
> end-user library specifically for tiny linux distros.  We could use your
> optimizations by default by using your library. (or even toolkit if you
> wanted)

Not sure how SDL compares as to speed.  SDL is a graphics library and
FLTK, GTK, Qt, etc. are GUI libraries.  There are GUI libraries that work
with SDL and you can use pdcurses with a SDL backend.  SDL is highly
portable and SDL 2.x works with Wayland.  There are tons of games that use
SDL as a backend but not as many desktop style applications.

Thanks for the compliments.  You've done some wonderful programming for
ToriOS and created some really nice FLTK applications.

I mainly try to write portable apps (which means they'll work on various
operating systems but that could also mean they port to low resource
operating systems).  My main goal usually isn't speed or efficiency
because that often means the code won't be portable.  I'm more interested
in being able to support multiple platforms, switch platforms and avoid
vendor lock-in.  I do prefer tools that do one job well following the Unix
philosophy and those types of programs tend to work well on low resource
computers.

I have been working on a GUI library of my own, mainly a proof of concept.
 I'm trying to port something I wrote years ago in BASIC and I need a GUI
to accomplish that.  I'm using SDL/PicoGL or OpenGL as the backends.  The
BASIC program could draw screens based on text input and launch
applications.

> That is a concern, I have thought about Devuan, but I am not really sure
> the best option.  I asked Stallman what he thought about it, and he didn't
> care.  I think it might be an invasion of the users freedom, since it is
> binary, rather than scripts you can read....

I've looked into Devuan and didn't find the developers all that friendly. 
AntiX is based on Debian and their own modifications.  It's not based on
Devuan.  Not sure about Freedom issues, but systemd seems invasive and
takes over the job of several other libraries/tools.  It's doesn't
necessarily do the job better either.  That's another form of lock-in.  I
prefer to avoid that when possible.

> Nio built tools to do this for our system, and it was included.  You
> could customize your system, and tar it up.  Plus it was written in bash,
> easy to modify in a pinch!

Sounds cool.  If this isn't already documented somewhere, that would be a
great thing to add to the ToriOS documentation.  It would also be a good
thing to highlight on the ToriOS web site.

> Ok, I like lighter libraries, but are the functions the same?  Is it a
> job for sed, or more complex?

musl is mostly compatible with glibc and far less bloated.  musl pretty
much supports the full POSIX standard.  Also, it has built in gettext
support for internationalization.  There are several small distributions
using it so you can see their build changes for things like libressl. 
Anything that follows ANSI/POSIX standards should work with it though. 
Some of the distros also push fixes upstream so more
applications/libraries will build with musl.  Debian uses glibc, so it
wouldn't be an easy switch.  If we want to keep compatibility with Debian,
we'd need to look into having the two C libraries coexist like Bedrock
Linux does.

> Perhaps, but Puppy doesn't, besides with flatkpak/snap/AppImage people
> can get huge programs if they want!  The only issue is infrastructure.

That's another way to have different libraries/Linux distro packages coexist.

> We don't have build servers, or package repos... just PPAs, which wont
> build for 32bit anymore.... so we need to find some other way to make
> ToriOS exist....

I think that's pretty much what some of the Puppy Linux developers are
doing.  They're trying to find ways to build a simple version of Linux
from Scratch in case whatever base system (Slackware, Debian, etc.)
they've been using no longer meets their needs.

I seem to recall OpenSuse has build servers that people can use (
https://build.opensuse.org/ ).  Of course, you'd have to be compatible
with their scripting for packages and the OpenSuse system.

> It might happen.  Debian is generally inclusive of older hardware. 

They seem to be more so than Ubuntu.  I've also noticed a lot of systems
trying to add ARM support for compatibility with devices like Raspberry Pi
or maybe even Android.  Google is definitely pushing for 64 bit only
support with Android even though there are still several low end 32 bit
ARM devices.

> Unless the code has been made to exclude 32bit (memory reasons,
> probably... they hog it now) it can always be made into a 32bit binary on a
> 64bit (unless they ruin compilers too :P ). 

They're definitely working on ruining compilers.  Google's not even
offering 32 bit llvm cross-compilers for Android anymore on Linux.

I've been trying to keep track of what's going on with Android/mobile to
some extent.  There are now currently more mobile devices than desktop
computers.  Rob Landley (developer of Toybox) has some interesting
articles on how he thinks mobile devices like phones will replace desktop
computers.  Android uses Linux but is optimized for low resource systems. 
The only part I don't like is that it runs each app in a virtual machine
which uses a Java-like environment.  The separate virtual machines make it
rather secure which is good.  I personally find applications that use a
run-time environment like Java are slow compared to natively compiled
applications (C/C++, Fortran, Pascal, etc.).  It is possible to get
Android running via a virtual machine in order to have access to Android
applications (such as latest browser builds).  There's also the libhybris
project which might help in porting Android apps to Linux systems.  Termux
is also an interesting project.  It ports a variety of command line and
ncurses applications so that they'll run on Android.  Some of the programs
they use would definitely work well on low resource computers.

I like being able to keep using my old hardware.  However, at some point,
it might be more cost effective for people to just buy a Raspberry Pi or
similar device and use it instead.  It's kind of a fine line at this
point.  Don't know if it would be worth looking into bridging some of the
mobile gap and being able to migrate ToriOS to mobile devices or migrate
some mobile apps to ToriOS to be able to keep running modern software like
browsers.

My hope is that if I stick with portable software that I can build myself
and learn as much as I can about how to put together a Linux system from
scratch, at some point it isn't going to matter as much where the other
Linux distributions head.

Would be interested to hear what other ToriOS users see as possible future
goals and directions for ToriOS.  Would it be useful to have ToriOS
working on inexpensive hobby systems like Raspberry Pi as well as older
computers?  How important is Internet support with modern browsers that
can handle things like online banking?  Do users find they're doing more
things online now or do they want productive software that works well even
in an environment where there's no Internet connectivity?

Sincerely,
Laura