It's a beta. How would they blame that on the users? One of fhe few times that a software company can release buggy software is with alpha and beta releases.
The fact that they pulled a beta for performance issues seems to counter your argument that Apple doesn't care. If they didn't care, they would have kept the beta out there.
You make it sound like all these different ballots are only put there to frustrate the voter; they are there as required by law and because that is the point of voting. Barring the national election races, each state, county, city has their own elections of officials. That doesn't include any special districts the voter may reside. Now, to simplify the ballot, there could be multiple separate elections but that require organization and cost by the local authorities. The other thing that you are ignoring is that no one is required to vote on all the ballot measures. Some people vote on the elections they care about and ignore the rest. The vote is only counted as long one ballot is filled.
Dude, chill out man. If you don't think Apple doesn't sell the highest priced item they can, you haven't bought a $30 cable when you can pay much less.
Okay here's how: HTML is content and there is a standards body to determine how content is formatted. Another example of this is h.264 and h.265. Now Apple might have an interest in how these standards are developed but they follow the standards in their own implementation.
Vulkan and Metal are graphics API which define not just content but processing and coding of content. For Vulkan they don't use it for the same reason they didn't adopt it from the beginning. Vulkan was years behind and Apple didn't want to wait. If Apple relies on Vulkan they have to rely on others on how their code works. For example, presumably Khronos is working on Vulkan 2.0. If Apple wants something in the new version, the group has to agree to it. What if the change helps Apple products but no others (or harms them)? Certain the group wouldn't approve such a change.
It's the same situation Apple found themselves with OpenGL. Apple needed lower level APIs to utilize newer mobile chip features but that was never going to happen with OpenGL as they have to maintain wide compatibility.
When they say Siri commands are not being recorded I assume they mean that no permanent audio file is saved. Buffering can happen in memory or temp files though I doubt it is more efficient to save files. Now I don't doubt the Siri content and meta data is being saved at the server but not the audio.
Don't forget cables and dongles.:) People seem to about business models. Without a doubt Apple will sell you the highest priced items that they can get away with selling; however, the vast majority of their business model is to sell hardware. Things like media is so that you will buy their hardware. For example, Apple took a stand against DRM in music because the public was against it and it benefited Apple not to have it. They have DRM in movies and shows because the public is fine with it.
The Open Group only certifies Unix standards; it does not control Unix so Apple, IBM, HP, etc can develop Unix as they see fit as long as it meets the standards. In the case of Apple they meet the 03 Standards but not the newer ones but I don't know of any that do.
No. I'm saying that the history of Vulkan and Metal shows clearly why Apple went their own way. Apple released Metal as a beta in June 2014 and officially released Oct 2014. That means they were working on it maybe years before that. Khronos didn't even start planning for the API known as Vulkan until July 2014. My reading of that is that as a group member, Apple knew Vulkan would be released years later than they wanted a new API and couldn't wait. So they went their own way. This is the problem with decisions by group; sometimes it takes forever to get anything done. If Apple were to go to Vulkan, they'd have to wait for changes by the group which might take years and they may not get priority for their changes as their user base is smaller.
Apple can and should participate in the group that develops the standard. To do otherwise would make Apple seem like a bunch of assholes. Oh wait, I'm starting to understand. You are from Apple right? You certainly are an asshole, so that would fit.
Why does Apple have to participate in a group in a standard they don't have interest in? That's like saying Apple should and can participate in a Microsoft Windows standards group.
But Apple was a prominent member of Kronos group and could easily have done a Vulkan alpha release, or glNext as it was called.
Haven been proved totally wrong that factually Apple could not have gone with Vulkan as it was released years after Metal, now your argument is that Apple could have forced the Khronos Group which is made of many members of the graphics community into an "early release"? You do know that the Khronos Group hadn't even released the early versions until years later but Apple was capable of doing it?
Instead, Apple abused its Kronos membership to learn Vulkan design details and rushed out an incompatible API a few months ahead of Vulkan. How sleazy can you get! And how sweet Apple got smacked on the head by Autodesk.
So your accusation is Apple somehow learned of the design details and rushed out an imcompatible API "months ahead". That's ludicrous at best. I wasn't in the Khronos Group but my reading of it was that Apple learned that Khronos would take years to decide on what to do next and Apple didn't want to wait. So they made their own spec.
You know nothing of FreeBSD. For example DragonflyBSD started after a food fight that ended up with revoking one of the core dev's commit access.
I never said anything about FreeBSD. I specifically mentioned OpenBSD and NetBSD. But continue with your tangent.
Sweet, your concept of intelligent discourse marks you as an Apple employee. Then you criticize other people's posts like an asshole. Again, how Apple of you. Chrome's multiprocess architecture was awkward to develop in Webkit. Apple could have moved Safari in the same direction but chose not to. So bam, fork.
No you made the assertion: "Apple wasn't sufficiently responsive to Google's needs so Google forked it, simple.". All I said is that you have to prove what you say. At this point it's another one of your assertions not grounded in evidence.
You niggle. Close enough to describe the reality. Would you prefer I said "mass migration away from Webkit"? There, said it.
I guess this means that you don't like it when people point out that you were not being entirely truthful?
There was no business case for introducing Metal instead of going with Vulkan, which can do the same but with less flexibility and no standarization. You can tattoo that on your Apple ass.
Apple released Metal beta in June 2014 and official release Oct 2014.. Vulkan wasn't released as a spec until Feb 2016. My business case is that the fact that Apple does not own a time machine and cannot have gone with Vulkan years before it was released. Remember Apple didn't release the spec in 2014; they released the beta which means they were developing it long before that time. But please go on with your unsubstantiated and uninformed opinions not grounded in facts.
Apple will never get back the community karma it lost by rolling its own Vulkan-like API and will eventually be forced to support Vulkan anyway to avoid more developer defections. Enjoy.
How can Apple roll out it's "Vulkan-like API" when Metal predates Vulkan by years? That's like saying Apple rolled out it's "Microsoft Windows like" OS in the original Macintosh.
If the cost of continuing to support those users (because, for example, you need to rewrite an entirely new graphics subsystem) is higher than the revenue from those users - then you drop them. Simple math. If I can support a small segment of the market with essentially a recompile or less, then sure - if I have to dedicate resources to internal rewrites, config management, QA, integration, deployment, etc. and those costs are higher than the profit potential - then no. They're gone.
Er what? Apple has never said that OpenGL will never work in the future. They said they are not continuing to support it. That doesn't mean someone will have to write OpenGL from scratch. It means that no new features of OpenGL will work and it will be stuck on the existing version. For example, X11 is no longer supported by Apple. You can still install it and it works but it is frozen on an older version of X11.
The problem is the cost to retrofit the old suit may cost more than to design a new one. And that's if there are no glaring functional deficiencies. For example, the suits will need some sort of battery to power sensors, communications, and life support. Most likely the old power packs can't be used. The old radios, life support, sensors can't be used. All of that will have to be redesigned; however, now you constrain the design to fit into a frame rather than design the frame with the systems.
Indeed there were a few different options Palm could have taken. They could have written their own program with their own cataloging system. They could have read the iTunes db as I think it was/is an XML file without any encryption. Instead they tried to trick iTunes in thinking that their device was an iPod.
Also in the show, some scenes in some episodes might be filmed on location in the US. Like for "The Impossible Astronaut". I think it was in Utah but it certainly wasn't on a soundstage and it on location in the U.K.
Describe "pittance". Every time someone thinks recreating old space tech is cheap or easy, I have to bring up a car analogy: If you found a junked classic car like a '64 Ford Mustang, would it be a "pittance" to restore a single car?
No. It would cost you many times what the car originally cost to
make. That's with the ability to source some original parts as it was a consumer product. That's with the possibility that you could sell a restored Mustang for more than your cost to restore. However, that Mustang does not meet current safety standards. It requires a lead substitute.
Now let's look at a space suit. Since this wasn't a consumer product, there are not a lot of sources for spare parts nor is there any financial incentive for someone to hold these parts. All parts have to be remanufactured. Unlike a Mustang where you could apply for an exception when it comes to certain standards, NASA does not that option. All parts have to brought up to current standards. For example, the suits will have to have current radio communications equipment as the oldsuits may not be broadcasting on the same frequencies.
They are less than 10% of your potential user base, and now you need to create a completely new code base to support them. And there are thousands of Alias users, not millions - meaning that macOS probably has mid-to-high 3 figure number of users. No longer really compelling, when you think of that number of users...
Apple has never had high number for decades now but you're saying that now you should abandon them because they don't have high number of users. . .
Well governed open source projects don't get forked.
BAHAHAHAHAHAHA. Wow you certainly don't know anything of open source. There are whole operating systems that have been forked. For example BSD, OpenBSD, NetBSD, etc.
Apple wasn't sufficiently responsive to Google's needs so Google forked it, simple.
HAHAHAHAHA. [Citation Needed]
Read your own link. Count the number of discontinueds. It's basically down to just Apple and Adobe. That happened really fast.
You said " now used by Safari and nobody else." That is factually untrue. Certainly not every browser is currently being used but you are either ignoring all of them or are delusional.
My assertion. Mark it down. I said the same about Metal, mark that down too. Do LLVM too while you're at it, though I think that of the three it has the best chance of avoiding a fork for now.
So you have no evidence for anything that you've said then. Then I can discount your posting as mere imagination.
Apple has no credible business case for Metal, which is a bespoke 3D API. I thought that was clear.
Slashdot Mirror
It's a beta. How would they blame that on the users? One of fhe few times that a software company can release buggy software is with alpha and beta releases.
The fact that they pulled a beta for performance issues seems to counter your argument that Apple doesn't care. If they didn't care, they would have kept the beta out there.
No what I said exactly is how you propose to "simplify" the elections other than not present the voter with all the ballots that are required by law?
I believe that in Canada, -40C is "Fecking cold, eh?" while in the US -40F is "Fucking cold, dude". Small difference.
You make it sound like all these different ballots are only put there to frustrate the voter; they are there as required by law and because that is the point of voting. Barring the national election races, each state, county, city has their own elections of officials. That doesn't include any special districts the voter may reside. Now, to simplify the ballot, there could be multiple separate elections but that require organization and cost by the local authorities. The other thing that you are ignoring is that no one is required to vote on all the ballot measures. Some people vote on the elections they care about and ignore the rest. The vote is only counted as long one ballot is filled.
Why does stating facts seem to piss you off?
Dude, chill out man. If you don't think Apple doesn't sell the highest priced item they can, you haven't bought a $30 cable when you can pay much less.
Okay here's how: HTML is content and there is a standards body to determine how content is formatted. Another example of this is h.264 and h.265. Now Apple might have an interest in how these standards are developed but they follow the standards in their own implementation.
Vulkan and Metal are graphics API which define not just content but processing and coding of content. For Vulkan they don't use it for the same reason they didn't adopt it from the beginning. Vulkan was years behind and Apple didn't want to wait. If Apple relies on Vulkan they have to rely on others on how their code works. For example, presumably Khronos is working on Vulkan 2.0. If Apple wants something in the new version, the group has to agree to it. What if the change helps Apple products but no others (or harms them)? Certain the group wouldn't approve such a change.
It's the same situation Apple found themselves with OpenGL. Apple needed lower level APIs to utilize newer mobile chip features but that was never going to happen with OpenGL as they have to maintain wide compatibility.
When they say Siri commands are not being recorded I assume they mean that no permanent audio file is saved. Buffering can happen in memory or temp files though I doubt it is more efficient to save files. Now I don't doubt the Siri content and meta data is being saved at the server but not the audio.
Don't forget cables and dongles. :) People seem to about business models. Without a doubt Apple will sell you the highest priced items that they can get away with selling; however, the vast majority of their business model is to sell hardware. Things like media is so that you will buy their hardware. For example, Apple took a stand against DRM in music because the public was against it and it benefited Apple not to have it. They have DRM in movies and shows because the public is fine with it.
That's not remotely close to developing their own graphics API or relying on a standards body for the graphics API.
In what way does Apple develop their own version of HTML?
The Open Group only certifies Unix standards; it does not control Unix so Apple, IBM, HP, etc can develop Unix as they see fit as long as it meets the standards. In the case of Apple they meet the 03 Standards but not the newer ones but I don't know of any that do.
No. I'm saying that the history of Vulkan and Metal shows clearly why Apple went their own way. Apple released Metal as a beta in June 2014 and officially released Oct 2014. That means they were working on it maybe years before that. Khronos didn't even start planning for the API known as Vulkan until July 2014. My reading of that is that as a group member, Apple knew Vulkan would be released years later than they wanted a new API and couldn't wait. So they went their own way. This is the problem with decisions by group; sometimes it takes forever to get anything done. If Apple were to go to Vulkan, they'd have to wait for changes by the group which might take years and they may not get priority for their changes as their user base is smaller.
Apple can and should participate in the group that develops the standard. To do otherwise would make Apple seem like a bunch of assholes. Oh wait, I'm starting to understand. You are from Apple right? You certainly are an asshole, so that would fit.
Why does Apple have to participate in a group in a standard they don't have interest in? That's like saying Apple should and can participate in a Microsoft Windows standards group.
But Apple was a prominent member of Kronos group and could easily have done a Vulkan alpha release, or glNext as it was called.
Haven been proved totally wrong that factually Apple could not have gone with Vulkan as it was released years after Metal, now your argument is that Apple could have forced the Khronos Group which is made of many members of the graphics community into an "early release"? You do know that the Khronos Group hadn't even released the early versions until years later but Apple was capable of doing it?
Instead, Apple abused its Kronos membership to learn Vulkan design details and rushed out an incompatible API a few months ahead of Vulkan. How sleazy can you get! And how sweet Apple got smacked on the head by Autodesk.
So your accusation is Apple somehow learned of the design details and rushed out an imcompatible API "months ahead". That's ludicrous at best. I wasn't in the Khronos Group but my reading of it was that Apple learned that Khronos would take years to decide on what to do next and Apple didn't want to wait. So they made their own spec.
You know nothing of FreeBSD. For example DragonflyBSD started after a food fight that ended up with revoking one of the core dev's commit access.
I never said anything about FreeBSD. I specifically mentioned OpenBSD and NetBSD. But continue with your tangent.
Sweet, your concept of intelligent discourse marks you as an Apple employee. Then you criticize other people's posts like an asshole. Again, how Apple of you. Chrome's multiprocess architecture was awkward to develop in Webkit. Apple could have moved Safari in the same direction but chose not to. So bam, fork.
No you made the assertion: "Apple wasn't sufficiently responsive to Google's needs so Google forked it, simple.". All I said is that you have to prove what you say. At this point it's another one of your assertions not grounded in evidence.
You niggle. Close enough to describe the reality. Would you prefer I said "mass migration away from Webkit"? There, said it.
I guess this means that you don't like it when people point out that you were not being entirely truthful?
There was no business case for introducing Metal instead of going with Vulkan, which can do the same but with less flexibility and no standarization. You can tattoo that on your Apple ass.
Apple released Metal beta in June 2014 and official release Oct 2014.. Vulkan wasn't released as a spec until Feb 2016. My business case is that the fact that Apple does not own a time machine and cannot have gone with Vulkan years before it was released. Remember Apple didn't release the spec in 2014; they released the beta which means they were developing it long before that time. But please go on with your unsubstantiated and uninformed opinions not grounded in facts.
Apple will never get back the community karma it lost by rolling its own Vulkan-like API and will eventually be forced to support Vulkan anyway to avoid more developer defections. Enjoy.
How can Apple roll out it's "Vulkan-like API" when Metal predates Vulkan by years? That's like saying Apple rolled out it's "Microsoft Windows like" OS in the original Macintosh.
If the cost of continuing to support those users (because, for example, you need to rewrite an entirely new graphics subsystem) is higher than the revenue from those users - then you drop them. Simple math. If I can support a small segment of the market with essentially a recompile or less, then sure - if I have to dedicate resources to internal rewrites, config management, QA, integration, deployment, etc. and those costs are higher than the profit potential - then no. They're gone.
Er what? Apple has never said that OpenGL will never work in the future. They said they are not continuing to support it. That doesn't mean someone will have to write OpenGL from scratch. It means that no new features of OpenGL will work and it will be stuck on the existing version. For example, X11 is no longer supported by Apple. You can still install it and it works but it is frozen on an older version of X11.
I failed to read that Apple said OpenGL would never work again. They said they were no longer supporting it. Just like you can still run X11 today.
The problem is the cost to retrofit the old suit may cost more than to design a new one. And that's if there are no glaring functional deficiencies. For example, the suits will need some sort of battery to power sensors, communications, and life support. Most likely the old power packs can't be used. The old radios, life support, sensors can't be used. All of that will have to be redesigned; however, now you constrain the design to fit into a frame rather than design the frame with the systems.
Indeed there were a few different options Palm could have taken. They could have written their own program with their own cataloging system. They could have read the iTunes db as I think it was/is an XML file without any encryption. Instead they tried to trick iTunes in thinking that their device was an iPod.
Also in the show, some scenes in some episodes might be filmed on location in the US. Like for "The Impossible Astronaut". I think it was in Utah but it certainly wasn't on a soundstage and it on location in the U.K.
Describe "pittance". Every time someone thinks recreating old space tech is cheap or easy, I have to bring up a car analogy: If you found a junked classic car like a '64 Ford Mustang, would it be a "pittance" to restore a single car?
No. It would cost you many times what the car originally cost to make. That's with the ability to source some original parts as it was a consumer product. That's with the possibility that you could sell a restored Mustang for more than your cost to restore. However, that Mustang does not meet current safety standards. It requires a lead substitute.
Now let's look at a space suit. Since this wasn't a consumer product, there are not a lot of sources for spare parts nor is there any financial incentive for someone to hold these parts. All parts have to be remanufactured. Unlike a Mustang where you could apply for an exception when it comes to certain standards, NASA does not that option. All parts have to brought up to current standards. For example, the suits will have to have current radio communications equipment as the oldsuits may not be broadcasting on the same frequencies.
They are less than 10% of your potential user base, and now you need to create a completely new code base to support them. And there are thousands of Alias users, not millions - meaning that macOS probably has mid-to-high 3 figure number of users. No longer really compelling, when you think of that number of users...
Apple has never had high number for decades now but you're saying that now you should abandon them because they don't have high number of users. . .
Well governed open source projects don't get forked.
BAHAHAHAHAHAHA. Wow you certainly don't know anything of open source. There are whole operating systems that have been forked. For example BSD, OpenBSD, NetBSD, etc.
Apple wasn't sufficiently responsive to Google's needs so Google forked it, simple.
HAHAHAHAHA. [Citation Needed]
Read your own link. Count the number of discontinueds. It's basically down to just Apple and Adobe. That happened really fast.
You said " now used by Safari and nobody else." That is factually untrue. Certainly not every browser is currently being used but you are either ignoring all of them or are delusional.
My assertion. Mark it down. I said the same about Metal, mark that down too. Do LLVM too while you're at it, though I think that of the three it has the best chance of avoiding a fork for now.
So you have no evidence for anything that you've said then. Then I can discount your posting as mere imagination.
Apple has no credible business case for Metal, which is a bespoke 3D API. I thought that was clear.
No you are merely wrong.