The first choice is kinda extreme, but it's most close to what I need. I don't feel an extreme urgency, but one can feel the pressure. Actually what bothers me is that the original Slackware team (basically, Patrick) doesn't say anything (or at least I didn't hear something certain) about this step.
I'm thinking about a transfer on one of the others 64 pure slacks which hopefully will emerge into the "core", but I'm not so accustomed to be able to debug too much (new user here ).
The "Slackware-based" I think are out of the question, because the details, like unmodified source code, discrete releases, individual revisions - make a complete whole. I agree they fill some gaps, though.
I think someone who knows personally the guys should tell them "come on, get together some guys for the ports, desktops, mobile and live CD & stuff and move on from the stone age. it's not that hard".

I don't think we are as much in the stone age as people think. Consider this. The boeing 737 has been in production for over 40 years. The airframe design hasn't changed much, the only thing that has happened are very basic and minor changes to keep with the times. Almost every part of the aircraft is still made the way it was back then (sans the modernization like cockpit equipment, and more efficient engines). It works well, so why change a design that works? Yes it may be based off an old design, but the fact that everything goes along smoothly has shown that there isn't a reason to change it. Just like Slackware. If it isn't broken don't fix it.

Also consider that Pat and the development team work on their own time and money. Therefore there is no time to create ports and live CD's. They leave it up to the community to do all of that. Again this goes back to the KISS principle that Slackware was founded on. By adding all of these things, it just makes the OS bigger to maintain and more complicated. Simple things work a lot more than complex things. Example,
Bike vs Car. While one does more than the other, one of them is also a hell of a lot easier to maintain and fix if something goes wrong.

At work I use 64 bit Vista (and am constantly finding new reasons validating my choice of Linux at home). Several of the programs I use are 32 bit, and I've gotten a "out of memory error", even though there was plenty of RAM available; I just hit 3-4GB with the 32 bit programs. Matlab is 64 bit, and I've pushed it to well over 1GB in the normal course of working. Of course, I could easily force it over 4GB by creating a large enough matrix . The need for 64 bit has definitely come, and I wish application developers in the proprietary world realized that.

Now, at home, my laptop is happily running Slamd64 with a measly 2GB of RAM, and I have a "headless" laptop (the screen stopped working) running Slackware 12.1. For my personal use, I don't think I'd "need" 64 bit for at least another few years.

I doubt it's a good example, C-Sniper. I myself have of course many things that are old or are build today like they were build maybe decades ago (yesterday I bought a new Opinel knife, and I'm still using a shaver that hasn't changed its shape in maybe 70 years...). But these are not electronical things. I would bet that the technical equipment of the 737 is NOT the same as 40 years before. 40 years is a very long time in computer history. Do you think udev is necessary? Power saving technologies? And compare 16-bit Windows to 32-bit Windows Do you use a mobile phone, maybe even with web access or built-in camera and MMS? Do you still use the hair dryer your parents used 40 years ago, do you like electronical safety equipment in your car? Or do you like WYSIWYG text editors? ... I guess you get what I think

I don't think 64 bit is an absolute must at the moment, but time is going faster in computer/electronic world I think, much faster. That depends on the market size, the costs to develop new models, how much a new model costs the consumer (of course I would rather exchange a computer that a Boeing 737 if I had one ), the lifetime of products, if there are many competitors and other factors. I'm not into business economies but I have a feeling there IS a differece between 64-bit computers and Boeing airplanes.

There is a little problem. I think, for 32bit software in many cases it is possible to use more than 4GB of memory (needs research/verification, but you definitely won't use malloc for that, only system calls). However, you won't be able to allocate a single continuous block of memory which will be larger than 4GB. So the only case where use of 64bit is unavoidable is "large enough matrix".

I agree everything works, and it is hard to think what advertise M$, Novell, Canonical and others is "evolution". Slackware don't address every one, as no distribution does it but there are companies and individuals who would use a 64 system because they need it.

Actually i find the structure of Slack useful rather than KISS. For example Arch is on the same idea, but their rolling releases and automation put it on an opposite site. I'm sure you'll say that the release method has not much to do with the distro itself, but it has if you look closer to the two mentalities. Automation gives those distros an advantage for growth loosing stability and control. But this can be solved with a bigger team, and as long as 2 guys are able to rebuild the distro on 64, why couldn't do this some other guys in the team?

I find the propaganda and world mouth unfitted to the real world in this case. Eg. I would like to recommend Slackware to others but I can't find anyone it could be fitted for. KISS means to do nothing unneeded, but when you need something and it's not there it means lack. For example I discovered the support for XFCE is very poor. KDE and GNOME (only the desktop) are simply not for me, or what I need, as SUSE is not for me and many other things. Imo KISS refers to complexity, not volume, if the requirement is large, than the structure and principles should be kept simply on a larger system.

For example I think Slackware + GNOME is for a large category of users and it is sad that these ports are not officially recognized. KDE is allegedly bloated and redundant and I doubt the searchers for a crystal clean OS are pleased about its "feature wealth". The exclusion of GNOME, applications (eg. multimedia/graphics)and ports I see only a side effect of the careless lack of human power rather than following a simplicity principle. I think these two things should not interfere.

On the other hand "slack" means "do whatever you want", it doesn't mean commitment, nor unification. Patrick does whatever he needs and can't be argued against, but he could be persuaded . Beers or something?

I researched a bit and I think no existing distribution would fill the gap Slackware would leave if it would disappear. And I'm afraid it will fade away . Tradition, fame, elitism and nostalgia are attracting more users today than Slack's core nature. Having it more popular and supported means more people Slackware addresses to have the chance to use it, today and in the future. I don't think it is a bad idea. is it?

With respect to the original thread question:

What would a 64-bit system provide me that the current 32-bit system does not? My basis for my question is my experience related to the transition from 16-bit to 32-bit. I still have a WFWG 3.11/Norton Desktop 2.0 partition on one of my computers. The operating system flies compared to any 32-bit system. Of course, I now run that 16-bit system on 32-bit hardware. Therefore, if my experience continues, I'd expect my current 32-bit system to run faster on my current 64-bit hardware than a 64-bit operating system. Will a 64-bit system run slower or faster on my 64-bit hardware?

With respect to concurrently producing both a 32-bit and 64-bit operating system:

How much labor is required to maintain two operating systems? I have no experience with this and I don't know. Are there 64-bit versions of the foundational tool chain? From that point is the only thing needed is recompiling all the packages --- something that Pat probably already automates with scripts?

With respect to Slackware filling a niche:

I agree that today Slackware fills a niche. I don't think Slackware is a good choice for non-technical people wanting to use a computer. Only a decade ago, people who used computers were also people who tinkered with computers. Back then Slackware was a good all-around choice for a computer operating system. That is not the case today. Many people today using computers want nothing to do with tinkering with computers.

I don't like everything about Slackware. I have voiced my opinions here at LQ, my web site, and personal emails with Pat and some of his support cast. My disagreements are similar in some respects to sibling rivalries: I voice my opinions but remain committed.

I use Slackware primarily because of the "do what you want" philosophy. Not long ago I decided I should expand my horizons by tasting some different distros. I admit I did not spend as much time with this effort as I could or should have, but the first thing I noticed was how many decisions were made for me and tended to frustrate me. Some of these distros provide some bells and whistles I would love to see with Slackware, but some of the basic configuration decisions frustrated me.

I am considering building an HTPC. With that new hardware I might travel a temporary side road where I experiment further with some of these distros. With a modern spare box, I can install and delete distros all day long without affecting my production box. After I get my fill of that kind of thing, I would proceed to building an HTPC. Regardless, is Slackware an ideal distro for an HTPC project?

I have some concerns for two reasons. One, my short and humble mini how-to to build Slackware into a more full-featured multimedia machine has received far more visits than I ever dreamed, which indicates the stock Slackware is missing some things in that arena. Second, I have scoured the web looking for related essays and how-tos with respect to using Slackware as the basis for an HTPC project. There is not a lot out there. A serious lack of such information indicates that perhaps Slackware is not an optimal choice in that arena. I don't know. For myself, my current production box is so highly tuned to my preferences that starting from scratch with a different distro is intimidating. I could mirror my current installation to my new HTPC and start building an HTPC from that point.

The bottom line is that Slackware fills the niche of not getting in the way and is packaged with very few presumptions about how the end-user should use an operating system. That one criterion is sufficient for me to keep using Slackware. So in the end I keep using Slackware because I can "do what I want." Despite the handful of things about Slackware that frustrate me, they are far outweighed by the personal freedoms I lose when I try to use other distros.

I'm unsure What filling a niche has to do with 64-bit systems, but the issue was raised and I offered my own observations. I suspect that if Slackware disappeared and I had to choose a different distro that I likely would be quite frustrated for a while.

+1

Really nothing else needs to be said

I understand what you are trying to say, but you might consider going over to Boeing's web site and doing some research on the 737.

http://www.boeing.com/commercial/737...ackground.html

While it looks the same on the outside, other than the fuselage the 737 has been completely changed over the years.
In 1998 Boeing delivered the Next Generation 737 which looks like the same 737 they have been making since the 1960s, but is entirely new from the inside out.

It would be like gutting an old XT or AT case and putting in the latest and greatest motherboard, dual core processor, etc., etc., etc.

Boeing has done this over the years with all their aircraft. As new technologies evolve in avionics, metal alloys, composites, wing designs, engines, etc., they are incorporated into their existing aircraft... but I'm off topic. Sorry.


As to a 64 bit version Slackware, yes I would like to see it as soon as possible. As it is I plan to install Slamd64 as soon as the telephone problems in my location have been resolved and I can once again have a broadband connection.

That may be the rule, but there are (many) exceptions.
There are applications that tend to behave differently in 64bit, applications that need additional configuration options, patches, even in some extreme cases additional dependencies.

PS. I am talking about applications in general, some of which may not be part of Slackware.

I use Zenwalk (which is based on Slackware) on an old PII of mine. I have no need now or ever (well, as long as those old boxes keep working) for 64 bit in Slackware/ZW since it's my "old iron OS", but I do require support for all the old crap.

If I had to choose either 64 bit or 32 bit slackware because of difficulties maintaining both, then of course at this point I would choose 32 bit. Having an exclusively 64 bit version would essentially wipe out slackware for many people with older hardware, though of course we could continue to run older versions, for a time.

Everything that has been written above seems reminscient of discussions during the transition from 16 to 32 bit. Certainly as all the hardware becomes 64 bit over time, and as all the applications move over to 64 bit, then so too must slackware, or become extinct. I suspect, however, based on how long it took to make the 16->32 transition, that it will be quite some time before that happens. How many years did we have 32 bit processors with 16 bit Windows and applications? Of course it was part of the reason (among many others) many of us moved to Linux, in order to better use the hardware.

So I think slackware has plenty of time to get there, with slamd64 (or bluewhite64) satisfying the needs of earlier adopters. But if we wait too long, people will move elsewhere.

Yeah, that's my fear, but so far slamd64 and bw64 fill the gap. One day, however, I would like to see an "official" version, even if it means simply nominating one of these as official. The main issue is the latency between a slackware fix and the time it takes to make it to the 64-bit versions, if anyone is running slackware on a server or something that needs to be up-to-date security-wise, the 64-bit versions (slamd64, bw64) may not cut it due to this latency. There are also 64-bit specific issues that do appear, and there is no "official" stance on them.

I don't think that most people will need 64-bit Linux until computers start having near 32 to 48 Gigabytes of memory as standard memory. Very few applications need more than the 2 to 3 Gigabytes of virtual address space of a 32-bit CPU and the 64 Gigabyte limit of PAE is not even close to being an issue.

64-bit is mostly a gimmick started by AMD to jump ahead of Intel and Microsoft saw it as a marketing opportunity (don't they always). Intel soon followed. If Microsoft was at all interested in providing a "state of the art" operating system they would have added true PAE support in Windows XP or at least Windows Vista. The fact that a Windows 7 32-bit is going to be sold without PAE support is idiotic. Of course third party developers may just decide not to support 32-bit Windows 7.

Linux fortunately supports the 64 Gigabytes of memory that has been available in Intel CPUs since the Pentium Pro. That provides some overlap between 32-bit and 64-bit operating systems. It's also the reason why I don't think that a 64-bit Linux is urgently needed.

If there was 64bit version of Slackware, I'd be using Slackware on all my servers, instead of just on my older boxes. There are very few reasons that people need to run 64bit on their desktops (for now), but when it comes to the server arena, that is a different story.