Or delete the DLL from the plugins directory, or change the permissions on the plugins directory or use Chromium (which is essentially Chrome without the DRM bit anyway).
This makes sense for Google, but not for me. It's high time someone forked Chromium. While they're at it.... Add back in the ability to Easily see SSL certificate information!
Go ahead and do it or pay somebody to do it, that's the point of Open Source. We saw the same thing with systemd, a lot of whining but no action so these changes get "forced" through. If you're just going to whine about it and do nothing then Open Source is pointless.
You can fork and maintain (merge from the mainline and keep your plugin changes) Chromium or pay somebody to do it and then Google can just keep doing what they want to do, if enough people don't like Google's approach and use yours then so much the better, that's "voting with your wallet" so to speak. The same thing could have happened with systemd, all those people complaining could have put that time and/or money into forking and maintaining the upstream so RedHat could do what they wanted and those who didn't want systemd could have their solution and again the best solution would win out.
Yes it requires more than zero effort but that's the case with anything worth doing.
Well that really depends on your point of view. Some applications - like office ones and video conferencing for example - are much more convenient as cross-platform web apps rather than native apps you need to install (or even worse browser and platform specific plugins) and they should be written to a standard so you aren't dependent on a specific vendor to run them.
HTML 6 or 5.1 depending on which standards body is being worked upon... just by Google setting the standards with Microsoft having some role too. Mozilla and Apple are irrelevant these days
Of course, because Google and Microsoft develop the sorts of applications best suited to run in platform-agnostic browsers so they need to innovate in that area to support greater capabilities. Mozilla doesn't really do that at all and Apple is focussed on native applications for their closed platforms rather than portable web applications.
Webkit is getting too popular. Many websites are using -webkit or blink specific CSS 3 tags and ignoring HTML 5 standards. THis is not healthy.
The glacial pace of the standards body is the problem, people want to use the new features rather than wait for a committee to standardize them and then of course they rarely go back and revisit them because the specific extensions continue to be supported.
Even Microsoft's 25 million subscribers at $7 per month bringing in around $175 million per month is hardly "failing".
Again, given their user base, I'd hardly call it "succeeding".
So how many subscribers and in what timeframe for what revenue does it need to meet your definition of "succeeding". I don't think you'll find a company in the world that would define ~$175 million per month in recurring revenue as anything but successful.
Python IS single-threaded, multi-threading is a big hack on Python and usually (at least a few years ago) came with big warning letters not to use unless you absolutely knew what you were doing.
No, the Python interpreter is single-threaded, that doesn't meant that things like I/O operations have to block everything else, in fact anything that isn't being interpreted can be done outside of the interpreter lock.
Time slicing is not multi-threading
I didn't say it was, I said that is how (on some Python implementations) concurrency is implemented, much like the way you can multi-task and run multi-threaded processes on a single core CPU.
Microsoft STILL hasn't figured out that most people prefer to own something than rent something.
Their quest for the almighty "endless-subscription" cash-cow is failing.
Yes that must be why Netflix, Spotify, Hulu, Apple Music, HBO Go, Stan, Adobe Creative Cloud, etc are failing so badly...oh wait. Even Microsoft's 25 million subscribers at $7 per month bringing in around $175 million per month is hardly "failing".
It's coming anyway - just like bridge builders and other REAL engineers.
So what's that got to do with Open Source? They will either continue releasing with licenses that explicitly avoid any claims for warranty or liability just like in the case we are talking about right here or it will just kill Open Source because nobody wants to open themselves up to that sort of legal backlash just to release OSS.
Much like pretty much every open source license the one here is no different. It's open source, you have the freedom to do whatever you like with it, but you are the one who assumes responsibility for it too.
Copyright (c) 2016, Comma.ai, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I know it's single threaded because I tried multithreading some existing code once and gave up.
Oh well if you tried and gave up then it must be single-threaded then right? In fact you can do multi-threading in Python - regardless of whether you gave up trying or not - and generally time-slicing is used to run the different threads "concurrently" on implementations that rely on the global interpreter lock.
You do have a point that the browser should not be minimal, along with the mail program, word processor, spreadsheet, photo and video editing software etc.
Just about every computer user is going to need a browser, the other things you listed...not so much.
Apple and especially IOS are special cases and expecting much out of them for choice is like expecting choice in a console.
They aren't 'special cases'. The fact that they don't give you choice at all makes them 'special'? Maybe Microsoft should just take away choice completely and become 'special' like Apple.
Yes an OS should come with a minimal browser to get you started. Once you've downloaded a replacement, you should be able to uninstall that minimal browser or at least totally remove it from your desktop
Some OSes do, most don't. In fact often the system relies on browser components because they've become integral to personal computing, iOS and OSX for example do not let you uninstall the browser at all, the former doesn't let you even install a replacement. If you want a barebones OS with no programs that you then have to go and download every little bit you need then you can go and get a minimal Linux distro.
This isn't 1995 anymore, the web is prevalent and it is expected that a computer (or computing device) be fully functional out of the box, not force the user to then have to go and install components that in this day and age are reasonably expected to already be there.
That is basically what I was saying, yes. Though the PS4/Switch use OpenGL, while the Xbox only uses DirectX...
No, neither of them use OpenGL. The PS4 uses a custom PSGL graphics library by Sony and the Switch uses the NVN API, a low-level, low-overhead graphics API that was designed for it by nVidia as it uses the Tegra processor.
Way to fly off the handle. You see it doesn't matter if coding is a skill people rarely use in their careers, in fact most of the stuff they learn in school won't be part of their career. But if it helps them see that computers are more capable than what is presented in a stupdified GUI they will be able to automate tasks, not be afraid of the command line, etc. and that is a very good thing given the prevalence of computers in the workplace. Otherwise economies of scale favor the simplified "computers as devices" model and the only thing worth producing is ipad-like computers.
I see, so the driver itself mplements the actual API function's behavior based on what *should* happen in a reference DirectX implementation?
Basically yes.
I guess I previously imagined that the driver opened a very basic interface to the hardware, and that somehow a DirectX library was responsible for translating an API call into some sort of low level code for the driver to run on bare hardware
The reason this isn't the case is that the low level code is GPU-specific (or at least specific to each GPU architecture) so that gets implemented by the driver vendor instead.
But most of the heavy lifting of translating the API call into machine instructions is actually done in the driver directly? So DirectX is just a spec... I guess I was confused because there is software called "DirectX" which installs libraries to the system, now I'm wondering what that huge install is, just basic SDK framework stuff like headers?
Well DirectX is more than just Direct3D, but the Direct3D component includes the libraries with the entry points that are bound to the driver implementation, helper libraries and functions for doing things like specifying state, building command buffers, math libraries, shader classes, etc. But the SDK itself also includes things like the debug libraries, debugging tools, documentation, samples, etc for 32 and 64bit as well and possibly the C# libraries for interfacing with it as well (the equivalent of something like OpenTK for C# + OpenGL). The Vulkan SDK is fairly similar, in the order of about 130MB but of course this is the first version of Vulkan, the DX SDK also includes a lot of stuff for backwards compatibility.
Then why are there often fixes on the game dev's end to fix issues with a specific graphics card? Shouldn't the patch notes say "fixed improper DirectX call" instead of say "fixed issue with lighting on Radeon 480" or "added support for Intel HD"... If the game is just asking DirectX to interpret calls, why should it have to worry about specific chipsets?
It doesn't, the implementation is in the driver, just like OpenGL. What "improper DirectX call" are you talking about? I think you need to be more specific about what the issue is you're referring to to be able to explain but if there is a fix for a specific GPU then it is in the driver implementation of OpenGL/DirectX for that architecture. Sometimes on the application side there are specific extensions that might be used to target specific GPUs more efficiently or an effect might be re-written with in a less efficient way to support GPUs that don't have the featureset to do it efficiently but are still powerful enough to at least support it. For example there are some great features in nVidia's Pascal architecture that I could use for effects but they wouldn't work on earlier GPUs and DirectX, Vulkan, OpenGL, etc do not abstract this away.
But DX/OGL are between the driver and the user application, the software asks DX to throw something up on the screen, and DX sends those calls to the driver. All the driver should have to worry about is properly handling DirectX requests, not about specific functions one game is trying to perform.
No, that's wrong. The DX/OGL libs that application developers link to are the functions that call into the implementation that resides in the driver. This is why getting support for newer versions of DirectX or OpenGL is a matter of upgrading your driver, not just upgrading the version of the application libs.
Why do driver patch notes then say "improved compatibility with game X" instead of "improved compatibility wit DirectX"...
I don't think they do, it's usually specific things like the way shader code is compiled to address compiler bugs or things specific to the architecture. The way the patch notes are written doesn't really matter, what matters is the message that X game will now work better or a bug has been resolved.
why would only one game benefit instead of all DirectX compatible software?
Because improvements for a specific game can come from resolving a shader compiler bug, shader optimizations or things like memory management optimizations for particular games dictated by the specific executable.
Why is the driver tested only against specific games and not some sort of reference DirectX implementation?
It is tested against a reference, but that doesn't mean it is completely optimized and bugfree in every possible combination of use case. Just the same as any programming language, API and even CPUs often have errata documentation.
This is basically my point as well! Yet as you figure, "of course" drivers are updated for specific games and also somehow games are implementing discrete fixes for specific GPUs instead of just for the broad implementation of DirectX...
Well it is like any language, you don't just write a compiler and be done with it, it is evolutionary. As developers use the features of the API and language (HLSL or GLSL) in different ways opportunities for optimizations (and of course bugs) present themselves and can then be addressed in updates.
Who cares about any of that? The only people interested in spec wars are braindead fanboys. The logical thing is to buy the console that has the games you want to play at the time regardless of its specifications. And quite frankly with consoles only costing a few hundred dollars anybody seriously into gaming that wants to play exclusives on both consoles will just buy both consoles since you can have both of them and some change for the price of a single highend PC gaming GPU.
Curiously though DirectX does not seem to help with compatibility. Games on Windows still have major issues with different hardware
I'm not quite sure what you mean specifically on how this relates to DirectX (or what you are implying is fundamentally different between it and say OpenGL), it in fact does help with compatibility in that you aren't coding for a specific GPU but for an abstraction where the implementation is provided by the driver. This is the same concept with both OpenGL and DirectX.
and interestingly on the GPU side we have Nvidia and AMD modifying their drivers to aid with game compatibility!!
Of course you do, that's where the implementation of the interface is. The driver provides the interface between the application and the hardware, now in the case of OpenGL and DirectX<=11 there is a lot of work done in the driver that the application developer has no control over (important things like memory management) so the driver writers then often include application-specific optimizations for popular programs. This is where DirectX12 and Vulkan come in, they reduce the amount of resource management that the driver has to do and the application becomes responsible for it, and of course there are frameworks starting to emerge that provide generic implementations for applications that do not need that level of optimization.
It seems like DirectX barely does anything to help with the situation... if at all.
Actually it seems like you fundamentally misunderstand what DirectX (and OpenGL for that matter) is and what they are designed to do. You see back before we had these APIs the issue was that you needed to write your rendering code specifically for every GPU (Glide for 3Dfx, S3d for the Virge, MSI for Matrox, etc) but DirectX and OpenGL meant that the code could be written for those APIs and the manufacturers just needed to provide an implementation in their driver so then that same code could run on any GPU without having to explicitly support it.
But the Playstation does have a range of hardware with the release of the PS Pro.
Yes, a range of 2, just like the XBox One and Project Scorpio. And it is forward compatible meaning that you can develop for the PS4 and it works just as good on the PS4 Pro, you only need to put in additional effort if you want create a unique experience on the PS4 Pro.
MS will have the advantage here as the DirectX API originating from the PC was designed from the start to easily develop for a range of hardware. It will be significantly easier for developers to take advantage of the extra power in Project Scorpio then it is for the PS Pro
Well given the assumption that Project Scorpio will be backwards compatible with the XBox One what is a specific example of something that will be so much easier to do with DirectX on Project Scorpio to create a unique experience that will be difficult to do on the PS4 Pro with PSGL?
And that's where you're wrong, I'm paying less for higher quality and in many cases higher convenience.
It's not higher convenience and you know it (unless of course you misunderstand what convenience means). And yes you pay more for a BR than a DVD so more money for higher quality. But in any case we're diverging from the original point of blaming the "younger invidivduals", which we've settled.
They sell twice as many consoles but have about 1/5 the amount of games as Xbox. This is what happens when people get too dependent on DirectX when OpenGL is soooo much better and available to everyone.
But the Playstation doesn't use OpenGL anyway, one advantage of those high level APIs is they allow abstraction of a vast range of hardware with a cost of overhead for doing so. The Playstation does not have a range of graphics hardware so suffering that overhead would be pointless, they use their own low-level graphics API.
Well given we're talking about blacklisting IPs that Windows sends information to and that you are looking for (haven't been able to find) a micro router/firewall I'd say it's pretty reasonable assumption that you do or that you would like to run Windows 10. If not then why bother? Just use the hosts file on Linux.
Anyway ok, you're not running Windows 10, no big deal. The suggestion still stands for anybody who does need to run it for whatever reason.
It's still optional; just stop using Chrome.
Or delete the DLL from the plugins directory, or change the permissions on the plugins directory or use Chromium (which is essentially Chrome without the DRM bit anyway).
No, I can't put valid certificates on them. That would violate compliance in the first place
Compliance with what?
This makes sense for Google, but not for me. It's high time someone forked Chromium. While they're at it.... Add back in the ability to Easily see SSL certificate information!
Go ahead and do it or pay somebody to do it, that's the point of Open Source. We saw the same thing with systemd, a lot of whining but no action so these changes get "forced" through. If you're just going to whine about it and do nothing then Open Source is pointless.
You can fork and maintain (merge from the mainline and keep your plugin changes) Chromium or pay somebody to do it and then Google can just keep doing what they want to do, if enough people don't like Google's approach and use yours then so much the better, that's "voting with your wallet" so to speak. The same thing could have happened with systemd, all those people complaining could have put that time and/or money into forking and maintaining the upstream so RedHat could do what they wanted and those who didn't want systemd could have their solution and again the best solution would win out.
Yes it requires more than zero effort but that's the case with anything worth doing.
HTML 6 or 5.1 depending on which standards body is being worked upon ... just by Google setting the standards with Microsoft having some role too. Mozilla and Apple are irrelevant these days
Of course, because Google and Microsoft develop the sorts of applications best suited to run in platform-agnostic browsers so they need to innovate in that area to support greater capabilities. Mozilla doesn't really do that at all and Apple is focussed on native applications for their closed platforms rather than portable web applications.
Webkit is getting too popular. Many websites are using -webkit or blink specific CSS 3 tags and ignoring HTML 5 standards. THis is not healthy.
The glacial pace of the standards body is the problem, people want to use the new features rather than wait for a committee to standardize them and then of course they rarely go back and revisit them because the specific extensions continue to be supported.
Even Microsoft's 25 million subscribers at $7 per month bringing in around $175 million per month is hardly "failing".
Again, given their user base, I'd hardly call it "succeeding".
So how many subscribers and in what timeframe for what revenue does it need to meet your definition of "succeeding". I don't think you'll find a company in the world that would define ~$175 million per month in recurring revenue as anything but successful.
Either way it's a hefty sum per month, hardly "failing".
Python IS single-threaded, multi-threading is a big hack on Python and usually (at least a few years ago) came with big warning letters not to use unless you absolutely knew what you were doing.
No, the Python interpreter is single-threaded, that doesn't meant that things like I/O operations have to block everything else, in fact anything that isn't being interpreted can be done outside of the interpreter lock.
Time slicing is not multi-threading
I didn't say it was, I said that is how (on some Python implementations) concurrency is implemented, much like the way you can multi-task and run multi-threaded processes on a single core CPU.
Microsoft STILL hasn't figured out that most people prefer to own something than rent something.
Their quest for the almighty "endless-subscription" cash-cow is failing.
Yes that must be why Netflix, Spotify, Hulu, Apple Music, HBO Go, Stan, Adobe Creative Cloud, etc are failing so badly...oh wait. Even Microsoft's 25 million subscribers at $7 per month bringing in around $175 million per month is hardly "failing".
It's coming anyway - just like bridge builders and other REAL engineers.
So what's that got to do with Open Source? They will either continue releasing with licenses that explicitly avoid any claims for warranty or liability just like in the case we are talking about right here or it will just kill Open Source because nobody wants to open themselves up to that sort of legal backlash just to release OSS.
Much like pretty much every open source license the one here is no different. It's open source, you have the freedom to do whatever you like with it, but you are the one who assumes responsibility for it too.
Copyright (c) 2016, Comma.ai, Inc.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
https://raw.githubusercontent.com/commaai/openpilot/master/LICENSE.openpilot
I know it's single threaded because I tried multithreading some existing code once and gave up.
Oh well if you tried and gave up then it must be single-threaded then right? In fact you can do multi-threading in Python - regardless of whether you gave up trying or not - and generally time-slicing is used to run the different threads "concurrently" on implementations that rely on the global interpreter lock.
You do have a point that the browser should not be minimal, along with the mail program, word processor, spreadsheet, photo and video editing software etc.
Just about every computer user is going to need a browser, the other things you listed...not so much.
Apple and especially IOS are special cases and expecting much out of them for choice is like expecting choice in a console.
They aren't 'special cases'. The fact that they don't give you choice at all makes them 'special'? Maybe Microsoft should just take away choice completely and become 'special' like Apple.
Yes an OS should come with a minimal browser to get you started. Once you've downloaded a replacement, you should be able to uninstall that minimal browser or at least totally remove it from your desktop
Some OSes do, most don't. In fact often the system relies on browser components because they've become integral to personal computing, iOS and OSX for example do not let you uninstall the browser at all, the former doesn't let you even install a replacement. If you want a barebones OS with no programs that you then have to go and download every little bit you need then you can go and get a minimal Linux distro.
This isn't 1995 anymore, the web is prevalent and it is expected that a computer (or computing device) be fully functional out of the box, not force the user to then have to go and install components that in this day and age are reasonably expected to already be there.
That is basically what I was saying, yes. Though the PS4/Switch use OpenGL, while the Xbox only uses DirectX...
No, neither of them use OpenGL. The PS4 uses a custom PSGL graphics library by Sony and the Switch uses the NVN API, a low-level, low-overhead graphics API that was designed for it by nVidia as it uses the Tegra processor.
Way to fly off the handle. You see it doesn't matter if coding is a skill people rarely use in their careers, in fact most of the stuff they learn in school won't be part of their career. But if it helps them see that computers are more capable than what is presented in a stupdified GUI they will be able to automate tasks, not be afraid of the command line, etc. and that is a very good thing given the prevalence of computers in the workplace. Otherwise economies of scale favor the simplified "computers as devices" model and the only thing worth producing is ipad-like computers.
No problem ;)
I see, so the driver itself mplements the actual API function's behavior based on what *should* happen in a reference DirectX implementation?
Basically yes.
I guess I previously imagined that the driver opened a very basic interface to the hardware, and that somehow a DirectX library was responsible for translating an API call into some sort of low level code for the driver to run on bare hardware
The reason this isn't the case is that the low level code is GPU-specific (or at least specific to each GPU architecture) so that gets implemented by the driver vendor instead.
But most of the heavy lifting of translating the API call into machine instructions is actually done in the driver directly? So DirectX is just a spec... I guess I was confused because there is software called "DirectX" which installs libraries to the system, now I'm wondering what that huge install is, just basic SDK framework stuff like headers?
Well DirectX is more than just Direct3D, but the Direct3D component includes the libraries with the entry points that are bound to the driver implementation, helper libraries and functions for doing things like specifying state, building command buffers, math libraries, shader classes, etc. But the SDK itself also includes things like the debug libraries, debugging tools, documentation, samples, etc for 32 and 64bit as well and possibly the C# libraries for interfacing with it as well (the equivalent of something like OpenTK for C# + OpenGL). The Vulkan SDK is fairly similar, in the order of about 130MB but of course this is the first version of Vulkan, the DX SDK also includes a lot of stuff for backwards compatibility.
Then why are there often fixes on the game dev's end to fix issues with a specific graphics card? Shouldn't the patch notes say "fixed improper DirectX call" instead of say "fixed issue with lighting on Radeon 480" or "added support for Intel HD"... If the game is just asking DirectX to interpret calls, why should it have to worry about specific chipsets?
It doesn't, the implementation is in the driver, just like OpenGL. What "improper DirectX call" are you talking about? I think you need to be more specific about what the issue is you're referring to to be able to explain but if there is a fix for a specific GPU then it is in the driver implementation of OpenGL/DirectX for that architecture. Sometimes on the application side there are specific extensions that might be used to target specific GPUs more efficiently or an effect might be re-written with in a less efficient way to support GPUs that don't have the featureset to do it efficiently but are still powerful enough to at least support it. For example there are some great features in nVidia's Pascal architecture that I could use for effects but they wouldn't work on earlier GPUs and DirectX, Vulkan, OpenGL, etc do not abstract this away.
But DX/OGL are between the driver and the user application, the software asks DX to throw something up on the screen, and DX sends those calls to the driver. All the driver should have to worry about is properly handling DirectX requests, not about specific functions one game is trying to perform.
No, that's wrong. The DX/OGL libs that application developers link to are the functions that call into the implementation that resides in the driver. This is why getting support for newer versions of DirectX or OpenGL is a matter of upgrading your driver, not just upgrading the version of the application libs.
Why do driver patch notes then say "improved compatibility with game X" instead of "improved compatibility wit DirectX"...
I don't think they do, it's usually specific things like the way shader code is compiled to address compiler bugs or things specific to the architecture. The way the patch notes are written doesn't really matter, what matters is the message that X game will now work better or a bug has been resolved.
why would only one game benefit instead of all DirectX compatible software?
Because improvements for a specific game can come from resolving a shader compiler bug, shader optimizations or things like memory management optimizations for particular games dictated by the specific executable.
Why is the driver tested only against specific games and not some sort of reference DirectX implementation?
It is tested against a reference, but that doesn't mean it is completely optimized and bugfree in every possible combination of use case. Just the same as any programming language, API and even CPUs often have errata documentation.
This is basically my point as well! Yet as you figure, "of course" drivers are updated for specific games and also somehow games are implementing discrete fixes for specific GPUs instead of just for the broad implementation of DirectX...
Well it is like any language, you don't just write a compiler and be done with it, it is evolutionary. As developers use the features of the API and language (HLSL or GLSL) in different ways opportunities for optimizations (and of course bugs) present themselves and can then be addressed in updates.
Who cares about any of that? The only people interested in spec wars are braindead fanboys. The logical thing is to buy the console that has the games you want to play at the time regardless of its specifications. And quite frankly with consoles only costing a few hundred dollars anybody seriously into gaming that wants to play exclusives on both consoles will just buy both consoles since you can have both of them and some change for the price of a single highend PC gaming GPU.
Curiously though DirectX does not seem to help with compatibility. Games on Windows still have major issues with different hardware
I'm not quite sure what you mean specifically on how this relates to DirectX (or what you are implying is fundamentally different between it and say OpenGL), it in fact does help with compatibility in that you aren't coding for a specific GPU but for an abstraction where the implementation is provided by the driver. This is the same concept with both OpenGL and DirectX.
and interestingly on the GPU side we have Nvidia and AMD modifying their drivers to aid with game compatibility!!
Of course you do, that's where the implementation of the interface is. The driver provides the interface between the application and the hardware, now in the case of OpenGL and DirectX<=11 there is a lot of work done in the driver that the application developer has no control over (important things like memory management) so the driver writers then often include application-specific optimizations for popular programs. This is where DirectX12 and Vulkan come in, they reduce the amount of resource management that the driver has to do and the application becomes responsible for it, and of course there are frameworks starting to emerge that provide generic implementations for applications that do not need that level of optimization.
It seems like DirectX barely does anything to help with the situation... if at all.
Actually it seems like you fundamentally misunderstand what DirectX (and OpenGL for that matter) is and what they are designed to do. You see back before we had these APIs the issue was that you needed to write your rendering code specifically for every GPU (Glide for 3Dfx, S3d for the Virge, MSI for Matrox, etc) but DirectX and OpenGL meant that the code could be written for those APIs and the manufacturers just needed to provide an implementation in their driver so then that same code could run on any GPU without having to explicitly support it.
But the Playstation does have a range of hardware with the release of the PS Pro.
Yes, a range of 2, just like the XBox One and Project Scorpio. And it is forward compatible meaning that you can develop for the PS4 and it works just as good on the PS4 Pro, you only need to put in additional effort if you want create a unique experience on the PS4 Pro.
MS will have the advantage here as the DirectX API originating from the PC was designed from the start to easily develop for a range of hardware. It will be significantly easier for developers to take advantage of the extra power in Project Scorpio then it is for the PS Pro
Well given the assumption that Project Scorpio will be backwards compatible with the XBox One what is a specific example of something that will be so much easier to do with DirectX on Project Scorpio to create a unique experience that will be difficult to do on the PS4 Pro with PSGL?
And that's where you're wrong, I'm paying less for higher quality and in many cases higher convenience.
It's not higher convenience and you know it (unless of course you misunderstand what convenience means). And yes you pay more for a BR than a DVD so more money for higher quality. But in any case we're diverging from the original point of blaming the "younger invidivduals", which we've settled.
They sell twice as many consoles but have about 1/5 the amount of games as Xbox. This is what happens when people get too dependent on DirectX when OpenGL is soooo much better and available to everyone.
But the Playstation doesn't use OpenGL anyway, one advantage of those high level APIs is they allow abstraction of a vast range of hardware with a cost of overhead for doing so. The Playstation does not have a range of graphics hardware so suffering that overhead would be pointless, they use their own low-level graphics API.
Well given we're talking about blacklisting IPs that Windows sends information to and that you are looking for (haven't been able to find) a micro router/firewall I'd say it's pretty reasonable assumption that you do or that you would like to run Windows 10. If not then why bother? Just use the hosts file on Linux.
Anyway ok, you're not running Windows 10, no big deal. The suggestion still stands for anybody who does need to run it for whatever reason.