No, it's true for people who don't care about security.
Which appears to make up a majority of users.
The first thing I ever do when I get a new phones or tablet is wipe it and install a custom Android firmware sans-manufacturer's and Google's garbage software.
The necessity of this convoluted process - where it is even an option - is probably the reason the statistics show the majority are vulnerable.
Companies have begun to realize the value of collaboration and that working with the community is really advantageous. Sure they still have their proprietary bits and often that is where their competitive advantage lies but it means we get so much code collaboration and with open source and proprietary people working together. The exclusive - rather than inclusive - nature of Free software means it is now competing not just with proprietary software but with open source software as well (LLVM, busybox for example).
The special exemptions in Linux's COPYING file that allow it to work with proprietary software are what have made it so successful. And with proprietary people realizing the value of collaboration - and the Free Software people too interested in not working with anybody who doesnt share a compatible ideology - we are seeing a rise of more great active open source projects these days.
This is exactly right, I don't quite understand how people can still be so ignorant of the concept that "there is no such thing as a free lunch". How is it that people here are still surprised to find that out?
Apple's 'device' model is good, the hardware and software are integrated rather than separate things and it means the cost of the device is then used for both the hardware and software development.
I'll admit I forgot something. A controller and a bicycle are cheaper than a car and insurance.
Not everybody lives within a bike-ride's distance of their friends and when it's raining, hailing or snowing then you're unlikely to be riding a bicycle. In any case a laptop in your backpack is just fine on a bicycle.
But this isn't strictly important anyway, the situation you are describing is a niche that is already very well served by major titles that have local multiplayer components. Not all do but a surprising amount (given the low price of systems and the pervasiveness of the internet) still do.
...And signal the market that everybody wants Windows and not Linux, because all it sees are the Windows laptop sales figures.
If you really care what "the market" - whatever you're referring to there - thinks then pay the extra for the Linux version. Obviously it has no crapware subsidies and the cost of testing is amortized over a MUCH smaller amount of sales so naturally it is going to cost more, but cheapness shouldn't be the main sell here.
I can't speak to how often "a lift from family or friends" can be repeated before they begin to object to "using me as your private taxi". But a controller is cheaper than successfully lobbying your city to add bus service at night or on Sunday. (Source)
If you can't get a lift from family or friends and there is no bus service then a controller doesn't help you either, no matter how cheap it is it doesn't get you from one place to another.
Uber just needs to pay attention and modify it's surge pricing accordingly
How though? It is based on "supply and demand". A low-priced service is pointless if there is nobody to actually deliver that service, you can't force people to work.
[Context: an assertion that split-screen is irrelevant because people can buy a PC and a car and go to a LAN party]
I don't think that was the assertion at all. It was that split-screen is more of a niche because most people have a PC or a laptop or a console and can transport this somewhere or have friends transport theirs.
So what factors have driven the slight shrinking of the split-screen gaming segment? Well the growth in the PC market and the slowing of the hardware race means that most people have access to a computer that can reasonably play most games, the increased pervasiveness of low-latency internet connections means direct physical connections (even LAN) are less necessary now and the reduced cost of TVs mean many households have more than one already.
Despite this, a huge amount of AAA titles still support local co-operative/competitive play. Pretty much all fighting and sports games do as do hugely popular AAA games like Call of Duty, Borderlands and Gears of War.
This means people have to plan LAN parties in advance. They can't gather for a reason other to play video games and then just spontaneously decide to break out the video games.
Of course they can! Plenty of games offer local multiplayer like fighting games, most sports games, quite a lot of shooters...it's just that not all of them do and for those that don't yes you do need to plan ahead, which results in a better experience anyway. Once you have diluted the problem down to Saudi Arabian women having to plan LAN parties ahead of time if they want to co-operatively play Halo 5 then I think we have reached a fairly widely acceptable solution.
What I mean is the information they can't release is the source for the - admittedly sub-par - existing proprietary driver, which you shouldn't need since if you want to make your own open source driver they have released the specs and if you want to use their binary driver you can do that without the source too.
When was the last time the NEW SHINY actually did SOLVE ALL OUR PROBLEMS?
I'm sorry I'm not across every single new invention but in the case of this domain then certainly, as I already mentioned, the switch from fixed function to programmable pipelines has been an enormous improvement but obviously that falls outside "your experience". So why do you believe that replacing an API design that presents a representation of antiquated hardware coupled with a heavy translation layer to convert this to the real hardware, with an API that much more closely replicates the underlying hardware such that the driver has much less work to do - therefore significantly reducing driver complexity - is not going to be a resolution to the issues of driver performance? Being a naysayer just because you don't understand is easy, actually understanding the issue and providing a valid critique on the proposed solution to the problem is much more difficult.
We understand that there are legal complications regarding releasing the information, but if they can't do that and they can't make a decent driver themselves, which it appears they can not, then yes they're going to get plenty of flak. Why wouldn't you expect competence?
Why do you need their driver - that you admitted isn't decent - when you have the specification to work to?
Well if you actually understand it then you understand why GP's comment is pretty valid and that taking a cynical view just because you don't know any better is pretty silly. Much of the problem of driver performance and complexity is the the current APIs are not an accurate abstraction of modern hardware. So the driver contains a lot of code to convert from what the developer writes for - the hardware view they get from the API - to what the actual hardware is. A lot of that code is application-specific too (hence the large driver size and changelogs that mention specific programs) and is hand optimized by the driver developers working with the application developers.
Not only that but we have seen this before, the transition from fixed to programmable pipeline and API support for it meant that all the hacks to make fixed function do things it wasn't designed for that were then overridden on an app-specific basis in the driver could be done directly by the developer. In this case the driver becomes a lot more simple because the APIs it works with are more closely representative of the hardware it controls, it's pretty obvious to see how this is beneficial.
There are actually people out there who want features bad enough, that are willing to pay other people to write them. Generally people do not work for free.
Contribution of patches doesn't seem to be a problem. There are plenty of patch submissions but looking at that list of tasks it's hard to see who you would charge for the task of "piecing together new releases" or "accepting patches" or "maintaining the mailing list".
I think what this benchmark really tells us is two things:
1. nVidia has not optimized their driver stack for DX12 as much as AMD has optimized for DX12
Maybe but the whole idea is that should have little impact. These new APIs are about reducing driver overhead by re-designing the API such that it is a more accurate representation of the underlying hardware requiring a lot less work from the driver in converting between what the application thinks the hardware looks like and what the hardware actually looks like.
I'm not quite sure why you are modded down, this is a perfectly valid and legitimate concern.
Part of the problem of PC gaming has always been that the choice of hardware has meant we have had to have abstraction layers and these introduced inefficiencies which have reached significant levels nowadays. You remember seeing every time a new console generation is released that PC gamers proclaim it is terrible because their PC hardware is theoretically more powerful? Well that is true however being more powerful is pointless if that power can not be efficiently utilized, it just goes to waste. Heavy abstractions and generic implementations mean a lot of that increased power is wasted. So it is about bringing APIs up to scratch with modern hardware and removing some of the legacy cruft. It means more responsibility on the part of the application developer in the same way that it did when we went from the fixed function pipeline to the programmable pipeline many years ago.
For this Direct X thing to really be useful, it needs to isolate the developer from the hardware implementation. You need to abstract away the vendor specifics and make the programming agnostic to what hardware it's running on.
Well it still is relatively hardware agnostic, the difference is that we have had many advances in hardware that are not reflected in modern APIs. Take resource binding for example, currently resources are bound to "slots" when you define a shader pipeline and are fixed at draw time so if you want to change the resources that this shader pipeline uses you need to bind those new resources to those slots and draw again. This was a great general view of hardware at the time and is forward-compatible. But modern hardware has long had the capability to index a table of resources rather than just whatever is currently bound to the resource slots though the APIs are not architected to allow this. So this is generally implemented on an application-specific basis in the driver when the driver author (usually the hardware manufacturer) works with the application developer to understand what they are trying to accomplish that the API doesn't provide and then create a kind of munging layer in the driver that converts the application's "bind->draw bound, rebind->draw bound" workflow into a "create table->draw all" workflow. This is partly why you see significant performance differences in applications between driver versions but also why an application on similarly capable hardware can perform so vastly different between vendors.
That's just one example, I hope it's somewhat clear. Yes there is less of an abstraction in some areas but at the API level it doesn't do things like expose an AMD R9 -specific feature or an nVidia GTX980 -specific feature.
Well the underlying datatype is an array of floating point values, if you have a language-specific wrapper around OpenGL then maybe for your language a ByteBuffer makes sense and nothing precludes doing that.
Textures can be objects instead of integers.
But what you are referring to isn't a texture, it is a texture id which is why it is an integer.
Modern GPUs can handle one modern standard compressed texture format with alpha.
And you need something disruptive to change that, not something that's pretty much the same but cheaper. Google is trying (and seems to be doing fairly well) with their Google Docs offering because not only is it a capable office suite but it's platform-agnostic (web-based, even MS Office has a web-based version), has native applications for all the major mobile platforms (if you prefer that) and it is well-integrated with all their other services. But LibreOffice doesn't really have a disruptive feature, it's just a cheaper version of MS Office.
Yes nobody is saying COLLADA isn't good or useful but USD is obviously very different, USD isn't focussed on the file format, more the scenegraph format that it has and the libraries for manipulating it that it provides.
Slashdot Mirror
No, it's true for people who don't care about security.
Which appears to make up a majority of users.
The first thing I ever do when I get a new phones or tablet is wipe it and install a custom Android firmware sans-manufacturer's and Google's garbage software.
The necessity of this convoluted process - where it is even an option - is probably the reason the statistics show the majority are vulnerable.
Companies have begun to realize the value of collaboration and that working with the community is really advantageous. Sure they still have their proprietary bits and often that is where their competitive advantage lies but it means we get so much code collaboration and with open source and proprietary people working together. The exclusive - rather than inclusive - nature of Free software means it is now competing not just with proprietary software but with open source software as well (LLVM, busybox for example).
The special exemptions in Linux's COPYING file that allow it to work with proprietary software are what have made it so successful. And with proprietary people realizing the value of collaboration - and the Free Software people too interested in not working with anybody who doesnt share a compatible ideology - we are seeing a rise of more great active open source projects these days.
Oh well this must be all lies then.
This is exactly right, I don't quite understand how people can still be so ignorant of the concept that "there is no such thing as a free lunch". How is it that people here are still surprised to find that out?
Apple's 'device' model is good, the hardware and software are integrated rather than separate things and it means the cost of the device is then used for both the hardware and software development.
I'll admit I forgot something. A controller and a bicycle are cheaper than a car and insurance.
Not everybody lives within a bike-ride's distance of their friends and when it's raining, hailing or snowing then you're unlikely to be riding a bicycle. In any case a laptop in your backpack is just fine on a bicycle.
But this isn't strictly important anyway, the situation you are describing is a niche that is already very well served by major titles that have local multiplayer components. Not all do but a surprising amount (given the low price of systems and the pervasiveness of the internet) still do.
...And signal the market that everybody wants Windows and not Linux, because all it sees are the Windows laptop sales figures.
If you really care what "the market" - whatever you're referring to there - thinks then pay the extra for the Linux version. Obviously it has no crapware subsidies and the cost of testing is amortized over a MUCH smaller amount of sales so naturally it is going to cost more, but cheapness shouldn't be the main sell here.
I can't speak to how often "a lift from family or friends" can be repeated before they begin to object to "using me as your private taxi". But a controller is cheaper than successfully lobbying your city to add bus service at night or on Sunday. (Source)
If you can't get a lift from family or friends and there is no bus service then a controller doesn't help you either, no matter how cheap it is it doesn't get you from one place to another.
Uber just needs to pay attention and modify it's surge pricing accordingly
How though? It is based on "supply and demand". A low-priced service is pointless if there is nobody to actually deliver that service, you can't force people to work.
I didn't intend to dilute it that far. A controller is still cheaper than driving lessons, a car, and insurance.
But not than a bus/train/tram fare or a lift from family or friends.
because there isn't a full specification to work to. did you even read what you were replying to?
Of course I did, the title and the comments in the thread.
they don't release _enough_ information to make a decent open source driver
What else do you need?
[Context: an assertion that split-screen is irrelevant because people can buy a PC and a car and go to a LAN party]
I don't think that was the assertion at all. It was that split-screen is more of a niche because most people have a PC or a laptop or a console and can transport this somewhere or have friends transport theirs.
So what factors have driven the slight shrinking of the split-screen gaming segment? Well the growth in the PC market and the slowing of the hardware race means that most people have access to a computer that can reasonably play most games, the increased pervasiveness of low-latency internet connections means direct physical connections (even LAN) are less necessary now and the reduced cost of TVs mean many households have more than one already.
Despite this, a huge amount of AAA titles still support local co-operative/competitive play. Pretty much all fighting and sports games do as do hugely popular AAA games like Call of Duty, Borderlands and Gears of War.
This means people have to plan LAN parties in advance. They can't gather for a reason other to play video games and then just spontaneously decide to break out the video games.
Of course they can! Plenty of games offer local multiplayer like fighting games, most sports games, quite a lot of shooters...it's just that not all of them do and for those that don't yes you do need to plan ahead, which results in a better experience anyway. Once you have diluted the problem down to Saudi Arabian women having to plan LAN parties ahead of time if they want to co-operatively play Halo 5 then I think we have reached a fairly widely acceptable solution.
What I mean is the information they can't release is the source for the - admittedly sub-par - existing proprietary driver, which you shouldn't need since if you want to make your own open source driver they have released the specs and if you want to use their binary driver you can do that without the source too.
When was the last time the NEW SHINY actually did SOLVE ALL OUR PROBLEMS?
I'm sorry I'm not across every single new invention but in the case of this domain then certainly, as I already mentioned, the switch from fixed function to programmable pipelines has been an enormous improvement but obviously that falls outside "your experience". So why do you believe that replacing an API design that presents a representation of antiquated hardware coupled with a heavy translation layer to convert this to the real hardware, with an API that much more closely replicates the underlying hardware such that the driver has much less work to do - therefore significantly reducing driver complexity - is not going to be a resolution to the issues of driver performance? Being a naysayer just because you don't understand is easy, actually understanding the issue and providing a valid critique on the proposed solution to the problem is much more difficult.
We understand that there are legal complications regarding releasing the information, but if they can't do that and they can't make a decent driver themselves, which it appears they can not, then yes they're going to get plenty of flak. Why wouldn't you expect competence?
Why do you need their driver - that you admitted isn't decent - when you have the specification to work to?
Yes! The NEW SHINY will SOLVE ALL OUR PROBLEMS!
Well if you actually understand it then you understand why GP's comment is pretty valid and that taking a cynical view just because you don't know any better is pretty silly. Much of the problem of driver performance and complexity is the the current APIs are not an accurate abstraction of modern hardware. So the driver contains a lot of code to convert from what the developer writes for - the hardware view they get from the API - to what the actual hardware is. A lot of that code is application-specific too (hence the large driver size and changelogs that mention specific programs) and is hand optimized by the driver developers working with the application developers.
Not only that but we have seen this before, the transition from fixed to programmable pipeline and API support for it meant that all the hacks to make fixed function do things it wasn't designed for that were then overridden on an app-specific basis in the driver could be done directly by the developer. In this case the driver becomes a lot more simple because the APIs it works with are more closely representative of the hardware it controls, it's pretty obvious to see how this is beneficial.
There are actually people out there who want features bad enough, that are willing to pay other people to write them. Generally people do not work for free.
Contribution of patches doesn't seem to be a problem. There are plenty of patch submissions but looking at that list of tasks it's hard to see who you would charge for the task of "piecing together new releases" or "accepting patches" or "maintaining the mailing list".
I think what this benchmark really tells us is two things:
1. nVidia has not optimized their driver stack for DX12 as much as AMD has optimized for DX12
Maybe but the whole idea is that should have little impact. These new APIs are about reducing driver overhead by re-designing the API such that it is a more accurate representation of the underlying hardware requiring a lot less work from the driver in converting between what the application thinks the hardware looks like and what the hardware actually looks like.
I'm not quite sure why you are modded down, this is a perfectly valid and legitimate concern.
Part of the problem of PC gaming has always been that the choice of hardware has meant we have had to have abstraction layers and these introduced inefficiencies which have reached significant levels nowadays. You remember seeing every time a new console generation is released that PC gamers proclaim it is terrible because their PC hardware is theoretically more powerful? Well that is true however being more powerful is pointless if that power can not be efficiently utilized, it just goes to waste. Heavy abstractions and generic implementations mean a lot of that increased power is wasted. So it is about bringing APIs up to scratch with modern hardware and removing some of the legacy cruft. It means more responsibility on the part of the application developer in the same way that it did when we went from the fixed function pipeline to the programmable pipeline many years ago.
For this Direct X thing to really be useful, it needs to isolate the developer from the hardware implementation. You need to abstract away the vendor specifics and make the programming agnostic to what hardware it's running on.
Well it still is relatively hardware agnostic, the difference is that we have had many advances in hardware that are not reflected in modern APIs. Take resource binding for example, currently resources are bound to "slots" when you define a shader pipeline and are fixed at draw time so if you want to change the resources that this shader pipeline uses you need to bind those new resources to those slots and draw again. This was a great general view of hardware at the time and is forward-compatible. But modern hardware has long had the capability to index a table of resources rather than just whatever is currently bound to the resource slots though the APIs are not architected to allow this. So this is generally implemented on an application-specific basis in the driver when the driver author (usually the hardware manufacturer) works with the application developer to understand what they are trying to accomplish that the API doesn't provide and then create a kind of munging layer in the driver that converts the application's "bind->draw bound, rebind->draw bound" workflow into a "create table->draw all" workflow. This is partly why you see significant performance differences in applications between driver versions but also why an application on similarly capable hardware can perform so vastly different between vendors.
That's just one example, I hope it's somewhat clear. Yes there is less of an abstraction in some areas but at the API level it doesn't do things like expose an AMD R9 -specific feature or an nVidia GTX980 -specific feature.
That's an awful lot of faffing about just to get your smartphone to work effectively.
It's OK to use float[] instead of ByteBuffer
Well the underlying datatype is an array of floating point values, if you have a language-specific wrapper around OpenGL then maybe for your language a ByteBuffer makes sense and nothing precludes doing that.
Textures can be objects instead of integers.
But what you are referring to isn't a texture, it is a texture id which is why it is an integer.
Modern GPUs can handle one modern standard compressed texture format with alpha.
Not sure what you mean there.
It's all inertia.
And you need something disruptive to change that, not something that's pretty much the same but cheaper. Google is trying (and seems to be doing fairly well) with their Google Docs offering because not only is it a capable office suite but it's platform-agnostic (web-based, even MS Office has a web-based version), has native applications for all the major mobile platforms (if you prefer that) and it is well-integrated with all their other services. But LibreOffice doesn't really have a disruptive feature, it's just a cheaper version of MS Office.
Reliance on MS office is the only thing that holds back many of my folks (familiy, friends) from a total FOSS conversion of their computing habits.
How many documents do they really have that don't open properly in something like Google Docs which is available on all platforms anyway?
Yes nobody is saying COLLADA isn't good or useful but USD is obviously very different, USD isn't focussed on the file format, more the scenegraph format that it has and the libraries for manipulating it that it provides.
Just like ODF is not about free software?
Correct. It is about inter-operability between closed source software, open source software, shared source software, free software, whatever.