Greetings
I'd just like to thank all of the people who contributed to 14.2 development and of course as always especially Patrick. I think you should be very proud. It's everything I've come to expect and venerate in a Slackware release - solid, stable, and quite thorough. Specifics follow since some are experiencing minor issues that so far, I am not.

I recently bought my first relatively modern notebook, which is a Thinkpad T-61 I got based on Joann Rutkowska's hardware (bios) security recommendations and the ability of well-admin'd Linux to operate smooth and fast on a Core 2 Duo at 2.0 GHz w/ 4 GB ram. I immediately wiped Windows Vista it came with and installed 14.2 - 32 bit. FWIW I simply don't yet see any compelling reason to add to complexity with multilibs for what is debatably little gain. I installed Recommended Full Install, as always and was quite pleased that even the built-in Intel Pro/Wireless 4965 adapter loads by default. The only issue I'm having is not sussed out yet because it seems a common problem with these wifi adapters, and that is they cease to power On. I checked and the Firmware in the kernel is newer than what's on the Intel site but I don't yet know how to verify the firmware is active. When I run iwconfig, if the front power switch is "Off". iwconfig reports so but when "On" merely says "0dbm" but the light never comes on and it won't operate.

This notebook has an nVidia Quadro 570m and I had no problems installing the proprietary driver, which I did as always, simply by dropping to runlevel 3 and running the 340.96 script. It work great and even HD videos play without stutter or sync problems. Sound ran out-of-the-box but I haven't decided yet whether to keep Pulseaudio. I'm much more used to Jack.

Once I discover what's wrong with the internal wifi I will post back here if anyone has interest. Everything else is "the bee's knees"


EDIT - Follow Up - It appears the firmware is not loading. I rmmod'd iwl4965 and ran "udevadm monitor --property" and then modprobe'd iwl4965 in another tab and looking back there is a large list butnbo Subsection - Firmware, no mention of firmware in the entire list of events. Now, I'm rather stuck at least for the time being.

1 members found this post helpful.

This is a completely subjective issue. A "debatably little gain" for you may be a massive gain for someone else. Just because you have no need for multilib doesn't mean others don't. Personally, I don't install multilib on my htpc because there is no benefit I gain from doing so. All the software I need to run on that runs perfectly fine as 64bit. However, my desktop is another story. I like to occasionally game, and I have a lot of games through steam. Unfortunately, steamclient is still 32bit only, so if you intend on using steam or some other program that is 32bit only, using multilib isn't a "little gain", it's massive.

If steam came out with a 64bit version, I'd probably stop using multilib altogether.

1 members found this post helpful.

While I never said it wasn't subjective especially since in my case I have less than 16GB of ram which PAE handles just fine, I'd like to keep up. I understand that over 16GB works but is a tad "hinky". It is the same for me on my desktop which has 8GB ram and which I run 32 bit as both Steam and Wine are native 32 bit. I tried a 64 bit multilib install on this machine and saw only barely noticeable gain and even that was not "across the board". It was considerably more difficult to tweak both Wine and Steam in that configuration.

I fully understand and support those uses in which 64 bit is indeed a gain with little or no tradeoff, and even support the role multilib plays for some. However since I haven't seen "massive gains" I'd like to know more about that, how you measured these gains, and how you got them since it has been my experience that very littler software outside of enterprise and server apps actually employ much of the power that 64bit offers. Maybe my research is outdated. I won't know if I don't ask. So please do expound even if only in a PM.

Apologies, I misread your post thinking that you were running 64bit and saying running multilib had little gain.

Personally, I haven't done any research on 32bit vs 64bit in years. Although, I did make the switch when Slackware introduced 64bit with 13.0 because at that point, pretty much everything seemed to work except for a few outliers. And I liked the memory benefits of 64bit, even if I had no idea if I'd ever hit the limit.

@enorbet,
can you please test does your 32-bit system sleep and wake up successfully on pm-suspend (resume=/dev/sdaN kernel parameter is required where sdaN is a swap partition)? Thanks.

I will attempt to do so but it may take a few days as I will have to use an external drive to expand swap. I am currently only using 200MB swap partition so nowhere near enough to suspend. I am motivated to do so since before too long I will need to run on battery a bit, but I expect to buy a new hdd ultimately as this one is too small and too slow for long term use. Setup I'm doing on AC power - no need for suspend yet. I have been focusing on the wifi prob but am "this close" to getting an external adapter as I have run out of options to fix the "power on" problem within days. Docs say that where I am it's time to submit a bug report (firmware won't load) but I imagine long waits on that.... so drop back 5 and punt seems likely. So I think possibly 4 days tops to suspend and report back.

General:
Re: 64 bit vs/ 32 bit - I haven't written in Assembly in over 5 years and I'm probably barely above "see the dog run" in C, but do understand a bit about code and it seems to me that the main push to 64 bit was driven by servers who need proper support for hundreds of terabytes of ram. Very few single apps need even 1 GB and most are still measured in hundreds of MB even at the high end. So it stands to reason as well as actual testing that most desktop systems, especially in Linux where PAE is available and quite solid up to around 16GB (works pretty well up to 32GB iirc and "sort of" to 64GB) but the main limiting factor is only 4GB for virtual (process) space, is sufficient. The process limitation still isn't a major factor for most SOHO Desktops, especially in that all important spread between 4GB and 16GB system ram. At some point it will become so, but it hasn't yet to my knowledge.

Thankfully AlienBob has produced Slackware Live 64bit so a 64bit system with a 32bit OpSys can fairly easily compare to 64bit OpSys... not perfect apples to apples, but will most often do if one hasn't the space for full install of both.

Bottom line is if you game much or have mostly pedestrian apps and under 16GB ram, there is very little advantage to 64bit and it comes at some overhead. It ain't a "free lunch". It is very possible many could make life easier by sticking with 32bit a little longer, but then I am admittedly old and slow to change

2 members found this post helpful.

I tried to PM you but apparently you have it disabled. Sorry for the extension but it appears I don't have an applicable external drive anymore so today I ordered the new larger, faster drive. Unfortunately they say 6-10 days so it will be that long until I can suspend and report back.

@enorbet,
thanks, also PM was enabled too.

Correct, the only domain I have right now is www.droplinegnome.org , the project is still alive, and shortly I should be able to release the 3.20 version. Unfortunately my time is less and less as time and age goes on. But still working on this desktop as it is my primary desktop I use for my work. It is very stable and thanks to the Slackware team we replace right now only about 19 packages from standard slackware install.

Rgds
Saxa

3 members found this post helpful.