The OpenGL standards committee had done very little to solve the real problems game/graphics developers had been complaining about for years. Interests in backwards compatibility and CAD were making OpenGL compromise and please nobody.
AMD Mantle drew a lot of attention that something could be done, but too many questions about it such as will it only work on video hardware designed exactly as AMD designed it (and displeasing companies like Nvidia), kept any real advancement from happening.
But Apple Metal shipping last year was a real shot in the arm for Khronos because it finally forced them to do something or become completely irrelevant. (DirectX 12 had also started making noise.) We finally saw it presented at GDC a few months ago in draft/prototype form. What is interesting is Vulkan is a clean break from OpenGL so there is no backwards compatibility interest/attempt.
You can't fault Apple for needing to ship something real, today (actually last year). You can thank Apple for forcing the Khronos committee to finally do something.
The real question is if Vulkan will be usable on Apple platforms in the future, either provided by Apple or built as a wrapper on top of Metal by a 3rd party.
OSX also had accessibility support built in from the beginning. Apple made it a big deal that every computer should be installed with it by default, because it used to be the case in Windows that you had to install support manually, and only one computer in a classroom in the corner would have support. The idea was any child should be able to use any computer.
OSX has been generally good for accessibility for a second reason. Besides user-facing features, Apple's core APIs like Cocoa have accessibility built into to the widgets. When you use standard Cocoa controls from buttons to textviews, Apple already provides useful behaviors for accessibility in them. That way, even if a developer is completely oblivious to accessibility needs, as long as the developer was being a good Mac/iOS citizen, their program automatically inherits accessibility support.
This is where most 3rd party toolkits completely fall down. Cross-platform toolkits, 3rd party web browsers, video games... They reinvent all the GUIs/widgets themselves, *poorly*, and they always miss this aspect. And very few call them on it.
Gatekeeper prevents downloaded applications that are untrusted from accidentally being run. It doesn't prevent trusted applications from doing anything.
Exactly. Mod parent up.
And this is a *good* thing.
Apple has a separate sandboxing and entitlements system for more security. Apple makes apps distributed on the Mac App Store enable sandboxing. But for those apps (usually tools) that can't work within the limitations of the sandbox, developers can still ship outside the Mac App Store and do whatever they want. Code signing for GateKeeper is merely a trust checkbox that it is unlikely the vendor is doing anything really malicious or Apple would revoke their certificate and possibly pursue legal/criminal action for really nefarious activities since Apple gets a paper trail to hunt you down with as part of the process of getting a key to sign with.
If everything was locked down in the name of security, we would be denied all sorts of useful things.
True and not saying Valve should do anything to Nvidia. But alliances are complicated in general and pretty shaky with respect to Microsoft. Remember that Nvidia first held the Xbox contract and now Xbox is AMD based. Also, Microsoft managed to alienate every single one of their old partners by promising not to compete with them in hardware and then did Windows Phone and Surface which pretty much shattered the age old alliances and trust with Intel, Dell, HP, and the rest of the Microsoft cottage industry. CEOs with a memory longer than a goldfish should be wary of actively seeking an alliance with Microsoft because they are scared of some other smaller company that has earned respect from its users.
People already think Apple's walled garden and sandboxing go overboard. Remember that legit developers have to pay Apple $99/year just to develop+run an app on their own device. Apple also has a long list of requirements about what your app not allowed to do. I'd really hate to see what they do if they got *serious* about locking down the platform.
Anybody find it suspicious that at the height of the Snowden/NSA spying revelations, NCIS brings in a sympathetic and pretty NSA agent into the main cast. (And her show's husband is played by Jamie Bamber (Battlestar Galactica), another NSA agent.)
Go buy a Steam Machine. There are already 15 vendors lined up to sell them. These OEMs are betting people are tired of this typical Microsoft BS. Prove them right and buy their machines and support their effort.
That is, unless VMWare sincerely thinks they are in the right and have a defensible case. Then things get very interesting because then there is a chance the GPL could be undermined/weakened if they win and you will see a lot of groups start paying attention to make sure Software Freedom Conservancy doesn't screw up the case for GPL. (And you may see other parties interested in exploiting a weakened GPL.)
Chances are VMWare will eventually just release the bare minimum code in question after they hit a small threshold in legal fees and make the lawsuit moot.
Waiting for somebody else bring up litigation didn't cost VMWare much. They can simply wait until somebody calls them on it, then do the bare minimum to make it go away.
And nobody will continue to press on them because seeking "damages" is really hard to demonstrate in this kind of case and continuing to pay lawyers to try to punish VMWare will be cost prohibitive.
There is also the case law risk that if VMWare does win, the GPL could be weakened/undermined, so there will be a lot of pressure on the plaintiff to not press their luck.
"Systemd gives a lot of features you couldn't get any other way. The boot-up speeds are real. And it's not saying you couldn't get the same things with non-systemd. But systemd stepped up and did it."
"I think the fight is mostly over."
"The lack of portability is sad. The thing I that I absolutely hate is that the bug reports have been basically ignored in some cases."
"I realize people expected me to hate systemd. I don't hate it, really. I think it is somewhat interesting and it has quirks, but what does not?"
Stock holders are forgiving to Apple because they constantly show profits. Even during the dot-com implosion, Apple continued to show growth and profits in their Mac lines as the rest of the PC industry struggled.
Amazon is the opposite. Amazon has never had a profitable quarter. Instead their spending always outstrips their revenue. Stock holders have been amazingly patient because Amazon has been doing this for like 20 years now. But a $170 million write-down is a lot of money (unless you are Microsoft, and they at least have enormous profits to offset their huge billion dollar losses), especially for a company that has never had a profitable quarter.
And this is for a product that everybody sees as outside Amazon's strengths. And the market reaction shows there is little interest and demand for this product, yet Amazon intends to double-down.
Considering it has been over 20 years, I'm surprised Amazon hasn't seen a lot more criticism. Kudos I guess to Amazon's ever-patient shareholders.
You are correct. But there is a much more direct answer to defend Bubble Sort.
In the real world, i.e. on real hardware, bubble sort usually faster than other algorithms for small data sets. This is due to cache locality. A cache miss can mean the difference between 4 clock cycles vs. over 400 cycles, simply waiting for 4 little bytes to be read from RAM.
Cache misses are now the biggest problem for high performance programming. For instance, (good) video game programmers are very aware of this fact.
Agreed. And for the op, Obj-C is the best language to use right now. Being well versed in C means he can learn Obj-C in a day. Obj-C is a very small superset of C.
The hard part is learning Cocoa, but that is true of any framework whether that is Swing, Android, MFC, GNOME, Qt.
Swift is so new, you will have to learn Obj-C anyway to learn Cocoa.
The best bet is for the op to write model/cross-platform code in C, and then use Obj-C for the native UI layer. Then repeat for Android/Java (via JNI) and Windows Phone/C++CX.
But is the ratings decline reflective of revenue or an overall problem with the show? Over the past 10 years, television viewership has been falling in general, losing out to other forms of entertainment.
However, the irony is that the cost for advertising in television is at an all time premium. This is because there is still no other advertising outlet that can capture such a wide audience at the same time with and also with well understood demographics.
48 replies to "DON'T FORCE ME TO UPGRADE!...PLEASE!", where the majority are people trying to help the few that are complaining, does not constitute "swamped".
In contrast there are 471 replies to "I show up as Online when I'm not"
The thing that happened was Microsoft started building/selling their own devices, competing directly with their former partners. That was a stab in the back and maybe they actually learned their lesson.
The op complaint was no 64-bit Firefox for Mac. Apple doesn't do x32, so it's not even an option.
Data starvation can be mitigated/manually controlled in 64-bit by understanding your data. High performance code utilizes contiguous blocks of memory and is very aware of data layout, and isn't going to be pointer chasing. So allocating arrays of types that use int32_t instead of int64_t is a trivial example. So in a 64-bit architecture, you still generally win performance-wise.
x32 failed for a lot of reasons. From the article you cited, here's a quote: "they just really don't see the [x32] ABI as being worthwhile... to make maintaining an extra ABI worthwhile."
As the quote highlights, the real crux of the problem is how much of a pain it is to maintain yet another ABI. The performance differences for x32 didn't justify it over true 64-bit. That means the data starvation due to larger pointer sizes wasn't the dominating factor. So going from i386 to x32 vs. i386 to x64, the latter wins because it gets the speed of more registers, negligible performance impact for pointer size differences, and the plus of large addressable memory if you need it.
To show the pain of another ABI, here is a simplified example: You are using a video editor in GNOME under x32. You suddenly need more than 4GB of addressable memory. That means you needs a x64 version. But then you need a GNOME that is also built as x64, so you have to load up an entirely separate instance of GNOME, all its dependencies, and the video editor. Either you need to shutdown your current environment and reboot another, or you need to load both simultaneously. (This is what happens now when you load 32-bit i386 on modern Mac, hence a large RAM hit, not to mention that every binary also takes double the disk space.)
Chrome was one of the first popular web browsers to use a separate process per tab. This architecture makes 64-bit less necessary because each tab is expected to use less than 2 GB of RAM.
It's not about addressable memory space.
64-bit usually yields better performance due to more registers and the fact that i386 was a register starved architecture.
But more importantly, everything on modern Mac is now 64-bit. Anything that is 32-bit must load in a 32-bit version of every shared system library that the application touches. At a minimum, Firefox would have to load in the entire 32-bit version of the Cocoa frameworks (because Firefox needs to at least create a native window). If Firefox is the only 32-bit app resident on your system (which is highly likely today), then it's wasting gobs of your system RAM and probably making you swap to disk more.
Slashdot Mirror
The OpenGL standards committee had done very little to solve the real problems game/graphics developers had been complaining about for years. Interests in backwards compatibility and CAD were making OpenGL compromise and please nobody.
AMD Mantle drew a lot of attention that something could be done, but too many questions about it such as will it only work on video hardware designed exactly as AMD designed it (and displeasing companies like Nvidia), kept any real advancement from happening.
But Apple Metal shipping last year was a real shot in the arm for Khronos because it finally forced them to do something or become completely irrelevant. (DirectX 12 had also started making noise.) We finally saw it presented at GDC a few months ago in draft/prototype form. What is interesting is Vulkan is a clean break from OpenGL so there is no backwards compatibility interest/attempt.
You can't fault Apple for needing to ship something real, today (actually last year). You can thank Apple for forcing the Khronos committee to finally do something.
The real question is if Vulkan will be usable on Apple platforms in the future, either provided by Apple or built as a wrapper on top of Metal by a 3rd party.
OSX also had accessibility support built in from the beginning. Apple made it a big deal that every computer should be installed with it by default, because it used to be the case in Windows that you had to install support manually, and only one computer in a classroom in the corner would have support. The idea was any child should be able to use any computer.
OSX has been generally good for accessibility for a second reason. Besides user-facing features, Apple's core APIs like Cocoa have accessibility built into to the widgets. When you use standard Cocoa controls from buttons to textviews, Apple already provides useful behaviors for accessibility in them. That way, even if a developer is completely oblivious to accessibility needs, as long as the developer was being a good Mac/iOS citizen, their program automatically inherits accessibility support.
This is where most 3rd party toolkits completely fall down. Cross-platform toolkits, 3rd party web browsers, video games... They reinvent all the GUIs/widgets themselves, *poorly*, and they always miss this aspect. And very few call them on it.
Gatekeeper prevents downloaded applications that are untrusted from accidentally being run. It doesn't prevent trusted applications from doing anything.
Exactly. Mod parent up.
And this is a *good* thing.
Apple has a separate sandboxing and entitlements system for more security. Apple makes apps distributed on the Mac App Store enable sandboxing. But for those apps (usually tools) that can't work within the limitations of the sandbox, developers can still ship outside the Mac App Store and do whatever they want. Code signing for GateKeeper is merely a trust checkbox that it is unlikely the vendor is doing anything really malicious or Apple would revoke their certificate and possibly pursue legal/criminal action for really nefarious activities since Apple gets a paper trail to hunt you down with as part of the process of getting a key to sign with.
If everything was locked down in the name of security, we would be denied all sorts of useful things.
True and not saying Valve should do anything to Nvidia. But alliances are complicated in general and pretty shaky with respect to Microsoft. Remember that Nvidia first held the Xbox contract and now Xbox is AMD based. Also, Microsoft managed to alienate every single one of their old partners by promising not to compete with them in hardware and then did Windows Phone and Surface which pretty much shattered the age old alliances and trust with Intel, Dell, HP, and the rest of the Microsoft cottage industry. CEOs with a memory longer than a goldfish should be wary of actively seeking an alliance with Microsoft because they are scared of some other smaller company that has earned respect from its users.
People already think Apple's walled garden and sandboxing go overboard. Remember that legit developers have to pay Apple $99/year just to develop+run an app on their own device. Apple also has a long list of requirements about what your app not allowed to do. I'd really hate to see what they do if they got *serious* about locking down the platform.
Anybody find it suspicious that at the height of the Snowden/NSA spying revelations, NCIS brings in a sympathetic and pretty NSA agent into the main cast. (And her show's husband is played by Jamie Bamber (Battlestar Galactica), another NSA agent.)
I know the NCIS family of series repeatedly hacks servers illegally and deliberately avoids getting warrants to do so.
Has this guy seen Detroit? You can't distinguish it from a missile strike.
Go buy a Steam Machine. There are already 15 vendors lined up to sell them. These OEMs are betting people are tired of this typical Microsoft BS. Prove them right and buy their machines and support their effort.
That is, unless VMWare sincerely thinks they are in the right and have a defensible case. Then things get very interesting because then there is a chance the GPL could be undermined/weakened if they win and you will see a lot of groups start paying attention to make sure Software Freedom Conservancy doesn't screw up the case for GPL. (And you may see other parties interested in exploiting a weakened GPL.)
Chances are VMWare will eventually just release the bare minimum code in question after they hit a small threshold in legal fees and make the lawsuit moot.
Waiting for somebody else bring up litigation didn't cost VMWare much. They can simply wait until somebody calls them on it, then do the bare minimum to make it go away.
And nobody will continue to press on them because seeking "damages" is really hard to demonstrate in this kind of case and continuing to pay lawyers to try to punish VMWare will be cost prohibitive.
There is also the case law risk that if VMWare does win, the GPL could be weakened/undermined, so there will be a lot of pressure on the plaintiff to not press their luck.
You forgot the MakeRocketLauncherGoNowFactory, the MakeRocketLauncherGoNowFactoryFactory, the MakeRocketLauncherGoNowException, the ...
Exactly. Check out EnterpriseQualityCoding/FizzBuzzEnterpriseEdition for a "proper" example:
https://github.com/EnterpriseQ...
What does Linus Torvalds have to say about all this?
Linus Q&A at Debconf 2014
https://www.youtube.com/watch?...
starts at 18:43
"I think systemd does a lot of things right."
"Systemd gives a lot of features you couldn't get any other way. The boot-up speeds are real. And it's not saying you couldn't get the same things with non-systemd. But systemd stepped up and did it."
"I think the fight is mostly over."
"The lack of portability is sad. The thing I that I absolutely hate is that the bug reports have been basically ignored in some cases."
"I realize people expected me to hate systemd. I don't hate it, really. I think it is somewhat interesting and it has quirks, but what does not?"
Stock holders are forgiving to Apple because they constantly show profits. Even during the dot-com implosion, Apple continued to show growth and profits in their Mac lines as the rest of the PC industry struggled.
Amazon is the opposite. Amazon has never had a profitable quarter. Instead their spending always outstrips their revenue. Stock holders have been amazingly patient because Amazon has been doing this for like 20 years now. But a $170 million write-down is a lot of money (unless you are Microsoft, and they at least have enormous profits to offset their huge billion dollar losses), especially for a company that has never had a profitable quarter.
And this is for a product that everybody sees as outside Amazon's strengths. And the market reaction shows there is little interest and demand for this product, yet Amazon intends to double-down.
Considering it has been over 20 years, I'm surprised Amazon hasn't seen a lot more criticism. Kudos I guess to Amazon's ever-patient shareholders.
You are correct. But there is a much more direct answer to defend Bubble Sort.
In the real world, i.e. on real hardware, bubble sort usually faster than other algorithms for small data sets. This is due to cache locality. A cache miss can mean the difference between 4 clock cycles vs. over 400 cycles, simply waiting for 4 little bytes to be read from RAM.
Cache misses are now the biggest problem for high performance programming. For instance, (good) video game programmers are very aware of this fact.
Agreed. And for the op, Obj-C is the best language to use right now. Being well versed in C means he can learn Obj-C in a day. Obj-C is a very small superset of C.
The hard part is learning Cocoa, but that is true of any framework whether that is Swing, Android, MFC, GNOME, Qt.
Swift is so new, you will have to learn Obj-C anyway to learn Cocoa.
The best bet is for the op to write model/cross-platform code in C, and then use Obj-C for the native UI layer. Then repeat for Android/Java (via JNI) and Windows Phone/C++CX.
But is the ratings decline reflective of revenue or an overall problem with the show? Over the past 10 years, television viewership has been falling in general, losing out to other forms of entertainment.
However, the irony is that the cost for advertising in television is at an all time premium. This is because there is still no other advertising outlet that can capture such a wide audience at the same time with and also with well understood demographics.
I thought Dark Matter was conceived to account for missing matter that the Big Bang theory predicts needs to exist.
48 replies to "DON'T FORCE ME TO UPGRADE!...PLEASE!", where the majority are people trying to help the few that are complaining, does not constitute "swamped".
In contrast there are 471 replies to "I show up as Online when I'm not"
No, this is proof we need autonomous vehicles. Consider the current alternative that these "idiots" are driving.
You can tell Siri to enable VoiceOver for you on iOS.
Suck Blue Frog (Quest for Glory 2)
Command parsers were fun.
The thing that happened was Microsoft started building/selling their own devices, competing directly with their former partners. That was a stab in the back and maybe they actually learned their lesson.
The op complaint was no 64-bit Firefox for Mac. Apple doesn't do x32, so it's not even an option.
Data starvation can be mitigated/manually controlled in 64-bit by understanding your data. High performance code utilizes contiguous blocks of memory and is very aware of data layout, and isn't going to be pointer chasing. So allocating arrays of types that use int32_t instead of int64_t is a trivial example. So in a 64-bit architecture, you still generally win performance-wise.
x32 failed for a lot of reasons. ... to make maintaining an extra ABI worthwhile."
From the article you cited, here's a quote:
"they just really don't see the [x32] ABI as being worthwhile
As the quote highlights, the real crux of the problem is how much of a pain it is to maintain yet another ABI.
The performance differences for x32 didn't justify it over true 64-bit. That means the data starvation due to larger pointer sizes wasn't the dominating factor. So going from i386 to x32 vs. i386 to x64, the latter wins because it gets the speed of more registers, negligible performance impact for pointer size differences, and the plus of large addressable memory if you need it.
To show the pain of another ABI, here is a simplified example: You are using a video editor in GNOME under x32. You suddenly need more than 4GB of addressable memory. That means you needs a x64 version. But then you need a GNOME that is also built as x64, so you have to load up an entirely separate instance of GNOME, all its dependencies, and the video editor. Either you need to shutdown your current environment and reboot another, or you need to load both simultaneously. (This is what happens now when you load 32-bit i386 on modern Mac, hence a large RAM hit, not to mention that every binary also takes double the disk space.)
how about bloody 64bit on mac.?
Chrome was one of the first popular web browsers to use a separate process per tab. This architecture makes 64-bit less necessary because each tab is expected to use less than 2 GB of RAM.
It's not about addressable memory space.
64-bit usually yields better performance due to more registers and the fact that i386 was a register starved architecture.
But more importantly, everything on modern Mac is now 64-bit. Anything that is 32-bit must load in a 32-bit version of every shared system library that the application touches. At a minimum, Firefox would have to load in the entire 32-bit version of the Cocoa frameworks (because Firefox needs to at least create a native window). If Firefox is the only 32-bit app resident on your system (which is highly likely today), then it's wasting gobs of your system RAM and probably making you swap to disk more.