Is the next Slackware32B(14?) going to have large memory capability enabled?
 

Just wondering now I see computers everywhere with 6G of ram or more if the new 32b kernels are going to be setup for large amounts of ram or will they still need to be recompiled? Also will there be better ssd support for things like "trim"? I know you edit the fstab to get the Linux version of trim but I am just wondering if stuff like that will just be automatic or if I will continue to need to tweak. I like to tweak but sometimes its the lack of need for tweaking that makes me like slack. It just works with no headaches.

Maybe 14 (not the next one) will be 64 bit only. I believe that a very high proportion of developers already use 64 bit as their main systems these days. This must make 32 bit builds increasingly under-tested.

That would be highly unlikely.

Automatic?
 

@dacidsrb You misunderstood. 32 bit Linux can address 64GB of ram with PAE enabled in the kernel. Look here

@slkrover If you read the above wiki you will see that some applications have difficulties when ram addressing exceeds certain limits. High Memory support in the Linux 32 bit kernel is divided into 3 options 1) Off 2)4GB and 3)64GB. Consider which option makes the best default?

Unlike Windoze, unless you're running a fairly massive server with lots of workstations it is highly unlikely you will ever max out even 2GB ram. If you are running software with those requirements or a server of that demand then you will find selecting the appropriate support level and recompiling not only trivial, but an important privilege also impossible in Windoze. This is the very reason, or at least a big one, that Linux outstrips Windoze on servers and embedded systems - flexibility, scaleability and choice. I don't see any option but "Off" being default any time soon.

PAE use isn't even recommended by the Linux Kernel developers. It almost seems like it was a feature added for completeness. It's stability in Linux is questionable. Though, if you did have a problem with it, you may not even know. A memory problem could happen and a program my freak out or return an invalid result. You would never know if it was the Kernel or the program. However, many people that use it claim that they have never had a problem. To them I say, how do you know?

Aside from that, almost everything is 64bit compatible and if it isn't, there is always multi-lib which seems to function reasonably well. I would suspect that only the things using assembly would be stuck. For example, zsnes can not be compiled in a 64bit environment. However, it is possible to compile it in a 32bit environment and run it on 64bit multi-lib.

Exactly, PAE is a bit of a bodge at best.
Sooner or later 64 bit is going to become the norm, maybe by the end of this year? I am still on 32 bit myself, but hope to try 64 bit fairly soon.
When you look at servers, then 64 bit is already becoming the standard as MS Windows Server has jumped.

Never going to happen is a better statement.

The Slackware team use 32-bit as much as 64-bit Slackware on their computers. The initial package builds are usually done for 64-bit because that exposes any "lib versus lib64" bugs in the build, but other than that, 32-bit Slackware gets as much testing as 64-bit.

There will be 32-bit computer hardware for a long time to come. And in the past year I have seen a few prorietary programs that started offering 64-bit binaries but a lot of others are still 32-bit only. I do not foresee that that is going to change any time soon.

Eric

Good old debate about PAE ...

PAE will eat your dog? God will punish you, because you use PAE?

My opinion: there's nothing evil in PAE and it works very well in Linux.

It is true, it is a somewhat slower memory access (estimated at 25% differences), but the memory is not the slowest in your system. The impact is minimal, because many other components are considerably slower. First of all, the champions are the hard disks, with an honor award for the PCI bus.

If, before moving on PAE and use all 8G of your system in Slackware32, you want an overview, here is a synthetic test, made by Phoronix:

Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks

And last but not least, PAE provides NX, which is an excellent protection against the exploits and buffer overflow attacks. If a PAE/NX kernel, in a mysterious way, will kill your process, you can be sure that a programmer has done something stupid. Don't blame the kernel, blame the application developer. ;)

Perhaps it would not be so painful for the Slackware distribution, also to ship a set of PAE/NX kernels for those who want to stay in Slackware32, and they have more than 3G memory on the system (almost all the relative new computers).

Linus in linux-kernel: http://article.gmane.org/gmane.linux.kernel/900604

The conclusion: "There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that."

Everyone knows about PAE/NX Linus's views. For this kernel's PAE/NX support, Linus is the child's stepfather, because it complicates the memory management. However, the kernel has a perfect PAE/NX support, because today there are plenty of pure x86 servers, with more than 2G memory. And RedHat and Novell will support them. You known, today, we eat what RedHat and Novell cook. ;)

The real problem of PAE compared to x86_64, is that you have a 4G memory limit, to allocate to a process, of total maximum of 64G. This can become a problem for applications such as 3D RENDERS, for example. But not everyone has a Pixar Render Farm at home, right? ;)

Anyway, my personal solution is to use an x86_64 kernel, on top of Slackware32, because I don't like Multi-Lib and I hit the 4G memory limit per process. It may be so.

But if we debate the PAE/NX, I do not think that's a bad choice ...

:) That's what I was hinitng at, but 'never' is a long time.

I've still got a working P3-800 that dates back to ~ 2000, but all of the purchases I've made after that seem to have blown capacitors or suffered other fatalities somewhere around the 3-5 year mark. They just don't make electronics to the same standards they used to. I doubt much of our current 32bit only kit will still be functional 10 years from now.

I don't see any reason to forbid me from using more than 4GB memory with my Intel Core Duo CPU. However, if Linus can give me a Core 2 Duo for free, I will agree with him.

Hi,

I too expect 32bit to be around for a long time. Not everyone in this world has the latest and greatest hardware. Loads of people still using fully functional equipment long past the time table of the marketing people.

If it ain't broke don't fix it, let it keep running on and on....

“As is a tale, so is life: not how long it is, but how good it is, is what matters.”- Seneca
:hattip:

I think there is a difference between forbidding something and saying "I personally refuse". No one will forbid you to use as much RAM as you want.

If the major maintainer(s) refuse to care about sth., it's under the risk of being forbidden. -- Though in principle anyone can fork their own Linu>< versions.

Sorry, but I don't see that.

To be honest, no more than 64GB on this silly 32 bits platform... There is still a limit. ;)

Hi,

So my wish for that new shared memory expansion unit is not granted? :)

“Passions unguided are for the most part mere madness.”- Thomas Hobbes

If you don't see it, it does not exist. -- That is Philosophy.

The 64G barrier is a physical limit set by the processor architecture. What is it?

Here's what a Core 2 Duo says:

Address registers are 36 bits, so you can access up to 64GB, in PAE mode.

Here's what a Phenom x4 says:

Address registers have 48 bits, so you can access up to 256TB, in PAE mode. Unbelievable, huh?

The 2G Barrier and appalling stories about PAE, are just myths.

In fact, before hitting the natural barrier of the processor architecture, you will be limited by the motherboard.

For example, I have a Gigabyte GA-M720-US3. Even if the CPU is a Phenom x4, which allows me to access up to 256TB using Slackware32! the motherboard is limited to only 16GB.

So no matter what option I use, this is my hardware limit: 16G. And, sadly, I already have 8G.

------------
And last but not least, if we ask why we need this huge memory. In my case, virtual machines and 3D rendering. But the problem today is that there are some developers that are stupid. Especially those that create Web content in Flash.

For example, I know a site whose creator can successfully compete for the prize Worst Ever Existing WebDesigner. This site contains a (Flash) gallery of images, that require to allocate about 1GB system memory! If you have 2G system memory and you access this site, you're surprised to directly reach the swap. Unbelievable, huh?

Hi,

Shared Memory expansion was utilized when we truly had to have the means to share memory between systems, mostly DEC VAX years ago.

Still used with some stacked inter-processors between multiple systems with external stacks. The technique was first used with early PC for GPU and system memory. I think the IBM Pcjr was the first released with this technique.

In fact most kernels use this technique for memory management.

One thing you have to remember is that there is more than one way to skin a cat. PETA notice! No cats were harmed.
:hattip:

Question for Darth Vader:

I'm curious, how would it be possible to use an x86_64 kernel on top of Slackware32?

I run 64 bit Slack current, but there are one or two 32 bit programs I would really like to have.
The programs have ancient requirements and cannot be updated to 64 bit.

One thing less known is that the kernels distributed by Slackware64 are able to run the full Slackware32 in a excellent way, if you have, of course, a 64-bit machine. In fact, this is The Great Secret of Multi-Lib.

How to get this weirdo? Simply install Slackware32 in a classic mode, then install/upgrade one of the pair of x86_64 kernels. Voila!

However, when you compile something, you must use setarch to report a fake i686. I must admit that if you want to compile kernel modules, things become slightly more complicated. You must install the x86_64's kernel source and use a bi-arch GCC, as in AlienBOB's Multi-Lib or the cross-compilling.

Hmmm
 

Isn't that essentially similar to recompiling a 32bit kernel and selecting something like "CONFIG_MK8=y"
but leaving "CONFIG_X86=y" and "CONFIG_X86_32=y" (and maybe a few other options) ?

No. The kernel is really x86_64, the operating system is the old good i486. You can use directly the kernels shipped by Slackware64, if you don't want to experiment with the bi-arch (multilib) GCC or the cross-compiling (my option).

Anyway, an excerpt from the weirdo's kernel source configuration file:

I'd like to see a thread covering this in detail, that is running a 64bit kernel on 32bit slackware. Kernel modules being the main brunt of the discussion. I use the nvidia module as I'm sure many others do. It would be nice to know if getting that running is possible with this setup.

Interesting. What is the advantage of such installation, and how does it save you from keeping a full multilib structure? Don't you still need the whole set of 64bit libs when you want to run a 64bit application?

Yes, or statically built 64bit apps.

Who said that I run 64 bit applications? :)

Like I said, I run ONLY 32 bit applications. Unfortunately, the standard platform for testing at my job require 6G memory virtual machines. And YES, the 32 bit VMWARE is able to run those machines on this setup. So, YES, I can work at home, too...

Then, you need this setup only if you need to be beyond "the 4G limit per application" of PAE.