Actually, you can't demand anything. You can ask. If they ignore you, then the COPYRIGHT owners can go after them. But not the end users. The GPL provides no legal recourse for users.
The title of this article of absolutely Android FUD. GPL conformance by vendors has long been a thorn to end users, and Android is no exception. But this gives the inference that Android itself somehow violates the GPL, which is utter baloney.
But somehow, the catalyst driver *IS* crap, which is what I was responding to
Overreacting by attacking I would say. The Catalyst driver is not crap either. I have used it a lot. Its binary installer on the other hand is poor. It will neither install the Catalyst driver completely nor remove it completely, leaving you in for considerable pain especially if you do not know your way around xorg.conf and especially is you do not have a second, web-connected machine at hand to track down problems while your GUI is broken by your attempt to install catalyst.Stupid, preventable issues like mysterious driver segfault if you have run the binary installer but not yet run the control center utility. Also, segfault if you have attempted to remove catalyst and not hand edited your xorg.conf to go back to the xorg driver. You may also find DRI failing to initialize and glxinfo just segfaults uninformatively.
Sticking with the xorg driver(s) is the best way to avoid this and other pain. The vast majority of users do not need more than a fraction of the horsepower even the cheapest Radeon delivers these days. By that measure, 60-70% of the proprietary driver performance is overkill. Even the factor of three or four difference we saw a few months ago is unlikely to be noticeable except in things like high end shooters at high resolution.
It's nice to have options, don't you think? To be sure, the driver differences are not just speed, certain capabilities of the card are not implemented as well in the xorg driver as in catalyst. As of xorg 7.6, lines are antialiased by catalyst but not by xorg (3D games typically draw thin polys instead of lines so this only affects things like engineering and game development applications). Mipmap filtering is visibly better in catalyst. I am sure this is just the beginning of the list. Nonetheless, the typical user just isn't going to notice, the xorg driver is already good enough.
As for me, I am happy that both open and closed drivers are actively developed, the latter as a cooperative effort between AMD and many outside developers, both professional and volunteer. The open driver will eventually surpass the closed one if history is anything to go by, and not just for products that have been on the market for years. Kudos all round I say, two code bases would seem to be better than one.
Your points are valid. Here is one distinct advantage of the open source driver. It can be used to support environments outside of X eventually, hopefully assisting in bringing us out of X11 into a new environment which isn't as bogged down with legacy support.
4 years? Where are you getting that number? The initial commit in Git of the r600g driver was in May 2010. May 2010 to July 2011 is not even close to 5 years.
The r600g driver was reworked based on capabilities present in the r300 driver.
For example, the Lightsmart benchmarks come in at around 25%.
That's not the Radeon driver's problem. All Mesa-based drivers have had similarly poor performance in Lightsmark for a long time, which suggests a shared CPU bottleneck.
Actually, another way to look at it is, all Gallium drivers exhibit similarly poor performance in intensive tests/use. But the point is, it's an alternative driver. Great! But it doesn't mean it's better. People buy hardware for performance, specifically, graphics cards. Perhaps the performance will someday surpass that of the proprietary driver. But it's not exactly newsworthy until it is at least equal or surpasses.
Only one when your just looking at that one singular article. Across the board, the Gallium3d drivers perform at around those levels across most of the spectrum.
I'm not saying it isn't notable for what they've accomplished. I'm just saying using this as an example of how proprietary drivers 'suck' is just silly. I, personally, would certainly use the open source driver, if the proprietary driver was failing for me. But jumping to the open source driver 'just cause' doesn't make much sense. Unless, of course, Linux is going to suddenly suck because the license isn't as liberal as hurd.
But somehow, the catalyst driver *IS* crap, which is what I was responding to. Only in the last month did they even consider the open source driver ready to be USED without crashing and acting strange.
For graphically intensive environments, many people have had the exact opposite experience, that the open source drivers require more time and effort then the proprietary ones.
They have NOT achieved what people are saying they have. the 60% number is a best case, with one or two specific benchmarks. In others, they are down by 25%. And they had achieved most of the initial speeds simply porting the old driver over, due to the similarities in the architecture.
The Gallium3D driver has been under development for nearly 4 years. Out of the box they where able to get roughly 30-40%, so, after 3 years, it increased roughly 10% per year. So yea, for 100%, itd be about 5 years. It should be noted that it performs in selected tests at that speed, NOT across the board. The more complicated and graphics rich the test, the worse the open source driver does. For example, the Lightsmart benchmarks come in at around 25%.
I can see how many people may not see a great cost/benefits ratio there...
Being open means that these drivers won't simply go away once the product line is deprecated in favour of the newest and coolest graphics card, and that it will be able to receive improvements and bug fixes essentially until the last working piece of hardware dies off.
Wewt! I can get speed improvements! Now, at their current rate or increase, it will only take 5 years for the driver to be able to perform at the same level as the proprietary driver.
Being open also means that it will be able to provide support for this Radeon graphics cards in other platforms besides the officially sanctioned ones, such as Windows and Linux. Being open also provides a way to provide competition for the people AMD employs to develop their official graphics card drivers, because if an open driver developed by amateurs on their spare time happens to be nearly as good or even better then they may as well be out of a job, and they can't have that.
If, by 'competition' you mean something which performs sub par to your own drivers, I guess there's a point there somewhere.
Being open also means that, if the open drivers mature enough so that they are comparable to AMD's official offering, then it will be in AMD's best interests to get directly involved in the development of these open drivers and even abandon their proprietary offering in favour of this project. And, obviously, if these open drivers represent a business success story to AMD then you can bet that this will spread out to other companies, and everyone who used windows and had to deal with hardware with support problems certainly knows what a PitA it is to be tied to proprietary drivers which are crap.
So, a product which is developed for years and has only recently achieved 60% of what the commercial driver can do *isnt* crap.
It's been spoken to ad naseum. Let them in, or be locked out. They chose to stay in. It's not like people there don't KNOW it isn't secure. It would be different if they where doing this without any sort of notice to the users.
Your account was affected. So was mine. It sucks. They are working on it, but they identified some accounts which where hit, and disabled them. According to them they needed to do this to restore the account.
They didn't disable all access to *ANY* google service, and send nasty 'This user is disabled for violating....' messages to anyone who attempts to email you.
Security? If I have a physical piece of hardware that could cut someones head off, why exactly would I have it connected to a network?
These PLC's operate with a swarm sort of mentality. The network is merely a method for them to communicate. Kind of like how your light switch authenticates you to turn on and off a light.
Oh wait, it doesn't... OMFGz0rs, someone could cause a fire by turning on the light without authentication!
Don't exaggerate the issue. The exploitation of PLC's by Stuxnet is akin to a device on your car vehicles CAN bus issueing commands across the network. Does your cars radio require authentication? Newp. How about your speedometer? Newp.
What StuxNet *does* emphasize is why it's a very, VERY dumb idea to have a network with PLCs connected to an external network of any kind.
"OMFG, I can't believe my cancer test came up negative because some hax0r compromised it. What kind of suck software was RUNNING on that device?"
OOOOOOoorrrrrrr..
"OMFG, you idiots, WTF would you connect a device which is going to tell me if I'm *DYING* to the MTF internet?!?!"
Yep, wave totally processing images, just like the web server your connecting to totally processes the images on this screen each time, custom, to fit your screen.. It's utterly amazing that the servers don't simply explode..
Slashdot Mirror
Actually, you can't demand anything. You can ask. If they ignore you, then the COPYRIGHT owners can go after them. But not the end users. The GPL provides no legal recourse for users.
The title of this article of absolutely Android FUD. GPL conformance by vendors has long been a thorn to end users, and Android is no exception. But this gives the inference that Android itself somehow violates the GPL, which is utter baloney.
But somehow, the catalyst driver *IS* crap, which is what I was responding to
Overreacting by attacking I would say. The Catalyst driver is not crap either. I have used it a lot. Its binary installer on the other hand is poor. It will neither install the Catalyst driver completely nor remove it completely, leaving you in for considerable pain especially if you do not know your way around xorg.conf and especially is you do not have a second, web-connected machine at hand to track down problems while your GUI is broken by your attempt to install catalyst.Stupid, preventable issues like mysterious driver segfault if you have run the binary installer but not yet run the control center utility. Also, segfault if you have attempted to remove catalyst and not hand edited your xorg.conf to go back to the xorg driver. You may also find DRI failing to initialize and glxinfo just segfaults uninformatively.
Sticking with the xorg driver(s) is the best way to avoid this and other pain. The vast majority of users do not need more than a fraction of the horsepower even the cheapest Radeon delivers these days. By that measure, 60-70% of the proprietary driver performance is overkill. Even the factor of three or four difference we saw a few months ago is unlikely to be noticeable except in things like high end shooters at high resolution.
It's nice to have options, don't you think? To be sure, the driver differences are not just speed, certain capabilities of the card are not implemented as well in the xorg driver as in catalyst. As of xorg 7.6, lines are antialiased by catalyst but not by xorg (3D games typically draw thin polys instead of lines so this only affects things like engineering and game development applications). Mipmap filtering is visibly better in catalyst. I am sure this is just the beginning of the list. Nonetheless, the typical user just isn't going to notice, the xorg driver is already good enough.
As for me, I am happy that both open and closed drivers are actively developed, the latter as a cooperative effort between AMD and many outside developers, both professional and volunteer. The open driver will eventually surpass the closed one if history is anything to go by, and not just for products that have been on the market for years. Kudos all round I say, two code bases would seem to be better than one.
Your points are valid. Here is one distinct advantage of the open source driver. It can be used to support environments outside of X eventually, hopefully assisting in bringing us out of X11 into a new environment which isn't as bogged down with legacy support.
4 years? Where are you getting that number? The initial commit in Git of the r600g driver was in May 2010. May 2010 to July 2011 is not even close to 5 years.
The r600g driver was reworked based on capabilities present in the r300 driver.
For example, the Lightsmart benchmarks come in at around 25%.
That's not the Radeon driver's problem. All Mesa-based drivers have had similarly poor performance in Lightsmark for a long time, which suggests a shared CPU bottleneck.
Actually, another way to look at it is, all Gallium drivers exhibit similarly poor performance in intensive tests/use. But the point is, it's an alternative driver. Great! But it doesn't mean it's better. People buy hardware for performance, specifically, graphics cards. Perhaps the performance will someday surpass that of the proprietary driver. But it's not exactly newsworthy until it is at least equal or surpasses.
Only one when your just looking at that one singular article. Across the board, the Gallium3d drivers perform at around those levels across most of the spectrum.
I'm not saying it isn't notable for what they've accomplished. I'm just saying using this as an example of how proprietary drivers 'suck' is just silly. I, personally, would certainly use the open source driver, if the proprietary driver was failing for me. But jumping to the open source driver 'just cause' doesn't make much sense. Unless, of course, Linux is going to suddenly suck because the license isn't as liberal as hurd.
But somehow, the catalyst driver *IS* crap, which is what I was responding to. Only in the last month did they even consider the open source driver ready to be USED without crashing and acting strange.
For graphically intensive environments, many people have had the exact opposite experience, that the open source drivers require more time and effort then the proprietary ones.
They have NOT achieved what people are saying they have. the 60% number is a best case, with one or two specific benchmarks. In others, they are down by 25%. And they had achieved most of the initial speeds simply porting the old driver over, due to the similarities in the architecture.
....
'60% of what it was using the proprietary driver'
way to deflect the point..
The Gallium3D driver has been under development for nearly 4 years. Out of the box they where able to get roughly 30-40%, so, after 3 years, it increased roughly 10% per year. So yea, for 100%, itd be about 5 years. It should be noted that it performs in selected tests at that speed, NOT across the board. The more complicated and graphics rich the test, the worse the open source driver does. For example, the Lightsmart benchmarks come in at around 25%.
You *really* didnt just make a comparison between CAD software..
And Mindcraft.......
Being open means that these drivers won't simply go away once the product line is deprecated in favour of the newest and coolest graphics card, and that it will be able to receive improvements and bug fixes essentially until the last working piece of hardware dies off.
Wewt! I can get speed improvements! Now, at their current rate or increase, it will only take 5 years for the driver to be able to perform at the same level as the proprietary driver.
Being open also means that it will be able to provide support for this Radeon graphics cards in other platforms besides the officially sanctioned ones, such as Windows and Linux. Being open also provides a way to provide competition for the people AMD employs to develop their official graphics card drivers, because if an open driver developed by amateurs on their spare time happens to be nearly as good or even better then they may as well be out of a job, and they can't have that.
If, by 'competition' you mean something which performs sub par to your own drivers, I guess there's a point there somewhere.
Being open also means that, if the open drivers mature enough so that they are comparable to AMD's official offering, then it will be in AMD's best interests to get directly involved in the development of these open drivers and even abandon their proprietary offering in favour of this project. And, obviously, if these open drivers represent a business success story to AMD then you can bet that this will spread out to other companies, and everyone who used windows and had to deal with hardware with support problems certainly knows what a PitA it is to be tied to proprietary drivers which are crap.
So, a product which is developed for years and has only recently achieved 60% of what the commercial driver can do *isnt* crap.
4 years after they stop making the hardware, they finally mature enough to be relevant.
Except.. These drivers have been around for years, and don't. So you wait for what, 3 years to get a driver that performs just over half as good.
Hey, here's a bug report..
"The driver seems to limit my hardwares performance to only 60% of what it was..."
Unless, of course, the country already had significant access to all internet traffic, VOICE phone calls, etc...
It's been spoken to ad naseum. Let them in, or be locked out. They chose to stay in. It's not like people there don't KNOW it isn't secure. It would be different if they where doing this without any sort of notice to the users.
No one else had reported it yet.
Your account was affected. So was mine. It sucks. They are working on it, but they identified some accounts which where hit, and disabled them. According to them they needed to do this to restore the account.
That'd be great, if...
They didn't disable all access to *ANY* google service, and send nasty 'This user is disabled for violating....' messages to anyone who attempts to email you.
Wait. A company who was just sold for less then 2 billion is worth more then a company who was just sold for less then.. 7?
How, exactly, is 2 alive, but 7 is dead?
*sigh* Siemans PCL's are network connected.
Reading.. It's whats for dinner.
Security? If I have a physical piece of hardware that could cut someones head off, why exactly would I have it connected to a network?
These PLC's operate with a swarm sort of mentality. The network is merely a method for them to communicate. Kind of like how your light switch authenticates you to turn on and off a light.
Oh wait, it doesn't... OMFGz0rs, someone could cause a fire by turning on the light without authentication!
Don't exaggerate the issue. The exploitation of PLC's by Stuxnet is akin to a device on your car vehicles CAN bus issueing commands across the network. Does your cars radio require authentication? Newp. How about your speedometer? Newp.
What StuxNet *does* emphasize is why it's a very, VERY dumb idea to have a network with PLCs connected to an external network of any kind.
"OMFG, I can't believe my cancer test came up negative because some hax0r compromised it. What kind of suck software was RUNNING on that device?"
OOOOOOoorrrrrrr..
"OMFG, you idiots, WTF would you connect a device which is going to tell me if I'm *DYING* to the MTF internet?!?!"
...
Really? Show me something which provides me a break capability, with the ability to inspect variables, and single step thru the code.
Sure there is..
Vow to never touch that sheep again!
........
Wow...
Just..
Wow..
Yep, wave totally processing images, just like the web server your connecting to totally processes the images on this screen each time, custom, to fit your screen.. It's utterly amazing that the servers don't simply explode..