absolutely agree!
but, in any case - x64 is the all of our future, and we cannot change that.
P.S. what soft you use as planetarium on linux ( as astro geek) ?
i mainly usinf kdestars, but on some machines he have a bug with all solar system objects culmination shows in one time. i write that bug in kde bugcenter, but it seems like not interested anyone there...:)

I honestly didn't see anything there that would jump out at me to the naked eye when using either on my system. 3 seconds in something like changing a wav to an mp3 isn't worth it to me, and the few things it had an advantage at that were big, again, won't make much difference to the naked eye.

Besides, I read too often still about problems with 64bit and apps to run in 64bit etc that it just isn't worth the hassle at this time for me to even think about switching. I'm sure it won't be much longer (in the computer world time frame of things) that 64bit will finally work as well as 32bit without all the gotcha's and such. For those who like the 64bit, for whatever reasons, good for them and I'm happy, it's just not for *me* yet. I'm not against 64bit, just that I don't see it as ready enough for me to be using yet is all.

Phoronix is just a ....
Look at this test http://www.phoronix.com/scan.php?pag...210_3264&num=3 and then view that test http://www.phoronix.com/scan.php?pag...xdistros&num=2
You'll see the diference's Phoronix just sucks
In one bench Slackware vs Arch vs Ubuntu vs Cents0S
NAS paraller test/EP.B UBUNTU have 373.16 but in Ubuntu32 vs Ubuntu64 on same test Ubuntu have 98.74
NAS paraller test/SP.A Ubuntu have 3830 but in Ubuntu32 vs Ubuntu64 on same test Ubuntu have 2460
NAS paraller test/UA.A Ubuntu have 49.12 but in Ubuntu32 vs Ubuntu64 on same test UBuntu have 16.79

Phoronix HATE SLACKWARE

p.s
Sorry for my english i hope you can understand me :)

Well, I certainly did not say that any arbitrary process could be better implemented on an 8 bit device. And although I did not say that the algorithm was O(1), I did say that it was both possible and more efficient than some other algorithm on newer hardware (and infer that to mean faster in particular). So if mine really were O(1) and both possible and faster as stated, then your conclusion would not follow and O(n^2) on 64 bits would still lose the race!

But my point was not to show a case where the bounds were understood.

It was specifically intended to counter the statement that 8, 16 and 32 bit desktop platforms were automatically obsoleted due to the calendar date and the availability of 64 bit hardware. And in that context, all too many programmers (so-called) rely on the speed of the CPU and availability of RAM to cover their own lack of understanding of their problem spaces - that is, where the programmer has no actual idea what the bounds of his/her code are!

If they understood those bounds on the older hardware and continued to implement similar good algorithms on the new platform, then we would see performance increases proportional to the hardware specs!

Which was really my point, perhaps poorly made.

Yes, 64 is here - and that is a good thing! I certainly did not mean to imply that availability of 64 bit hardware was a negative thing! But I am still waiting for the day that we can rely on getting actual, useful benefits, as opposed to glitter and flash, from those dizzying hardware specs on our desktops - and that will require better discipline and knowledge level on the part of those who write the code that runs on them - and that trend is not often hopeful in my personal opinion... (but I am certainly no expert either!)

Much of my professsional career was involved with the development and support of motion control and receiver systems for many of the world's large telescopes, radio telescopes in particular. It was the perfect marriage of passion and profession! Hence, astrogeek...

I play with Celestia sometimes as a planetarium of sorts, and use a few ephemerides, but prefer to sit out with my 8" Celestron or a good pair of binoculars and paper charts... or just close my eyes and go places, still the best hardware platform!

As mentioned before (I think...too tired to read the whole thread), There are a few categories missing. I run mustly 64-bit multilib, but with one laptop 64-bit only, and one old laptop (P3-900) that 32-bit. In my household there are a few more with various mixes of 64, multilib and 32 bit.

By the way, who has just one computer these days?

the poll didn't really make since to me...
 

So I'll just post.

I run a pure Slackware64 most everywhere.

On virtually *ALL* installations, I do not run multi-lib either.

If there is software I don't get to use because of this, typically speaking, things like Skype or Jitsi or Wine - then so be it, They no longer exist, generally speaking, and that application is not part of my universe.

On the other hand, with some apps I will go and install the 32 bit apps with static libs.

I've nothing against multi-lib, but it's a kludge.

Now, having said that, I do run some 32 bit slackware machines - for building SBo's I maintain or for running things with limited resources - like PBX systems on old boxes.

A 64 bit OS has no advantage over that last item.

In truth, I would opt for using a 386SX based system for many small UNIX projects, or even a 286 based system for a lot of DOS or CP/M kinds of things, were it not for the Raspberry Pi, which makes those quite viable chips and their capabilities now unequivocally obsolete.

For powering a TNC or running a packet radio station there just isn't any relay that needs to switch faster than a 4.77MHz 8088 anyway, and those tactile click keyboards are awesome too!

But that's not what this thread is about. It's simply another survey to help determine when 32 bit Slackware can or should be retired.

And I don't see this as a software issue. I see this as something that should be predicated upon the general availability of cheap hardware resources - as the Linux community has always prided ourselves in serving (cheap hardware).

This is what gave way to the rise of Linux (You didn't have to run Jolix, Xenix, or Own a VAX) - someone could use any 386 computer as their UNIX workstation/server/develpment platform.

I don't think Slackware should abandon those principles. I would like to remind everyone about the huge Slackware version bump a few years back, which Pat did as a tongue-in-cheek response to the insane versioning races of other distros at the time.

I want to know that when I use hardware that is up to ten years old (think 2003 or so, AMD K6 and K7 processors) for things that they will be perfectly adequate for (a FreeSwitch or Asterisk PBX, for example), that I don't have to wonder whether I can support my project using Slackware.

So...

No offense @H_TeXMeX_H, but as often as I use Slackware64 exclusively, and as little as I use 32bit Slackware, I certainly don't see that as any measure of when 32bit hardware support should be retired.

Well that's my :twocents:

Kindest regards,

.

I'm regularly setting up Squid and SquidGuard as filtering proxy on LAN servers for 50 to 200 users. The servers' job is to analyze every outgoing HTTP connection against a trivial database with several million entries. Slackware64 on the server does make a difference here.

And that's fine, for those who run servers or servers of that kind. There's an awful lot of people who just want a desktop or laptop for things everyday people like me need it for. I'll never in a million years need to run a server of *any* kind on my system.

Like another posted above, linux in general and Slackware especially (since I happen to like it and use it exclusively after 11 years with suse/opensuse) needs to be able to keep running easily, without headache of kludging a 64bit system together, on old hardware. Folks like me just can't afford to upgrade hardware at the drop of a hat.

Let 64 bit keep going forward, yes, and when it finally gets to be as polished as 32 bit and works on anything one happens to have, *then* is when someone can say 'Let's not worry about putting 32 bit software on the Slackware repo's and DVD's anymore.'

For those in situation's like yours, it works now for you and that's great, but let's keep 32 bit around until it *all* works for everyone and anyone and is as easy to find *all* the same software that it will work on etc.

I mostly want to differentiate hardware reasons from software reasons. It seems that it's mostly hardware that doesn't support 64-bit. In this case, you cannot get rid of Slackware 32 and not alienate users.

Software and laziness currently account for about as much as hardware reasons.

Lilo refuses to boot 64 bit Slackware from an Extended partition.
Lilo will only boot 32 bit Slackware from an Extended partition.
The following partitions must exist.

Windows Boot
Windows User
MS-DOS
Linux
Linux_backup

As you can see, there are more than four partitions, therefore all
but the first three partitions must be extended partitions.
Lilo will NOT boot Linux from extended partitions !!!

p.s. It doesn't help that my processor is 32 bits only...

I hope you were joking when you complained like this?
A 32-bit CPU will never run 64-bit Slackware. Your partition schema is irrelevant.

Eric

It does for me. From fdisk -l:
/dev/sda6 is my linux root partition which contains /boot.

Now you are trolling.

I think you got something wrong here. In my business, I badly depend on 32-bit Slackware, since most of the time, I have to install client desktops on existing hardware that's actually quite ancient. Think "PCs that were new around 2005, sometimes even 2001". That's also one of the chief arguments for using Slackware, since it belongs to those happy few of distros whose installer won't choke on ancient hardware.

On my website there's a page explaining to folks how they can keep their old hardware as long as it won't die and still install a highly usable Linux system on it. You'll see that minimum specs are quite low:

http://www.microlinux.fr/votre_materiel.php

I'm running this offer in partnership with a local vendor for refurbished hardware (http://www.plusdepc.com/) and it's quite popular among clients.

I have three systems. Two systems have 32-bit CPUs and the third has a 64 bit CPU.

Of course 64-bit Slackware won't boot on the two systems with 32-Bit CPUs in them.

I have consistently been unable to boot 64-bit Slackware (both 13.37 and 14.0)
from extended partitions on the third system with a 64-bit CPU. The two
64-Bit Slackware O/S boot just fine from primary partitions.

Maybe I have been walking under too many ladders?!