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