Combined architecture 32/64bit

There appears to be a very interesting possibility, which I never considered before. It is actually possible to detect - during the boot time - if you are booting the OS on a 64bit system or not, and thanks to this, the boot loader can automatically choose the right Linux Kernel image - 32bit one on a 32bit computer, and 64bit one on a 64bit computer. Furthermore, as I tested already, a pure 32bit operating system (binaries and libraries) can run without any problem on a 64bit computer while even the running kernel is 64bit (!) too. (The 64bit kernel is necessary when you want to access more than 4GB of total RAM).

To sum it up, it is actually possible to package a 32bit operating system, with two kernels (one 32bit and one 64bit) and then boot this OS in a way that it will automatically select appropriate kernel for the given machine it runs on, while all the userland processes (programs) will be 32bit (thus smaller, and loading faster, when running from CD or a flash drive).

Smaller and faster. That sounds great. What are disadvantages?

Disadvantage of having a 32bit-only system is that any process can not allocate more than a few gigabytes of RAM (if I understand this properly). For a Live OS such as Slax, we don't really need to allocate more than that for any particular process. If you do then you'll probably use some other OS anyway.

Another disadvantage may be that when the software (programs) is compiled for 32bit processors, it will not use some newer (and probably more optimal) instructions, which were added only to the newer 64bit processors and are not available for, say, i486 instruction set, thus there can be some performance penalty. I assume this will not be any significant problem for a Live OS such as Slax again, since if user really needs to gain the extra few percentages of performance, he or she will probably be using some other OS anyway.

Having only one Slax version (32bit OS, with extra 64bit kernel included, which adds only around 20MB to the total OS size), would save me around 40% of the development time needed to package and distribute two variants 32+64, so I'm definitely open to try this out. It also simplifies decision for users, who do not need to care about the architecture, and they can safely use single Slax on all their machines.

Let me know please your thoughts on this. Thank you

User comments
Noxigar 2016-05-17 14:26

Unfortunately I use a modified Slax 64bits for using 64bits calculation software.
But I admit that is not an typical usage for a Slax distribution.

Eng Hong Lean 2016-05-17 19:42

Sounds great!
Smaller, faster and able to use on all machines; looking forward to it

Gary Zhang 2016-05-17 19:55

Hi Tomas,

Awesome, actually Slax aims to old boxes as well, and thus i486 shall not be a problem.

Otherwise, pulseaudio shall need to be into formal release. Latest Skype needs it, and alsa will not be used by Skype anymore.


jcsoh 2016-05-18 00:59

Sound good.

When you built Slax 7, you rebuilt an entire new website for Slax 7 (minus a forum) while keeping the old Slax 6 forum. I hope you won't do the same again as time spend on the new forum, as time spend on the website is better off spend on the new slax.

Just provide a link on the Slax 7 website to the old slax 6 forum (for use as a forum for the new /old slax)

Gary Zhang 2016-05-18 09:10

Hi Tomas,

Is it possible to combine kernel w/ PAE as well? That would be 3 kernels in one release?


Renaud Fivet 2016-05-18 20:38


Tomasz Jokiel 2016-05-20 16:41

Hello Tomas,

Imagine this scenario:
Slax boots 64bit kernel and 32bit userland -> user finds that need to compile 3rd party kernel driver (nVidia, broadcom-sta, VirtualBox, etc) -> even if you provide 64bit crippled sources will 32bit gcc be able to compile 64bit kernel driver?

Never checked myself but i dont think it will work ...

Gary Zhang 2016-05-21 08:02

Hi Tomasz,

Your concern shall not be a problem. You may google: cross compile linux kernel driver.


SlaxUser 2016-05-23 04:23

This sounds great.

Going even further, there should be only one ISO image to download.

Make hybrid ISO that can be written both on CD and USB. Add (64-bit) EFI bootloader to enable booting on modern PCs with EFI firmware.

ISO image should contain all keyboard layouts but only English translations. Other translations should be made available as separate modules (or not at all).

anon2016 2016-05-28 12:15

> Disadvantage of having a 32bit-only system is that any
> process can not allocate more than
> a few gigabytes of RAM

Sorry, by my opinion, this is too big disadvantage (-java and/or -virtualization).

For example, I have slax livecd with my own java-server and prebuilt db. This server boot from iso into virtual box.

Gianluca Cippitelli 2016-05-30 02:35

Sorry, even in my opinion 32bit is a big disavantage
your live cd is so versatile that can be used also as a real server
i have packed the server with a 64 virtualization suite, as a database server

is so easly customizable, with super simple disaster recovery, and have so many features that limit it to 32/64 bit hybrid is a big disavantage for those scenarios

but slax is the best!!

Lightning 2016-06-06 19:34

well, not being able to use a native build would be a definitive reason for me to abandon slax.

this is not just being able to address more than 4gigs of mem, it's about huge page tables / speed, debugging-software on my live system, stress-testing, ...

there are SO many possibilities where the flexibility of a live-system is useful; chaining this is not an option.

i'm using slax because it's a live-system based on slackware and i guess many people out there have the same reason. the "simplicity" of not having to chose between iso1 and iso2 is not relevant (especially as most machines in the wild are 64bit arch nowadays, so a default-download of x86_64 would be adequate for the majority).

Sponge Bob 2016-07-01 23:34

As I understand the matter, a 32-bit system as a whole (the kernel) can not address more than ~3GB of RAM.

Furthermore, I think in these days, a 32-bit userland on a 64-bit machine should only be used for compatibility reasons in special cases. The waste on modern hardware is to big to justify the support of older hardware.

32-bit only hardware should be so old by now, in my experience it requires older or hand-crafted kernels anyway because of some strange drivers, configurations, blacklists... Might not yet be true for the conservative Slackware kernels?

To save even more time, a good poll question would be who needs a new slax in 32-bit and maybe consider 64-bit only. Newer, even 'lightweight', DEs tend to run like crap on that old hardware and the current slax might be a better alternative for years to come.

Hyeonjin Oh 2016-09-26 02:06

Is it possible to boot at tablet with bay-trail process (CPU is 64bit but UEFI is 32 bit)

Currently I have big trouble to use Linux at the tablet (Fotunately Sparky Linux 32bit version is supprting to boot in 32 bit UEFI, seems it is only one supporting 32bit UEFI boot , But I really to use Slax on my tablet)

Please consider this(bootable at 32 bit UEFI) for next version Slax Linux.

Thanks in advance.

Arseniy P 2016-10-11 00:23

how will work chrome with 100+ tabs(only few runing, other sleep or hybernated--greatsuspender, 7+windows, + about 40 addons, css, scripts) in 32 bit os?
what do you think about lxqt?

Spiralofhope 2016-10-13 17:22

I am worried that 4GB won't be enough for all of Slax and applications, but when I use Linux (Slackware) I don't use much over 2GB, so I think that is fine.

I like this idea, and I support it. I want your development time spent on security updates (especially kernel updates!).

It's also interesting and would get Slax noticed more.