Linux in 32MB Flash

[nctnico]

You don't need accellerated graphics to run X-Windows as long as the skin you are using isn't heavy on graphic effects. GTK is pretty versatile when it comes to skins.

[legacy]

X11 on 32MB ? Simply ridiculous 

[nctnico]

Why? X-Windows has the option to compile a cut down version which is really really small. Less than a decade ago I have used X-Windows on an embedded Linux platform but I can't remember whether the flash was 16MB or 64MB. I think 16MB.

[alan242]

Alpine Linux (https://alpinelinux.org) has an ARM distribution and a minirootfs tar. It is built on busybox, the musl C library and uses openrc for init. The current kernel is 4.9.17 so that will need to be replaced with a the custom 4.11-rc kernel. I am not entirely sure the distribution will strip down to for the size limitation. However, the minirootfs tar expands to about 3.5MB. Maybe start with that and add the packages that are needed to see if it will fit?

[technix]

I actually needs udev, dbus and maybe systemd. NetworkManager too. Those packages can be huge...

[legacy]

Why? X-Windows has the option to compile a cut down version which is really really small

it's nanoX

Less than a decade ago

When Kernel 2.2 were much more smaller, and nanoX was not a part of integration (aka #ifdef ) into X11.
Nowadays, dead elephants, especially if compiled with uclibc.

[legacy]

X-Windows on an embedded Linux platform

are you sure it was not directfb? or QTopia (used by SHARP in 2004)?

[nctnico]

X-Windows on an embedded Linux platform

are you sure it was not directfb? or QTopia (used by SHARP in 2004)?

No, definitely X-Windows. It is a bit like the adagio not to use printf if you are space constrained. The funny thing about that is that by the time you are done creating an alternative it will be more bloated than printf. It is quicker and easier to create a mini-printf. It will save space while keeping a very standard API. The same goes for X-Windows. If the regular version is too bloated then compile the minimalistic version. You'll have the same API so most software will work with it.

[legacy]

directfb can be compiled with uclibc without problems, and it's small footprint, you can neither say nor do the same with xorg. nanoX was excellent for the same reason.

dude, if you need glibc then binaries and libraries will be 220% bigger at least.

[technix]

directfb can be compiled with uclibc without problems, and it's small footprint, you can neither say nor do the same with xorg. nanoX was excellent for the same reason.

dude, if you need glibc then binaries and libraries will be 220% bigger at least.

This is interesting... directfb seemed to be a good option for the graphics layer for me.

And no I don't need glibc. I know that I will definitely need dbus (NetworkManager as I have Wi-Fi and Bluetooth) and udev (kernel depends on this now) but systemd is still undecided. I don't know if any of those will put a hard requirement on glibc though. If udev and dbus can work with some lightweight libc but systemd depends on glibc, I am going to try use Apple's launchd as the init system as it depends only on POSIX API (I am a full Apple Developer Program enrollee) and start udev and dbus from there.

As of the GUI layer, I am investigating creating a display server based on directfb that implements the Cocoa Touch API. The semantics of this device is similar to that of iOS devices, hence this API.

[calin]

Look @ this - http://tinycorelinux.net/welcome.html

[cezar]

OpenWRT?

it fits nicely in https://www.seeedstudio.com/LinkIt-Smart-7688-p-2573.html