The chances of OS X being stripped down to the extent necessary is zero.
Consider the graphics subsystem. X, for all its faults, degrades gracefully. If you have lots of memory then you can enable compositing or even fully OpenGL accelerated graphics which OS X doesn't actually have and won't until they enable Quartz 2D Extreme. But if you don't have lots of memory - and these machines have nearly none (no swap remember!) - then you can fall back to the redraw-on-demand model very easily. In the OS X graphics model it would be very difficult to support such a mode.
Consider the desktop environment. It's designed in such a way that it wastes screen space. The dock is the only way to switch windows and it is primarily designed to look pretty, not conserve screen space or processing power. Maximizing a window doesn't maximize it, instead it makes it the "ideal size" - probably leaving plenty of space around the edges. On Linux desktop environments are pluggable. On MacOS X there is only one and it's deeply coupled with the rest of the operating system.
Consider the low level performance requirements. Objective-C on Mach-O is very slow and this is well documented. C on ELF is very fast (once fixup has been performed).
But technological problems can be solved, given enough time and effort. The real kiler is this - consider the political requirements. Apple could revoke the OLPCs free license to OS X at any time, effectively ending the project overnight. Not possible with Linux.
I have heard on the grapevine that the numerical core of Excel is ancient and still written in K&R C... a bit like the dynamic linker on Windows the engineers don't like to touch it as the only people who truly understood it have long since moved on. Also there may be spreadsheets relying on the inaccuracy (perhaps).
I don't think he's feigning it. If you read his past comments on the competition he is always remarkably respectful of the the competition and choices they have made. Maybe it's because Nintendo is a fish amongst whales but I'd rather believe he is just a remarkably honourable man. I should be more like that in future:)
Thanks, very interesting stuff. Don't worry I think plenty of people will see:)
Though to be blunt, it sounds more and more like fusion won't be an answer to anything anytime soon. I wonder how much progress there'd be in renewables if that much money was poured into them internationally.
Paying for any compressed music is something I'll never do willingly.
You're in an extreme minority. Given a well encoded MP3 (many aren't) most people can't tell the difference between that and a CD. I know I certainly can't. In practice, for day to day listening factors like speaker/headphone quality make far more difference.
$15 a month to rent music is absolutely lame in my book and I hope it's practice that quickly becomes obsolete and dies a painful death. It's kind of sad that peeps would willingly allow other companies to own their assets.
What an incredibly stupid position. I guess you have moral objections to renting a house too? What about a suit? Oh, wait, music is special and whilst renting other stuff is OK renting music is "absolutely lame".
Look. There are a ton of people, like Ben, like myself, like my brother (who is a Napster subscriber) for whom the subscription model works well. I can count on the fingers of one hand the number of albums or tracks I bought over a year ago and still listen to. Listening to old music just isn't the way I work. The way I work is I discover some new music, often via the radio, I buy the track or album and obsess over it for a few weeks. If the album is good I'll literally just have it on constant rotation whilst I work. And after a while I lose interest and forget about it.
If half my CD collection disappeared tomorrow I really wouldn't give a crap. In fact often when I move around I don't take it with me, so it "disappears" quite regularly. This position is alien or offensive to some people who take such things rather passionately but to people who don't the subscription/DRM model (and you can't have one without the other) actually makes a great deal of sense.
The issue of price rises has been raised but it seems to me the nature of the subscription model solves it implicitly - if you build up a huge collection via Urge and Microsoft jack up the prices, you can simply cancel your subscription and go to another subscription store. They all license the same libraries from the record companies anyway. If there are a few tracks you can only get via Urge then just buy them.
Hymn no longer works, assuming you used the latest version of iTunes with your account at some point.
The "drmdbg/drm2wmv" hack worked for about 3 weeks before Microsoft patched it and used their renewal mechanism to seal the break for new media. It's been useless since Feb 2005 as a result.
Trust me, cracking 11 is just a matter of time.
The supply of people with the combination of reverse engineering talent, time, motivation and luck isn't infinite. The "Janus" DRM has not been digitally cracked for about a year and a half, despite being very high profile. That doesn't mean it's uncrackable obviously, just that it appears the balance has tipped in Microsofts favour lately. Of course you can still just record the analogue signal to strip it, but that requires a fair bit of effort and the goal of DRM isn't really to eliminate piracy entirely, it's to make it so much hassle not many people bother. There's a big difference between clicking a "Decrypt" button and setting up a recorder and hooking them up via analogue out. Most won't bother to do the latter for their whole collection just so they can "share" it on Kazaa.
Erm, nothing ever stopped distributors from simply throwing away those binaries after they'd been built. The fact that twm, xeyes etc are still shipped is more to do with inertia and UNIX history than any real technical problems.
Server is the MSN Switchboard server that negotiates file transfers between clients (or whatever the equivalent is on AIM/etc).
Who is to set up CoreForce - operating system or anti-malware vendor.
Who decides which applications get the right to do that - by default none have that right. The only real use case I can see is accessibility related (and gui unit testing in software dev shops but they can sort it out themselves). Accessibility apps are often shipped with the OS, certainly true on Linux, in situations where that's not the case the user can be prompted to give that app "god access" or whatever.
Not saying this is a perfect answer but it's a lot closer than existing answers IMHO - and don't worry end users would not really notice it implemented properly.
CoreForce is the Windows baby brother of security frameworks like SELinux and AppArmor. It allows you to precisely specify what an application can and cannot do. So you can say "this program can launch that program but no other", for instance.
Generally programs are distinguished by their label (which can be their file path). It requires some setup, but nearly everybody in Europe at least uses MSN Messenger which is shipped with the operating system so this can be setup beforehand. Alternatively hashes can be used to recognise and sandbox common programs. Nothing stops the user defining a security profile for an application but that requires some level of skill and the effort required is likely to set alarm bells ringing if some equally non-technical friend suddenly starts walking you through the procedure;)
Preventing application scripting is mostly a matter of ensuring UI events were generated by hardware and not injected into the message stream via an API. On Windows I do not know if this is possible short of running on separate window stations (which interferes with the clipboard) - on X11 systems there is a flag set in the message saying where it came from. You can also check to see if an application using the accessibility APIs is labelled as being a known acessibility related app (eg screenreader) and selectively allow access.
Note that these techniques are quite advanced and not currently implemented on any shipping desktop OS.
It's not the fault of IM but it's not Windows' fault either. As pointed out by others, privilege separation does not solve malware. Period, end of story, it achieves nothing. Unsurprising given that it was designed to solve an entirely different problem, back in the days when malware didn't exist.
The key problem here is that a program is able to impersonate a user in such a way that other humans can't tell the difference. People are very reliant on trust cues to guide their decision making and computers routinely present incredibly misleading trust cues. Messages that say they are from a friend but actually are not are just evil, and should not be allowed. In practice this means fixing chat programs so that they can't be controlled by other programs and ensuring the local password is encrypted sufficiently well (or simply not stored at all) that a program can't establish a direct network connection.
Block transmission of executables at the server level
Use something like CoreForce to prevent IM clients executing other programs (and switch "open this file" type actions via a privilege mux or RPC to a higher privileged system service).
Use operating system level services to prevent any application scripting another, restricting that privilege to accessibility applications.
Ah hmm wait, so Veritas produced a technology and patented it, Microsoft licensed/bought the software and incorporated it into Windows. Fair play. Later on Symantec buy Veritas and now sue Microsoft for using the technology they actually bought?
That can't be right. Or rather, it sounds like it could be, but that's pretty unfair on Microsoft... Symantec didn't invent this technology and Microsoft used it first, so where's the damages?
A large-ish collection of possibly out of date or broken packages, maybe, as long as they don't offend Red Hat/Novells lawyers... or
A even larger collection of possibly out of date or broken packages, maybe, as long as they don't offend the sensibilities of somebody on debian-legal
I'm sorry but this choice doesn't really excite me either way, so arguing which is "superior" seems silly.
Being up to date and correct does matter - only yesterday I was frustrated by Debian as the ancient version of ImageMagick included in Debian Stable doesn't have the ability to vertically center text, a feature I wanted. Even on Ubuntu, the situation is worrisome: I'm really don't see any safe way to backport some of the security fixes in Firefox 1.5, which were fundamental changes to the DOM security model.
Freshness isn't the only problem, correctness is too. There are numerous reports of the Ubuntu Firefox being much slower (as in responsiveness) to the upstream binaries, so presumably in the process of packaging it they broke or changed something which noticably lowers performance.
There are excellent reasons why Apple didn't choose apt-get for its next generation operating system when designing MacOS X; those are only a few.
Janus DRM is renewable, that is, it can be upgraded "in place" with new forms of encryption and protection
The time taken to brute force any reasonable encryption system is so large that it would take Alien Technology (tm) to find the key within, say, the lifetime of the solar system.
Public domain expiration could be solved using a key escrow system so this is hardly a killer blow against DRM. Better, use a rolling key algorithm such that once protected even changes in the law can't be retro-actively applied to previously protected content so solving the "disney problem".
Final, unrelated point, if there's got to be a mobile DRM standard, I'd much prefer Janus over FairPlay, as Janus does have the minor advantage of being "open" in the sense of anybody can protect things with it and anybody can play things back protected with it (subject to obtaining a license from MS). FairPlay unfairly joins iTunes, the iPod and their music store together for no valid market reason, whereas Janus does at least give you a choice of music store and mobile device.
The SonyEricsson W800 has a "music only mode" for this exact reason. I've found it's mostly worthless however as flight attendents don't really understand what it is, and will ask you to switch it off regardless. Given a choice between explaining the details of your phone/mp3 player moments before takeoff (so looking like a jackass) or just switching it off, the latter is always easier.
It's mostly common sense - header files express facts and facts cannot be copyrighted. Even in the presence of stupid games like kernel developers who put functions inlined into headers, they are still "facts" in the legal sense as they are simply information on how to integrate with the rest of the system.
From an old post of Gav State (who runs TransGaming):
Copyright law does not protect idea, just the expression of them.
Several court decisions have been rendered which suggest that the
'purely functional' elements of a computer program are not copyrightable.
There are several cases that explicitly deal with the issue of copyright
and header files. The most relevant one for Wine development is
probably the 1992 decision in Sega v. Accolade, where Accolade reverse
engineered the headers for Sega's ROM libraries in order to develop
games compatible with Sega's hardware without paying Sega's royalties.
(
http://www.eff.org/pub/Legal/Cases/sega_v_accolade _977f2d1510_decision.html )
The court in that case said:
Computer programs pose unique problems for the application of the
"idea/expression distinction" that determines the extent of copyright
protection. To the extent that there are many possible ways of
accomplishing a given task or fulfilling a particular market demand,
the programmer's choice of program structure and design may be highly
creative and idiosyncratic. However, computer programs are, in essence,
utilitarian articles -- articles that accomplish tasks. As such, they
contain many logical, structural, and visual display elements that are
dictated by external factors such as compatibility requirements and
industry demands... In some circumstances, even the exact set of
commands used by the programmer is deemed functional rather than
creative for the purposes of copyright. When specific instructions,
even though previously copyrighted, are the only and essential means
of accomplishing a given task, their later use by another will not
amount to infringement.
The LGPL acknowledges this legal issue in section (5):
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
You cannot copyright an interface and this has already been established by the legal system (Microsoft tried to claim the Windows API was copyrighted some time ago to stop Wine, and failed).
If the kernel developers try and claim using the headers makes the resulting code GPL, the headers can be reimplemented under an alternative license and this is A-OK.
NVidia cannot produce a GPL violation because NVidia is not redistributing NVidia's software. They are the copyright older. If you give someone else NVidia's software then you are redistributing it.
This is merely playing with words and is not logically sound. If your reading of the license were canonical then pretty much every company that violates the GPL today would be in the clear, as they are distributing their own work and the kernel but not redistributing it. Instead, the shops that sell the companies products would be liable. This isn't the case, therefore, your statement must be wrong.
The GPL did not originally have the distribution clause. It was added due to scalability and privacy concerns, specifically, people wondered if the license meant they had to make any change they ever made available including experimental or private/site-specific patches. RMS was convinced by others that this was unworkable, and so added the distribution clause to allow people to make private modifications without having to flood the original authors (bearing in mind this was in the days before search engines or the web).
What I say is documented on the FSF website if you want to investigate further. Suffice it to say the contortions people are putting the wording through here are not supported by their strength - the distribution clause was added as a convenience and not as make-or-break condition.
Well, then they can't do it!
It's just yet another example of how proprietary software restricts innovation...
nVidia developers wrote large parts of the GLX_ext_texture_from_pixmap specification which the whole framework revolves around. They've been contributing to the debate on how to evolve X into the 21st century. Their engineering team have been consistently supporting new features as the X community add them. Not only are nVidia not restricting innovation, they are taking part in it! The fact that some people would rather have an all or nothing situation (and get nothing) does not mean everybody shares that philosophy.
When a user compiles the glue code and links it with the binary-only component to produce a kernel module, the result is a derived work of the GPL'd Linux kernel.
This point is legally questionable (I am an armchair lawyer). What you're effectively saying is that using an interface makes your code a derived work of the implementation. Using this logic, Microsoft could claim every Windows program ever made is a derived work of Windows itself and so claim they should be able to dictate how they are used. This is clearly laughable.
For this reason, people usually argue that the two are a "combined work", the definition of which is extremely vague in the GPL and entirely open to interpretation. For instance you could claim that a GPLd program to check your Google Mail account is a combined work of your code and Googles, which isn't allowed, because GMail is not available under the GPL. But this interpretation is nonsense and so nobody uses it.
Likewise, in the past RPC has been proposed as an alternative.... the idea being it's not allowed to link two bits of code together in the same address space but it's OK if they are separated by RPC. Another laughable idea that a judge is likely to really not care about.
My own reading of the GPL is this - the technical details are not really what's relevant here, the core question is "Does program A depend on program B to operate?" and if the answer is YES then it's clearly a combined work and if the answer is NO then it clearly isn't. In this case the nVidia driver definitely does not depend on the Linux kernel, it can work fine with many kernels in exactly the same way, so I would argue that they are not legally a combined work.
However I am not a kernel developer, so it's not my copyright to wield. What I do know is that this campaign smacks more of black/white extremism than realistic gestalt policy - they demand the source code for the driver but, presumably, not the source code to the chip itself. Why? Their principles would appear to require that they demand both!
The GPL is designed to prohibit this for a reason, and it's not because the FSF people enjoy making people's lives difficult, it's to keep Linux and the kernel from becoming dependent on proprietary binary lumps
Newsflash, this policy has failed and the kernel is already dependent upon "proprietary binary lumps" for much modern functionality. The alternative to the nVidia driver for modern 3D graphics are.... hmm. There isn't one. Looks like if you need these things (eg, you are a 3D artist) then you are out of luck, you can't use Linux.
Some people (*cough*kernel developers) are entirely satisfied with that state of affairs, however, what they tend to ignore is that their salaries are paid for by companies that are aggressively pushing desktop Linux, and a desktop OS that can't do accelerated graphics or wireless or virtualization or any of the other things proprietary drivers are used for is not very competitive, therefore, they'd probably be out of work if the issue was forced.
Given that OS X uses CUPS too, if your printer isn't supported by CUPS then a Mac user would suddenly have to care as well. So your point is moot. I'm also going by the latest versions of things - in the past I've had to care about CUPS, with the latest OpenSUSE (and I'm sure it's the same for other distros too) I did not have to care about CUPS - I just added a network printer using the GNOME printing GUI. Printing is about to get a lot more consistent too as it's being moved into GTK+.
Slashdot Mirror
Consider the graphics subsystem. X, for all its faults, degrades gracefully. If you have lots of memory then you can enable compositing or even fully OpenGL accelerated graphics which OS X doesn't actually have and won't until they enable Quartz 2D Extreme. But if you don't have lots of memory - and these machines have nearly none (no swap remember!) - then you can fall back to the redraw-on-demand model very easily. In the OS X graphics model it would be very difficult to support such a mode.
Consider the desktop environment. It's designed in such a way that it wastes screen space. The dock is the only way to switch windows and it is primarily designed to look pretty, not conserve screen space or processing power. Maximizing a window doesn't maximize it, instead it makes it the "ideal size" - probably leaving plenty of space around the edges. On Linux desktop environments are pluggable. On MacOS X there is only one and it's deeply coupled with the rest of the operating system.
Consider the low level performance requirements. Objective-C on Mach-O is very slow and this is well documented. C on ELF is very fast (once fixup has been performed).
But technological problems can be solved, given enough time and effort. The real kiler is this - consider the political requirements. Apple could revoke the OLPCs free license to OS X at any time, effectively ending the project overnight. Not possible with Linux.
What did it get wrong?
I have heard on the grapevine that the numerical core of Excel is ancient and still written in K&R C ... a bit like the dynamic linker on Windows the engineers don't like to touch it as the only people who truly understood it have long since moved on. Also there may be spreadsheets relying on the inaccuracy (perhaps).
I don't think he's feigning it. If you read his past comments on the competition he is always remarkably respectful of the the competition and choices they have made. Maybe it's because Nintendo is a fish amongst whales but I'd rather believe he is just a remarkably honourable man. I should be more like that in future :)
Though to be blunt, it sounds more and more like fusion won't be an answer to anything anytime soon. I wonder how much progress there'd be in renewables if that much money was poured into them internationally.
You're in an extreme minority. Given a well encoded MP3 (many aren't) most people can't tell the difference between that and a CD. I know I certainly can't. In practice, for day to day listening factors like speaker/headphone quality make far more difference.
What an incredibly stupid position. I guess you have moral objections to renting a house too? What about a suit? Oh, wait, music is special and whilst renting other stuff is OK renting music is "absolutely lame".
Look. There are a ton of people, like Ben, like myself, like my brother (who is a Napster subscriber) for whom the subscription model works well. I can count on the fingers of one hand the number of albums or tracks I bought over a year ago and still listen to. Listening to old music just isn't the way I work. The way I work is I discover some new music, often via the radio, I buy the track or album and obsess over it for a few weeks. If the album is good I'll literally just have it on constant rotation whilst I work. And after a while I lose interest and forget about it.
If half my CD collection disappeared tomorrow I really wouldn't give a crap. In fact often when I move around I don't take it with me, so it "disappears" quite regularly. This position is alien or offensive to some people who take such things rather passionately but to people who don't the subscription/DRM model (and you can't have one without the other) actually makes a great deal of sense.
The issue of price rises has been raised but it seems to me the nature of the subscription model solves it implicitly - if you build up a huge collection via Urge and Microsoft jack up the prices, you can simply cancel your subscription and go to another subscription store. They all license the same libraries from the record companies anyway. If there are a few tracks you can only get via Urge then just buy them.
The "drmdbg/drm2wmv" hack worked for about 3 weeks before Microsoft patched it and used their renewal mechanism to seal the break for new media. It's been useless since Feb 2005 as a result.
The supply of people with the combination of reverse engineering talent, time, motivation and luck isn't infinite. The "Janus" DRM has not been digitally cracked for about a year and a half, despite being very high profile. That doesn't mean it's uncrackable obviously, just that it appears the balance has tipped in Microsofts favour lately. Of course you can still just record the analogue signal to strip it, but that requires a fair bit of effort and the goal of DRM isn't really to eliminate piracy entirely, it's to make it so much hassle not many people bother. There's a big difference between clicking a "Decrypt" button and setting up a recorder and hooking them up via analogue out. Most won't bother to do the latter for their whole collection just so they can "share" it on Kazaa.
Erm, nothing ever stopped distributors from simply throwing away those binaries after they'd been built. The fact that twm, xeyes etc are still shipped is more to do with inertia and UNIX history than any real technical problems.
Who is to set up CoreForce - operating system or anti-malware vendor.
Who decides which applications get the right to do that - by default none have that right. The only real use case I can see is accessibility related (and gui unit testing in software dev shops but they can sort it out themselves). Accessibility apps are often shipped with the OS, certainly true on Linux, in situations where that's not the case the user can be prompted to give that app "god access" or whatever.
Not saying this is a perfect answer but it's a lot closer than existing answers IMHO - and don't worry end users would not really notice it implemented properly.
Generally programs are distinguished by their label (which can be their file path). It requires some setup, but nearly everybody in Europe at least uses MSN Messenger which is shipped with the operating system so this can be setup beforehand. Alternatively hashes can be used to recognise and sandbox common programs. Nothing stops the user defining a security profile for an application but that requires some level of skill and the effort required is likely to set alarm bells ringing if some equally non-technical friend suddenly starts walking you through the procedure ;)
Preventing application scripting is mostly a matter of ensuring UI events were generated by hardware and not injected into the message stream via an API. On Windows I do not know if this is possible short of running on separate window stations (which interferes with the clipboard) - on X11 systems there is a flag set in the message saying where it came from. You can also check to see if an application using the accessibility APIs is labelled as being a known acessibility related app (eg screenreader) and selectively allow access.
Note that these techniques are quite advanced and not currently implemented on any shipping desktop OS.
The key problem here is that a program is able to impersonate a user in such a way that other humans can't tell the difference. People are very reliant on trust cues to guide their decision making and computers routinely present incredibly misleading trust cues. Messages that say they are from a friend but actually are not are just evil, and should not be allowed. In practice this means fixing chat programs so that they can't be controlled by other programs and ensuring the local password is encrypted sufficiently well (or simply not stored at all) that a program can't establish a direct network connection.
That can't be right. Or rather, it sounds like it could be, but that's pretty unfair on Microsoft ... Symantec didn't invent this technology and Microsoft used it first, so where's the damages?
You're right. This is just plain old organized crime. And like all criminals, the "free ride" only goes on so long.
I'm sorry but this choice doesn't really excite me either way, so arguing which is "superior" seems silly.
Being up to date and correct does matter - only yesterday I was frustrated by Debian as the ancient version of ImageMagick included in Debian Stable doesn't have the ability to vertically center text, a feature I wanted. Even on Ubuntu, the situation is worrisome: I'm really don't see any safe way to backport some of the security fixes in Firefox 1.5, which were fundamental changes to the DOM security model.
Freshness isn't the only problem, correctness is too. There are numerous reports of the Ubuntu Firefox being much slower (as in responsiveness) to the upstream binaries, so presumably in the process of packaging it they broke or changed something which noticably lowers performance.
There are excellent reasons why Apple didn't choose apt-get for its next generation operating system when designing MacOS X; those are only a few.
Are they using this for their own webapps?
This situation may improve with time.
From an old post of Gav State (who runs TransGaming):
If the kernel developers try and claim using the headers makes the resulting code GPL, the headers can be reimplemented under an alternative license and this is A-OK.
This is merely playing with words and is not logically sound. If your reading of the license were canonical then pretty much every company that violates the GPL today would be in the clear, as they are distributing their own work and the kernel but not redistributing it. Instead, the shops that sell the companies products would be liable. This isn't the case, therefore, your statement must be wrong.
The GPL did not originally have the distribution clause. It was added due to scalability and privacy concerns, specifically, people wondered if the license meant they had to make any change they ever made available including experimental or private/site-specific patches. RMS was convinced by others that this was unworkable, and so added the distribution clause to allow people to make private modifications without having to flood the original authors (bearing in mind this was in the days before search engines or the web).
What I say is documented on the FSF website if you want to investigate further. Suffice it to say the contortions people are putting the wording through here are not supported by their strength - the distribution clause was added as a convenience and not as make-or-break condition.
nVidia developers wrote large parts of the GLX_ext_texture_from_pixmap specification which the whole framework revolves around. They've been contributing to the debate on how to evolve X into the 21st century. Their engineering team have been consistently supporting new features as the X community add them. Not only are nVidia not restricting innovation, they are taking part in it! The fact that some people would rather have an all or nothing situation (and get nothing) does not mean everybody shares that philosophy.
This point is legally questionable (I am an armchair lawyer). What you're effectively saying is that using an interface makes your code a derived work of the implementation. Using this logic, Microsoft could claim every Windows program ever made is a derived work of Windows itself and so claim they should be able to dictate how they are used. This is clearly laughable.
For this reason, people usually argue that the two are a "combined work", the definition of which is extremely vague in the GPL and entirely open to interpretation. For instance you could claim that a GPLd program to check your Google Mail account is a combined work of your code and Googles, which isn't allowed, because GMail is not available under the GPL. But this interpretation is nonsense and so nobody uses it.
Likewise, in the past RPC has been proposed as an alternative .... the idea being it's not allowed to link two bits of code together in the same address space but it's OK if they are separated by RPC. Another laughable idea that a judge is likely to really not care about.
My own reading of the GPL is this - the technical details are not really what's relevant here, the core question is "Does program A depend on program B to operate?" and if the answer is YES then it's clearly a combined work and if the answer is NO then it clearly isn't. In this case the nVidia driver definitely does not depend on the Linux kernel, it can work fine with many kernels in exactly the same way, so I would argue that they are not legally a combined work.
However I am not a kernel developer, so it's not my copyright to wield. What I do know is that this campaign smacks more of black/white extremism than realistic gestalt policy - they demand the source code for the driver but, presumably, not the source code to the chip itself. Why? Their principles would appear to require that they demand both!
Newsflash, this policy has failed and the kernel is already dependent upon "proprietary binary lumps" for much modern functionality. The alternative to the nVidia driver for modern 3D graphics are .... hmm. There isn't one. Looks like if you need these things (eg, you are a 3D artist) then you are out of luck, you can't use Linux.
Some people (*cough*kernel developers) are entirely satisfied with that state of affairs, however, what they tend to ignore is that their salaries are paid for by companies that are aggressively pushing desktop Linux, and a desktop OS that can't do accelerated graphics or wireless or virtualization or any of the other things proprietary drivers are used for is not very competitive, therefore, they'd probably be out of work if the issue was forced.
Given that OS X uses CUPS too, if your printer isn't supported by CUPS then a Mac user would suddenly have to care as well. So your point is moot. I'm also going by the latest versions of things - in the past I've had to care about CUPS, with the latest OpenSUSE (and I'm sure it's the same for other distros too) I did not have to care about CUPS - I just added a network printer using the GNOME printing GUI. Printing is about to get a lot more consistent too as it's being moved into GTK+.