Could be [tiny]core improved?

[nick65go]

I want to underline that I like very much tiny-core. Few distributions rise to his implementation of technical know-how AND "simplicity". But maybe few things could be trimmed down ...

So, I discovered sabotage distribution: https://github.com/sabotage-linux/sabotage
The concepts I like about it are:
- compiling the kernel without using perl (it was possible for few years).
- static link the core tools (busybox); less exposure to attacks, easier chroot/sandbox on the fly.
 (would you like chroot from 64 bits into 32 bits, run sandboxed browser, or install 32 bits tcz aka syslinux)
- smaler auxiliar libs: (libnl-tiny?); libnl-tiny is known to work without issues with at least: iw, wpa-supplicant, kismet, aircrack-ng, libpcap
- simple package and build manager, ala archlinux pacman AUR repository; so both the core AND the tcz extensions could be scripted if you are security concerned about alien (not exposed) tcz recipes..

I like the freedom of (better) alternatives:
- to use llvm vs gcc (gcc is surviving because it is still the only one who can compile the full kernel)
- smaller C libs, like musl (not uclib) vs glibc.
- smaller core tools (like toybox vs busybox partial/total replacment ?). Imagine even a static compiled busybox (with musl) and part of tinycore rootfs64.gz is the same as rootfs32.gz, because any CPU (32/64 bits) can run same code. core.gz= commonFs.tools +libs.spec+ modules.

I am just skimming the top of the iceberg...would you like a recipe for a controlled build firefox?
https://github.com/sabotage-linux/sabotage/blob/master/pkg/firefox

[nick65go]

IMHO I think that the (tiny-)core success could arrive just from the FINAL product (small and modular).

The analogy with cellphone: does not matter how complicated or huge resources you use (manpower, big factories) if the final product is optimized (a tiny cellphone/tablet) for large consumer (linux user).
The manufacture has no intention to explain to final user the process of production, the recipes  and pieces used to build, or the specs of the pieces. Of course you can smash it, look inside and google etc.

The emphasis in tiny-core is NOT on self-sufficient (re-build from himself like Phoenix bird, sorry like aboriginal Linux). Of course you can dismantle it in pieces and rebuild again. Or read the wiki pages and hunt for strings in the forum etc. Or said after me: compile the kernel, and busybox, read and learn the smart home- made scripts (init, mount shuashfs tcz, etc) and be happy.

But this statement is true, it is not a vast interest to provide a recipe of it:
- a list with links to all virgin sources used (kernel, busybox, patches)
- a tarball with specific home-made scripts, for core and tcz extensions.
- an automated script to rebuild it on the fly, if you have willing, time, resources CPU/RAM, knowledge.
- a know-how philosophy, about why use some options against others; like eglib -> glic but not use uclib or musl as a base C library; why libz and not lzma/xz for compression of squash modules; why some kernel modules build-in, etc

Of course the developers KNOW all these, because they did tested various options (but not publicly shared the benchmarks) before settle for some options. Like it is said, use it as it is, or switch to another distribution.

Anything which grows way-out of it originally declared scop (gcc, systemd, pulseaudio) is as cancer by definition, so should by avoided (fork), if you can.
I like this tiny-core "distribution", and I would like to contribute to improve it, but unfortunate I am not a programmer, neither a developer. I am just an end-user learning linux and I try avoid the bloat.

I search for things to improve linux hobby; some of them are just old news, only news for me; but because I have found no explanation here in the forum, I try to expose them. And maybe other more knowledgeable people will implement them, or at least say why are not suitable.

[LichenSymbiont]

"Like it is said, use it as it is, or switch to another distribution."
Yes... well... that's how we arrived at this mess:
https://en.wikipedia.org/wiki/List_of_Linux_distributions
Look at that image...
The *insanity* of crowds in this instance -- no single person would design such a thing.

So we have yet to establish a core upon which everything else can be built!
If we had it, I think it would explode in adoption and contributions, and we would see more interesting projects than useless new distros.

I think the idea of a base/core distro, which can be built upon, should be the goal of TC.
Especially now as dCore is becoming stable and practical, then it can replace a Debian distro, but be much smaller, and have more use-cases by it's great performance and small size.
I think we need to focus on making dCore as complete as possible -- a purpose not at all interfering with the improvements of the core. Though such a different core as Sabotage Linux would interfere with all the Debian packages (I would expect).

But if we had our own build-system, like Gentoo or Arch, we could certainly use all kinds of crazy cores if we would like to.
I think such a unified core distro would require to have an easy build-system.

TC is not overly minimalistic, and you can still get a regular build-environment with TC quickly, without tinkering (just downloading packages).
It's a sound, yet extremely minimal distro.

And I think we can have a beautiful unified core from Micro Core / dCore, without forking -- just extending.
Instead of focusing what tools we could switch out to make it even smaller and more performant, we should focus on removing limitations / expanding the limits.

Like how we could have dCore on Android phones!
Now that's a huge problem to tackle, yet Ubuntu and Arch (and others?) are expanding quickly into the mobile space.
So we should just be able to run a droid-phone-install.sh script, and have drivers fetched for the phone automatically.

Just some terminal-lines flashing by, and then -- BAM! A graphical futuristic touch interface! hehe...

This relies on the manfacturers releasing their source-code, and providing binary blobs for other drivers.
You may not see immediate benefits from running a pure Linux distro on a phone, nor do Android smartphone manufacturers see it. But it's entirely possible to create superior user interfaces in a regular distro (though not really from existing applications).

Well, in the future there won't be any difference, there will just be Linux, as there are quite a lot of companies interested in this.
Too bad that there isn't a more open and unified effort, but at least we have Linaro:
http://www.linaro.org/
Commercial entities tend to not be as idealistically guided... obviously in favour of money, or some direct results.

And don't think the manufacturers are oblivious to the real Linux world, and free open software, look at this link:
http://www.cnx-software.com/2014/09/18/mediatek-releases-linux-source-code-for-android-one-smartphones/
They just need more incentive, and be pushed more from the FOSS community. The FOSS world is after all much older and much bigger than some silicon company, or smartphone manufacturer.

I see it as an titanic slumbering chthonic entity, of pure energy, waiting for the moment to pounce.

Back on subject:
To have a core built entirely from scripts would be great. It would remove some limitations, and we would have more eyes on the most basic system. So building everything from scratch would be one command away, instead of fetching everything yourself.
Awesome stuff for sure.
But I'm very focused on the unification of GUI tools now, something which would make all this much more easy, and also make it appealing to new and learning users.

More personal:
I hope you are at least learning scripting (bash), as if more people knew and liked to work with scripts, we would have more eyes in the project.
And surely have a great future Linux developer, as you already seem to think like a developer in some ways
You have learned well, keep going!

[mocore]

i like that the pkg mgr is an awk script =]

"sabotage-linux/butch pkgmgr ( in shell/awk)" @ https://forum.tinycorelinux.net/index.php/topic,27217.0.html

[nick65go]

Necromancy of an old topic. Time is passing by and our goals and priorities are changing.

1. I would prefer ARM architecture (most energy efficiency), but unfortunatly most Applications I "need/want" are for x86, so the future is for x86_64[_v3] appls colection, from year 2025+.

2. The base LIB is musl (not libc) because is smaller (means more secured).

3. X-org as implementation of X-server is dying, so future could be Wayland (more secured) of any impementation.

4. Then, for the few app that we are not often comuting between, we could just use JWM /FLWM.

5 .My ideal (for now) linux system will start with a GUI like FLTK; see that it has all wigets that the big/bloated brothers (GTK, QT) have  https://www.fltk.org/shots.php

6. And of course a small (less RAM used) browser like a nestsurf, compiled with FLTK interface (not GTK). It should allow Java-script ondemands.

7. Maybe NOT apps wtitten in Rust, maybe not init system-d, etc.

For now the big demanding is X-org + mesa-3D-drivers +firmware (GPU/CPU) + Firefox (GTK3+) + audio/video HD decoders => the minim productive system, or for entertainment is very demanding; not so tiny, even if we start with tiny*.*

But there there are signs that (a part of) world is moving in that direction...
FLTK 1.4 Released With Wayland & HiDPI Display Support
FLTK 1.4 Released With Wayland & HiDPI Display Support - Phoronix

[GNUser]

our goals and priorities are changing.

Not mine. And hopefully not TCL's

1. Like ARM? Knock yourself out. See current ports here: http://repo.tinycorelinux.net/15.x/

2. curaga has spoken about libc in the recent past (search the forum). TCL considered musl but will stick with glibc for wider cross-distro compatibility.

3. curaga has also spoken about X in the past (ditto). TCL controls TinyX in case Xorg kicks the bucket. Wayland and a lot of nice wayland userland tools are already in the repo.

4. repo already has jwm and flwm. I prefer fluxbox and labwc but this is a matter of taste. If a WM arises that you like better than what's in the repos, just create an extension and submit it.

5. You can already create your ideal linux system using TCL and existing repo extensions.

6. netsurf is already in the repo. I prefer brave-browser, others prefer firefox, etc. TCL can accommodate all of this.

7. Nobody will force a user to use an app written in Rust. But I think if a user submits an app written in rust, Juanito will not reject it. TCL uses busybox init and last I checked with curaga, there are no plans to use systemd because it would add complexity without adding any tangible benefit to TCL.

I think TCL is in great shape for the present and the future. TCL bucks the trend of most other distros, which become increasingly complex over time.

[nick65go]

Taken into account that TC focuses on compatibility to older CPU (ex:i486), but just partially (because firefox asks for better CPU),  plus not many users contributing back to TC, then is OK to take for free what someone can, and not be picky (like me?):

- X-org runs (by default) as user=root (it is bad!), allows key-press shared (= spy!) between apps.
- Some apps use different versions of the shared library (lib-poppler?).
- Some library written in rust (not C), like librsvg becoming 3x bigger in time.
- Security of packages checked by md5 (weeker than sha256), in year 2024.
- Only few apps use FLTK, the rest 99% as size/number of tcz from total repo, use GTK* or QT as GUI.

I mean ... I could continue the list, but the intention is not to criticize;
If someone wants to spend time to compile from source (for percevied security) there are other distros (Gento) which provide even the scripts for EACH package to do it (Archlinux, Alpine). There are not demanding distro (DSL, Puppy) for lower resources; for modern hardware are the big boys (Fedora, OpenSUSE, Ubuntu, Debian).

If the sources and instructions to compile them are for free everywhere, even the compiled binaries provided for free; standard linux kernels, standard linux file herarchy, file systems etc. The theory is known: busybox + run from RAM, mounting squashfs files.. done!

So what could be improved? maybe re-check/change the compresion algorithms or block size;
But as long as "compatibility" with low resources (unchanged for 10-20 years) is the goal, limitations of CPU/RAM/HDD of that era do not allow for too much improvement. Maybe tune-up here and there, for some better user confort.

Summary: OK GNUser, you are right, TC is good as it is now, for its intended audience.