Slax author's Blog (RSS)

I do not think that Slax is quite ready for the 64bit world yet.
Perhaps moving to i686 might be desirable, but I would say that the majority of computers I see are still 32bit. I also believe that the Slax website should be in a fairly finished state before the project moves to a new major version number. Another issue to consider when the change eventually moves to 64bit (I would guess that it will happen eventually) is: Will Slackware upgrade at the same time? If Slackware will not then that means that Slax will lose some of the steady footing that it has with the Slackware base. Slax could start using a 64bit variant of Slackware if it needs, but that does bring up stability questions. As far as I know 64 bit is still not as stable as 32bit.

On the issue of recompiling the kernel, I do think that it would be best if the kernel was separated into the vmlinux, the initrd.gz and 000-kernel.lzm in future versions of Slax. This would make it easier for the users to toss in a new kernel version with support for various extras, like the 4GB+ support.

I am in full agreement with Tomas here. I have at least 3 or 4 machines with 64 bit processor and since Slax is currently 32 bit only, the processor is not used to its maximum capabilities. There is already a 64 bit port of SLackware SLAMD64 and Blue???64 which are SLackware ports to 64 bit. Adobe is already recoginizing the need for a 64 bit flashplayer and they are working on it.

root@slax:~# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping : 2
cpu MHz : 2599.894
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips : 5199.78
clflush size : 64
power management: ts fid vid ttp tm stc 100mhzsteps

processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping : 2
cpu MHz : 2599.894
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips : 5200.22
clflush size : 64
power management: ts fid vid ttp tm stc 100mhzsteps

root@slax:~#

In light of the argument that Slax will not boot in many machines because of 64 bit, I propose two versions the regular old Slax with 32 bit that is mostly bootable in all/most machines and a 64 bit one without the kernel memory limitation. Also it would be great if the ath5k/ath9k, other kernel included drivers which are not included in slax currently are now included in the newer versions. This way more people can help and report bugs, new innovations and new technologies to ensure the growth of linux and of course Slax :)

Just my $0.02

Antonio

Greetings Tomas,

why not making the 6.x "officially" the last release to support i486 computers...? (Or even for i586:)) If this version is still around and everyone knows, you don't really have to bother with these PCs in the future releases and thus focus on innovation...!

At least version 6.x works for me and I would not mind, if I were unable to use 7.x even on PII or PIII, once the support is maintained, or at least not abandoned completely. These old architectures will have to be left behind eventually, right? Then, is version 7.x any worse occasion than 8.x or 9.x or "whoknows"... :D ?

*eM*

It is your right to choose 64 bit or 32 bit,
I think it's a good idea if Slax7 support both 32 bit and 64 bit.
may be in your western country 64 bit processor is popular but it isn't widely in our eastern community

There's also the netbook factor to consider and it's Atom chip which is essentially 32-bit with little ~real 64-bit support (via wikipedia).

There's such a strong movement today toward portable computing in the form of netbooks, handhelds, laptops, smartphones, etc.. that finding a single OS to run on all these devices is getting extremely difficult.

I think Slax is primed to move into the netbook arena and possibly even MID/Handheld computers because it's already optimized for speed.

The biggest issue today is support for modern hardware such as wireless, flash card formats, usb portable storage, etc...

A 64-bit Slax is a great idea but seeing Slax available and optimized for these new portable devices (with low-powered cpus) is an exciting possibility also.

i also think you should maybe make 2 releases... a 32 and a 64 bit version for 2 reasons:

my INTEL iMac (which is built 2006! has 32 bit,as many other NEW processors also...so that would not be a good ida no longer making a 32 bit release)

and:

modules/apps are most times i486 for slackware...they would needed to be recompiled,didn't they? ... so that would be even harder for you to finally check all modules and release them =/... i think the module page is still far to empty


so you really should think of keep on doing a 32 bit release,thanx!

I see little value in 64 bit in a few years from now (at least 5). ¿Speed? Little more and only in specialized software. ¿Memory? You already have PAE to reach 64G. Also you have to remember that equivalent code will take more memory (64 bit pointers) and that you'll probably need 32 AND 64 bit libs for compatibility with some older code.

I think that compatibility is difficult to overestimate and that you better not fix what it's not broken!

Compatibility of a 64-bit OS with 32 bit applications is possible, slamd64 does exactly that. Comments show that it is perhaps not so good idea to drop support for 32bit processors at all, so I'll have to consider it once more.

While most computers now support 64 bit, I do agree that support should be offered both for 32 and 64 bit processors.

I also agree that slax would be the perfect netbook/portable PC OS option. It is lightweight, simple and works with most hardware with little or no configuration.

I work in a call center for tech support, and I will say this. There is always some old-timer who doesn't want to upgrade their PC because it is stable and they are comfortable with it. There are still people running windows 95 for that simple reason. So abandoning 32 bit might not be good for users that run linux on older machines which they cannot/will not upgrade.

Slax is my swiss knife. It's not my primary desktop, but I boot it on computers that I can access, but cannot (or do not want to) replace the OS.

Slax had numerous times proven to be priceless tool, which you can rely on. Used it numerous times when recovering machines of my friends.

Having said that, I would not get rid of slax on 32bits. Rather than that I would prepare to multiple architecture. You choose one platform to be primary (even 64bits) and it will be you dev, others to be just auto-compiled.

This would have one advantage - if needed you will have more than one version/architecture on your USB/CD or whatever. In such case you can have single arcitecture distro, which is small or multiple distros if you have enough space and which you will choose during boot

64bit pointers use much more memory. Isn't Slax a light OS ?

For Slax 7, I would better propose getting rid of initrd. Floppies time are gone for years. Why spending so much time duplicating a true Linux in a uLinux ? Why not a huge initrd ? You have it, it is 001-core.lzm ! I see 2 problems. It's against a strong choice you made: linuxlive is one thing, Slax is another thing totally separated. The second problem is PXE booting. The whole 001-core.lzm would have to be D/Led instead of httpfs-ed.

Regarding initrd PhilippeL mentioned, it is not such simple. If you use huge initrd, it is in memory all the time you run Slax. There are still a lot of people who use Slax on computers with 128MB of RAM, and putting 001-core.lzm in RAM would take 50MB... That is not the way to go.

If you wish to download modules in PXE boot, you'll have to add copy2ram option to syslinux.cfg's default cmdline. Not too hard.

Hello Tomas.

I will be very happy if slax have a version in the future of 64bit.

Thanks for your work!

I suggest NOT to move to 64 bits. Instead, I suggest to have all the SLAX compiled for i686. 64-bit CPUSs are getting more and more common, but I prefer to maintain compatibility with e.g. IBM ThinkPads T/R/X 2x, 3x, 4x (that are very popular within Linux community). From my point of view, i686 SLAX is an appropriate solution these days.

How about both?
I believe that slax can have the traditional version plus an enhanced 64 bit version, slax-6.0.10 plus slax-6.0.10-x86_64 that would really make slax much better for all users that have 64 bit machines and also keep Slax in its traditional form to boot on older machines as the swiss army knife :)

I have tried all the existing 64-bit recompiles of Slack [that I know about; Slamd64, Vector, Maya, Blue-white, ??] and so far I see no value added from any of them. Maybe we're just waiting for a better compiler? And that goes for distros using i586 and i686 compiles -- they are no faster than Slax.

I understand that Slack kernels use the 486 instruction set, but what is "686 tuning" ?? Can someone explain that simply?

These results don't make sense to me, but that's what I see here, running an older amd64-3000+ system.

The one problem I would see with 64-bit is many of the earlier EEE PC netbooks from Asus do not support 64-bit. Although I think the later ones with atom processors do. granted that's not necessarily a big part of the install base out there it is a platform I like trying Slax out on.

The idea of splitting into 2 developments seem promising - after all it is just a kernel configuration isn't it? Just more work compiling the kernel twice for different branches.

Just my 2 cents worth.

Eventually, everything will go 64-bit, so it is worthwhile starting a 64-bit branch, but I would keep 32-bit as the main distribution for the short term.

In general 64-bit code is no faster than 32-bit code. The main difference is that 64-bit code can access more than 4G of memory space within a single process. For most applications, people often find that 32-bit code is actually slightly faster due to less memory usage.

However, some applications do use huge amounts of RAM. For example, some games use it to hold run-time graphics. It may be a benefit for video processing, or working with several high-res images. Are people actually doing this sort of thing in Slax?

More importantly, IMMHO, is that 32-bit Slax should move to at least 586 as the base processor for the kernel, so it can support up to 64G memory. It still only supports 4G of address space per process, but 486 can only access up to about 3G total, due to things like video memory mapping.

I would love to have a 64 bit Slax. For older hardware I will just keep my Slax 5 and 6 series discs.

I think you should move to 32bit kernel with PAE enabled, this way Slax can use up to 64GiB ram. Intels Core Duo (release in 2006) is 32bit only, and it wasn't discontinued before early 2008. So if Slax is 64bit only some quite recent computers will not be supported.

the average life of a home computer is ten years thomas! :-(

the average life of a home computer is ten years thomas! :-(

Many computers are not ready for Slax to become 64-bit. There are still computers sold with x86 processors. We should probably make it straight: 6.x is now the last Slax version to support ancient, old computers. We need to move on to i586.