Why should they? Linux has made it near-impossible for *any* proprietary drivers to exist whatsoever. I agree with the grandparent, the Linux community should get down on their knees and thank NVidia and ATI that they have any drivers at all.
You must work for NVidia, or ATI or Microsoft.
That doesn't benefit Linux.
I have a better idea: Why doesn't the Linux community meet the hardware makers halfway and stabilize the ABI, at least for each major versions, so that poor NVidia and ATI don't have to constantly twiddle with their installers/glue code just to work at all?
I have a better idea: Why doesn't NVidia or ATI release documentation? Then poor Linux users wouldn't have to make the decision between their anal cherry and three-dee graphics.
I know what you chose...
Think about it economically: Because Linux's interfaces change so often and Windows/OS X ones do not, you've created a situation where it's ATI/NVidia supporting drivers for Linux (3% of the market) is more difficult than the other 97% of the market combined. Again, the Linux community is damned lucky that ATI/NVidia's accountants haven't put a stop to the whole thing.
You aren't even a software developer, are you?
The ATI/NVidia people are glad to have schmucks like you. Willing to take it from them, and willing to tell other people to do the same.
Take your prison. I want no part of it, and the community doesn't either.
You are wrong. I'll only speak in regards to Nvidia, though I believe ATI is the same. There are two parts to the Nvidia driver. One is the actual binary driver and one si the kernel interface. Nvidia provides source for the interface and that is wht gets compiled. Nvidia also ditributes precompiled interfaces for serveral distro's kernels. If there is a GPL violation, then Nvidia has been violating copyright for a long time.
You do not know what you are talking about.
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.
GPL only applies to redistribution.
The interface you can treat as LGPL.
You're confused. GPL and LGPL are redistribution licenses. They are not usage licenses.
Linus explicitly said that some of the interfaces are stable and do not constitute aggregation. Of those interfaces, all of the syscall-exported interfaces and a few kernel-internal interfaces.
So the question is basically can someone link a closed source binary to a LGPL binary then link the LGPL binary to a GPL binary?
You can link anything you want. Usage cannot be restricted by licenses unless you sign them.
Linking anything to GPL-covered works is GPL (except with certain exceptions). Even if it's LGPL'd- if linked, anyone you distribute the linked binary to must have the right to redistribute it under the GPL (although the LGPL is more permissive). If you cannot guarantee that right, then you cannot distribute it to them.
Hence the reason NVidia doesn't distribute linked code, just "patches".
It's also the reason KORORAA cannot link and apply these "patches" and then redistribute the patched program. That's copyright violation.
This is a rare case where I doubt the FSF would even attempt to pursue as it could very easily lead to a court decision against the GPL.
You are not a lawyer. Or a judge for that matter.
KORORAA doesn't have the right to redistribute Linux. They can assume that right if they meet the FSF's requirements (as outlined the GNU GPL v2). If they do not or cannot meet those requirements, then they do not have any right to redistribute Linux.
No. The note is all about gcc-specific code. The problem is that:
long long f(long long a, long long b) { return a / b; }
is automatically linked with GPL code. In fact, just making a main() function on quite a few platforms links in GPL code.
The note means that your code (that may look very much like that) isn't automatically under the GPL. That code that you're being linked to is still redistributable under the GPL, but THAT PARTICULAR CODE isn't making your program redistributable.
It isn't just to clear up confusion (duh, it's there, so it must be there to explain something), but because this is a particular time that you ARE linking with GPL code.
If your argument were correct, then it would be a violation of GPL for any distribution to make these drivers available. Yes, the major distributions do make them available for download, and no one, not even the FSF, says they are violation the GPL.
No. You're confused.
If the kernel can load the module, it's because the kernels' source code, and the GNU toolchain were available to build it.
Hence the reason NVidia and ATI don't distribute kernel modules, but instead a build-system that may-or-may-not be legal. Linus seems to think those kinds of build-systems are okay- not good, but probably okay.
KORORAA isn't using those build systems. They're distributing the binary kernel modules; The things the kernel can actually load. That's a violation of the GPL.
Just out of curiosity, who are the non-suckers? The people who bought video hardware from... who, exactly?
I use Matrox boards. The Xorg driver works fine with them, and I'm very happy. I bought about 10 of these dual-head G400 boards for 7$USD a piece and I've been using them a lot lately.
Personally I'd say go with NVidia, because they seem markedly less evil and their binary drivers seem to suck less, but that doesn't mean I'm happy about it.
Then don't. Tell them you don't want their permission to give them money and use their hardware. I say if you buy a piece of hardware , you have the right: one-way or another- to make it work and do whatever you want to make it work and do.
Without source code, NVidia and ATI are saying: no, you don't have that right. You need us around so that you can have the privilege of using these cards.
That seems really slimy to me- and I've been burned by it before. I've purchased hardware- and then the company goes out of business and I can't use it anymore. I've purchased software- and it eats my data, and there's nothing I can do about it anymore.
The GPL guarantees that this doesn't happen to me anymore. That's important to me. Meanwhile, some of my hardware magically works again- because of other people who decided they wanted it to work. They figured it all out, and now I've got a driver.
There really aren't any other options for most people.
Sure there are. They can go and firebomb ATI and NVidia- They can say loudly that ATI doesn't own their computer! That they don't want the NVidia teat anymore. If they want to sell their hardware, they have to sell the hardware- not a privilege, and not a permission to use that hardware.
No, that's blatently wrong. OpenWRT includes the closed source BroadComm network driver
If OpenWRT is distributing a Linux kernel with closed-source software linked into it, then yes, they are violating the GPL.
and RedHat Enterprise includes lots of Redhat only software that isn't GPL.
As far as I know, RHEL doesn't allow their trademark to be redistributed. That's a very different thing.
Now, if you created your own custom kernel in order to make the binary drivers work, but then didn't include the source code for that, I would agree with you. But they didn't modify the kernel at all. They just compiled kernel modules.
But the kernel modules are based on the Linux kernel. They use hidden magical interfaces. They don't necessarily make the modules GPL (says Linus), but that doesn't mean the resulting linked modules can be redistributed.
If the drivers themselves were "Derived works" then that would prohibit distribution. However, that would also prevent people from using them at all and require ATI and nVidia open sourced the drivers. This is not the case, though. The drivers contain a GPL kernel interface and a binary only driver. The kernel interface that the ATI and nVidia drivers use is the derived work, and is opensource. You can get it in the respective packages from ATI and nVidia's websites.
You're confused. The GPL isn't a usage-license, it's a redistribution license. You're free to download ATI or NVidia's copyrighted work (as they say- that's their distribution) and compile and link them into your kernel. You cannot redistribute your binary modules, or your built kernel with them, because you cannot satisfy the requirement of the GPL that says you need to be able to provide source code for those things.
Does Red Hat not want your business because there are things in RHEL that you can not distribute?
Red Hat doesn't want people redistributing their trade-mark. Their code is all GPL. There are several zero-cost RHEL distributions- they're just not called RHEL.
Maybe if it was easier to install video drivers in linux in the first place
Good. Take that attitude to NVidia and ATI. Tell them to stop making it so fucking hard to use their video hardware on your favorite operating system, and they can keep you as a customer.
Seriously does anyone except open-souce zealots (who are preventing a wider adoption of linux), really care that these drivers are not open-source.
We have to care because you don't. Without us, you wouldn't have anything. Quit whining that you don't have everything yet, and quit trying to convince people "the Right Thing" to do is to throw away everything.
Companies like ATI and Nvidia basically survive on their trade-secrets and it would not be reasonable to ask either of these companies to put their IP in jeapordy just so we could have a fully open-source video drivers.
That's a load of shit. Quit listening to their lies, and start thinking for yourself!
NVidia and ATI claim to have "trade secrets" that protect eachother from eachother right? Except their hardware capabilities are almost equal and their prices are both competitive.
That's like saying the only thing keeping Pepsi from beating out Coca Cola is that they just don't have that Coca Cola secret formula- despite the fact that lots of people actually claim to like Pepsi.
We should be grateful they provide closed-source drivers to us AT ALL.
That's absolutely right! You should be grateful that you spent a hundred dollars on a piece of equipment that you should ask THEIR PERMISSION every time you want to draw a line on it.
You're not grateful enough! You're trying to make them support three different platforms! Quick, everyone run Windows so that they only have to support one!
Or here's a better idea: Stop using their hardware. Let them know that they're losing money- I'm not buying their hardware or playing games while its too expensive to do so. You should do the same, so that we can all have three-dee environments that, as you put it, blow you.
Aggregation of components is not the same think as linking, the FSF is totally clear about that. So both the GPL code and the binary code can be present together on the same medium, not linked.
That's a load of crap. What do you think the ld command does if not link?
The distributed NVidia and ATI chunks have to be compiled and linked in order to make kernel modules.
The drivers aren't GPL though and they don't include GPL code.
Even though I doubt that they don't include GPL code, they are certainly based on GPL code.
Linux is under the GPL, and not the LGPL.
This is like saying my source files are GPLed because GCC can parse them.
Except GCC has an explicit note in its license that says that C source files that GCC (and perhaps only GCC- say using GCCisms) can compile are not automatically under the GPL.
This doesn't negate other reasons why these C files might be redistributable under the GPL, however.
Or this webpage is MPLed because Mozilla can read it, etc...
No, this is for a different reason: The pages mozilla displays are copyright their original authors. If these pages were explicitly designed for Mozilla (say, by using -moz- interfaces), then the GPL-license for Mozilla could apply. It's only because thos e interfaces are documented separately (under the MPL) that the GPL doesn't apply to them.
Just because the kernel can load your module doesn't mean your modules is GPLed.
Yes, that's exactly what it means.
The way I understand the GPL is anything you derive from GPL code must be open source and what not.
No. Anything derived from GPL code must be redistributable under the GPL as well.
This is probably why you're a bit confused: GPL is a redistribution license, and NOT a usage license. That means that if you have something GPL- binary only perhaps, then you cannot redistribute it unless you can also supply the source code.
Since you're building the drivers into the Linux kernel yourself, YOU are the one that is making a beast that you cannot redistribute. If someone else did this for you, they could not legally give you their binary images without also providing the source code. Since they don't have the source code, they cannot redistribute their binary images to you.
The drivers are proprietary and just happen to be compatible with GPL code.
When speaking in matters of law, "compatible" has a very specific definition that is at odds with the definition you are using. If the drivers were compatible with GPL code it would be because all of the terms of the GPL could be satisfied.
Note that GCC's explicit clause, and the existance of the W3C as methods of providing a compatability layer between the authors copyright of the C or HTML files, and the device used to manipulate them.
I always thought it was ok as long as they provided everything necessary to build the CD on your own, IE all of the GPL code that was used and which non-GPL packages (the nVidia and ATI drivers) were used.
Nope. You have to provide every piece of source code necessary to build it. The maintainers of KORORAA don't have the source code to NVidia and ATI drivers. Hence the violation.
If anything I would have expected this to be a violation of nVidia and ATI's copyright, distributing their drivers rather than sending people to their respective websites to download.
Except they (well, at least NVidia) explicitly allow redistribution. They do this because nobody is legally allowed to (because of the GPL), and therefore they get to look like the "good guys" instead of just a bunch of mean-spirited SCOX/Microsoft toolies that want to hurt Linux users.
By making the driver closed-source, they've made it such no Linux-based systems can ship with support for NVidia or ATI displays. Of course, free drivers are starting to get pretty good for ATI and NVidia, and I'm sure "the good guys" will eventually swoop in to protect all those suckers that bought NVidia or ATI video hardware, but until then, don't confuse the issue by suggesting even for a minute that the GPL is hurting anybody here...
The people who got suckered into buying video cards from people who don't want their business? Or the people who want to make sure their rights are protected from evildoers who usurp "Open Source" code on a regular basis?
It seems to me that NVidia and ATI don't want KOROAA to work with their graphics cards, and the maintainer just didn't know that. Oh well...
It's clear you don't know what you are talking about. That statement is just plain wrong.
No. What's clear is you don't know what I'm talking about. That's not the same thing at all.
% man mmap . . . MAP_PRIVATE Create a private copy-on-write mapping. Stores to the region do not affect the original file. It is unspecified whether changes made to the file after the mmap call are visible in the mapped region.
So what? You've found yet another Linux manual page that's wrong.
Consider for a moment- if you were right- mmap(MAP_PRIVATE) immediately followed by writing to those pages would cause a page-fault.
mmap(MAP_PRIVATE) does exactly what SUS and POSIX 1003 say it does- it marks the pages as private. fork() actually makes those pages copy on write- and thus, a write to the page after fork() is what actually produces the page-fault.
It's entirely possible to (correctly and completely!) implement mmap(MAP_PRIVATE) on a machine without virtual memory- that is, a machine without an mmu- provided you don't also have to implement fork().
In any event, it's moot: Nobody on this thread is talking about using CoW to protect pages between two processes except people who didn't read the article and/or didn't understand it.
First of all, vista won't have this activated by default. Here's how you can turn it on in Vista Beta:
And exactly where in that (albeit very technical) article does it say that BitLocker hands your data over to Microsoft?
Where is the materials that describe how to "decrypt" a Bitlocker "protected" drive when the motherboard explodes? or Windows eats itself- either by user fault or by design?
just like the linux system.
You're completely wrong.
Linux's offerings encrypt the drive to a key (or using key material) the user knows- instead of material that only Microsoft and the TPM manufacturer knows.
The difference means that with Linux you're protecting your data, but with BitLocker, Microsoft is protecting your data- which by itself probably wouldn't be so bad, except that it means that Microsoft is protecting your data from you!
They're introducing file system functionality for added security and being ripped apart for it by the same people that scream at them for their lack of security focus? I've had a bit of a read into it, and at least on the surface it seems like a good idea.
You're missing something fundemental: The data is being secured from the user instead of from the bad guys.
That's not security- that's trusting Microsoft to keep your data safe.
If Microsoft were really as interested in security as they claim to be (and as you seem to believe), then they would publish the materials necessary to decrypt these volumes on other systems- especially for rescue circumstances.
Will it be possible to mount non-encrypted disks in Vista?
You're missing the point.
Even if the user is given a choice in the matter, are they going to understand that they're signing away their data to Microsoft?
That nice boy down the street that helped them recover their data with a reinstall so easily- are these fictional users going to understand that checkbox means their next screwup means their data is gone for good?
Linux disk encryption makes it just as hard for linux to dualboot windows.
No it doesn't. The bootsector and partition tables are most certainly NOT encrypted because then the system wouldn't boot.
In fact every linux distro should just use FAT to make sure windows can be dualbooted and read the linux data.
I've got a better idea. Instead of trying to convince all those distributions that you're right and their wrong, why don't you just try and convince ONE distribution- say Microsoft- that they should support ext3 and cryptoloop out of the box.
Drive encryption is optional.... Don't automatically trust the guy telling you stuff because it's embarassing to the person he's telling you about.
He says it's there and may do things people don't expect, you say those Dells coming off the assembly line are going to make it an option.
One slight detail: Vista isn't out yet.
To me, it looks like you're both guessing, but even if you're right, are users going to understand that they're signing away their data to Microsoft with the push of a checkbox?
There certainly is. That what a copy-on-write page usually is. MAP_PRIVATE means shared until written.
No it isn't. MAP_PRIVATE is a flag to mmap(). It says nothing about copy on write, it says not to share this page with any other processes that map the same file/region.
Most unixes will implement CoW on fork()- and that usually includes pages allocated using MAP_PRIVATE- but it's not MAP_PRIVATE that has anything to do with this- the pages allocated with malloc() were also copy-on-write.
No. You've got that wrong. The difference between MAP_PRIVATE and MAP_SHARED is not whether the pages are shared or not, but whether changes to the page are shared.
I said access. The operating system is free to use whatever definition it likes for access - except when we're talking about writes. Since we ARE talking about writes, I apologize for assuming you understood that I could only possibly mean write.
Is this your first experience with virtual memory?
Was your first experience with virtual memory with mmap()?
mmap() can be implemented (entirely to POSIX.1b) without virtual memory and without shared pages. If you want a hint, read the manual page for msync().
I was discussing the generalities of VM rather than Linus's tirade.
Correction: You were discussing a common implementation of mmap() and not mmap and not virtual memory. Tirade is subjective. Read the article. Learn how virtual memory works, and how mmap() has nothing to do with virtual memory. Then pay attention to the fact that we're talking about zero-copy buffers and not fork() and not reading zeros.
You are right that it shouldn't be an example of zero copy because there is no opportunity to read zeros from the page.
zero-copy has nothing to do with reading zeros. It has to do with the operating system mapping the same buffer that write() used to the network interface itself. If this is the case, then the network hardware reads the buffer directly from userspace. Substitute network hardware for disk or any other peripheral and you've got the kind of zero-copy that Linus is talking about.
The trick is we want write() to be able to return immediately. The FreeBSD people CoW that page that write() used so that if the caller uses it again too soon, the page faults and gets copied.
The caller could've used malloc() or the stack to get that buffer- it doesn't matter.
Linux gives explicit notification- that is, userspace gets told when write() completes (later), and it can reuse that buffer.
Once this is in-place, there is no need to CoW the pages because userspace isn't going to accidentally use it before the pages are available for reuse.
If it's an RS-232 port, who the hell cares whether the buffer page is copy-on-write.
This must be the model the FreeBSD people were using when implementing CoW on I/O buffers. The problem is when those buffers move VERY VERY QUICKLY, and the page fault just isn't worth it.
From the sound of it, unless Linus is defining a flag to the mmap call, he's making a copy of every multiply mapped PROT_WRITE, MAP_PRIVATE page whether it gets written to or not
There isn't any such thing as a multiply mapped PROT_WRITE MAP_PRIVATE. Where are these terms coming from? If multiple processes have access to the same page allocated using mmap(), it was allocated using MAP_SHARED.
which means large PROT_WRITE, MAP_PRIVATE mappings use more memory but page fault less.
MAP_PRIVATE has nothing to do with faults.
In BSD, you get more page faults but use less memory.
No, you get page faults on every read, and use the same amount of memory that doing read() and write() would do. That's why it's stupid.
Each has advantages depending upon the application. Neither requires calling the user of the other an imbecile.
No. There is no advantage to BSD zero_copy because it's slower than read() and write() in the real world. It may be possible for userspace to make it faster than read() and write(), but this is extremely complicated, and nobody does it.
the COW scheme has benefits.
No it doesn't. Go read the article. We're not talking about reading and writing data sets. We're talking about kernel buffer sharing.
The proper thing would be to split MAP_PRIVATE into two options MAP_PRIVATE_COW and MAP_PRIVATE_COM (COM=copy on map) with MAP_PRIVATE being defined to one or the other.
MAP_PRIVATE isn't COW. It's not even related. MAP_PRIVATE is a flag for mmap() which has nothing at all to do with COW.
Your example code isn't an example of zero_copy because the pages aren't touched. If you touch the pages in buffer, a page fault occurs. If you had a [fictional] zero_write() on buffer, then the kernel wouldn't have to page fault, but then, you've just invented a more complicated sendfile() - something that has nothing to do with the article.
That's more-or-less what FreeBSD does. The problem is that the user program ALWAYS attempts to reuse the buffer and so ALWAYS generates a page fault.
So you can avoid this by never reusing buffers (until you absolutely have to), but the question becomes when CAN you reuse the buffers?
What's really necessary is for the user program to be told when kernel space is done with the pages- and if you have this, you don't need to touch the page tables, or implement copy-on-write or anything.
You describe a special case of sendfile()- which does what you describe without the mmap() call.
There isn't any need to mark the buffer specially if it doesn't come from a file- it's just important that it not get reused by anything but another zero-copy write operation.
Wouldn't there be a constant (an unknowable one) representing the percentage of the instances in which memory is reused? If a piece of memory used in a copyOnWrite scheme is never written to by another process, none of the page table updates occur, right? If K is the (often unknowable) constant indicating this percentage of the time when the copyOnWrite exception is generated,
What are you babbling about? The COW always occurs. The "other process" is the kernel and the page fault occurs when the original process attempts to re-fill it's memory buffer. If the write is part of a very tight loop, then the page fault occurs at the top of every loop. Since the page fault happens at the top of every loop, that means that you have the copy, and the page fault, in addition to the pagetable updates. It simply would've been faster to copy it once.
Linux `solves this' by using explicit notification. That means that userspace can reuse or free the buffer after the kernel is done using it, and as a result, copy-on-write simply isn't necessary.
Please read the article, and if you still don't understand, read my other posts in this thread on the subject.
You'll forgive me for taking that with a grain of salt so long as memory over-commit remains the default mode of operation within Linux.
That works under the assumption that VM overcommit is bad.
The PostgreSQL people seem to think so- lots of people seem to think so.
But believe it or not, lots of people think it's a good thing, and structure their system so that they can take advantage of the good things that VM overcommit buys them- it prevents obvious deadlocks (when paired with the OOMK), and improves system stability (when using resource limits and inittab).
Unforunately, lots of developers seem to think that the system administrator will always be selecting resource limits- even if they don't use them when developing (and as a result, cannot recommend reasonable ones). Lots of developers also shun inittab, and like to pretend that their program can run as long as init can- and any reason why it doesn't isn't their problem or fault.
Lots of administrators even go to great lengths- using things like monit- to simulate the behavior that inittab and the oomk already provides.
So don't make a baseless argument without justification- You might say that overcommit isn't good for default Debian, Fedora, and other LSB-ish systems that come off the pipeline, or you might have some other reason, but to suggest that it's mind-blowingly stupid means only one of two things:
a) _YOU_ and YOU alone are right, or b) everyone is right but you.
And you'll forgive us if we hope that you don't think it's this way, that you really honestly do have something to contribute besides everyone but you is right- no justification- no clarification- and etc.
Because if you really do think this way, then we have to point out that you're completely and totally wrong, and the world and state of things is not quite so simple.
Do understand that the difference between Linux and FreeBSD zero-copy interfaces is that Linux gives explicit notification when a page is no longer reserved for zero-copy, and FreeBSD doesn't. FreeBSD guards against this with CoW, or with a blocking system call. Linux avoids the whole CoW thing because the EXACT SAME HOOPS need to be jumped through on each interface, except the Linux interface isn't guesswork.
Now, with that said, who exactly would think making a program guess is a good idea? That's exactly what Linus thinks FreeBSD is doing- it's not like the FreeBSD people like CoW- they even suggest ways to avoid it in the zero_copy manual page. They just aren't quite clever enough to think of adding explicit notification.
Now once we have explicit notification, doing CoW just wastes time- it doesn't buy anything at all anymore. So why bother doing it? Once explicit notification is there, what good does CoW do?
It guards against naive implementations. Those aren't right anyway, and it's better to make the user fail earlier on in development than randomly later.
Unless you put the malloc on the outside of the loop, or call free() at the end of the loop, you've got a serious memory leak there.
Please re-read this thread. You are not following it, and what you're bringing up is redundant.
This fragment is designed to be called from a big select() or poll() loop. It wasn't designed to appear in isolation.
So yes, of course you have to free() the memory- the question is _when_. If you free it too soon, FreeBSD does a page fault and an extra copy thus taking longer than just using read() and write(). If you free() it too late, you waste memory.
Linux allows userspace to receive notification of when free() needs to take place.
Slashdot Mirror
Why should they? Linux has made it near-impossible for *any* proprietary drivers to exist whatsoever. I agree with the grandparent, the Linux community should get down on their knees and thank NVidia and ATI that they have any drivers at all.
You must work for NVidia, or ATI or Microsoft.
That doesn't benefit Linux.
I have a better idea: Why doesn't the Linux community meet the hardware makers halfway and stabilize the ABI, at least for each major versions, so that poor NVidia and ATI don't have to constantly twiddle with their installers/glue code just to work at all?
I have a better idea: Why doesn't NVidia or ATI release documentation? Then poor Linux users wouldn't have to make the decision between their anal cherry and three-dee graphics.
I know what you chose...
Think about it economically: Because Linux's interfaces change so often and Windows/OS X ones do not, you've created a situation where it's ATI/NVidia supporting drivers for Linux (3% of the market) is more difficult than the other 97% of the market combined. Again, the Linux community is damned lucky that ATI/NVidia's accountants haven't put a stop to the whole thing.
You aren't even a software developer, are you?
The ATI/NVidia people are glad to have schmucks like you. Willing to take it from them, and willing to tell other people to do the same.
Take your prison. I want no part of it, and the community doesn't either.
You are wrong. I'll only speak in regards to Nvidia, though I believe ATI is the same. There are two parts to the Nvidia driver. One is the actual binary driver and one si the kernel interface. Nvidia provides source for the interface and that is wht gets compiled. Nvidia also ditributes precompiled interfaces for serveral distro's kernels. If there is a GPL violation, then Nvidia has been violating copyright for a long time.
You do not know what you are talking about.
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.
GPL only applies to redistribution.
The interface you can treat as LGPL.
You're confused. GPL and LGPL are redistribution licenses. They are not usage licenses.
Linus explicitly said that some of the interfaces are stable and do not constitute aggregation. Of those interfaces, all of the syscall-exported interfaces and a few kernel-internal interfaces.
So the question is basically can someone link a closed source binary to a LGPL binary then link the LGPL binary to a GPL binary?
You can link anything you want. Usage cannot be restricted by licenses unless you sign them.
Linking anything to GPL-covered works is GPL (except with certain exceptions). Even if it's LGPL'd- if linked, anyone you distribute the linked binary to must have the right to redistribute it under the GPL (although the LGPL is more permissive). If you cannot guarantee that right, then you cannot distribute it to them.
Hence the reason NVidia doesn't distribute linked code, just "patches".
It's also the reason KORORAA cannot link and apply these "patches" and then redistribute the patched program. That's copyright violation.
This is a rare case where I doubt the FSF would even attempt to pursue as it could very easily lead to a court decision against the GPL.
You are not a lawyer. Or a judge for that matter.
KORORAA doesn't have the right to redistribute Linux. They can assume that right if they meet the FSF's requirements (as outlined the GNU GPL v2). If they do not or cannot meet those requirements, then they do not have any right to redistribute Linux.
Ignoring the question of GCC-specific code
No. The note is all about gcc-specific code. The problem is that:
long long f(long long a, long long b) { return a / b; }
is automatically linked with GPL code. In fact, just making a main() function on quite a few platforms links in GPL code.
The note means that your code (that may look very much like that) isn't automatically under the GPL. That code that you're being linked to is still redistributable under the GPL, but THAT PARTICULAR CODE isn't making your program redistributable.
It isn't just to clear up confusion (duh, it's there, so it must be there to explain something), but because this is a particular time that you ARE linking with GPL code.
If your argument were correct, then it would be a violation of GPL for any distribution to make these drivers available. Yes, the major distributions do make them available for download, and no one, not even the FSF, says they are violation the GPL.
No. You're confused.
If the kernel can load the module, it's because the kernels' source code, and the GNU toolchain were available to build it.
Hence the reason NVidia and ATI don't distribute kernel modules, but instead a build-system that may-or-may-not be legal. Linus seems to think those kinds of build-systems are okay- not good, but probably okay.
KORORAA isn't using those build systems. They're distributing the binary kernel modules; The things the kernel can actually load. That's a violation of the GPL.
Just out of curiosity, who are the non-suckers? The people who bought video hardware from ... who, exactly?
I use Matrox boards. The Xorg driver works fine with them, and I'm very happy. I bought about 10 of these dual-head G400 boards for 7$USD a piece and I've been using them a lot lately.
Personally I'd say go with NVidia, because they seem markedly less evil and their binary drivers seem to suck less, but that doesn't mean I'm happy about it.
Then don't. Tell them you don't want their permission to give them money and use their hardware. I say if you buy a piece of hardware , you have the right: one-way or another- to make it work and do whatever you want to make it work and do.
Without source code, NVidia and ATI are saying: no, you don't have that right. You need us around so that you can have the privilege of using these cards.
That seems really slimy to me- and I've been burned by it before. I've purchased hardware- and then the company goes out of business and I can't use it anymore. I've purchased software- and it eats my data, and there's nothing I can do about it anymore.
The GPL guarantees that this doesn't happen to me anymore. That's important to me. Meanwhile, some of my hardware magically works again- because of other people who decided they wanted it to work. They figured it all out, and now I've got a driver.
There really aren't any other options for most people.
Sure there are. They can go and firebomb ATI and NVidia- They can say loudly that ATI doesn't own their computer! That they don't want the NVidia teat anymore. If they want to sell their hardware, they have to sell the hardware- not a privilege, and not a permission to use that hardware.
So you cant include it out of the box, but what about forcing the user to implcitly enable it? Still shipping it then, so I'd say still a violation..
It's all about redistribution, not about usage. If they don't redistribute the binary kernel modules, then it's not a violation.
No, that's blatently wrong. OpenWRT includes the closed source BroadComm network driver
If OpenWRT is distributing a Linux kernel with closed-source software linked into it, then yes, they are violating the GPL.
and RedHat Enterprise includes lots of Redhat only software that isn't GPL.
As far as I know, RHEL doesn't allow their trademark to be redistributed. That's a very different thing.
Now, if you created your own custom kernel in order to make the binary drivers work, but then didn't include the source code for that, I would agree with you. But they didn't modify the kernel at all. They just compiled kernel modules.
But the kernel modules are based on the Linux kernel. They use hidden magical interfaces. They don't necessarily make the modules GPL (says Linus), but that doesn't mean the resulting linked modules can be redistributed.
If the drivers themselves were "Derived works" then that would prohibit distribution. However, that would also prevent people from using them at all and require ATI and nVidia open sourced the drivers. This is not the case, though. The drivers contain a GPL kernel interface and a binary only driver. The kernel interface that the ATI and nVidia drivers use is the derived work, and is opensource. You can get it in the respective packages from ATI and nVidia's websites.
You're confused. The GPL isn't a usage-license, it's a redistribution license. You're free to download ATI or NVidia's copyrighted work (as they say- that's their distribution) and compile and link them into your kernel. You cannot redistribute your binary modules, or your built kernel with them, because you cannot satisfy the requirement of the GPL that says you need to be able to provide source code for those things.
Does Red Hat not want your business because there are things in RHEL that you can not distribute?
Red Hat doesn't want people redistributing their trade-mark. Their code is all GPL. There are several zero-cost RHEL distributions- they're just not called RHEL.
Maybe if it was easier to install video drivers in linux in the first place
Good. Take that attitude to NVidia and ATI. Tell them to stop making it so fucking hard to use their video hardware on your favorite operating system, and they can keep you as a customer.
Seriously does anyone except open-souce zealots (who are preventing a wider adoption of linux), really care that these drivers are not open-source.
We have to care because you don't. Without us, you wouldn't have anything. Quit whining that you don't have everything yet, and quit trying to convince people "the Right Thing" to do is to throw away everything.
Companies like ATI and Nvidia basically survive on their trade-secrets and it would not be reasonable to ask either of these companies to put their IP in jeapordy just so we could have a fully open-source video drivers.
That's a load of shit. Quit listening to their lies, and start thinking for yourself!
NVidia and ATI claim to have "trade secrets" that protect eachother from eachother right? Except their hardware capabilities are almost equal and their prices are both competitive.
That's like saying the only thing keeping Pepsi from beating out Coca Cola is that they just don't have that Coca Cola secret formula- despite the fact that lots of people actually claim to like Pepsi.
We should be grateful they provide closed-source drivers to us AT ALL.
That's absolutely right! You should be grateful that you spent a hundred dollars on a piece of equipment that you should ask THEIR PERMISSION every time you want to draw a line on it.
You're not grateful enough! You're trying to make them support three different platforms! Quick, everyone run Windows so that they only have to support one!
Or here's a better idea: Stop using their hardware. Let them know that they're losing money- I'm not buying their hardware or playing games while its too expensive to do so. You should do the same, so that we can all have three-dee environments that, as you put it, blow you.
Aggregation of components is not the same think as linking, the FSF is totally clear about that. So both the GPL code and the binary code can be present together on the same medium, not linked.
That's a load of crap. What do you think the ld command does if not link?
The distributed NVidia and ATI chunks have to be compiled and linked in order to make kernel modules.
The drivers aren't GPL though and they don't include GPL code.
Even though I doubt that they don't include GPL code, they are certainly based on GPL code.
Linux is under the GPL, and not the LGPL.
This is like saying my source files are GPLed because GCC can parse them.
Except GCC has an explicit note in its license that says that C source files that GCC (and perhaps only GCC- say using GCCisms) can compile are not automatically under the GPL.
This doesn't negate other reasons why these C files might be redistributable under the GPL, however.
Or this webpage is MPLed because Mozilla can read it, etc...
No, this is for a different reason: The pages mozilla displays are copyright their original authors. If these pages were explicitly designed for Mozilla (say, by using -moz- interfaces), then the GPL-license for Mozilla could apply. It's only because thos e interfaces are documented separately (under the MPL) that the GPL doesn't apply to them.
Just because the kernel can load your module doesn't mean your modules is GPLed.
Yes, that's exactly what it means.
The way I understand the GPL is anything you derive from GPL code must be open source and what not.
No. Anything derived from GPL code must be redistributable under the GPL as well.
This is probably why you're a bit confused: GPL is a redistribution license, and NOT a usage license. That means that if you have something GPL- binary only perhaps, then you cannot redistribute it unless you can also supply the source code.
Since you're building the drivers into the Linux kernel yourself, YOU are the one that is making a beast that you cannot redistribute. If someone else did this for you, they could not legally give you their binary images without also providing the source code. Since they don't have the source code, they cannot redistribute their binary images to you.
The drivers are proprietary and just happen to be compatible with GPL code.
When speaking in matters of law, "compatible" has a very specific definition that is at odds with the definition you are using. If the drivers were compatible with GPL code it would be because all of the terms of the GPL could be satisfied.
Note that GCC's explicit clause, and the existance of the W3C as methods of providing a compatability layer between the authors copyright of the C or HTML files, and the device used to manipulate them.
I always thought it was ok as long as they provided everything necessary to build the CD on your own, IE all of the GPL code that was used and which non-GPL packages (the nVidia and ATI drivers) were used.
Nope. You have to provide every piece of source code necessary to build it. The maintainers of KORORAA don't have the source code to NVidia and ATI drivers. Hence the violation.
If anything I would have expected this to be a violation of nVidia and ATI's copyright, distributing their drivers rather than sending people to their respective websites to download.
Except they (well, at least NVidia) explicitly allow redistribution. They do this because nobody is legally allowed to (because of the GPL), and therefore they get to look like the "good guys" instead of just a bunch of mean-spirited SCOX/Microsoft toolies that want to hurt Linux users.
By making the driver closed-source, they've made it such no Linux-based systems can ship with support for NVidia or ATI displays. Of course, free drivers are starting to get pretty good for ATI and NVidia, and I'm sure "the good guys" will eventually swoop in to protect all those suckers that bought NVidia or ATI video hardware, but until then, don't confuse the issue by suggesting even for a minute that the GPL is hurting anybody here...
GPL shooting the "good guys" this time
Which "good guys" are you referring to?
The people who got suckered into buying video cards from people who don't want their business? Or the people who want to make sure their rights are protected from evildoers who usurp "Open Source" code on a regular basis?
It seems to me that NVidia and ATI don't want KOROAA to work with their graphics cards, and the maintainer just didn't know that. Oh well...
It's clear you don't know what you are talking about. That statement is just plain wrong.
No. What's clear is you don't know what I'm talking about. That's not the same thing at all.
% man mmap
. . .
MAP_PRIVATE Create a private copy-on-write mapping. Stores to the region do not affect the original file. It is unspecified whether changes made to the file after the mmap call are visible in the mapped region.
So what? You've found yet another Linux manual page that's wrong.
Consider for a moment- if you were right- mmap(MAP_PRIVATE) immediately followed by writing to those pages would cause a page-fault.
mmap(MAP_PRIVATE) does exactly what SUS and POSIX 1003 say it does- it marks the pages as private. fork() actually makes those pages copy on write- and thus, a write to the page after fork() is what actually produces the page-fault.
It's entirely possible to (correctly and completely!) implement mmap(MAP_PRIVATE) on a machine without virtual memory- that is, a machine without an mmu- provided you don't also have to implement fork().
In any event, it's moot: Nobody on this thread is talking about using CoW to protect pages between two processes except people who didn't read the article and/or didn't understand it.
First of all, vista won't have this activated by default. Here's how you can turn it on in Vista Beta:
And exactly where in that (albeit very technical) article does it say that BitLocker hands your data over to Microsoft?
Where is the materials that describe how to "decrypt" a Bitlocker "protected" drive when the motherboard explodes? or Windows eats itself- either by user fault or by design?
just like the linux system.
You're completely wrong.
Linux's offerings encrypt the drive to a key (or using key material) the user knows- instead of material that only Microsoft and the TPM manufacturer knows.
The difference means that with Linux you're protecting your data, but with BitLocker, Microsoft is protecting your data- which by itself probably wouldn't be so bad, except that it means that Microsoft is protecting your data from you !
They're introducing file system functionality for added security and being ripped apart for it by the same people that scream at them for their lack of security focus? I've had a bit of a read into it, and at least on the surface it seems like a good idea.
You're missing something fundemental: The data is being secured from the user instead of from the bad guys.
That's not security- that's trusting Microsoft to keep your data safe.
If Microsoft were really as interested in security as they claim to be (and as you seem to believe), then they would publish the materials necessary to decrypt these volumes on other systems- especially for rescue circumstances.
Will it be possible to mount non-encrypted disks in Vista?
You're missing the point.
Even if the user is given a choice in the matter, are they going to understand that they're signing away their data to Microsoft?
That nice boy down the street that helped them recover their data with a reinstall so easily- are these fictional users going to understand that checkbox means their next screwup means their data is gone for good?
Linux disk encryption makes it just as hard for linux to dualboot windows.
No it doesn't. The bootsector and partition tables are most certainly NOT encrypted because then the system wouldn't boot.
In fact every linux distro should just use FAT to make sure windows can be dualbooted and read the linux data.
I've got a better idea. Instead of trying to convince all those distributions that you're right and their wrong, why don't you just try and convince ONE distribution- say Microsoft- that they should support ext3 and cryptoloop out of the box.
Drive encryption is optional. ... Don't automatically trust the guy telling you stuff because it's embarassing to the person he's telling you about.
He says it's there and may do things people don't expect, you say those Dells coming off the assembly line are going to make it an option.
One slight detail: Vista isn't out yet.
To me, it looks like you're both guessing, but even if you're right, are users going to understand that they're signing away their data to Microsoft with the push of a checkbox?
There certainly is. That what a copy-on-write page usually is. MAP_PRIVATE means shared until written.
No it isn't. MAP_PRIVATE is a flag to mmap(). It says nothing about copy on write, it says not to share this page with any other processes that map the same file/region.
Most unixes will implement CoW on fork()- and that usually includes pages allocated using MAP_PRIVATE- but it's not MAP_PRIVATE that has anything to do with this- the pages allocated with malloc() were also copy-on-write.
No. You've got that wrong. The difference between MAP_PRIVATE and MAP_SHARED is not whether the pages are shared or not, but whether changes to the page are shared.
I said access. The operating system is free to use whatever definition it likes for access - except when we're talking about writes. Since we ARE talking about writes, I apologize for assuming you understood that I could only possibly mean write.
Is this your first experience with virtual memory?
Was your first experience with virtual memory with mmap()?
mmap() can be implemented (entirely to POSIX.1b) without virtual memory and without shared pages. If you want a hint, read the manual page for msync().
I was discussing the generalities of VM rather than Linus's tirade.
Correction: You were discussing a common implementation of mmap() and not mmap and not virtual memory. Tirade is subjective. Read the article. Learn how virtual memory works, and how mmap() has nothing to do with virtual memory. Then pay attention to the fact that we're talking about zero-copy buffers and not fork() and not reading zeros.
You are right that it shouldn't be an example of zero copy because there is no opportunity to read zeros from the page.
zero-copy has nothing to do with reading zeros. It has to do with the operating system mapping the same buffer that write() used to the network interface itself. If this is the case, then the network hardware reads the buffer directly from userspace. Substitute network hardware for disk or any other peripheral and you've got the kind of zero-copy that Linus is talking about.
The trick is we want write() to be able to return immediately. The FreeBSD people CoW that page that write() used so that if the caller uses it again too soon, the page faults and gets copied.
The caller could've used malloc() or the stack to get that buffer- it doesn't matter.
Linux gives explicit notification- that is, userspace gets told when write() completes (later), and it can reuse that buffer.
Once this is in-place, there is no need to CoW the pages because userspace isn't going to accidentally use it before the pages are available for reuse.
If it's an RS-232 port, who the hell cares whether the buffer page is copy-on-write.
This must be the model the FreeBSD people were using when implementing CoW on I/O buffers. The problem is when those buffers move VERY VERY QUICKLY, and the page fault just isn't worth it.
From the sound of it, unless Linus is defining a flag to the mmap call, he's making a copy of every multiply mapped PROT_WRITE, MAP_PRIVATE page whether it gets written to or not
There isn't any such thing as a multiply mapped PROT_WRITE MAP_PRIVATE. Where are these terms coming from? If multiple processes have access to the same page allocated using mmap(), it was allocated using MAP_SHARED.
which means large PROT_WRITE, MAP_PRIVATE mappings use more memory but page fault less.
MAP_PRIVATE has nothing to do with faults.
In BSD, you get more page faults but use less memory.
No, you get page faults on every read, and use the same amount of memory that doing read() and write() would do. That's why it's stupid.
Each has advantages depending upon the application. Neither requires calling the user of the other an imbecile.
No. There is no advantage to BSD zero_copy because it's slower than read() and write() in the real world. It may be possible for userspace to make it faster than read() and write(), but this is extremely complicated, and nobody does it.
the COW scheme has benefits.
No it doesn't. Go read the article. We're not talking about reading and writing data sets. We're talking about kernel buffer sharing.
The proper thing would be to split MAP_PRIVATE into two options MAP_PRIVATE_COW and MAP_PRIVATE_COM (COM=copy on map) with MAP_PRIVATE being defined to one or the other.
MAP_PRIVATE isn't COW. It's not even related. MAP_PRIVATE is a flag for mmap() which has nothing at all to do with COW.
Your example code isn't an example of zero_copy because the pages aren't touched. If you touch the pages in buffer, a page fault occurs. If you had a [fictional] zero_write() on buffer, then the kernel wouldn't have to page fault, but then, you've just invented a more complicated sendfile() - something that has nothing to do with the article.
That's more-or-less what FreeBSD does. The problem is that the user program ALWAYS attempts to reuse the buffer and so ALWAYS generates a page fault.
So you can avoid this by never reusing buffers (until you absolutely have to), but the question becomes when CAN you reuse the buffers?
What's really necessary is for the user program to be told when kernel space is done with the pages- and if you have this, you don't need to touch the page tables, or implement copy-on-write or anything.
You describe a special case of sendfile()- which does what you describe without the mmap() call.
There isn't any need to mark the buffer specially if it doesn't come from a file- it's just important that it not get reused by anything but another zero-copy write operation.
Wouldn't there be a constant (an unknowable one) representing the percentage of the instances in which memory is reused? If a piece of memory used in a copyOnWrite scheme is never written to by another process, none of the page table updates occur, right? If K is the (often unknowable) constant indicating this percentage of the time when the copyOnWrite exception is generated,
What are you babbling about? The COW always occurs. The "other process" is the kernel and the page fault occurs when the original process attempts to re-fill it's memory buffer. If the write is part of a very tight loop, then the page fault occurs at the top of every loop. Since the page fault happens at the top of every loop, that means that you have the copy, and the page fault, in addition to the pagetable updates. It simply would've been faster to copy it once.
Linux `solves this' by using explicit notification. That means that userspace can reuse or free the buffer after the kernel is done using it, and as a result, copy-on-write simply isn't necessary.
Please read the article, and if you still don't understand, read my other posts in this thread on the subject.
You'll forgive me for taking that with a grain of salt so long as memory over-commit remains the default mode of operation within Linux.
That works under the assumption that VM overcommit is bad.
The PostgreSQL people seem to think so- lots of people seem to think so.
But believe it or not, lots of people think it's a good thing, and structure their system so that they can take advantage of the good things that VM overcommit buys them- it prevents obvious deadlocks (when paired with the OOMK), and improves system stability (when using resource limits and inittab).
Unforunately, lots of developers seem to think that the system administrator will always be selecting resource limits- even if they don't use them when developing (and as a result, cannot recommend reasonable ones). Lots of developers also shun inittab, and like to pretend that their program can run as long as init can- and any reason why it doesn't isn't their problem or fault.
Lots of administrators even go to great lengths- using things like monit- to simulate the behavior that inittab and the oomk already provides.
So don't make a baseless argument without justification- You might say that overcommit isn't good for default Debian, Fedora, and other LSB-ish systems that come off the pipeline, or you might have some other reason, but to suggest that it's mind-blowingly stupid means only one of two things:
a) _YOU_ and YOU alone are right, or
b) everyone is right but you.
And you'll forgive us if we hope that you don't think it's this way, that you really honestly do have something to contribute besides everyone but you is right- no justification- no clarification- and etc.
Because if you really do think this way, then we have to point out that you're completely and totally wrong, and the world and state of things is not quite so simple.
Do understand that the difference between Linux and FreeBSD zero-copy interfaces is that Linux gives explicit notification when a page is no longer reserved for zero-copy, and FreeBSD doesn't. FreeBSD guards against this with CoW, or with a blocking system call. Linux avoids the whole CoW thing because the EXACT SAME HOOPS need to be jumped through on each interface, except the Linux interface isn't guesswork.
Now, with that said, who exactly would think making a program guess is a good idea? That's exactly what Linus thinks FreeBSD is doing- it's not like the FreeBSD people like CoW- they even suggest ways to avoid it in the zero_copy manual page. They just aren't quite clever enough to think of adding explicit notification.
Now once we have explicit notification, doing CoW just wastes time- it doesn't buy anything at all anymore. So why bother doing it? Once explicit notification is there, what good does CoW do?
It guards against naive implementations. Those aren't right anyway, and it's better to make the user fail earlier on in development than randomly later.
Unless you put the malloc on the outside of the loop, or call free() at the end of the loop, you've got a serious memory leak there.
Please re-read this thread. You are not following it, and what you're bringing up is redundant.
This fragment is designed to be called from a big select() or poll() loop. It wasn't designed to appear in isolation.
So yes, of course you have to free() the memory- the question is _when_. If you free it too soon, FreeBSD does a page fault and an extra copy thus taking longer than just using read() and write(). If you free() it too late, you waste memory.
Linux allows userspace to receive notification of when free() needs to take place.