I already run Mac OS X. Why would I want to switch to Linux?
There are not as many reasons as there would have been if you had been using Windows. If you want a complete opensource system Mac OS X is not for you. But if you are satisfied with less Mac OS X might be fine. AFAIK the Mac OS X kernel is in fact opensource, and the kernel is the most important part of the software. If we don't consider the availability of source, I think the most important difference is that if you use Linux you get X, if OTOH you use Mac OS X you don't get X. (Well you can run X on Mac OS X, but native Mac OS X applications doesn't work with X, so you never get the full advantages of X). Kind of ironic that they take more or less the Unix design, ditch X, and call the result Mac OS X.
Here's a cd with linux on it. You have to install it to use the computer.
Try that with Windows.
Seriously - if any of my friends or family came to me and said they wanted to try Linux, I would help them install it. And I could even do remote administration of the box if they need it. At the moment I administrate one box remotely for one of my friends, who does not know much about computers.
"where is my internet explorer" and I need my Norton Anti-Virus.
The answer is simple. You don't need it.
Linux is great, but it's not for the average user yet.
Neither is Windows.
What would he do if I took his start menu away?
A lot of the desktop environments you can use on Linux have one. My personal preference is KDE. The button looks slightly different, but it is in the same place as on Windows 95. Do you say the average user is so stupid he cannot abstract from a button looking a bit different? I don't think the average user is that stupid.
More than once when I have shown KDE or Gnome to people that were not used to Linux, the reaction I got was: "That looks just like Windows". I'm not sure if this is good or bad. Looking the same is bad because it was supposed to be better, and it is obviously just the same. Looking different is bad because windows by definition is userfriendly, and anything that is different is not userfriendly. The last part is of course just how I believe the average user thinks. But we have to deal with that. So I guess we are comming to the point where the average user cannot tell the difference. That makes it easier to switch, but OTOH makes some people think there is not much reason to switch. What they don't realize is all the important differences under the hood, which are not visible to the average user.
This is when I do things like find . -iname '.*'|awk '{print "chown root:root " $0}'|less and then check it by hand.
I can see at least two problems with that command line. First of all it doesn't find the intended names, which would be anything where the first component start with a dot, instead it finds anything where the last component starts with a dot. But even worse it would surely fail if some of the filenames contains special characters. Imagine if there were a file named "./. //.gotya" or something like that. Even worse if there were a file named "./.`rm -rf/.`". Such a file name could exist if you had ever extracted an archive from an untrusted source. In fact it is even dangerous to try to use tab completion on such a filename. (I'm so happy I didn't have the guts to actually test the full name). Guess I should report this as a security hole in bash.
It won't match files named..something, and I have actually seen programs that created files named like that. But if we combine some of the suggestions we would come up with something that should work:.[^.].??*
Ouch. Now I realize that the right expression for this is not easy to come up with. I think.!(|.) would work if you are using bash with extended globing enabled. But can anybody come up with something better with the same result.
Personally I can't remember any real bad accidents of my own. I have had a harddisk crash a few years ago, but I did have a backup. I have tried to help out people who have done something extremely stupid, but that is not always easy. OK, I have made a few mistakes back when I was using DOS. One of them was to type del *.* and expected it to not touch files without a . in the name. Another was once I wanted to temporarily disable a secondary partition. So I started fdisk and deleted the partition, later I created the partition again. Litle did I know that fdisk under DOS would not only change the partition table, but would also change parts of the partition. So I lost the FAT table, which means every file that was larger than 4KB got corrupted. But I had backups of everything but a single game. Neither of those mistakes would have been possible if I had been using Linux.
I also remember once so many years ago I accidentially took a floppy out of the drive while it was writing. What was kind of interesting is, that the file it was writing to did not get corrupted, but a lot of other files did. However I had backups of all of those.
which is why this website needs to have a distributed client
How much would that help? Presumably everybody submiting a password to have cracked have a different salt, so how much can they help each other? Of course if you want to find the reverse image of a hash value by brute force, it would help to have a lot of machines working on it, and if everybody had a list of all the hashes being searched for, they could help each other. But brute forcing MD5 this way is something that wouldn't be realistic now, maybe in a 100 years we will have enough computing power to do that. So some shortcuts must be made, which is why they allow only short passwords using a restricted set of chars. This "service" will only find the password from a small set with 42 bits of entropy, the salt alone have 48 bits of entropy. Probably you could make similar shortcuts even given a salt, but they would have to be aimed at one particular salt.
Who cares about the drivers, just give out the specs and the community can write their own drivers.
I agree with that. And I even think I did state that somewhere in the thread. I don't care who writes the drivers, as long as they are open source and the specs are available, so we can fix the bugs. So releasing the specs is more important than releasing the driver. But of course releasing the driver as well would be a help such that we don't have to implement it from scratch.
Correct me if I'm wrong.
Sounds like you know a bit more about that than me.
I myself don't care what license the drivers are, I'm not a coder
You should care. Because the license affects not only what you can do to the driver yourself, but also what other people can do to the driver, which in the end may benefit you.
What you describe is a solution only for the easy part, which Linux already has a better solution for. Finding the functions to call isn't really a problem, that is just a question about linking. Every module have a list of the names of symbols that needs to be resolved, and the kernel exports a list of available symbols. The problem is more fundamental changes. For example some parameter might be a struct, but between two kernel versions a new field might have been added to this struct. So if a module allocates an instance of this type, the wrong amount of memory is allocated. And when accessing fields, the wrong offsets are used. There are even more tricky differences. A function in the API might in some cases be implemented as a macro and in other cases as a real function. And the macro might very well expand to different pieces of code depending on your compile time options. For example on a UP kernel without kernel preeemption, a spinlock is an empty struct. And locking and unlocking are really no-ops. OTOH if you enable debuging, SMP, or preemption, then the spinlock is no longer empty. A module compiled for one case would not work in the other case. Finally there is the current macro, which need to know the stack size to find the task struct of the current thread. All of these differences does not cause any incompatibility at the source level, just compile the module against the right kernel headers, and it will work. If a change doesn't break compatibility at the source level, it will be performed regardless of binary modules. Maintaining binary compatibility for kernel modules means to stop development, and we don't want to stop development just because of NVidia and a few other vendors.
Hence an executable file with a specific MD5 value either is the original or garbage that won't run.
Don't count on it. When you create an executable it is easy to put 17 bytes somewhere, that is really not used for anything. After this has been done just start searching for a combination of those 17 bytes that produce the expected hash. It is very likely that more than one choice will exist. Of course this would take too much time.
It is easier to produce a collision. Create two executables, and instead of the 17 bytes from before just leave 9 unused bytes in each file. Then try all choices for each of the two files, and sort the results to find your collision. 2*256^9 is way smaller than 256^17. Of course even this is still infeasible. But it will be possible in a few (50) years. Using SHA1 is a bit better, but it will only take about 100000 times as much CPU time to find a SHA1 collision as an MD5 collision. Which means the computer to do it will be available about 25 years later than the one to find an MD5 collision (assuming More's law still holds).
Have you tried this yourself?
I have tried it once, and it does in fact work. (Not that I would have needed to try it, I knew it would work).
I am curious about filesystems being mounted and such when you do
this.
There is one detail you must remember. The root filesystem is normally mounted read only if you follow the example, so you would have to remount it read/write before trying to change the password. Or you could just add rw to the boot command. Of course you have to type/bin/sh or/bin/bash,/bin/bah wouldn't work. It is a good idea to remount the filesystem read only again after changing the password. Then you can reboot or type exec/sbin/init.
You can prevent all of this by protecting your bootloader with a password, such that you cannot change the boot command without providing a password. Of course booting from an alternate media is still an option. To prevent that you could change your BIOS configuration, and weld the case to prevent anybody from resetting your CMOS. (If you just need to protect confidential information on the HD, encryption would be a better solution).
I never really looked into exactly how crypt
works, so I can't say for sure if it use iterated hashing. But in the case of MD5 passwords, it does indeed use a 48 bit salt (8 chars base 64 encoded). So mentioning/etc/shadow doesn't really make any sense. I still find it a bit worrying that they can crack a password with about 42 bits of entropy. A good 8 character password will have about 48 bits of entropy, which means it would take only 64 times as long to crack as what they can do now (a litle more if the hashing is in fact iterated). But the salt does mean they couldn't be cracking more than one password at a time. (I'm glad my root password is 16 chars long).
Maybe if Linux didn't break compatibility every third kernel
Linux kernel modules will usually be compatible across a lot of versions. But the compatibility is on source level. If you compile for different architectures or with different compile time options - binary modules will not be compatible even with the same kernel version. Some people keep whining about this, but obviously they don't understand what this is all about. There are a lot of good reasons for binary modules to be incompatible.
I belive you need to invest in a pair of glasses. I said a million switches per second. That means you can afford 10000 switches per frame if you didn't have to use time for anything else. And since you should be able to do with less than 1000 switches per frame in any reasonable design, you would use less than 10% of your time for switching, which means that is not going to kill your performance.
nVidia's drivers contain large amounts of software that is better than any of their competition. They spent money developing this, and they want to milk the competitive edge it gives them.
I believe you could also get a competitive edge by just producing good hardware and save a lot of money for driver development by letting the free software community help you.
Someone reserve engineer it and we'll see how smart they think they are. A kiddy with free time out there?
Why kiddy? If I had had the time I would have reverse engineered gfx drivers a long time ago. And before anybody start ranting about the legality of this, I should point out that I don't live in the US.
Does the size (4K) have any relation to the AMD page bug?
4KB is the page size. But other than that there is no relation. The problems using older NVidia drivers with 4KB kernel stacks are completely unrelated to the bug mentioned by that article.
Or go out and revise the nv drivers. Nothing (I would assume) prevents you from doing so.
I don't know the driver, so I cannot say for sure. But AFAIK the problem is that you have to chose between a buggy closed source driver that only work with some kernel versions, and a open source driver written by people without access to hardware specifications, which means it is bound to be buggy and badly performing.
Nothing prevents you from getting a video card from another company.
If I knew a company with good support, I would support them. Good support means complete hardware specification available to all developers, and that the company tests their hardware with at least one GPL'ed driver.
Besides, what would 99.9% of linux people do even if it was open source?
They would use the driver provided with their distribution.
And for the 0.1% of people who do mess with it, unless they discovered some great tweak that would provide a significant feature or speed advantage over the NVidia drivers
Probably you wouldn't see much improvements in terms of rendering speed. But you would see bugfixes and maybe improvements in case the driver might sometimes cause a performance degrade of the rest of your system. There are different ways for the improvements to end up on end users machines, the most likely go through the users' preferred distribution.
I trust them more since the quality of their drivers partially determines their sales, and thus they have a bigger motivation to make them
better.
You wish. I think it took way too long time for them to release a version that worked with 4KB stacks. But an open source version might even improve the version of the driver supplied by NVidia. As patches become available it would be fairly easy for NVidia to include in the version they supply. But of course most end users wouldn't use it unless the one that came with their distribution didn't work.
How about a closed source kernel driver and an open source X
driver?
Not a good solution. We don't want code in the kernel for which we don't have source.
Or, an open source kernel driver, an open source X driver, and a common, closed-source library in the middle?
Common? The kernel doesn't use any such thing as libraries. The closest we come is modules. A closed source user mode library is what I already suggested. Not the best solution, but better than closed source code in the kernel.
having to stick to the existing driver interface due to 3rd party vendors having closed source drivers is a major handicap.
I understand your concern. But I'd rather use a proprietary X server than a proprietary kernel module. I consider an old X server with some closed source user mode code a better option than a closed source kernel module. This shouldn't stop development of X. Just means that if you want a newer X version you cannot use this partiuclar gfx board. Having different X servers for people with different gfx boards is not that bad.
It also mentions something about interupts that I don't
understand.
The problems with interrupts is, that you don't have much control over when they arrive, and when they do arrive, they need stack space. So with interrupts interrupting each other, you can quickly use a lot of stack space. If you were very unlucky, you could probably overflow even a 16KB stack that way.
So you would either have to disable interrupts or make sure there were always enough stack space to take an interrupt. Disabling interrupts is something we don't want to do for more than a few nanoseconds, so something have to be done.
With 4KB stacks this problem become even worse, but there is a solution. Assume we need to be able to handle for example five interrupts at the same time and each of them need 3KB of stack space. With the traditional approach, we would need to always leave 15KB of stack space in every thread. But we are never going to need all of that, because at any time there is only one thread executing on each CPU.
Interrupt stacks means that rather than using the stack of the current thread, we simply switch the stack pointer to a different stack only used for interrupts. We will still use a small amount of stack space in the current thread, but certainly less than 100 bytes, and only for the first interrupt. This means that the thread stack no longer needs to leave free space for some unpredictable amount of data.
The kernel design requires the kernel stack of every thread to have exactly the same size (and a power of two). The current macro on x86 is one piece of code relying on this. But within an interrupt current doesn't make any sense. So it should be possible to make the interrupt stacks larger than the thread stacks. That way we can have a few large interrupt stacks and a lot of small thread stacks. This use less memory than a lot of large thread stacks. The number of thread stacks just have to be one pr CPU or one pr handler depending on your design.
My system currently have 1 CPU, 12 interrupt handlers, and 101 threads. Which means that saving 4KB per thread and then creating a single 16KB interrupt stack would save a lot of memory.
Actually, this is the idea.
Huh? There certainly is a difference between what I described and how the driver is currently working. Maybe my suggestion would require changes of the binary code and/or the X server, but it certainly should be possible.
The interface with the kernel is open source
That statement doesn't make any sense. You can say the interface is open, and you can say the kernel is open source. But an interface is something more abstract than a piece of code. Of course when talking about interfaces to the kernel it is important to keep in mind, that there are two different interfaces. There is the user/kernel mode interface. This API complies (mostly) with various standards: Posix, BSD, Single Unix specification, SysV. But the standards only specify the API, not the ABI which is Linux specific. This ABI is kept as stable as possible even across kernel versions. But this interface is not really important when discussing kernel modules. The functions kernel modules can link against may change, and no attempt is made to keep the ABI stable, only the API is kept stable within each major version as long as the API doesn't turn out to be a major problem. This API is however the same across multiple CPU architectures (unlike the user/kernel ABI discussed before). But this really means that if you want to ship a Linux kernel module, you have to ship it as source. Because it is only at the source level there is a well known interface. A fixed ABI is just not possible, just the differences between CPU architectures is enough to make it impossible, but in addition some data types in the kernel are different depending on the options. And finally there are stuff like the 4K stacks where the current macro had to be changed.
the closed source code is a binary object that gets linked into the module.
And that is a problem. Not only does it only work on one architecture, but it makes assumptions about the kernel, which may not be satisfied. The amount of stack space is not the only problem here. The code can break the kernel in various ways, which means you can no longer trust your kernel.
context switching to a different privilege level would only hurt performance.
Some years ago I did some meassurements of this on a computer, that is now five years old. It could do one million switches from user mode to kernel mode and back again per second. I believe newer machines can do a bit more than that. I guess very few people have a monitor refresh rate of more than 100Hz. That means you will have time for about 10000 switches. Of course you can't use all your CPU time just to be switching, but let's say you can do a single frame with less than 1000 switches, then you certainly wouldn't have a performance problem. And if more than 1000 switches are required to do a single frame, then you have a broken design that needs to be fixed. It is not the amount of data needing to be transfered that is a problem, because you could either map board memory directly into the user mode process, or (a litle more complicated) do DMA directly to user space. So I won't believe your talking about performance problems, until I see a proof that it can't be avoided.
NVidia has been so far quite open source friendly when it comes to producing drivers.
NVidia have not really been that friendly. They may seem friendly when compared to other 3Dgfx manufacturers. This really just means there is a market, where no vendor give a damn about their customers. I hope some vendor will realize this, because if they do, and make the product the customers want, then I believe they can make some money.
But drivers is not one of them. Had they put the closed source code in a user mode library and used just a small open source kernel driver, we wouldn't have all the problems with the driver. It still wouldn't be optimal, but it would be way better than the current situation.
Slashdot Mirror
I already run Mac OS X. Why would I want to switch to Linux?
There are not as many reasons as there would have been if you had been using Windows. If you want a complete opensource system Mac OS X is not for you. But if you are satisfied with less Mac OS X might be fine. AFAIK the Mac OS X kernel is in fact opensource, and the kernel is the most important part of the software. If we don't consider the availability of source, I think the most important difference is that if you use Linux you get X, if OTOH you use Mac OS X you don't get X. (Well you can run X on Mac OS X, but native Mac OS X applications doesn't work with X, so you never get the full advantages of X). Kind of ironic that they take more or less the Unix design, ditch X, and call the result Mac OS X.
Here's a cd with linux on it. You have to install it to use the computer.
Try that with Windows.
Seriously - if any of my friends or family came to me and said they wanted to try Linux, I would help them install it. And I could even do remote administration of the box if they need it. At the moment I administrate one box remotely for one of my friends, who does not know much about computers.
"where is my internet explorer" and I need my Norton Anti-Virus.
The answer is simple. You don't need it.
Linux is great, but it's not for the average user yet.
Neither is Windows.
What would he do if I took his start menu away?
A lot of the desktop environments you can use on Linux have one. My personal preference is KDE. The button looks slightly different, but it is in the same place as on Windows 95. Do you say the average user is so stupid he cannot abstract from a button looking a bit different? I don't think the average user is that stupid.
More than once when I have shown KDE or Gnome to people that were not used to Linux, the reaction I got was: "That looks just like Windows". I'm not sure if this is good or bad. Looking the same is bad because it was supposed to be better, and it is obviously just the same. Looking different is bad because windows by definition is userfriendly, and anything that is different is not userfriendly. The last part is of course just how I believe the average user thinks. But we have to deal with that. So I guess we are comming to the point where the average user cannot tell the difference. That makes it easier to switch, but OTOH makes some people think there is not much reason to switch. What they don't realize is all the important differences under the hood, which are not visible to the average user.
This is when I do things like find . -iname '.*'|awk '{print "chown root:root " $0}'|less and then check it by hand.
/.gotya" or something like that. Even worse if there were a file named "./.`rm -rf /.`". Such a file name could exist if you had ever extracted an archive from an untrusted source. In fact it is even dangerous to try to use tab completion on such a filename. (I'm so happy I didn't have the guts to actually test the full name). Guess I should report this as a security hole in bash.
I can see at least two problems with that command line. First of all it doesn't find the intended names, which would be anything where the first component start with a dot, instead it finds anything where the last component starts with a dot. But even worse it would surely fail if some of the filenames contains special characters. Imagine if there were a file named "./. /
What's wrong with ".[^.]*"?
..something, and I have actually seen programs that created files named like that. But if we combine some of the suggestions we would come up with something that should work: .[^.] .??*
It won't match files named
chown -R root: dir/
That wouldn't work, as it would apply to everything, not just the hidden files.
chown -R root:root .*
.!(|.) would work if you are using bash with extended globing enabled. But can anybody come up with something better with the same result.
Ouch. Now I realize that the right expression for this is not easy to come up with. I think
Personally I can't remember any real bad accidents of my own. I have had a harddisk crash a few years ago, but I did have a backup. I have tried to help out people who have done something extremely stupid, but that is not always easy. OK, I have made a few mistakes back when I was using DOS. One of them was to type del *.* and expected it to not touch files without a . in the name. Another was once I wanted to temporarily disable a secondary partition. So I started fdisk and deleted the partition, later I created the partition again. Litle did I know that fdisk under DOS would not only change the partition table, but would also change parts of the partition. So I lost the FAT table, which means every file that was larger than 4KB got corrupted. But I had backups of everything but a single game. Neither of those mistakes would have been possible if I had been using Linux.
I also remember once so many years ago I accidentially took a floppy out of the drive while it was writing. What was kind of interesting is, that the file it was writing to did not get corrupted, but a lot of other files did. However I had backups of all of those.
which is why this website needs to have a distributed client
How much would that help? Presumably everybody submiting a password to have cracked have a different salt, so how much can they help each other? Of course if you want to find the reverse image of a hash value by brute force, it would help to have a lot of machines working on it, and if everybody had a list of all the hashes being searched for, they could help each other. But brute forcing MD5 this way is something that wouldn't be realistic now, maybe in a 100 years we will have enough computing power to do that. So some shortcuts must be made, which is why they allow only short passwords using a restricted set of chars. This "service" will only find the password from a small set with 42 bits of entropy, the salt alone have 48 bits of entropy. Probably you could make similar shortcuts even given a salt, but they would have to be aimed at one particular salt.
I could not verify some of their "cracks".
That is because you computed the MD5 hash of the wrong string. Eith times s does not produce the same MD5 hash as eight times s followed by a newline.
Who cares about the drivers, just give out the specs and the community can write their own drivers.
I agree with that. And I even think I did state that somewhere in the thread. I don't care who writes the drivers, as long as they are open source and the specs are available, so we can fix the bugs. So releasing the specs is more important than releasing the driver. But of course releasing the driver as well would be a help such that we don't have to implement it from scratch.
Correct me if I'm wrong.
Sounds like you know a bit more about that than me.
I myself don't care what license the drivers are, I'm not a coder
You should care. Because the license affects not only what you can do to the driver yourself, but also what other people can do to the driver, which in the end may benefit you.
What you describe is a solution only for the easy part, which Linux already has a better solution for. Finding the functions to call isn't really a problem, that is just a question about linking. Every module have a list of the names of symbols that needs to be resolved, and the kernel exports a list of available symbols. The problem is more fundamental changes. For example some parameter might be a struct, but between two kernel versions a new field might have been added to this struct. So if a module allocates an instance of this type, the wrong amount of memory is allocated. And when accessing fields, the wrong offsets are used. There are even more tricky differences. A function in the API might in some cases be implemented as a macro and in other cases as a real function. And the macro might very well expand to different pieces of code depending on your compile time options. For example on a UP kernel without kernel preeemption, a spinlock is an empty struct. And locking and unlocking are really no-ops. OTOH if you enable debuging, SMP, or preemption, then the spinlock is no longer empty. A module compiled for one case would not work in the other case. Finally there is the current macro, which need to know the stack size to find the task struct of the current thread. All of these differences does not cause any incompatibility at the source level, just compile the module against the right kernel headers, and it will work. If a change doesn't break compatibility at the source level, it will be performed regardless of binary modules. Maintaining binary compatibility for kernel modules means to stop development, and we don't want to stop development just because of NVidia and a few other vendors.
Hence an executable file with a specific MD5 value either is the original or garbage that won't run.
Don't count on it. When you create an executable it is easy to put 17 bytes somewhere, that is really not used for anything. After this has been done just start searching for a combination of those 17 bytes that produce the expected hash. It is very likely that more than one choice will exist. Of course this would take too much time.
It is easier to produce a collision. Create two executables, and instead of the 17 bytes from before just leave 9 unused bytes in each file. Then try all choices for each of the two files, and sort the results to find your collision. 2*256^9 is way smaller than 256^17. Of course even this is still infeasible. But it will be possible in a few (50) years. Using SHA1 is a bit better, but it will only take about 100000 times as much CPU time to find a SHA1 collision as an MD5 collision. Which means the computer to do it will be available about 25 years later than the one to find an MD5 collision (assuming More's law still holds).
Have you tried this yourself?
/bin/sh or /bin/bash, /bin/bah wouldn't work. It is a good idea to remount the filesystem read only again after changing the password. Then you can reboot or type exec /sbin/init.
I have tried it once, and it does in fact work. (Not that I would have needed to try it, I knew it would work).
I am curious about filesystems being mounted and such when you do this.
There is one detail you must remember. The root filesystem is normally mounted read only if you follow the example, so you would have to remount it read/write before trying to change the password. Or you could just add rw to the boot command. Of course you have to type
You can prevent all of this by protecting your bootloader with a password, such that you cannot change the boot command without providing a password. Of course booting from an alternate media is still an option. To prevent that you could change your BIOS configuration, and weld the case to prevent anybody from resetting your CMOS. (If you just need to protect confidential information on the HD, encryption would be a better solution).
This is why we use salted, iterated hashing.
/etc/shadow doesn't really make any sense. I still find it a bit worrying that they can crack a password with about 42 bits of entropy. A good 8 character password will have about 48 bits of entropy, which means it would take only 64 times as long to crack as what they can do now (a litle more if the hashing is in fact iterated). But the salt does mean they couldn't be cracking more than one password at a time. (I'm glad my root password is 16 chars long).
I never really looked into exactly how crypt works, so I can't say for sure if it use iterated hashing. But in the case of MD5 passwords, it does indeed use a 48 bit salt (8 chars base 64 encoded). So mentioning
It wouldn't be the first time somebody implemented an April fools RFC.
Maybe if Linux didn't break compatibility every third kernel
Linux kernel modules will usually be compatible across a lot of versions. But the compatibility is on source level. If you compile for different architectures or with different compile time options - binary modules will not be compatible even with the same kernel version. Some people keep whining about this, but obviously they don't understand what this is all about. There are a lot of good reasons for binary modules to be incompatible.
I believe you need to invest in a calculator.
I belive you need to invest in a pair of glasses. I said a million switches per second. That means you can afford 10000 switches per frame if you didn't have to use time for anything else. And since you should be able to do with less than 1000 switches per frame in any reasonable design, you would use less than 10% of your time for switching, which means that is not going to kill your performance.
nVidia's drivers contain large amounts of software that is better than any of their competition. They spent money developing this, and they want to milk the competitive edge it gives them.
I believe you could also get a competitive edge by just producing good hardware and save a lot of money for driver development by letting the free software community help you.
Someone reserve engineer it and we'll see how smart they think they are. A kiddy with free time out there?
Why kiddy? If I had had the time I would have reverse engineered gfx drivers a long time ago. And before anybody start ranting about the legality of this, I should point out that I don't live in the US.
Does the size (4K) have any relation to the AMD page bug?
4KB is the page size. But other than that there is no relation. The problems using older NVidia drivers with 4KB kernel stacks are completely unrelated to the bug mentioned by that article.
Or go out and revise the nv drivers. Nothing (I would assume) prevents you from doing so.
I don't know the driver, so I cannot say for sure. But AFAIK the problem is that you have to chose between a buggy closed source driver that only work with some kernel versions, and a open source driver written by people without access to hardware specifications, which means it is bound to be buggy and badly performing.
Nothing prevents you from getting a video card from another company.
If I knew a company with good support, I would support them. Good support means complete hardware specification available to all developers, and that the company tests their hardware with at least one GPL'ed driver.
Besides, what would 99.9% of linux people do even if it was open source?
They would use the driver provided with their distribution.
And for the 0.1% of people who do mess with it, unless they discovered some great tweak that would provide a significant feature or speed advantage over the NVidia drivers
Probably you wouldn't see much improvements in terms of rendering speed. But you would see bugfixes and maybe improvements in case the driver might sometimes cause a performance degrade of the rest of your system. There are different ways for the improvements to end up on end users machines, the most likely go through the users' preferred distribution.
I trust them more since the quality of their drivers partially determines their sales, and thus they have a bigger motivation to make them better.
You wish. I think it took way too long time for them to release a version that worked with 4KB stacks. But an open source version might even improve the version of the driver supplied by NVidia. As patches become available it would be fairly easy for NVidia to include in the version they supply. But of course most end users wouldn't use it unless the one that came with their distribution didn't work.
How about a closed source kernel driver and an open source X driver?
Not a good solution. We don't want code in the kernel for which we don't have source.
Or, an open source kernel driver, an open source X driver, and a common, closed-source library in the middle?
Common? The kernel doesn't use any such thing as libraries. The closest we come is modules. A closed source user mode library is what I already suggested. Not the best solution, but better than closed source code in the kernel.
having to stick to the existing driver interface due to 3rd party vendors having closed source drivers is a major handicap.
I understand your concern. But I'd rather use a proprietary X server than a proprietary kernel module. I consider an old X server with some closed source user mode code a better option than a closed source kernel module. This shouldn't stop development of X. Just means that if you want a newer X version you cannot use this partiuclar gfx board. Having different X servers for people with different gfx boards is not that bad.
It also mentions something about interupts that I don't understand.
The problems with interrupts is, that you don't have much control over when they arrive, and when they do arrive, they need stack space. So with interrupts interrupting each other, you can quickly use a lot of stack space. If you were very unlucky, you could probably overflow even a 16KB stack that way.
So you would either have to disable interrupts or make sure there were always enough stack space to take an interrupt. Disabling interrupts is something we don't want to do for more than a few nanoseconds, so something have to be done.
With 4KB stacks this problem become even worse, but there is a solution. Assume we need to be able to handle for example five interrupts at the same time and each of them need 3KB of stack space. With the traditional approach, we would need to always leave 15KB of stack space in every thread. But we are never going to need all of that, because at any time there is only one thread executing on each CPU.
Interrupt stacks means that rather than using the stack of the current thread, we simply switch the stack pointer to a different stack only used for interrupts. We will still use a small amount of stack space in the current thread, but certainly less than 100 bytes, and only for the first interrupt. This means that the thread stack no longer needs to leave free space for some unpredictable amount of data.
The kernel design requires the kernel stack of every thread to have exactly the same size (and a power of two). The current macro on x86 is one piece of code relying on this. But within an interrupt current doesn't make any sense. So it should be possible to make the interrupt stacks larger than the thread stacks. That way we can have a few large interrupt stacks and a lot of small thread stacks. This use less memory than a lot of large thread stacks. The number of thread stacks just have to be one pr CPU or one pr handler depending on your design.
My system currently have 1 CPU, 12 interrupt handlers, and 101 threads. Which means that saving 4KB per thread and then creating a single 16KB interrupt stack would save a lot of memory.
Actually, this is the idea.
Huh? There certainly is a difference between what I described and how the driver is currently working. Maybe my suggestion would require changes of the binary code and/or the X server, but it certainly should be possible.
The interface with the kernel is open source
That statement doesn't make any sense. You can say the interface is open, and you can say the kernel is open source. But an interface is something more abstract than a piece of code. Of course when talking about interfaces to the kernel it is important to keep in mind, that there are two different interfaces. There is the user/kernel mode interface. This API complies (mostly) with various standards: Posix, BSD, Single Unix specification, SysV. But the standards only specify the API, not the ABI which is Linux specific. This ABI is kept as stable as possible even across kernel versions. But this interface is not really important when discussing kernel modules. The functions kernel modules can link against may change, and no attempt is made to keep the ABI stable, only the API is kept stable within each major version as long as the API doesn't turn out to be a major problem. This API is however the same across multiple CPU architectures (unlike the user/kernel ABI discussed before). But this really means that if you want to ship a Linux kernel module, you have to ship it as source. Because it is only at the source level there is a well known interface. A fixed ABI is just not possible, just the differences between CPU architectures is enough to make it impossible, but in addition some data types in the kernel are different depending on the options. And finally there are stuff like the 4K stacks where the current macro had to be changed.
the closed source code is a binary object that gets linked into the module.
And that is a problem. Not only does it only work on one architecture, but it makes assumptions about the kernel, which may not be satisfied. The amount of stack space is not the only problem here. The code can break the kernel in various ways, which means you can no longer trust your kernel.
context switching to a different privilege level would only hurt performance.
Some years ago I did some meassurements of this on a computer, that is now five years old. It could do one million switches from user mode to kernel mode and back again per second. I believe newer machines can do a bit more than that. I guess very few people have a monitor refresh rate of more than 100Hz. That means you will have time for about 10000 switches. Of course you can't use all your CPU time just to be switching, but let's say you can do a single frame with less than 1000 switches, then you certainly wouldn't have a performance problem. And if more than 1000 switches are required to do a single frame, then you have a broken design that needs to be fixed. It is not the amount of data needing to be transfered that is a problem, because you could either map board memory directly into the user mode process, or (a litle more complicated) do DMA directly to user space. So I won't believe your talking about performance problems, until I see a proof that it can't be avoided.
NVidia has been so far quite open source friendly when it comes to producing drivers.
NVidia have not really been that friendly. They may seem friendly when compared to other 3Dgfx manufacturers. This really just means there is a market, where no vendor give a damn about their customers. I hope some vendor will realize this, because if they do, and make the product the customers want, then I believe they can make some money.
Closed source software has its places,
But drivers is not one of them. Had they put the closed source code in a user mode library and used just a small open source kernel driver, we wouldn't have all the problems with the driver. It still wouldn't be optimal, but it would be way better than the current situation.