Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
|
08-02-2014, 07:22 PM
|
#16
|
Member
Registered: Jul 2014
Posts: 56
Rep: 
|
You mean forward compatible... But there's no way for an OS written in 2000 to support hardware made in 2010, unless you stick to generic drivers.
The whole point of new hardware is to upgrade performance, include new or needed features, then remove too old/unneeded features. How can a 10 year old OS know what features will be there?
On the flipside, i know you're gonna use the argument that the hardware developer should make drivers compatible with old OSes. But let me ask you this... Why do various Linux distros have short/long term support and not indefinitely/infinite support?
Simple, it takes resources to handle the upkeep. What's that saying... Time is money?
Edit:
okay, what exactly is nvidia's driver hung up on? Is it an incomplete cpu identification? What are uname's dependencies? Can uname or its dependencies get updated, at least to something a little newer, if not the latest version to pick up newer cpus? I mean, is it really the kernel that gives the full id? Or is it more of the kernel CAN pick up a standard id format, and uname simply didn't have the right translation/look up table for the newer ids.
On the other hand, would the nvidia driver proceed even if it had the full cpu id? Or would it still hang if the cpu were classified as "too old?"
Last edited by Goobers; 08-02-2014 at 07:41 PM.
|
|
|
08-02-2014, 08:16 PM
|
#17
|
Senior Member
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 4,442
Original Poster
Rep:
|
No, I mean downwards compatible. The new machine must be compatible with the old OS and the new OS should be compatible with old programs. So, when NVIDIA builds a new video controller, it should be compatible with previous operating systems so that the OS will use a subset of the NVIDIA controller. Example: The 8250 was the UART in early PC computers, and it was replaced by the more powerful 16550. But this did not make old communication programs to fail, because the old program used a subset of the 16550 which was identical with the 8250. The program did not notice the difference. Look at Intel. I have one of the last generation PC compatibles and it can run machine code written for the 8086 CPU, which was released in the 1980's.
The NVIDIA thing. Once the installer was deceived by making it believe the machine was i686, it however disliked the 2.2.16 kernel. It needed kernel >= 2.4 to compile the kernel module. But the NVIDIA card I have can use things as old as VGA. Where was the compatibility broken?
Last edited by stf92; 08-02-2014 at 08:25 PM.
|
|
|
08-02-2014, 08:34 PM
|
#18
|
Member
Registered: Jul 2014
Posts: 56
Rep: 
|
You do realize that the reason the new cpu can run all that old machine code, is because that machine code is incorporated as GENERIC code in the cpu's command set. Which is no different from the very first line i said... Old linux supports new nvidia if you stick to generic drivers.
Is your "machine code" an OS? Or is it a specific program that does a small set of tasks? Pretty sure you can't tell that machine code to support sse4 or netburst architecture optimized code. Its the same with the nvidia hardware, the generic driver lets you do all the basics, just none of the advanced stuff that MIGHT require a more advanced cpu. Driver installations have specific hardware "sub" requirements, because after a certain point, their advanced feature get too crippled and i haven't seen any driver turn off support for a feature that the hardware actually HAS.
You call it downward compatible from the point of view of the hardware... But its a forward compatibility from the point of view of the OS... And that is the bigger portion of the over issue of coding compatibility.
|
|
|
08-02-2014, 09:17 PM
|
#19
|
Senior Member
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 4,442
Original Poster
Rep:
|
Machine code is, so to speak, the program as seen by the CPU. I used that expression instead of just program because the OS can't know before hand the format of the executable file and so won't be able to load it, let alone to run it. Once loaded into memory, however, the program is no other thing than a sequence of CPU instructions that is, machine code. I think this expression is demode nowadays.
You're right. I'm running a GUI under Linux 2.2.16 (slackware 7.1) with no problems. The machine is the one with the NVIDIA card. Only that I can't use its full potential. So no compatibility problem here. However, I was speaking about the uname command. Well, it did what it could, after all, as it printed 'i?86'. The '15' it could not guess it. All I say is that the program, or the OS, or both of them should have been a bit smarter and realize it could run perfectly well in a Celeron D, as in fact the program did.
|
|
|
08-02-2014, 11:31 PM
|
#20
|
Member
Registered: Jul 2014
Posts: 56
Rep: 
|
Unfortunately, I realize I wasn't very clear. I didn't mean to imply using machine code in general with modern CPUs, but code that had been created prior to these modern CPUs.
Because if you think about it... creating new machine code to work with modern CPUs and say, creating a driver for an old OS to use new hardware is the same thing... they both can be done. It takes time and resources, that's all.
What you're saying about them being "smarter" doesn't make any sense. I don't even understand WHAT it is you're arguing about anymore...
Are you seriously complaining that an old version of uname, that came out before the Celeron D, can't recognize a newer CPU? Can you tell me, right now, what the name of Intel's next chip released 5 years from now? And if you were locked in a room for 10 years without being told anything about Intel, would you know the answer to the chip released in 2020, when asked in 2025? What, you can't? Why can't you be smarter!
|
|
|
08-03-2014, 01:04 AM
|
#21
|
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453
|
Quote:
Originally Posted by stf92
I tried to install the NVIDIA driver under slackware 7.1 and the installer refused to go on
|
Why not try to install a turbocharger on your Ford Model T?
|
|
|
08-03-2014, 04:12 AM
|
#22
|
Senior Member
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 4,442
Original Poster
Rep:
|
The NVIDIA installer refused to run because the CPU was too new. There was nothing wrong with the CPU. The program could run and in fact ran perfectly well. Later on it objected the kernel version and halted. What do you call this? I call it incompatibility. And that's the whole point.
|
|
|
08-03-2014, 05:02 AM
|
#23
|
LQ Addict
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,418
Rep: 
|
Please indicate the exact NVIDIA driver version and provide output of following command on your old system:
Code:
lspci -knn|grep -A3 VGA
Also, telling in the first post what you wanted to achieve (getting the proprietary NVIDIA to run on that system) could have saved time for people who answered.
Last edited by Didier Spaier; 08-03-2014 at 06:20 AM.
|
|
|
08-03-2014, 06:02 AM
|
#24
|
Member
Registered: Jul 2014
Posts: 56
Rep: 
|
Quote:
Originally Posted by stf92
The NVIDIA installer refused to run because the CPU was too new. There was nothing wrong with the CPU. The program could run and in fact ran perfectly well. Later on it objected the kernel version and halted. What do you call this? I call it incompatibility. And that's the whole point.
|
If it halted on the kernel... version to old... why are you blaming the CPU? You're still going back to bitching about driver support, or rather, lack of in an older OS, company decision based on resources, and nothing to do with the OS itself being "not smart," as I've repeatedly said.
If the issue is that the video card is too new... the cpu is too new... the OS is too old... why not upgrade the OS altogether?
I don't get it... do you realize that you're spinning in circles? nVidia's decision not to support an OS (version), yet, you're blaming the OS.
It's like a guy driving his car into the wall, and blaming the wall for being there.
p.s. and my flaw is the need to get people to open their eyes... gah, gotta stop doing that and let them be, however messed up it might be.
Last edited by Goobers; 08-03-2014 at 06:04 AM.
|
|
|
08-03-2014, 06:18 AM
|
#25
|
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453
|
Quote:
Originally Posted by Goobers
It's like a guy driving his car into the wall, and blaming the wall for being there.
p.s. and my flaw is the need to get people to open their eyes... gah, gotta stop doing that and let them be, however messed up it might be.
|
Keep It Slammin' Stupid. 
|
|
|
08-03-2014, 06:59 AM
|
#26
|
Member
Registered: Nov 2008
Location: US
Distribution: slackware
Posts: 909
|
Quote:
Originally Posted by stf92
It needed kernel >= 2.4 to compile the kernel module. But the NVIDIA card I have can use things as old as VGA. Where was the compatibility broken?
|
7.1 had XFree 3.x which had separate "servers" per video hardware.
So I would say if you want Nvidia to work with XFree 3 you will need to write the X module yourself. If I remember correctly at the time I had a S3 card and a nvidia card, nvidia did not work until Slackware 8.0 which was when Slackware moved to XFree4.
Note, I strongly doubt kernel 2.2.x has the hooks for the nvidia proprietary driver.
Edit: if you mean by "works" you can see the login screen, that is because your board is running in straight vga mode
John
Last edited by jmccue; 08-03-2014 at 07:03 AM.
Reason: added why it seems the board 'works'
|
|
|
08-03-2014, 09:51 AM
|
#27
|
LQ Addict
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,418
Rep: 
|
Next time you want to install something on a computer system, please read the minimum software requirements first.
As an example, this is what says the README for the legacy NVIDIA driver 71.86.01, last updated 2007/06/15
Code:
__________________________________________________________________________
(app-b) APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS
__________________________________________________________________________
o linux kernel 2.4.0 # cat /proc/version
o XFree86 4.0.1 # XFree86 -version, or
Xorg 6.7 # Xorg -version
o Kernel modutils 2.1.121 # insmod -V
If you need to build the NVIDIA kernel module:
o binutils 2.9.5 # size --version
o GNU make 3.77 # make --version
o gcc 2.91.66 # gcc --version
o glibc 2.0 # /lib/libc.so.6
So no, there's no way to make that work on Slackware 7.1. Period.
Last edited by Didier Spaier; 08-03-2014 at 10:01 AM.
|
|
|
08-03-2014, 12:52 PM
|
#28
|
Senior Member
Registered: Apr 2007
Location: Buenos Aires.
Distribution: Slackware
Posts: 4,442
Original Poster
Rep:
|
I'm well aware of that README file. To make the driver work, Slackware 9.1 is enough. But this thread was not about a video card installation. It was about the uname command. I'm running the installer in a CPU that is newer than the GPU, and the installer gets confused. I don't care if he relied on the OS to know the CPU type, he should have got it right.
|
|
|
08-03-2014, 01:34 PM
|
#29
|
LQ Addict
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,418
Rep: 
|
Quote:
Originally Posted by stf92
I'm running the installer in a CPU that is newer than the GPU, and the installer gets confused. I don't care if he relied on the OS to know the CPU type, he should have got it right.
|
Just tell us how it could have done that, in other words from where it could have got the "i686" information.
You certainly know that any program that needs an information as input, can get it either
- from the user,
- from a file where it is recorded,
- or from an output of another program.
So please tell us from where the NVIDIA installer can get the "machine is an i686" information in case of a Slackware 7.1 system.
Last edited by Didier Spaier; 08-03-2014 at 01:38 PM.
|
|
|
08-03-2014, 01:39 PM
|
#30
|
Senior Member
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367
|
1. You are complaining about an OS that has been deprecated for many years. Nothing will be done to fix it.
2. You are complaining because the installer for an application that is known not to work on that OS, failed to work on that OS.
3. You have posted 11 times in this thread about your dissatisfaction knowing that it will never be fixed (again, it is completely deprecated and has been for many years).
4. You haven't indicated an actual problem here -- is there an application that will actually work on that out-dated OS that is tripping up on uname output, or is it simply a matter of principal?
This forum seems to be increasingly used for ranting but in general I think it's supposed to help solve problems...I don't know what problem you are having. Why are you using a 14-year-old operating system when the machine appears to be able to handle something at least slightly newer? The earliest I would go in order to support old hardware is Slackware 11.0 (which has also reached EOL).
[edit] The last time Slackware 7.1 had a package update was in 2002! It has been completely unsupported for 12 years! Why are we having this discussion!? [/edit]
Last edited by T3slider; 08-03-2014 at 01:47 PM.
|
|
|
All times are GMT -5. The time now is 07:09 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|