SliTaz Forum
Vous n'êtes pas connecté.
Hey everyone,
SliTaz is turning 20 this year. What started as a challenge — can you fit a full desktop in 25 MB? - became a distro that's still running on machines all over the world. That's thanks to all of you.
A few things have been happening behind the scenes. We had amazing phone call with Pascal and Shann, and it's time to share them.
New website
The site has been completely rebuilt with clean HTML5 semantic markup and a modern look. Same address: https://slitaz.org. If you haven't visited recently, go take a look. Feedback welcome.
New branding
Fresh logo treatments, new color palette (the spider is still there, don't worry), new banners for social media. SliTaz looks like a 2026 project now, not a 2006 one.
SliTaz Core - Signal group for contributors
We've created a Signal group called SliTaz Core for anyone actively contributing to the project - code, documentation, translations, testing, packaging. This is where we coordinate, make decisions fast, and stay in sync. If that's you, join us:
https://signal.group/#CjQKII-q9r70WOMwHW9HjXbPRdOJZQnrx5yfOlYWjXoenQCEEhCDErF0XFUslqW-If5oEn5F
Public discussions still happen here on the forum and on Telegram. Speaking of which — a new forum platform is in the works to replace the current one.
Roadmap: SliTaz 2026 → 2046
We're not just maintaining SliTaz, we're planning the next 20 years. The direction we're exploring: local AI, edge computing, and sovereign intelligence, light Desktop - all while staying true to what makes SliTaz what it is. No bloat. No cloud dependency. No black boxes. Lightweight, autonomous, understandable.
More details on the technical roadmap will come soon. For now, what I want to know from you:
- What hardware are you running SliTaz on today?
- What would make SliTaz more useful to you in 2026?
- Are you interested in contributing? In what area?
This project has always been built by its community. That hasn't changed and it won't.
Let's go.
— Shann, Pascal & Christophe
En ligne
Hello,
What a good news!
What hardware are you running SliTaz on today?
Old pentiums 4, 1.5GHz (with 256MB/512MB RAM), Rolling and 6.0 32bit
AMD64 Ryzen 5, 6GB, Rolling, current 64bit
Recently, Pi 1 B+, SliTaz-ARM; trying to update packages
What would make SliTaz more useful to you in 2026?
I really don't know. Maybe upgrading SliTaz-ARM?
Are you interested in contributing? In what area?
With pleasure! But my skills are rather limited 
I could help to rework the docs (english and french) but I think this should be discuss. Needs to have a roadmap.
(I must add that I don't have many free time during the good season...)
Hors ligne
Hey! Comme c'est bon de t'avoir toujours parmis-nous!
Ok so we need to keep a 32bit version. 64bit is right now the focus.
Yes indeed I would love an upgrade on ARM. Right now ii's out of date but functional on rpi 1. I don't have the hardware and the time. But, you could be the one ;-) And after all that time, your skills are enough.
The short roadmap planned with Shann, he is the master!
* Back to stable/cooking model.
* Current wok tagged 5.0 --> Cosmetic/history
* So we have a new stable
(in a few weeks)
* Move all Shann work on wok-current to wok
* New Cooking 32bit & full 64bit for testing
* Tag 6.0 --> New stable, more up-to-date, get security fix.
(in a few mounts)
* Kernel 7.0 for SliTaz 7.0
* Local and small IA integration
* The community will continue write the story!
Hope to Catch you on Signal!
En ligne
@pankso
- What would make SliTaz more useful to you in 2026?
1. 64-bit focus
2. Newer kernel
3. Newer glibc
4. Newer mesa
5. Vulkan support
6. Wayland support
7. Add Xlibre or newer Xorg with glamour acceleration support
8. Add Pipewire, gtk4, libadwaita, and flatpak.
Hors ligne
Hi mistfire,
Thanks for return, nice wish list, hope 6.0 future include most of this, or at least include this on development branch.
@Ceel, it's on todo to improve arm version, focus on x86/x64, but i don't forget arm 
.
On my side i have eights rpi 3 B+, plan to use it for build farm of arm version and test device.
Hors ligne
Wow! The new website is nice and simple to use - a long needed overhaul.
>- What hardware are you running SliTaz on today?
A dozen of old PCs for my Linux experiments: quad core 775 xeon, athon x4, some 4 core AMD APUs and a couple of 8 core AMD FX systems.
All of them run dated integrated graphics of different generations.
Also all systems are 64bit-capable.
And a used Xeon V4 workstation on a china motherboard as a build server)
>- What would make SliTaz more useful to you in 2026?
Updating a toolchain and base system. Modern kernel with updated drivers are needed for a daily driver system.
>- Are you interested in contributing? In what area?
Well, I used to write some new and updated receipts and fix package bugs back in versions 2-3 when I used Slitaz as a main Linux distro.
Maybe some general housekeeping and optimization efforts)
Hors ligne
Hi,
As said here, we plan to go back on stable/cooking model, it's easy on writepaper, less easier to doing.
- Freeze wok of cooking, move it to wok-5.0
- Merge / move wok-current to new wok "cooking"
- Mass rebuild of cooking chroot and prepare 6.0
=> But this implied all users that running cooking/rolling receive new packages (glibc 2.34, linux 5.10, ...) without proper upgrade process.
----------------------------------------
I'm doing few tests with rolling to test migration on "current/6.0" in vm.
- Install rolling on disk
- adjust mirror to point on my repo for current
- block "busybox" to keep 1.37 (cooking) vs 1.31.1 (current/6.0)
- upgrade tazpkg first, upgrade glibc/gcc-lib-base to have core critical system packages updated
- doing [c]tazpkg up -r[/c] to upgrade remain system.
=> It's work as weel minus issue with locale
I use fr_FR.UTF-8, with glibc 2.14.1 > glibc 2.34, need to regenerate locale with localedef.
[c]localedef -i fr_FR -f UTF-8 fr_FR.UTF-8[/c] to fix it
----------------------------------------
We shouldn't doing it, don't break system of users.
In rolling model, all updates come day to day without big gap, on our case, core component not upgraded since long time.
Think we could do another way, upgrade cooking wok directly with core components.
Cooking continue to be upgraded, openssl 1.0 > 3.5, busybox 1.31.1 > 1.37, no reason to change it
We can continue with upgrade glibc, toolchain, just keep in mind "test", "test" to no broken daily user system and apps.
It's hard to found right line, i try to found best way.
Modern kernel, drivers support, support of recent toolkit (gtk4, xorg, ...) without lost foundations small, fast, easy to use.
On test i doing, we can upgrade glibc 2.14.1 to 2.19, no breaking change, test on cooking installed, upgrade glibc-base ok, apps include on "core/desktop" works, firefox-official 77, vlc also.
Edit :
In all case, bump toolchain step by step or merge stuff to wok directly, tazpkg need updated on system to ensure upgrade smooth.
- Patched to upgraded glibc-base,gcc-lib-base first
- Ensure tazpkg was upgraded if needed
Totally forget that in 2024 i backport patch in cooking about upgrade core pkg first.
In case if we upgrade glibc, we ensure that gcc-lib-base/glibc-base upgraded correctly, that's good
Another step need to meticulous check, tazpkg himself, infact i rewrite config_files feature and compressed files (switch cpio to tarball xz)
Hors ligne
Hi,
The first but not least point push on cooking to prepare migration.
Backport features on tazpkg :
- if tazpkg need upgraded, don't upgrade and ask to upgrade tazpkg first.
- Check at boot if tazpkg needed upgrade, add lock to ensure consistency of package (no install until tazpkg no upgraded).
With this, upgraded become possibility without broken something.
Need to do more tests to ensure upgrade could be simple that [c]tazpkg recharge && tazpkg up[/c]
Hors ligne
I hope for retaining support for old HW (Pentium class, 64 MB RAM) :-)
Thanks for all the efforts!
Hors ligne
@shann,
@Ceel, it's on todo to improve arm version, focus on x86/x64, but i don't forget arm
I agree, x86/x64 first.
Hors ligne
It was quite a gamble, but I think it paid off hands down.
I use Slitaz on some PCs with Pentium 4 and Celeron processors as a 32-bit system. On a Bay Trail tablet, I use the 64-bit version (current/6.0).
As for contributing, I can only do what I’ve done so far; after all, I’ve been self-taught since the dawn of BASIC, and I don’t have enough knowledge to...
Hors ligne
Thanks gibor, mifritscher .
@mifritscher, it's goal, keep as possible support for old HW.
I know could be hard, but i would like keep it.
Hors ligne
What hardware are you running SliTaz on today?
Hi, I use Slitaz daily on a Acer Aspire One Netbook AOA110 which is a 32 bit i686 mini laptop, connected to an external 17 inch screen
Processor: 2x Intel(R) Atom(TM) CPU N270 @ 1.60GHz
Memory: 487MiB DDR2
SSD: 7.5GB
LCD: 8.9" CrystalBrite WSVGA
Resolution: 1024x600 pixels
What would make SliTaz more useful to you in 2026?
the availability of all software packages
making Slitaz very popular so that it gets mentioned in all the software installation procedures just like Ubuntu, Arch Linux, etc
I've been wondering about another Slitaz OS that is musl based? Would this be viable?
Are you interested in contributing? In what area?
if there are any easy tasks for me to help and assist with. My main focus currently is learning game development using C and SDL2.
The software i use regularly: bash, vim text editor, gcc, make, GIMP, git
Hors ligne
Hi Ravenslock,
Nice, not sure all software could be purpose, hope most of them.
For musl based version, maybe to discuss with other devs, not sure at time is priority.
Hors ligne
Hi,
- What hardware are you running SliTaz on today?
-- Asus EeePC 4G (701) daily :
--- Gnumeric 1.12.53 (statistics for my solar thermal and wood heating system)
--- Backup my calendars and contacts from Radicale server on Rpi2B
- What would make SliTaz more useful to you in 2026?
-- I'm wondering if Slitaz would be better than Debian Bookworm Xfce on my 2009 Dell XPS M1330, which I use when traveling.
- Otherwise
-- My main computer is an iMac (21.5-inch, Late 2009) A1311. It’s set up for dual booting—sometimes running “macOS High Sierra,” but usually “Debian Bookworm Xfce.”
- Are you interested in contributing? In what area?
-- I don't think I have enough skills or the time for that.
Thank's for your continued support of so-called “old” computers !
Hors ligne
https://hackaday.com/2026/04/30/jennys-daily-drivers-going-32-bit-with-slitaz-in-2026/
Guys, we are mentioned on Hackaday! YAY! :3
Hors ligne
Hi devl547, nice
thanks for your comment on post.
I update toolchain to gcc 6.3.0, and begin to rebuild packages.
I follow my cookall.sh script and also commits i do to ensure upgrade/patch when needed.
Another point it's to remove "*.la" file could be break build packages.
Hors ligne
@shann
How's the rebuild process going?
Any suggestions on what to install to get up to the bleeding edge of Slitaz develoipment?
Hors ligne
Hi devl547,
Normally all available on cooking, remain think ~10/20% of pkgs from my cookall list.
End of april after test locally with cooking env i pushed new toolchain on cooking and test rebuild, fix/push receipt when needed.
Of course not rebuild of ~6000 packages, i'm focused on pkgs list i have (~1843) more/less.
Another point it's that discover silency broken package, for exemple on cooking Audacity broken since 2022 due of runtime dep upgraded wihout tests .
When i will finished to rebuild remain packages, i will take time for try to fix broken packages we see on cook, and hope not other break hidden.
Maybe not said it publicly, but to be honest, i'm really afraid of situation.
I feel like exhausting myself trying to upgrade the Cooking version.
I can blame myself because I contributed to this situation, since in 2022, when I started working on an updated version of 4.0/cooking, I didn't reintegrate my modifications, not wanting to break the users' existing system.
We are very small team, big miss is QA improvment to ensure that when package upgrade or added not break version.
Cooking (by default development version), has become rolling release and daily use system for user, we need to warranty that working for users.
It's my big reflection, how we can ensure users that use cooking version can be switch to "stable" version.
In long term not able to continue with a rolling-release without having a quality process.
We are not fedora, arch linux, we need to have good organization to purpose something great for our users.
Hors ligne
ok, so installing a fresh rolling on my systems and testing/fixing software will be a nice start?
>I can blame myself
No need. Also, the situation is less painful than it used to be.
At least someone is working up keeping the distro updated)
Hors ligne
Hi devel547,
Normally yes, i'm doing quick test with rolling iso of 110526 (doing in live, need ensure on disk same).
* Boot rolling-110526 iso
* point mirror to current
* Doing upgrade
=> [c]tazpkg -gi tazpkg --forced[/c] (ensure we have latest tazpkg)
=> [c]tazpkg up -r[/c] (upgrade packages to current version)
Bugs i see :
- need to rebuild locales with "localedef -i LANG -f UTF-8 LANG.UTF-8" (ex localedef -i fr_FR -f UTF-8 fr_FR.UTF-8)
- configs files .new remain and not merged (but it's expected, need review files need to merge)
- few packages in rolling exist and need to be purge (at least for desktop iso found 3 [gcc83-lib-base, libwebkit-video, midori-video])
- see miss runtime dep that need to fix (midori need icu, audacity need libdb)
But not sure if enough to ensure system sanity without keep artefact.
Thanks devel547.
Hors ligne
[ Généré en 0.017 secondes, 7 requêtes exécutées - Utilisation de la mémoire: 1.59 MiO (Pic : 1.77 MiO) ]