Refonte de Tiny Core Linux?

On pourrait travailler sur des OS encore plus minimaliste que Puppy Linux. Je parle de Tiny Core Linux. Je cherche le source code, le github est un peu léger....

Je pense que c'est une bonne approche, on a pas assez creuser le concept "minimaliste" à vrai dire.

• http://tinycorelinux.net/15.x/x86/release/src/
• git clone https://github.com/tinycorelinux/Core-scripts
• git clone https://github.com/jidoteki/tinycore-kernel

BIOS/UEFI
   ↓
Bootloader (syslinux/extlinux/grub)
   ↓
initrd.gz (ramdisk compressé)
   ↓
vmlinuz (noyau Linux custom)
   ↓
init (script init dans initrd)
   ↓
Core OS (BusyBox + flwm + tce-load)
   ↓
Extensions utilisateur (Xlibs, Firefox, Python, etc. via *.tcz)

Je pense que l'avenir est au low-tech, les petits ordinateurs tels que Mango Pi MQ Pro sur RISC-V. Et des réseaux internet sous protocole comme Gemini.

Il faudrait réflechir, selon déjà mes réflections à un nouveau micro-kernel en C++ moderne, tel que le projet Daogoi. Il faudrait une libc++ pour le projet. Le noyau doit pas faire plus de 1,5Mo de binaire. C'est à dire quelques choses d'humainement lisible 2000 pages pour le débogages soit environ 100 000 lignes de code. Au délà de 2000 pages, personne ne lit...

Il faudrait un OS, specialement conçu pour créer Qasari et la CAO low-tech.... De type minimaliste.

Mais comment gérer le CPU, la mémoire? L'optimiser? J'ai une idée. On va refondre l'ordonnanceur et la pile. On va inventer un truc: l'hyperstack torique à 64 cellules. Dans notre OS, feature expérimentale.

C'est à dire Anthony? Pourquoi 64? car 8 bits x 8 bits.

🧠 1. Linux aujourd’hui : ordonnanceur + mémoire

a. L’ordonnanceur (scheduler)

• Linux utilise des algorithmes comme CFS (Completely Fair Scheduler) pour répartir le temps CPU.
• Il fonctionne sur une file d’attente ordonnée (red-black tree) selon le temps d'exécution virtuel.
• Objectif : garantir une équité temporelle et des priorités selon les tâches.

b. La pile (stack)

• Utilisée pour l’exécution des fonctions : LIFO (Last In, First Out).
• Chaque thread a sa propre pile, souvent limitée (ex. 8 Mo).
• Très adaptée aux appels imbriqués et à la récursivité.

c. La mémoire

• Gérée par un système hiérarchique : RAM, cache, swap, avec des mécanismes comme paging, NUMA, ZRAM, etc.
• La gestion est optimisée pour la localité, le prédictible, et la sécurité (protection de stack, etc.).

🔮 2. Et si on utilisait une hyperstack toriques de 64 cellules ?

🌀 "Hyperstack toriques" – une intuition

Tu sembles proposer une structure circulaire (torique), rotationnelle (non linéaire), avec 64 cellules. Imaginons :

• Une structure mémoire circulaire, pas en LIFO/FIFO strict.
• Chaque "cellule" serait un contexte, une fonction, une tâche, ou un état de mémoire.
• L'accès se fait par rotation (modulo 64), donc on évite l’empilement/dépilement.
• Possibilité de garder en permanence une mémoire des 64 derniers états ou appels, accessibles aléatoirement.

📈 Avantages théoriques :

• Accès constant sans empilement ni dépilement.
• Moins de fragmentation (pas besoin d'agrandir/diminuer la pile).
• Bonne structure pour des applications temps-réel, audio, jeux, ou systèmes distribués.
• Potentiel pour des modèles non bloquants / asynchrones cycliques (ex : musique modulaire, shader, multitâche temps-réel).

⚠️ Problèmes concrets :

• Les stacks sont conçues pour la récursivité structurée. Une rotation libre introduit des ambiguïtés de contexte.
• Problèmes de consistance : quel est le "dernier appel" si on tourne ?
• Débogage et sécurité plus complexes : pas de trace claire.
• Difficile à intégrer dans les ABI (interfaces binaires d’appel) classiques.

🔧 Cas d’usage possible