The distro you use should be the ones compiling things. All you need to do is hit update. If that breaks, it's the distro's fault, not the gpl's or the kernel devs'.
From user POV: what if device is too new to be supported by distro, and I want to download drivers directly from vendor's site (e.g. NVidia has partner program where it releases beta drivers)? What if the device is too old and I can only get drivers on vendor's site, again?
And more importantly: what if cross-licensing agreements, which happen more and more in modern world, prevent the vendor from releasing drivers as open source? This is not something specific to GPU these days, soon this situation is going to be commonplace for CPUs as well, as CPUs are already migrating towards CPU+GPU in a single package. As a user, I prefer to have my hardware supported by binary drivers than not supported at all.
From vendor POV: Stable binary format will enormously help vendors to target Linux, reducing the number of "SKUs" to test and frequency of releases. Currently, only NVidia is willing to invest heavily in Linux graphics drivers, and you can see from TFA what attitude it gets in return. Meanwhile, if it weren't for excellent Linux support by NVidia (on par with Windows drivers), I personally wouldn't be using Linux at all, as I'm interested in demoscene and graphics programming. With stable ABI that would make binary drivers first-class citizens, it would be less expensive for NVidia to support Linux, and hopefully other vendors (AMD, PowerVR) would improve support as well - AMD's hardware is currently a pain with Linux (unless you are Ok with 2005-level feature set provided by open drivers).
Apparently some people don't mind being behind the whole world in terms of graphics hardware support. I'm not one of them, and while I value freedom that Linux gives me, if I am forced to decide between access to the latest technology and the said freedom, I will probably give up some control over my computer in order to be able to further develop myself in my areas of interest.
I want stable driver model as a user. Because I want to be able to install specific drivers without paying attention what kernel version they have been compiled for (even open source ones, which could be then distributed separately from the kernel itself).
At the same time, I realize and acknowledge that not everything can be released as open source, so I'm Ok with using binary-only drivers as long as they leave me in the control of the machine. After all, you cannot realistically avoid using binary only firmware even in Linux kernel itself.
"The pressure to use a particular version of the kernel" comes from the fact that kernel doesn't have stable binary interface for drivers, so you have to upgrade the entire kernel to get some new hardware supported. If kernel had such an interface, there would be no pressure, and both GPL'd and proprietary drivers could co-exist.
However, it is unlikely for kernel to have one, because as long as it remains binary unstable there's an incentive to release drivers as open source. With stable driver API most drivers would be shipped as binaries and kernel developers would need to devote significant effort to make user's life simpler erm... to remain backward compatible. And they don't want that, because that would have turned kernel development into a real work, and work is hard (like developing commercial proprietary software is), while all they want is just to have fun.
As someone said: people paint for free. People tend not to clean up toilets for free. With Linux you have a community of painters who don't want to "bend over sideways for a paranoid corporation" that wants to supply a proprietary toi-toi, lest they lose the ability to shit everywhere.
What NVidia needs is to team up with Intel, ARM, AMD, Red Hat and other sane entities developing Linux and create one big binary stable uberwrapper around all GPL code, essentially a binary driver API. And then GPL freaks (non-corporate developers constitute less than 25% of all Linux developers these days) can have their GPL-only APIs just for themselves...
I guess that's what will happen in the event Linus steps down as a maintainer. Some corporate entity will take over this role and will hopefully make Linux binary stable. GNU zealots will retreat to HURD and disappear from the radars.
My personal experience with NEON code cannot really be shared (or even discussed) due to NDA. But I can say that I was surprised how powerful NEON is on those dinky mobile processors....
Why is that? NEON instruction set is open. And as fast as it is, it's no match for a dedicated video decoder chip (both performance-wise and power consumption-wise). It's just a SIMD instruction set, like SSE or 3DNow!, really good for processing several data elements at once, but doesn't offer more parallelism than that.
* The mangling in C++ is a serious pain and makes loading C++ libraries and programs retardedly slow.
How so? The mangling gives functions funny long names, but they appear to the linker as just functions with long names, and behave the same way as C programs. I don't recall ever being bitten by this...
This is only an issue under Unix, where linking happens at run-time. May also happen under Windows if you begin to carelessly __declspec( export ) whole classes.
I can't say for China, but in Russia there are governmental institutions that work on "detecting superfluous functionality" in licensed software (foreign or otherwise). This doesn't include just building and comparing, a lot of other work needs to be done which is akin to unit-testing the code.
"Video workstation" with an Intel chip... what can it be good for? Even Photoshop has been supporting GPGPU for like 3 years, let alone video processing/encoding software.
Forget about "one standard to rule them all" mantra. You will never win with the diversity of this world. And if you do, that will be a dull, dystopian world ruled by a single "committee" and devoid of any innovation.
Wrong. You _could_ vote on issues you want to vote on, ald let professional politicians vote on stuff you dont care or dont know about.
Now there's a question how your vote would compare to professional politician's one. If they are of equal "parity", then professional politicians' decision will be easily overridden by population of a small village, if not - how exactly do they compare?
but direct democracy is only going to result in widespread populism.
How is it different than representative democracy? It isnt.
In representative democracy, it is still possible to make unpopular decisions. And this is sometimes needed (e.g. if there was a direct democracy inside my body, I would never go to gym - the fat would have voted that decision down and won by its sheer weight:-) ).
Elitism is a valid concern. Ideally, for each issue, voters would vote for each other to determine the most qualified ones among them to make the decision (e.g. I would vote for my doctor friend if issue is about health) first, then everyone "elected" in the first round would vote (possibly weighted by number of "electors") on the issue itself. Don't think it's ever going to be implemented though, too much overhead.
Politicians are at least supposed to do these things, they have dedicated time and resources just for that. Under direct democracy, you would have to vote several times a week in your "free time" on issues you might have heard for the first time.
Also, do you think general population is smart? Don't forget it were them who elected those politicians that don't have a clue in the first place.
In each particular question, only tiny minority of people are qualified to make an informed decision. We need to invent better mechanisms than rigid elections that would allow us to identify those people and assign larger weight to their votes, but direct democracy is only going to result in widespread populism.
Many representative positions could be abolished completely when people could directly vote on everything.
Uh, no. Unless voters are given unequal weight, you could reasonably assume that the most voters won't have enough qualifications/knowledge/big picture view to make any particular decision. Also, lack of a single decider can result in "design by committee"-like problems if combining choices is allowed.
You are implying that only PC enthusiasts are interested in single-thread performance. How come that Intel invests so much in improving it, then, and does not lose its market share to AMD? This is also at odds with AMD's improvements in Turbo Core in Bulldozer.
I am afraid that either most of desktop workloads remain essentially single-threaded (e.g. compilers are single-threaded if you want to perform global (whole program) optimizations as opposed to trivial - but suboptimal - splitting the program to multiple compile units) or it is peak single threaded performance that affects the feeling of "snappiness" that customers want to pay money for.
I think he simply claimed that you have to deal with C++ written by C programmers all too often. That's my experience, too.
I'm probably one of those C programmers. I use C++ features when I feel they are appropriate, but my definition of "the right thing" changed over years. I started to value custom-tailored solutions, often hardware- and problem-specific. No longer I'm trying to find (or create) code that would fit all (or even the most) cases, and micro-managed security is of lesser concern to me.
I don't see what that has to do with the above. I suppose there are some rare cases where the standard library isn't appropriate, but are you arguing this is an excuse *never* to use it?
There are always multiple tradeoffs involved, that's why I am very wary of saying "never". STL is no silver bullet, this is what I'm saying.
E.g. STL is bad at managing memory, it's hard to make it NOT allocate it dynamically - yes, you can write a custom allocator for it, but STL allocators are inflexible and also - for some poorly thought reason - manage object construction, not just memory allocation, making this unnecessarily hard. STL is a template library, and templates produce separate implementation for every type used - whereas you can have a single void *-based container for all your POD types, with templates providing just minimal wrapper. Also, STL makes it hard for you to control how often memory (object instances) is copied - there's no way to influence its behavior if memory copying tops your profiler results.
If you are developing primarily for desktop computers which are quite beefy (and also vague in terms of hardware), this may matter less (although it will never cease to matter - just think of all that slow code running on our desktops which eats the performance improvements we still (marginally) get, making desktop performance appear flat since 2004), but if your target is well-defined hardware-wise and if you know/set "upper bounds" for all the practical problem sizes your program is designed to handle, you can think of more optimal solutions for your case. This is one of reasons why you can still play the newest games on 2005 hardware (XBox 360) which hasn't even got an out-of-order CPU, while running the newest desktop software (not games!) on PC of the same era is problematic.
To sum up, I'm not saying "never use STL", but I would not say "always use STL" either. People claim that using "standard" code helps you create more secure, robust, performant programs - but in my experience, you will end up running a lot of custom tools (all kinds of profilers and validators) anyway before shipping your binary, that makes the point of "performant/secure code by design" moot. When profiler tells you that some code in an STL container underperforms, reimplementing it - or even understanding why that happens - is harder than fixing/improving your own implementation, yet you'll probably have to do that anyway. And no one starts "from scratch" these days, each "low-level" programmer I know has their own set of STL-alike classes.
By the way, your reference seems severely dated. Some of its complaints are still valid, but seem based on the state of STL support ten years ago.
Well, it is perhaps improving with new "move" constructors and whatnot, but that's actually a problem: it's better to have cross-platform code with predictable behavior than code that is supposedly optimal everywhere, but which depends on highly varied implementations. What good is it for me to know that some compilers (e.g. gcc), on some platforms (e.g. x86), handle new, C++11-ready STL well - gcc isn't particularly good at optimizing code even for x86, and another compiler that is a good optimizer may not support the newest features and make my STL-heavy code suck.
P.S. Also, STL (in implementations I saw) is written in quite unreadable, convoluted style - I always wondered why. This is of course less rele
Bullshit is what we have now: when "managed code" ends up being run as JIT-compiled chunks that lie scattered throughout the whole memory and make CPU instruction cache the bottleneck, when memory is accessed through chain of pointers, when people don't even know the memory layout of data they are using... let alone care about temporal and spatial locality when accessing it...
But "the free lunch is over" and single-threaded CPU performance hit a glass ceiling in like 2004, so we are slowly going "back to the roots" for single-threaded code - not every algorithm has, or will ever have, a nice/easy parallel version, so new processors won't help much.
As if those were the worst problems. And allocating memory dynamically fragments it. Ever tried writing custom allocators for STL to avoid dynamic memory allocations (or do them thru your own memory manager)? Good luck and hope you are tolerant to rectal pain.
So what? STL isn't suited for all possible uses, sometimes you need your own string and container classes.
Don't be a zealot, pragmatic programmer should find the right trade-off between reusing code and writing an optimal one for a specific problem/area. Nothing can be optimal in all cases - sometimes you need to be as close to hardware as possible at the expense of unreadable/inflexible code (for me, those are the most interesting and challenging areas), and sometimes you only care about maintainability of your code by a disposable programming drone.
Slashdot Mirror
Ever heard of Microsoft's Driver Verifier ? Not to mention its efforts in WHQL program.
The distro you use should be the ones compiling things. All you need to do is hit update. If that breaks, it's the distro's fault, not the gpl's or the kernel devs'.
From user POV: what if device is too new to be supported by distro, and I want to download drivers directly from vendor's site (e.g. NVidia has partner program where it releases beta drivers)? What if the device is too old and I can only get drivers on vendor's site, again?
And more importantly: what if cross-licensing agreements, which happen more and more in modern world, prevent the vendor from releasing drivers as open source? This is not something specific to GPU these days, soon this situation is going to be commonplace for CPUs as well, as CPUs are already migrating towards CPU+GPU in a single package. As a user, I prefer to have my hardware supported by binary drivers than not supported at all.
From vendor POV: Stable binary format will enormously help vendors to target Linux, reducing the number of "SKUs" to test and frequency of releases. Currently, only NVidia is willing to invest heavily in Linux graphics drivers, and you can see from TFA what attitude it gets in return. Meanwhile, if it weren't for excellent Linux support by NVidia (on par with Windows drivers), I personally wouldn't be using Linux at all, as I'm interested in demoscene and graphics programming. With stable ABI that would make binary drivers first-class citizens, it would be less expensive for NVidia to support Linux, and hopefully other vendors (AMD, PowerVR) would improve support as well - AMD's hardware is currently a pain with Linux (unless you are Ok with 2005-level feature set provided by open drivers).
Apparently some people don't mind being behind the whole world in terms of graphics hardware support. I'm not one of them, and while I value freedom that Linux gives me, if I am forced to decide between access to the latest technology and the said freedom, I will probably give up some control over my computer in order to be able to further develop myself in my areas of interest.
I want stable driver model as a user. Because I want to be able to install specific drivers without paying attention what kernel version they have been compiled for (even open source ones, which could be then distributed separately from the kernel itself).
At the same time, I realize and acknowledge that not everything can be released as open source, so I'm Ok with using binary-only drivers as long as they leave me in the control of the machine. After all, you cannot realistically avoid using binary only firmware even in Linux kernel itself.
"The pressure to use a particular version of the kernel" comes from the fact that kernel doesn't have stable binary interface for drivers, so you have to upgrade the entire kernel to get some new hardware supported. If kernel had such an interface, there would be no pressure, and both GPL'd and proprietary drivers could co-exist.
However, it is unlikely for kernel to have one, because as long as it remains binary unstable there's an incentive to release drivers as open source. With stable driver API most drivers would be shipped as binaries and kernel developers would need to devote significant effort to make user's life simpler erm... to remain backward compatible. And they don't want that, because that would have turned kernel development into a real work, and work is hard (like developing commercial proprietary software is), while all they want is just to have fun.
As someone said: people paint for free. People tend not to clean up toilets for free. With Linux you have a community of painters who don't want to "bend over sideways for a paranoid corporation" that wants to supply a proprietary toi-toi, lest they lose the ability to shit everywhere.
Poor kernel developers, they can't debug anything they don't have sources for. Probably they could learn a thing or two from Microsoft.
What NVidia needs is to team up with Intel, ARM, AMD, Red Hat and other sane entities developing Linux and create one big binary stable uberwrapper around all GPL code, essentially a binary driver API. And then GPL freaks (non-corporate developers constitute less than 25% of all Linux developers these days) can have their GPL-only APIs just for themselves...
I guess that's what will happen in the event Linus steps down as a maintainer. Some corporate entity will take over this role and will hopefully make Linux binary stable. GNU zealots will retreat to HURD and disappear from the radars.
My personal experience with NEON code cannot really be shared (or even discussed) due to NDA. But I can say that I was surprised how powerful NEON is on those dinky mobile processors....
Why is that? NEON instruction set is open. And as fast as it is, it's no match for a dedicated video decoder chip (both performance-wise and power consumption-wise). It's just a SIMD instruction set, like SSE or 3DNow!, really good for processing several data elements at once, but doesn't offer more parallelism than that.
* The mangling in C++ is a serious pain and makes loading C++ libraries and programs retardedly slow.
How so? The mangling gives functions funny long names, but they appear to the linker as just functions with long names, and behave the same way as C programs. I don't recall ever being bitten by this...
This is only an issue under Unix, where linking happens at run-time. May also happen under Windows if you begin to carelessly __declspec( export ) whole classes.
That's nothing: this is the real ubersecure requirement.
I can't say for China, but in Russia there are governmental institutions that work on "detecting superfluous functionality" in licensed software (foreign or otherwise). This doesn't include just building and comparing, a lot of other work needs to be done which is akin to unit-testing the code.
They shared the sources with Russia as well, for similar reasons (to obtain necessary certificates).
... and don't buy oil.
"Video workstation" with an Intel chip... what can it be good for? Even Photoshop has been supporting GPGPU for like 3 years, let alone video processing/encoding software.
Forget about "one standard to rule them all" mantra. You will never win with the diversity of this world. And if you do, that will be a dull, dystopian world ruled by a single "committee" and devoid of any innovation.
Wrong. You _could_ vote on issues you want to vote on, ald let professional politicians vote on stuff you dont care or dont know about.
Now there's a question how your vote would compare to professional politician's one. If they are of equal "parity", then professional politicians' decision will be easily overridden by population of a small village, if not - how exactly do they compare?
but direct democracy is only going to result in widespread populism.
How is it different than representative democracy? It isnt.
In representative democracy, it is still possible to make unpopular decisions. And this is sometimes needed (e.g. if there was a direct democracy inside my body, I would never go to gym - the fat would have voted that decision down and won by its sheer weight :-) ).
Elitism is a valid concern. Ideally, for each issue, voters would vote for each other to determine the most qualified ones among them to make the decision (e.g. I would vote for my doctor friend if issue is about health) first, then everyone "elected" in the first round would vote (possibly weighted by number of "electors") on the issue itself. Don't think it's ever going to be implemented though, too much overhead.
Politicians are at least supposed to do these things, they have dedicated time and resources just for that. Under direct democracy, you would have to vote several times a week in your "free time" on issues you might have heard for the first time.
Also, do you think general population is smart? Don't forget it were them who elected those politicians that don't have a clue in the first place.
In each particular question, only tiny minority of people are qualified to make an informed decision. We need to invent better mechanisms than rigid elections that would allow us to identify those people and assign larger weight to their votes, but direct democracy is only going to result in widespread populism.
They at least have the time and (presumably) abilities to study the issue in depth.
Many representative positions could be abolished completely when people could directly vote on everything.
Uh, no. Unless voters are given unequal weight, you could reasonably assume that the most voters won't have enough qualifications/knowledge/big picture view to make any particular decision. Also, lack of a single decider can result in "design by committee"-like problems if combining choices is allowed.
You are implying that only PC enthusiasts are interested in single-thread performance. How come that Intel invests so much in improving it, then, and does not lose its market share to AMD? This is also at odds with AMD's improvements in Turbo Core in Bulldozer.
I am afraid that either most of desktop workloads remain essentially single-threaded (e.g. compilers are single-threaded if you want to perform global (whole program) optimizations as opposed to trivial - but suboptimal - splitting the program to multiple compile units) or it is peak single threaded performance that affects the feeling of "snappiness" that customers want to pay money for.
I think he simply claimed that you have to deal with C++ written by C programmers all too often. That's my experience, too.
I'm probably one of those C programmers. I use C++ features when I feel they are appropriate, but my definition of "the right thing" changed over years. I started to value custom-tailored solutions, often hardware- and problem-specific. No longer I'm trying to find (or create) code that would fit all (or even the most) cases, and micro-managed security is of lesser concern to me.
I don't see what that has to do with the above. I suppose there are some rare cases where the standard library isn't appropriate, but are you arguing this is an excuse *never* to use it?
There are always multiple tradeoffs involved, that's why I am very wary of saying "never". STL is no silver bullet, this is what I'm saying.
E.g. STL is bad at managing memory, it's hard to make it NOT allocate it dynamically - yes, you can write a custom allocator for it, but STL allocators are inflexible and also - for some poorly thought reason - manage object construction, not just memory allocation, making this unnecessarily hard. STL is a template library, and templates produce separate implementation for every type used - whereas you can have a single void *-based container for all your POD types, with templates providing just minimal wrapper. Also, STL makes it hard for you to control how often memory (object instances) is copied - there's no way to influence its behavior if memory copying tops your profiler results.
If you are developing primarily for desktop computers which are quite beefy (and also vague in terms of hardware), this may matter less (although it will never cease to matter - just think of all that slow code running on our desktops which eats the performance improvements we still (marginally) get, making desktop performance appear flat since 2004), but if your target is well-defined hardware-wise and if you know/set "upper bounds" for all the practical problem sizes your program is designed to handle, you can think of more optimal solutions for your case. This is one of reasons why you can still play the newest games on 2005 hardware (XBox 360) which hasn't even got an out-of-order CPU, while running the newest desktop software (not games!) on PC of the same era is problematic.
To sum up, I'm not saying "never use STL", but I would not say "always use STL" either. People claim that using "standard" code helps you create more secure, robust, performant programs - but in my experience, you will end up running a lot of custom tools (all kinds of profilers and validators) anyway before shipping your binary, that makes the point of "performant/secure code by design" moot. When profiler tells you that some code in an STL container underperforms, reimplementing it - or even understanding why that happens - is harder than fixing/improving your own implementation, yet you'll probably have to do that anyway. And no one starts "from scratch" these days, each "low-level" programmer I know has their own set of STL-alike classes.
By the way, your reference seems severely dated. Some of its complaints are still valid, but seem based on the state of STL support ten years ago.
Well, it is perhaps improving with new "move" constructors and whatnot, but that's actually a problem: it's better to have cross-platform code with predictable behavior than code that is supposedly optimal everywhere, but which depends on highly varied implementations. What good is it for me to know that some compilers (e.g. gcc), on some platforms (e.g. x86), handle new, C++11-ready STL well - gcc isn't particularly good at optimizing code even for x86, and another compiler that is a good optimizer may not support the newest features and make my STL-heavy code suck.
P.S. Also, STL (in implementations I saw) is written in quite unreadable, convoluted style - I always wondered why. This is of course less rele
Bullshit is what we have now: when "managed code" ends up being run as JIT-compiled chunks that lie scattered throughout the whole memory and make CPU instruction cache the bottleneck, when memory is accessed through chain of pointers, when people don't even know the memory layout of data they are using... let alone care about temporal and spatial locality when accessing it...
But "the free lunch is over" and single-threaded CPU performance hit a glass ceiling in like 2004, so we are slowly going "back to the roots" for single-threaded code - not every algorithm has, or will ever have, a nice/easy parallel version, so new processors won't help much.
As if those were the worst problems. And allocating memory dynamically fragments it. Ever tried writing custom allocators for STL to avoid dynamic memory allocations (or do them thru your own memory manager)? Good luck and hope you are tolerant to rectal pain.
So what? STL isn't suited for all possible uses, sometimes you need your own string and container classes.
Don't be a zealot, pragmatic programmer should find the right trade-off between reusing code and writing an optimal one for a specific problem/area. Nothing can be optimal in all cases - sometimes you need to be as close to hardware as possible at the expense of unreadable/inflexible code (for me, those are the most interesting and challenging areas), and sometimes you only care about maintainability of your code by a disposable programming drone.
The smartest criminals do not violate laws. They bend/exploit them, breaking the spirit of law, but not the letter.