It operates kind of like a subscription and works out to a few dollars a month except that you still have all the offline components of the game without having to continue paying. That's why people keep buying it, they don't have to.
Also you mischaracterize it by claiming it is every year, in fact they don't shut down the servers a year after release, it's usually 3-4 years so if you work on that time frame it becomes even cheaper.
Who really cares what OS it is? On my gaming PC I turn it on, launch the game I want to play and then don't even see the OS. Whether it's Linux or Windows makes no difference and dual booting means you aren't beholden to one or the other anyway.
Steam Machines (Linux gaming in general) need to provide some compelling thing that you can't get on Windows, not just supporting a subset of the games available on Windows. The biggest praise I see in every discussion on this is just people being surprised at how many games are supported but really given that Unity, Unreal and Source engines are all supported on Linux it's not that big of a leap.
If they decrease the prices for developers that provide support for Vulkan on their store it would give a nice stepping stone to promote SteamOS or other Linux variants
Why? Vulkan is supported on Windows too, just like OpenGL.
I agree, I'm not sure an attentive human driver would have necessarily avoided that collision but the real question is why all the sensors of the autonomous vehicle didn't pick up that there was an obstacle in the road.
Why should they only get impunity for copyright violations of the GPL? Why doesn't Microsoft support a "first time free" policy for their own software?
This isn't "first time free", it's that you get impunity if you come into compliance.
Even then you can use LibreOffice on Windows - which is what comes installed on the vast majority of desktop and laptop computers - or Mac. There's not much you can do with Ubuntu that you can't with macOS or Windows.
Not everything on the WWW is a website, if it requires Javascript it's often a webapp or dynamic content presentation. Static content generally doesn't need javascript. There are plenty of web applications out there, Google Docs for instance or Apple's iCloud suite, most webmail.
> cross-platform, open spec low level graphics API to the Mac
A "low level graphics API" sounds suspiciously like a standard to me. Doesn't it sound like a standard to you?
No. First of all something that is a "low level graphics API" most certainly does not sound like a standard, nor has it got anything to do with whether or not it would be a standard. But the point is MoltenVK is not even that, it is just an implementation of the Vulkan API on top of the Metal API so no, MoltenVK is most certainly not a standard.
> Nor are these APIs competing,
I'm very confused how you might think such a thing. As I understand it, "Vulkan" is competing with "Metal", the Apple published, closed source API. Both compete for market share and developer time with DirectX on Windows based machines. Even if you consider Vulkan to be the software successor to OpenGL, it's competing with the older versions of OpenGL.
Vulkan isn't competing with Metal, in the only situations where you can run both Metal and Vulkan code (on iOS and OSX) the Vulkan code you run is running Metal code underneath anyway so any deficiencies of Metal when compared to Vulkan are exposed through MoltenVK so the fact that you wrote to the Vulkan API doesn't help you avoid issues with Metal at all.
For example Vulkan's DMA queue access is not a competitive feature over Metal in this instance because Metal does not provide this access therefore MoltenVK has to abstract this away.
There is a famous XKCD cartoon that describes very well the need for new standards.
MoltenVK isn't a new standard, it is a mechanism for bringing the only cross-platform, open spec low level graphics API to the Mac. Nor are these APIs competing, if you use Vulkan on the Mac (via MoltenVK) you're using Metal underneath, it just means you don't have to rewrite your renderer in Metal just to be able to run it on Apple platforms.
You sound just like the HiTech Complier people, who argued that C Compilers and microcontrollers in general had gotten to the point where even in time and performance-sensitive portions of real-time embedded code, there was absolutely no need for Assembly Language coding.
Then you missed the point, in fact I wasn't arguing anything at all. But if anything my advocacy is for lower level APIs being available rather than that functionality being hidden in the driver.
My point is, Just like tightly-hand-coded Assembly Language is likely to beat even the best Compiled code, as far as raw performance goes, it is also true that you will NEVER increase performance by adding interposing "translation" API layers to time-sensitive code.
Then you misunderstand the point of MoltenVK completely, it isn't about improving performance over Metal, it is about enabling portability in a more performant way than OpenGL. Vulkan on top of Metal has lower overhead than OpenGL (and Apple didn't manage to support OpenGL very well even before Metal anyway) because many of the concepts do map between them (lots of discussions on this around webgpu as this needs to be an abstraction for all the low level APIs).
My recollection was they got so fed up waiting for the Khronos Group to start real discussions about "OpenGL-next gen" they just got on with it, then Vulkan turned up. The article (and a lot of people on the internet, shocking that) in part try's to re-write history so it appears Apple ignored a standard (and a complete one at that...) because there evil and not playing nice (Umm OpenCL...CUDA...anyone) but at the time it didn't exist so what were they to do?
It will be interesting to see what Apple does next.
But they kept it closed and proprietary rather than just releasing it as open so others could implement it on other platforms.
The Vulkan platform is decent, but it isn't the card gamers want, nor is it particularly well made for it. I doubt Vulkan alone will win gamers over to the Mac. It seems like a classic chicken egg situation. Games will likely run better on the Mac than they did before, but unless the developers see demand from Mac users they simply wont take the time to port anything meaningful.
That's part of why Vulkan is important, previously porting to the Mac would require re-writing the rendering engine in Metal (or going back to OpenGL 4.1 with Apple's poor OpenGL support) whereas now you can run your Vulkan renderer on OSX/iOS.
Basically, Vulcan is a better and more modern alternative to DirectX than OpenGL with many of the benefits of OpenGL such as cross-platform, portable, open, etc. but easier to use than OpenGL, and better performance as good or better than DirectX.
It's certainly not easier to use than OpenGL, with Vulkan you must do a LOT of the things yourself that OpenGL does for you. Just writing a simple 'hello triangle' example in Vulkan is massively more complex than OpenGL: think of the OpenGL versions as a simple C hello world, you end up using a printf to write to the screen but behind the scenes that printf does a massive amount of stuff. Writing a Vulkan version is like having to write all that stuff that printf does.
While the CONCEPT of "One API to Rule Them All" is always tempting, weren't DirectX, Metal, etc. created SPECIFICALLY to REDUCE the number of "Layers" between well, the Software and the "Metal"?
DirectX12 (the Direct3D bit), Metal and Vulkan were designed to expose more of the driver details to the developer so we could get away from these monolithic drivers that contained application-specific code in them. It also offered a clean break from many of the legacy baggage carried through from older versions of APIs. The problem is that Metal and Direct3D are closed source and proprietary so in order to do cross platform applications you generally need a rendering backend layer that sits between your API-agnostic engine/application and the graphics API that the driver exposes.
With Vulkan drivers (and therefore API) available on Windows, Linux and Android that makes application portability much simpler and more efficient. The implementation of Vulkan (MoltenVK) sits atop the Metal driver and the concepts don't map exactly so Vulkan on Apple isn't going to perform as well or be as flexible as Vulkan on other platforms.
Yes, don't worry I understand that. I'm not particularly adept at arguing that point of view given it's not something I agree with but it seems they don't want their 'free platform' polluted with non-free software. The idea around restricting freedom of choice is the same religious argument of saving you from yourself, again not something I subscribe to.
Also in your case Jane is unlikely to be contributing anything to the free software version if she is using the proprietary one, but that just runs into the same stupid "loss of potential profits" arguments the MPAA/RIAA make about the damages of copyright infringement.
In any case if you want an argument best to reach out to the FSF;)
The more ensconced people get in using certain tools and develop the ecosystem around them the harder it is for them to move away and the less resources there are for funding/developing free alternatives. Once you have an incumbent it's almost impossible to unseat them without some disruptive innovation (again I see no issue with that) and a free software also-ran is not disruptive or innovative.
I don't think it's that difficult to understand but I think it's difficult to justify that point of view unless you're a free software absolutist.
It's not about affecting the OS, it's the network effects of people using non-free software on a free platform. Personally I agree with you, the ultimate freedom is a user's freedom of choice and users have that. Hardcore free software evangelicals disagree. I can't really speak to the state of mind that drives people like this though.
Though my opinion on this is that such people should write their own kernel without the provisions that allow non-free linkage to the kernel that Linux has. Of course if they do that it's unlikely to gain any traction and to just fail.
The issue is pre-installing. Give them a Linux PC and they will use it. Just as they will use Android or anything else.
It's trivially easy to install Linux distributions these days, there aren't going to be many people that want to install Linux that are going to get hung up because it is too difficult.
The problems come when they get to usability, given Razer is a maker of gaming peripherals let's take just one common gaming example: For the best performance you want the latest graphics drivers from nVidia, so you go and download them, then to run them you need to install the kernel development package (some googling will help you with that for your distro), then you have to kill your x server (again some more googling depending on your distro, the version of your distro, whether it uses systemd to manage daemons and default window manager), then you go through the build/installation process hitting all the defaults and you *should* be good to go, of course you can screw up your xorg config along the way but assuming that goes ok you are ready to go. Then you do an update that updates the kernel and when you reboot you just get a blank screen and nothing else, assuming you actually know what's happened (the kernel got updated so the kernel module you built for your graphics drivers is incompatible and can't be loaded) you have to switch to a TTY console and go through the build/installation process again, assuming the old driver is still compatible with the new kernel otherwise you'll need another system to download the new driver and copy it to your system either by mounting a usb drive via the terminal or doing an scp from one machine to another.
These are the kinds of things that put people off using Linux, installation is the easy part.
There's the more advanced stuff like the Precision Touchpad in Windows and the custom way Apple's Magic Trackpads work that isn't standard HID and, AFAIK (I could be wrong), has no Linux equivalent.
So I take it that means you can't steal electricity, cable television, someone else's internet bandwidth, or any number of other things with no physical or tangible component?
Perhaps a better analogy is your bank account details. If I copied your bank account details you would probably quite reasonably use the term 'stolen' (even if that's not strictly the correct word based on a particular dictionary definition) even though it hasn't caused you any harm nor have you been deprived of anything. Of course if I were to then sell/give a copy of those details to some nefarious party who then transferred your money somewhere then you would quite rightly hold me significantly accountable for taking possession of those credentials in the first place.
What you have said is correct and I don't think we need a new term, to redefine existing terms or to explain this in terms of copyright. I'm sure 'steal' or 'theft' is perfectly adequate to describe taking into your possession something that you know you should not have that does not belong to you, be that physical property, access credentials or source code. And most people with any mental capacity that aren't just being intentionally obtuse can understand that. i.e. I doubt the OP would be just fine with somebody taking and distributing his/her banking credentials on the basis that he/she has not been deprived of anything (yet) and I also doubt at that point he/she would be quibbling over the definition of 'stolen' or 'theft'.
If you run a website from JimBob's AutoParts in its own app that JimBob's third cousin grabbed the code for off the net you have NO IDEA how well it's sandboxed if at all.
Of course, but how does that relate to what we're talking about? The application in this case is run inside a sandboxed browser just like any web app, in reading the article it certainly doesn't appear as though the web app developer is providing the container app like you suppose.
In reading the article it appears they effectively launch the website in its own browser frame without all the browser chrome. But it's still a web app, but if you're concerned about applications that can be updated without Microsoft being aware of it isn't that any application that doesn't come from Microsoft?
Slashdot Mirror
It operates kind of like a subscription and works out to a few dollars a month except that you still have all the offline components of the game without having to continue paying. That's why people keep buying it, they don't have to.
Also you mischaracterize it by claiming it is every year, in fact they don't shut down the servers a year after release, it's usually 3-4 years so if you work on that time frame it becomes even cheaper.
Who really cares what OS it is? On my gaming PC I turn it on, launch the game I want to play and then don't even see the OS. Whether it's Linux or Windows makes no difference and dual booting means you aren't beholden to one or the other anyway.
Steam Machines (Linux gaming in general) need to provide some compelling thing that you can't get on Windows, not just supporting a subset of the games available on Windows. The biggest praise I see in every discussion on this is just people being surprised at how many games are supported but really given that Unity, Unreal and Source engines are all supported on Linux it's not that big of a leap.
If they decrease the prices for developers that provide support for Vulkan on their store it would give a nice stepping stone to promote SteamOS or other Linux variants
Why? Vulkan is supported on Windows too, just like OpenGL.
I agree, I'm not sure an attentive human driver would have necessarily avoided that collision but the real question is why all the sensors of the autonomous vehicle didn't pick up that there was an obstacle in the road.
Why should they only get impunity for copyright violations of the GPL? Why doesn't Microsoft support a "first time free" policy for their own software?
This isn't "first time free", it's that you get impunity if you come into compliance.
Even then you can use LibreOffice on Windows - which is what comes installed on the vast majority of desktop and laptop computers - or Mac. There's not much you can do with Ubuntu that you can't with macOS or Windows.
Not everything on the WWW is a website, if it requires Javascript it's often a webapp or dynamic content presentation. Static content generally doesn't need javascript. There are plenty of web applications out there, Google Docs for instance or Apple's iCloud suite, most webmail.
If I may quote your own words:
> cross-platform, open spec low level graphics API to the Mac
A "low level graphics API" sounds suspiciously like a standard to me. Doesn't it sound like a standard to you?
No. First of all something that is a "low level graphics API" most certainly does not sound like a standard, nor has it got anything to do with whether or not it would be a standard. But the point is MoltenVK is not even that, it is just an implementation of the Vulkan API on top of the Metal API so no, MoltenVK is most certainly not a standard.
> Nor are these APIs competing,
I'm very confused how you might think such a thing. As I understand it, "Vulkan" is competing with "Metal", the Apple published, closed source API. Both compete for market share and developer time with DirectX on Windows based machines. Even if you consider Vulkan to be the software successor to OpenGL, it's competing with the older versions of OpenGL.
Vulkan isn't competing with Metal, in the only situations where you can run both Metal and Vulkan code (on iOS and OSX) the Vulkan code you run is running Metal code underneath anyway so any deficiencies of Metal when compared to Vulkan are exposed through MoltenVK so the fact that you wrote to the Vulkan API doesn't help you avoid issues with Metal at all.
For example Vulkan's DMA queue access is not a competitive feature over Metal in this instance because Metal does not provide this access therefore MoltenVK has to abstract this away.
There is a famous XKCD cartoon that describes very well the need for new standards.
MoltenVK isn't a new standard, it is a mechanism for bringing the only cross-platform, open spec low level graphics API to the Mac. Nor are these APIs competing, if you use Vulkan on the Mac (via MoltenVK) you're using Metal underneath, it just means you don't have to rewrite your renderer in Metal just to be able to run it on Apple platforms.
You sound just like the HiTech Complier people, who argued that C Compilers and microcontrollers in general had gotten to the point where even in time and performance-sensitive portions of real-time embedded code, there was absolutely no need for Assembly Language coding.
Then you missed the point, in fact I wasn't arguing anything at all. But if anything my advocacy is for lower level APIs being available rather than that functionality being hidden in the driver.
My point is, Just like tightly-hand-coded Assembly Language is likely to beat even the best Compiled code, as far as raw performance goes, it is also true that you will NEVER increase performance by adding interposing "translation" API layers to time-sensitive code.
Then you misunderstand the point of MoltenVK completely, it isn't about improving performance over Metal, it is about enabling portability in a more performant way than OpenGL. Vulkan on top of Metal has lower overhead than OpenGL (and Apple didn't manage to support OpenGL very well even before Metal anyway) because many of the concepts do map between them (lots of discussions on this around webgpu as this needs to be an abstraction for all the low level APIs).
My recollection was they got so fed up waiting for the Khronos Group to start real discussions about "OpenGL-next gen" they just got on with it, then Vulkan turned up. The article (and a lot of people on the internet, shocking that) in part try's to re-write history so it appears Apple ignored a standard (and a complete one at that...) because there evil and not playing nice (Umm OpenCL...CUDA...anyone) but at the time it didn't exist so what were they to do?
It will be interesting to see what Apple does next.
But they kept it closed and proprietary rather than just releasing it as open so others could implement it on other platforms.
The Vulkan platform is decent, but it isn't the card gamers want, nor is it particularly well made for it. I doubt Vulkan alone will win gamers over to the Mac. It seems like a classic chicken egg situation. Games will likely run better on the Mac than they did before, but unless the developers see demand from Mac users they simply wont take the time to port anything meaningful.
That's part of why Vulkan is important, previously porting to the Mac would require re-writing the rendering engine in Metal (or going back to OpenGL 4.1 with Apple's poor OpenGL support) whereas now you can run your Vulkan renderer on OSX/iOS.
Basically, Vulcan is a better and more modern alternative to DirectX than OpenGL with many of the benefits of OpenGL such as cross-platform, portable, open, etc. but easier to use than OpenGL, and better performance as good or better than DirectX.
It's certainly not easier to use than OpenGL, with Vulkan you must do a LOT of the things yourself that OpenGL does for you. Just writing a simple 'hello triangle' example in Vulkan is massively more complex than OpenGL: think of the OpenGL versions as a simple C hello world, you end up using a printf to write to the screen but behind the scenes that printf does a massive amount of stuff. Writing a Vulkan version is like having to write all that stuff that printf does.
That's what I was thinking.
While the CONCEPT of "One API to Rule Them All" is always tempting, weren't DirectX, Metal, etc. created SPECIFICALLY to REDUCE the number of "Layers" between well, the Software and the "Metal"?
DirectX12 (the Direct3D bit), Metal and Vulkan were designed to expose more of the driver details to the developer so we could get away from these monolithic drivers that contained application-specific code in them. It also offered a clean break from many of the legacy baggage carried through from older versions of APIs. The problem is that Metal and Direct3D are closed source and proprietary so in order to do cross platform applications you generally need a rendering backend layer that sits between your API-agnostic engine/application and the graphics API that the driver exposes.
With Vulkan drivers (and therefore API) available on Windows, Linux and Android that makes application portability much simpler and more efficient. The implementation of Vulkan (MoltenVK) sits atop the Metal driver and the concepts don't map exactly so Vulkan on Apple isn't going to perform as well or be as flexible as Vulkan on other platforms.
Yes, don't worry I understand that. I'm not particularly adept at arguing that point of view given it's not something I agree with but it seems they don't want their 'free platform' polluted with non-free software. The idea around restricting freedom of choice is the same religious argument of saving you from yourself, again not something I subscribe to.
Also in your case Jane is unlikely to be contributing anything to the free software version if she is using the proprietary one, but that just runs into the same stupid "loss of potential profits" arguments the MPAA/RIAA make about the damages of copyright infringement.
In any case if you want an argument best to reach out to the FSF ;)
The more ensconced people get in using certain tools and develop the ecosystem around them the harder it is for them to move away and the less resources there are for funding/developing free alternatives. Once you have an incumbent it's almost impossible to unseat them without some disruptive innovation (again I see no issue with that) and a free software also-ran is not disruptive or innovative.
I don't think it's that difficult to understand but I think it's difficult to justify that point of view unless you're a free software absolutist.
It's not about affecting the OS, it's the network effects of people using non-free software on a free platform. Personally I agree with you, the ultimate freedom is a user's freedom of choice and users have that. Hardcore free software evangelicals disagree. I can't really speak to the state of mind that drives people like this though.
Though my opinion on this is that such people should write their own kernel without the provisions that allow non-free linkage to the kernel that Linux has. Of course if they do that it's unlikely to gain any traction and to just fail.
I'm afraid I don't see how non-free software on a free OS necessarily makes the OS any less free
It doesn't, nor is that their argument.
The issue is pre-installing. Give them a Linux PC and they will use it. Just as they will use Android or anything else.
It's trivially easy to install Linux distributions these days, there aren't going to be many people that want to install Linux that are going to get hung up because it is too difficult.
The problems come when they get to usability, given Razer is a maker of gaming peripherals let's take just one common gaming example: For the best performance you want the latest graphics drivers from nVidia, so you go and download them, then to run them you need to install the kernel development package (some googling will help you with that for your distro), then you have to kill your x server (again some more googling depending on your distro, the version of your distro, whether it uses systemd to manage daemons and default window manager), then you go through the build/installation process hitting all the defaults and you *should* be good to go, of course you can screw up your xorg config along the way but assuming that goes ok you are ready to go. Then you do an update that updates the kernel and when you reboot you just get a blank screen and nothing else, assuming you actually know what's happened (the kernel got updated so the kernel module you built for your graphics drivers is incompatible and can't be loaded) you have to switch to a TTY console and go through the build/installation process again, assuming the old driver is still compatible with the new kernel otherwise you'll need another system to download the new driver and copy it to your system either by mounting a usb drive via the terminal or doing an scp from one machine to another.
These are the kinds of things that put people off using Linux, installation is the easy part.
Unity being non-free. I certainly don't see that as an issue but evangelicals of the church of free software would argue that this is unacceptable.
If you follow the rantings of RMS you'll see those people sit on the "non-free software on a free os is worse than nothing at all" side of the camp.
Likely the conflict between those who like Linux as a technical achievement and those who like it as free software.
There's the more advanced stuff like the Precision Touchpad in Windows and the custom way Apple's Magic Trackpads work that isn't standard HID and, AFAIK (I could be wrong), has no Linux equivalent.
So I take it that means you can't steal electricity, cable television, someone else's internet bandwidth, or any number of other things with no physical or tangible component?
Perhaps a better analogy is your bank account details. If I copied your bank account details you would probably quite reasonably use the term 'stolen' (even if that's not strictly the correct word based on a particular dictionary definition) even though it hasn't caused you any harm nor have you been deprived of anything. Of course if I were to then sell/give a copy of those details to some nefarious party who then transferred your money somewhere then you would quite rightly hold me significantly accountable for taking possession of those credentials in the first place.
What you have said is correct and I don't think we need a new term, to redefine existing terms or to explain this in terms of copyright. I'm sure 'steal' or 'theft' is perfectly adequate to describe taking into your possession something that you know you should not have that does not belong to you, be that physical property, access credentials or source code. And most people with any mental capacity that aren't just being intentionally obtuse can understand that. i.e. I doubt the OP would be just fine with somebody taking and distributing his/her banking credentials on the basis that he/she has not been deprived of anything (yet) and I also doubt at that point he/she would be quibbling over the definition of 'stolen' or 'theft'.
If you run a website from JimBob's AutoParts in its own app that JimBob's third cousin grabbed the code for off the net you have NO IDEA how well it's sandboxed if at all.
Of course, but how does that relate to what we're talking about? The application in this case is run inside a sandboxed browser just like any web app, in reading the article it certainly doesn't appear as though the web app developer is providing the container app like you suppose.
In reading the article it appears they effectively launch the website in its own browser frame without all the browser chrome. But it's still a web app, but if you're concerned about applications that can be updated without Microsoft being aware of it isn't that any application that doesn't come from Microsoft?