I would never argue that vendors will not write drivers without a stable kernel API. (If you read my comment before, you will see that I was arguing for a stable API between the userspace apps and the driver, not between the driver and the kernel.
My argument is that a stable API would improve legacy support of binary drivers without any of the claimed downsides in the stable api document. That's it. Period.
Now, I understand that the counter argument is that open-sourcing the driver solves the same problem, and my counter-argument is that the community only has control over one of those two things.
I believe we have Office XP at work, but I can't check from here...
I don't know for sure that is ordering by date in it's search, but the results are displayed as they are found, and it's always the oldest matches displayed first.
Not only does outlook search by walking one at a time, it starts with the oldest e-mail first.
That pisses me off to know end, and I'd love to know how to fix it.
I keep every non-spam e-mail I receive because it makes my inbox a datastore that I can mine later on. It has helped me out of technical jams, reminded me of forgotten information, and saved my ass in a lawsuit. But every e-mail I receive at work (I'm forced to use outlook at work) makes it take that much longer to find the bit of data I need, which is more often than not in an e-mail from the last several weeks.
That should say "That's not what makes it a good idea."
One are built into Linus' kernel, and they work really well. The others, people seem to throw up their arms and say "well, those are Too Hard to get right, so we'll just ignore them and let the userspace folks try to write drivers for them"
You forgot the other two types... The ones that are in the kernel and work really poorly (some Fibre Channel, Infiniband, some SATA, some audio), and userspace drivers that work perfectly and have no business being in the kernel (most printers, modems, tape changers, some filesystems).
Why can't the kernel simply declare that OpenGL is The Graphics Interface for Linux, and provide only raw text and OpenGL as supported graphics APIs, and do software rendering for anybody who needs it?
Plenty of reasons, but the one you'd care about the most would be that you would be stuck forever with outdated video instead of having some slim hope like you have now. OpenGL is a morass of standards combined with vendor specific extensions. You'd be exactly as likely to get those extensions into the kernel tree as you are to get drivers into the kernel tree now, and you'd still need the drivers.
Also, I don't know how you can say: "do software rendering for anybody who needs it" and "then nobody would ever get stuck without working 3d acceleration again" in the same context. It's contradictory. Besides, after years of mocking windows for the problems caused by having graphics in the kernel, why would we want to follow their lead? Additionally, why should the current 3D acceleration paradigm be enforced by the kernel. What if somebody comes up with a new paradigm for rendering acceleration? Then the Linux kernel would be left out. The kernel part of the interface should be as generic as possible. It should handle I/O rapidly. End of story.
There isn't a single technical benefit to having the drivers in the kernel that can't be had with the drivers in user-space given the correct design. The reasons for this argument are political.
There is no educating people like you because you will never admit that humanity is ever capable of doing extraordinary things.
I have a theory that people like this exist mostly because we haven't done any large (physically) scale extrodinary things lately... At least, the western world hasn't. Where are our recent Appolos, Hoover Dams, or George Washington Bridges? All of our current achievments are either small (in size, not in value), out of site (space station? hubble? mars rovers?), or die in the beuracracy since there is no reward in our governements to think long term.
It's ironic that you say that in a conversation about graphics drivers... Especially in a conversation about graphics drivers from the only manyfacturer who's drivers are now open source, but aren't backwards compatable. Say what you will about ATI or nvidia drivers, but you load them up and they still run the old chips.
And old hardware support from open source drivers is great if the device was popular when it was still in production. Otherwise, you're lucky if you can get it to work at all. Sure, there is a reasonable chance that the driver will compile (though even that hasn't always been the case)...
Also, when I said vendor, I meant linux vendor, not device vendor. Over the long term, the majority of users are ones that run a supported distribution on hardware supported by their distribution vendor, either because they built their box to the distro's specs (most businesses), or because they bought the hardware with the OS bundled (most home users).
This conversation is only really interesting at all to people with obscure hardware, or people who roll their own kernel and system.
Yeah right. Meanwhile, real life shows us that what you describe is exceptions rather than a rule.
That's only true if you use popular hardware.
The driver being in the kernel means you can bug the Linux kernel devs to make it work with each new release of the kernel (hence stable). The driver not being in the kernel means they won't do anything about it, and you have no way of knowing if the driver will work or not. The basic premise is that the maintainer of a driver would support his driver in the Linux kernel tree.
In the real world, all the smart users have vendor support to take care of this issue for them. As linux popularity grows, the number of people using a non-vendor kernel shrinks. A tiny minority of linux boxes run Linus' tree.
The discipline is to make the kernel work better no matter what, and to not get stuck by in-kernel stable interface
Not only is that the lie, but it is provably wrong. Look how many operating systems there are out there that are successful and have excelent driver support even though they don't have the flexability of changing the driver API every release and the drivers aren't built with the kernel. I can count seven that are on the market right now. If this was really about making the kernel better no matter what, they would add a stable interface, because that would be an improvement. Drivers in the tree could continue to exploit new features and wouldn't be stuck using the old interface as the document implies. There is a history of this happening in the real world, and even in the linux kernel, as in the past, the Adaptec SCSI driver was shared code between Linux and BSD, with a compatability layer inserted.
I can appreciate the goal of being good over being stable and or popular, but there are some parts of 'good' that only come after you are stable and popular.
And this is still moot in relation to this discussion, as graphics drivers are written for X an not the kernel.
Now I wonder how you can have the guts to write that. So you basically admit that you do closed drivers that have equivalent Free Software ones, though they used to be worse in Free Software version. And then you complain about the unstable API document and want to be taken seriously ? But you know what, I'd rather praise the guys who made the FOSS drivers.
Yes. And I don't see why that's surprising to you, unless you buy into Stallman's 'all software should be free' trash. I didn't say I don't have any open code. I simply don't have the luxury of being generous when it comes to this stuff most of the time. I have to make a living, and if that means taking a contract that is uder NDA in exchange for a paycheck, so be it. Pull a 2.4 tree and look in the ppc branch at the galileo code. Check the mailing lists for alpha, ppc, and just plain linux-kernel. When my contracts allow, the code goes into the tree.
It hardly matters anyway, because the only part of the system that really needs to be open is the platform, and none of this changes my main argument, which is that it's not the status of the source license that is causing the driver issues with linux graphics.
Do you have any idea what DirectX actually is? Did you even read my initial comment?
OpenGL is, at best, a replacement for a subset of DirectX. Worse, the latest features of modern graphics hardware exist as non-standard vendor extensions to OpenGL. Even without the missing functionality that DirectX has (input, sound, 2D, etc...) you're still missing my point. I'm not claiming Microsoft has the lead because of a technically superior product. They have a business development team out there pushing their API. So what I'm saying is... First linux needs the API (SDL + OpenGL cames close, but lacks polish), and then they need people to sell the API to developers and manufacturers. Only then will widespread, quality 3D driver support come; whether the drivers are open sourced now, or not.
Also, that document is a complete lie. I don't care that it's in the kernel tree. There's lots of wrong stuff in there.
A driver does not have to be in the tree to be stable, running driver, and the driver being in the kernel tree doesn't mean that it is either stable or running.
And I should know, as I have written multiple closed-source Linux device drivers, two of which have open-source versions in the kernel that have at various times either not worked, or worked poorly, and both of which perform signifigantly worse than the closed version.
Go actually read that document. The argument it makes is that a stable kernel/driver API is a bad idea because the kernel/driver API is unstable. It's a circular argument. The real issue is three-fold. One, there isn't enough agreement amongst the diversity of kernel developers to ever come up with a stable API, two, there is no dicipline amongst the people in charge to maintain that stability even if a consensus was reached, and three, there are some who would like to keep the interface unstable merely to keep this argument for open source drivers valid.
Dispite all that, the only real roadblock between ease of binary driver development and what we have today is that there is heavy backporting amongst distribution vendors without incrementing the kernel version number. In other words, vendors lie about their versions in order to maintain the illusion of version stability for their customers... But even that is a minor issue, as it only makes the people who run on the bleeding edge suffer, and nobody runs on the bleeding edge in production.
I'm not talking about an API between the driver and the kernel. I'm talking about the API between the app and the driver. The kernel should be irrelevant. The application writer shouldn't care what the driver or the kernel are. As an example, take DirectX and Windows XP, Windows Mobile, and Xbox. The drivers are different, the kernels are different, the kernel/driver APIs are different, but what is the same, and what is important is that the third party app writer only has to learn one interface, and they (mostly) don't need to know anything about the hardware, the kernel, or the driver.
Read the entire thread. This isn't the only post like that. It's not the correct, or informative posts that are modded up. It's the cheerleader/fanboy posts.
It's a symptom of the fact that 99% of the people reading this article simultaniously know practically nothing about what they're talking about, and think they are experts.
First of all, that's really, seriously, just a rumor.
Secondly, there is already an open source driver with a 'functional subset' of features for both ATI and nVidia cards. If they were to do this, nothing would change. Do you really think anybody who is upset about the current state of Linux graphics drivers would be satisfied in any way by crippled open-source drivers?
They like to compete instead by actually having good performance.
Besides, graphics drivers are the least of Linux's desktop problems. In the home it's major roadblock is the Microsoft business development executives in charge of DirectX, and in the workplace it's Exchange/Outlook. Get those things covered, and desktop Linux succeeds. Get just the DirectX issue covered (including marketing and developer outreach) and the graphics drivers will follow.
Don't believe me? Notice how MacOS doesn't seem to have the same driver issues as Linux dispite similar market share... When there is a unified graphics API, the driver writers have a finite set of things to test, and quality follows. It's not like ATI and Nvidia aren't trying... And sure, Intel's graphics drivers aren't as buggy... They don't perform either though.
Ok, maybe you didn't misconstrue it. Maybe you're just a moron.
Here's the issue... You are directly implying that I said what they did was right, when what I really said was that nobody should be surprised. Quite honestly, that's rude and insulting.
as well as no practical way for a non-ISP to get my traffic unless they commit fraud to perpitrate a man-in-the-middle attack.
What does 'non-ISP' have to do with anything. Who is to say that your ISP isn't logging your searches? If they're a big ISP they almost certainly are in the log files for their transparent proxy. And that is to say nothing of the routers and firewalls that may be between you and the internet any time you sit down at a terminal you didn't configure yourself. I will say it one more time... You have no expectation of privacy when sending unencrypted data over the internet unless you personally have taken steps to guarantee it.
then it's ok for any company to violate their published privacy policy
They didn't violate their own policy. Yes I've read it.
Consent to use your personal information is opt-out according to their policy. I'm guessing this person (I still want to know why you keep saying 'she') didn't or the searches wouldn't have been in this list were it made public or not.
You have a weird sence of right and wrong.
I can't think of a better thing to say to you for intentionally misconstruing my argument and putting words in my mouth than: "Fuck you."
If there was no privacy issue, nobody would be mad at them for releasing the info.
That's funny.
It's cute that you actually believe that too.
The people are mad because the situation is not what they expected. There are many, many cases where things are not what people expect and said people get upset about it. Frequently in these cases, the issue is that people weren't paying attention. That is the case here. It's not a privacy issue, it's an attention issue.
Almost no data transmitted over BitTorrent is without copyright, as under the Berne Convention, works are copyrighted upon creation even when such rights are not claimed by the creator, or when the creator remains anonymous.
The only works which are not copyrighted are those in the public domain due to the expiration of their term, or those where the copyrights were explicitly waived. In other words, the vast minority of content transferred over BitTorrent.
Also keep in mind that this data is transmitted in plain text over the public network. I continue to maintain that you have to be delusional or uninformed if you consider that data to be private, regardless of whether AOL says they are keeping it private or not.
Slashdot Mirror
I should mention that changing the message sorting of the mailbox doesn't change the search behavior.
Do you mean the sort order of the results?
That seems pretty obvious. What I would like to know is how to change that.
You're debunking "not my argument".
I would never argue that vendors will not write drivers without a stable kernel API. (If you read my comment before, you will see that I was arguing for a stable API between the userspace apps and the driver, not between the driver and the kernel.
My argument is that a stable API would improve legacy support of binary drivers without any of the claimed downsides in the stable api document. That's it. Period.
Now, I understand that the counter argument is that open-sourcing the driver solves the same problem, and my counter-argument is that the community only has control over one of those two things.
I believe we have Office XP at work, but I can't check from here...
I don't know for sure that is ordering by date in it's search, but the results are displayed as they are found, and it's always the oldest matches displayed first.
Not only does outlook search by walking one at a time, it starts with the oldest e-mail first.
That pisses me off to know end, and I'd love to know how to fix it.
I keep every non-spam e-mail I receive because it makes my inbox a datastore that I can mine later on. It has helped me out of technical jams, reminded me of forgotten information, and saved my ass in a lawsuit. But every e-mail I receive at work (I'm forced to use outlook at work) makes it take that much longer to find the bit of data I need, which is more often than not in an e-mail from the last several weeks.
That doesn't make it a good idea.
That should say "That's not what makes it a good idea."
One are built into Linus' kernel, and they work really well. The others, people seem to throw up their arms and say "well, those are Too Hard to get right, so we'll just ignore them and let the userspace folks try to write drivers for them"
You forgot the other two types... The ones that are in the kernel and work really poorly (some Fibre Channel, Infiniband, some SATA, some audio), and userspace drivers that work perfectly and have no business being in the kernel (most printers, modems, tape changers, some filesystems).
Why can't the kernel simply declare that OpenGL is The Graphics Interface for Linux, and provide only raw text and OpenGL as supported graphics APIs, and do software rendering for anybody who needs it?
Plenty of reasons, but the one you'd care about the most would be that you would be stuck forever with outdated video instead of having some slim hope like you have now. OpenGL is a morass of standards combined with vendor specific extensions. You'd be exactly as likely to get those extensions into the kernel tree as you are to get drivers into the kernel tree now, and you'd still need the drivers.
Also, I don't know how you can say: "do software rendering for anybody who needs it" and "then nobody would ever get stuck without working 3d acceleration again" in the same context. It's contradictory. Besides, after years of mocking windows for the problems caused by having graphics in the kernel, why would we want to follow their lead? Additionally, why should the current 3D acceleration paradigm be enforced by the kernel. What if somebody comes up with a new paradigm for rendering acceleration? Then the Linux kernel would be left out. The kernel part of the interface should be as generic as possible. It should handle I/O rapidly. End of story.
There isn't a single technical benefit to having the drivers in the kernel that can't be had with the drivers in user-space given the correct design. The reasons for this argument are political.
There is no educating people like you because you will never admit that humanity is ever capable of doing extraordinary things.
I have a theory that people like this exist mostly because we haven't done any large (physically) scale extrodinary things lately... At least, the western world hasn't. Where are our recent Appolos, Hoover Dams, or George Washington Bridges? All of our current achievments are either small (in size, not in value), out of site (space station? hubble? mars rovers?), or die in the beuracracy since there is no reward in our governements to think long term.
That should say: "As linux popularity grows, the percentage of people using a non-vendor kernel shrinks."
Oops.
It's ironic that you say that in a conversation about graphics drivers... Especially in a conversation about graphics drivers from the only manyfacturer who's drivers are now open source, but aren't backwards compatable. Say what you will about ATI or nvidia drivers, but you load them up and they still run the old chips.
And old hardware support from open source drivers is great if the device was popular when it was still in production. Otherwise, you're lucky if you can get it to work at all. Sure, there is a reasonable chance that the driver will compile (though even that hasn't always been the case)...
Also, when I said vendor, I meant linux vendor, not device vendor. Over the long term, the majority of users are ones that run a supported distribution on hardware supported by their distribution vendor, either because they built their box to the distro's specs (most businesses), or because they bought the hardware with the OS bundled (most home users).
This conversation is only really interesting at all to people with obscure hardware, or people who roll their own kernel and system.
Yeah right. Meanwhile, real life shows us that what you describe is exceptions rather than a rule.
That's only true if you use popular hardware.
The driver being in the kernel means you can bug the Linux kernel devs to make it work with each new release of the kernel (hence stable).
The driver not being in the kernel means they won't do anything about it, and you have no way of knowing if the driver will work or not.
The basic premise is that the maintainer of a driver would support his driver in the Linux kernel tree.
In the real world, all the smart users have vendor support to take care of this issue for them. As linux popularity grows, the number of people using a non-vendor kernel shrinks. A tiny minority of linux boxes run Linus' tree.
The discipline is to make the kernel work better no matter what, and to not get stuck by in-kernel stable interface
Not only is that the lie, but it is provably wrong. Look how many operating systems there are out there that are successful and have excelent driver support even though they don't have the flexability of changing the driver API every release and the drivers aren't built with the kernel. I can count seven that are on the market right now. If this was really about making the kernel better no matter what, they would add a stable interface, because that would be an improvement. Drivers in the tree could continue to exploit new features and wouldn't be stuck using the old interface as the document implies. There is a history of this happening in the real world, and even in the linux kernel, as in the past, the Adaptec SCSI driver was shared code between Linux and BSD, with a compatability layer inserted.
I can appreciate the goal of being good over being stable and or popular, but there are some parts of 'good' that only come after you are stable and popular.
And this is still moot in relation to this discussion, as graphics drivers are written for X an not the kernel.
Now I wonder how you can have the guts to write that. So you basically admit that you do closed drivers that have equivalent Free Software ones, though they used to be worse in Free Software version. And then you complain about the unstable API document and want to be taken seriously ? But you know what, I'd rather praise the guys who made the FOSS drivers.
Yes. And I don't see why that's surprising to you, unless you buy into Stallman's 'all software should be free' trash. I didn't say I don't have any open code. I simply don't have the luxury of being generous when it comes to this stuff most of the time. I have to make a living, and if that means taking a contract that is uder NDA in exchange for a paycheck, so be it. Pull a 2.4 tree and look in the ppc branch at the galileo code. Check the mailing lists for alpha, ppc, and just plain linux-kernel. When my contracts allow, the code goes into the tree.
It hardly matters anyway, because the only part of the system that really needs to be open is the platform, and none of this changes my main argument, which is that it's not the status of the source license that is causing the driver issues with linux graphics.
Do you have any idea what DirectX actually is? Did you even read my initial comment?
OpenGL is, at best, a replacement for a subset of DirectX. Worse, the latest features of modern graphics hardware exist as non-standard vendor extensions to OpenGL. Even without the missing functionality that DirectX has (input, sound, 2D, etc...) you're still missing my point. I'm not claiming Microsoft has the lead because of a technically superior product. They have a business development team out there pushing their API. So what I'm saying is... First linux needs the API (SDL + OpenGL cames close, but lacks polish), and then they need people to sell the API to developers and manufacturers. Only then will widespread, quality 3D driver support come; whether the drivers are open sourced now, or not.
Also, that document is a complete lie. I don't care that it's in the kernel tree. There's lots of wrong stuff in there.
A driver does not have to be in the tree to be stable, running driver, and the driver being in the kernel tree doesn't mean that it is either stable or running.
And I should know, as I have written multiple closed-source Linux device drivers, two of which have open-source versions in the kernel that have at various times either not worked, or worked poorly, and both of which perform signifigantly worse than the closed version.
Go actually read that document. The argument it makes is that a stable kernel/driver API is a bad idea because the kernel/driver API is unstable. It's a circular argument. The real issue is three-fold. One, there isn't enough agreement amongst the diversity of kernel developers to ever come up with a stable API, two, there is no dicipline amongst the people in charge to maintain that stability even if a consensus was reached, and three, there are some who would like to keep the interface unstable merely to keep this argument for open source drivers valid.
Dispite all that, the only real roadblock between ease of binary driver development and what we have today is that there is heavy backporting amongst distribution vendors without incrementing the kernel version number. In other words, vendors lie about their versions in order to maintain the illusion of version stability for their customers... But even that is a minor issue, as it only makes the people who run on the bleeding edge suffer, and nobody runs on the bleeding edge in production.
-1, Complete lack of understanding
I'm not talking about an API between the driver and the kernel. I'm talking about the API between the app and the driver. The kernel should be irrelevant. The application writer shouldn't care what the driver or the kernel are. As an example, take DirectX and Windows XP, Windows Mobile, and Xbox. The drivers are different, the kernels are different, the kernel/driver APIs are different, but what is the same, and what is important is that the third party app writer only has to learn one interface, and they (mostly) don't need to know anything about the hardware, the kernel, or the driver.
Read the entire thread. This isn't the only post like that. It's not the correct, or informative posts that are modded up. It's the cheerleader/fanboy posts.
It's a symptom of the fact that 99% of the people reading this article simultaniously know practically nothing about what they're talking about, and think they are experts.
Aah, crap...
That should, of course, say 'its', and not 'it's'.
Hah!
First of all, that's really, seriously, just a rumor.
Secondly, there is already an open source driver with a 'functional subset' of features for both ATI and nVidia cards. If they were to do this, nothing would change. Do you really think anybody who is upset about the current state of Linux graphics drivers would be satisfied in any way by crippled open-source drivers?
They like to compete instead by actually having good performance.
Besides, graphics drivers are the least of Linux's desktop problems. In the home it's major roadblock is the Microsoft business development executives in charge of DirectX, and in the workplace it's Exchange/Outlook. Get those things covered, and desktop Linux succeeds. Get just the DirectX issue covered (including marketing and developer outreach) and the graphics drivers will follow.
Don't believe me? Notice how MacOS doesn't seem to have the same driver issues as Linux dispite similar market share... When there is a unified graphics API, the driver writers have a finite set of things to test, and quality follows. It's not like ATI and Nvidia aren't trying... And sure, Intel's graphics drivers aren't as buggy... They don't perform either though.
I see their results, but I come to a different conclusion.
My headline would read "DC Power Results in 15% Increase in Equipment in Data Centers"
Unless you like it Frank Zappa style.
I didn't intentionally misconstrue it.
Ok, maybe you didn't misconstrue it. Maybe you're just a moron.
Here's the issue... You are directly implying that I said what they did was right, when what I really said was that nobody should be surprised. Quite honestly, that's rude and insulting.
as well as no practical way for a non-ISP to get my traffic unless they commit fraud to perpitrate a man-in-the-middle attack.
What does 'non-ISP' have to do with anything. Who is to say that your ISP isn't logging your searches? If they're a big ISP they almost certainly are in the log files for their transparent proxy. And that is to say nothing of the routers and firewalls that may be between you and the internet any time you sit down at a terminal you didn't configure yourself. I will say it one more time... You have no expectation of privacy when sending unencrypted data over the internet unless you personally have taken steps to guarantee it.
Exactly. :)
then it's ok for any company to violate their published privacy policy
They didn't violate their own policy. Yes I've read it.
Consent to use your personal information is opt-out according to their policy. I'm guessing this person (I still want to know why you keep saying 'she') didn't or the searches wouldn't have been in this list were it made public or not.
You have a weird sence of right and wrong.
I can't think of a better thing to say to you for intentionally misconstruing my argument and putting words in my mouth than: "Fuck you."
If there was no privacy issue, nobody would be mad at them for releasing the info.
That's funny.
It's cute that you actually believe that too.
The people are mad because the situation is not what they expected. There are many, many cases where things are not what people expect and said people get upset about it. Frequently in these cases, the issue is that people weren't paying attention. That is the case here. It's not a privacy issue, it's an attention issue.
Almost no data transmitted over BitTorrent is without copyright, as under the Berne Convention, works are copyrighted upon creation even when such rights are not claimed by the creator, or when the creator remains anonymous.
The only works which are not copyrighted are those in the public domain due to the expiration of their term, or those where the copyrights were explicitly waived. In other words, the vast minority of content transferred over BitTorrent.
Also keep in mind that this data is transmitted in plain text over the public network. I continue to maintain that you have to be delusional or uninformed if you consider that data to be private, regardless of whether AOL says they are keeping it private or not.