Stepping stones. Windows 8 was a wobbly stepping stone but it was a stepping stone. Dev on MS is much easier to cross over platforms than it was in the past.
But seriously (and I'm not Trolling here):
IMHO, Mobile Applications are, for the most part, very rarely directly translatable in either scope or purpose to Desktop or Server Applications; so what is to be gained by making the poor Developer have to be saddled with a Presentation Layer (GUI) that is an absolute Train-Wreck between Touch and Non-Touch paradigms?
I understand how they can share a common kernel and SOME Frameworks/APIs, and maybe even the (very) occasional GUI concept; but that's where it should end. But it doesn't.
Truth be told, I would bet that not one Application in 1,000 actually benefits more than 10% from a "Unified Codebase". The only product that looks to be designed with this in mind is the Surface Pro 3, And that is not the Game-Changer that Microsoft is touting it to be. Too heavy and expensive for a Tablet; and simply not good enough compared with other Laptops at the same price-point. They keep trying to compare it with Apple's entry-level ultraportable (the one that sacrifices many other things for the sake of "small"; but if you look at the pricing, it should be more-fairly compared with something like a 13 inch Macbook Pro, where these folks say that it loses hands-down.
Nope. I'll give MS some points for trying to rescue Windows 8; but they are suffering from the "Gone too far to go back." syndrome, and it's going to (continue to) bite them, bad. Really bad...
ON the contrary.... insufficient QA = potentially a hundred million functionally broken machines, vs. perhaps 5 nerds with compromised mac web servers exposed to the internet from not pushing it out.
And 15 million more with CUPS Servers running, and possibly exposed to the internet.
I hope that's sarcasm. Every other distro had this fixed last week. Apple are only fixing one instance and leaving it broken elsewhere. They're not at risk anyway, no one uses OS X for hosting.
Speak for yourself. Maybe not too often on a commercial scale; but there are many OS X boxen that have one or more "listeners" a-listenin'.
And didn't I read something about CUPS being possibly an attack vector? That makes it only Every. Single. Mac.
And all it takes is someone not understanding how Port Forwarding works, and going "F-it." I'm just gonna put my machine in my Router's DMZ..."
I'm a big iPhone fan (also, for what it's worth, an engineer) but I also carry an Android device -- a Sony Xperia Z Ultra along with my iPhone 6. I can tell you that when I buy a $900 device, "good enough" doesn't cut it.
You say you are "an engineer"; but are you an ME, a metallurgist, or do you drive a train?
If, by chance, you actually are an engineer that is on a team that produces consumer-level products, can you honestly sit there with a straight face and say that your products are regularly tested to the level demonstrated in the Verge article?
I have designed many products that were to survive in the supposedly much-harsher world of an "industrial environment", and I can tell you that not one of them was subjected to the destructive and non-destructive physical testing that the Verge article showed to which Apple products are being subjected. And I don't think the companies I worked for were the exception in the "lack" of testing. In fact, Apple's testing seems almost over-the-top. Probably why almost all of their products have a (deserved) reputation for being extremely rugged, relative to the competition.
Do I think that they have a minor issue with the strength of the case at the point at which the volume-button punch outs are made? Yeah, probably. Is it worth all the hand-wringing? Definitely not.
1. Jobs wa never known for engineering products for form over function with disastrous results -- i.e. the Apple///, the Lisa, the Cube, etc.
.
Let's take these one-at-a-time:
1. Apple///. According to Woz (who should know), the Apple/// was a victim of the engineering directive (not Jobs', BTW, but a team-consensus) that it must have 100% compatibility with the Apple ][ (a laudable goal); but, the kicker was that it must not allow any of the Apple///'s capabilities to be available when in "Apple ][ Emulation mode". That resulted in massive amounts of extra circuitry (remember, this was 1978 when the Apple/// was being developed) to accomplish that goal. The end result was a design that was beyond the PCB manufacturer's capabilities for the day. There was nothing wrong with the design,per se; it just out-stripped the manufacturing capacities of 1979-80. And by the time the Rev. 3 PCBs came around, it was actually a very solid machine (with an incredibly-advanced OS (AppleSOS)). Unfortunately, by then it was simply too late, market-wise. It is interesting to note that the trace-density that was impossible on the Apple/// PCBs is absolutely trivial these days.
2. The Lisa: Nothing at all wrong with the engineering of the Lisa. It's a damned tank!. Have you ever been inside of a Lisa? Probably the best-engineered computer ever. The only problem with the Lisa was the Price. That, and the fact that it was "too far ahead of its time." Seriously. Next! (no pun)
3. The G4 Cube. This one is all on Jobs. It was made impractical by Jobs' hatred of fans (and before they figured out that fans could be made quiet by making them bigger and turning them slower (duh!), and by doing stuff like uneven spacing of the fan-blades (not so "duh"). And secondarily, it was killed by Jobs' longstanding vision of a small-self-contained computer. But I guess he doesn't get credit for pulling that off again and again in the Mac mini, original G4 iMac (the "Sunflower" iMac), the flat-screen iMacs, the MacBook Air, and most recently, the incredible Mac Pro (which of course had to be well into final phases of design when Jobs died), right? No, no credit at all. And then, let's never forget that it was also Jobs and Apple who pretty-much single-handedly, completely revolutionized the phone and tablet. To deny that is to simply deny reality.
Bottom line: Every single company that produces as many "hi-tech" products, for as many applications, for as many years, as Apple, will have some products that are absolutely great, and some, not so much.
The general consensus that Consumer Reports seems to be getting at here is that the results that they observed shows that while the iPhones do bend, the amount of force required to do so results in phones from other manufacturers simply breaking under the stresses involved.
Doesn't this statement pretty much say it all?
Looking back into the past, there have been great feats of engineering that have stood the tests of time and survived admirably, and a large part of that has been due to being "over engineered" than what was technically required, or from a simple lack of knowledge at the time of what really *needed* to be done to withstand the rigors of severe, gail force winds, earthquakes, or the like.
A friend of mine that was an ME for Delco, said something a long time a long time ago that has always stuck with me: "You can always tell when something is built by someone who doesn't know what they are doing, because it will always be 'over engineered'."
So, I guess it is an entire engineering discipline, not just Apple's engineers, that have "Fallen into the fallacy..."
Did you even read the Verge article, which specifically stated that Apple adds stiffeners, sometimes even made of steel or Titanium, when its destructive, and non-destructive, testing shows that is warranted?
Truth is, you can't fix stupid; nor can you design a series of tests that will duplicate every single scenario that a product will encounter in the "real world". That's not making excuses for Apple; it is just the way it is.
The Verge article clearly demonstrates that Apple has done its Due Diligence; but that it is pretty much impossible to make something that is indestructible.
Oh, and BTW: Where was your Righteous Outrage at the makers of the HTC One (M8), that apparently bends with approximately the same force as the new iPhone? Where was the hand-wringing then?
FYI, Dalvik (no "c") and its successor, ART (Android RunTime) are a version of Java, so no matter what you do, you'll have to rewrite for Java.
There is the option of writing "native" code, but you'll need to compile for ARM, MIPS, and Intel if you want the widest compatibility for your apps.
Hey, my article submission said "Dalvik". Slashdot editors put in the unwanted "c".
Although I am well-versed in C, I have thus-far avoided C++, C# and Java [...]
It's amazing to think there is someone like this in 2014. It's like those stories they used to tell of Japanese soldiers stranded on Pacific Islands, back in the '50s and '60s, who allegedly had no idea WWII had ended. In all honesty, I find it almost easier to believe in the stories about the Japanese soldiers.
Not in the real-time measurement and control world, where the vast amount of my experience lies.
Until very recently (and really only since the advent of the iPhone), Microcontrollers simply didn't have the resources to stand the cycle-stealing overhead of languages like C++; so, the vast majority of devs. that were having to write stuff that had to keep up with the real-world (or else Bad Things would actually happen; not just a Sprite-Draw would be a little late) write in either Assembly and/or C, and most still do.
I still get a chuckle when job requirements for real-time Projects insist on C++. It's usually a sure sign that the requirements were written by HR from a series of Buzzwords; or by a clueless PHB.
As I said, just like the Porn industry drives multimedia capabilities, the smartphone/tablet industry is creating SoCs (can't even call them MCUs anymore!) that, while they are incredibly powerful, are still out of reach, budget and size-wise, for the vast majority of embedded designs.
So, it is you that is an anachronism; because the world you think we live in, and its obligatory Flying Cars, sadly won't exist for another decade, at least. And until then, you are better served as an Embedded Dev. to know C and Assembler, than to know C++, Java, or, quite frankly, any other Object-Oriented Language.
Assembler is the tool. Assembly is the language. You could admit you are the pretender, with hopes and dreams of one day knowing what it is you... pretend to know - Pretender.
No Poser I.
Not to brag, but I have been an Embedded Dev. For over three decades. I have written tens and tens of thousands of lines of Assembly Language for everything from 8 bit 6502 to 32 bit ARM9 Cortex, and everything in between. Various MCUs and CPUs from Microchip, Mot., Zilog, Intel, ST, Atmel, to name but a few. I have personally rewritten 6502 assemblers to cross-assemble for 6809 and 8051. I am experienced in many, many different IDEs, debuggers, ICEs, etc. My specialty is real-time measurement and control systems, with or without RTOSes.
But sometimes, just like the many Nuclear Physicists that still occasionally slip-up and say "Nuke-U-Ler", I occasionally flip the terms "Assembler" and "Assembly".
So, Mr. terminology-Nazi: You are hereby cordially invited to Bite Me.
You are correct, at least partially, Barbara. This IS more of a case of "I have a cool idea..." But I thought I made that clear.
And there is neither the budget nor time to do what you, and others, have suggested; contract it out, as sensible a suggestion as that may be.
But, not every useful App needs a top-notch Developer; and I have been a Developer (and quite often the only one) on enough Projects, for enough disciplines, for enough decades, that I can tell you with confidence that in any reasonable Language, this is a medium-low-complexity Project. The people that have said that I will spend more time mastering the necessary Frameworks than learning whichever Language, are exactly singing to me...
I do, of course, intend to start learning the IDE and APIs (at least for iOS) before I seriously commit to a programming Language; but I just thought I could take advantage of the Collective Intelligence of the Slashdot Community, mainly to see if there was a clear consensus as to whether, at this point in time, there was a clear "winner".
I am intensely grateful that the vast majority of the Posters Responded with thoughtful and non-condescending advice. Too bad you were too busy with your arrogant belittlement and holier-than-thou self-aggrandizement to offer anything worthwhile.
Why not write it in C and ommit Swift/Objective-C?
Perhaps easier to port even, but honestly, if you want to use the Frameworks, try Swift.
There is a reason we have a flodded AppStore market with iOS Apps... Apples tools are 30 years old, granted. But the rest of the industry simply did not catch up since 35 years.
Using a text editor to write code for a device like an iOS device, that simply displays the weather or a stock price is so... 1960s?
OP here. Thanks to everyone for all the wonderful info and suggestions!
I didn't think it was "legal" to target an App Store-bound iOS App in anything but Obj-C and now, Swift. Could I hypothetically write an iOS App in ARM Assembly?
I'm not a huge OOP fan in general; so the more I can avoid the Heartbreak Of OOP, the better.
Are there any resources for learning how to use the CocoaTouch APIs from C?
Christ, this could turn into armageddon. All these morons were duped into thinking they could get rock solid computer systems for free? WHERE DO I SIGN UP! What could possibly go wrong? Using stuff that people whip up at home for no money is a much better idea than using secure systems that experts were paid to design and code correctly. And then I'll load it up with the company and countries and customers most important information. Never. Fucking. Again. Will. I. Trust. Linux. Or any software that I didn't pay for, to store sensitive data. I hope someone starts filing lawsuits against the companies that get hacked for not properly securing their customer's data.
Wow! The Microsofties are out in force today!
This vulnerability also exists in non F/OSS OSes, such as OS X.
And as I posted above, no MS fan should ever mock a vulnerability in another OS.
It's amazing how electronic devices break when the case they are in bends enough.
It's also amazing how metal effectively doesn't bend when you use enough of it. (like my iPhone 5...)
Slashdot Mirror
Stepping stones. Windows 8 was a wobbly stepping stone but it was a stepping stone. Dev on MS is much easier to cross over platforms than it was in the past.
But seriously (and I'm not Trolling here) :
IMHO, Mobile Applications are, for the most part, very rarely directly translatable in either scope or purpose to Desktop or Server Applications; so what is to be gained by making the poor Developer have to be saddled with a Presentation Layer (GUI) that is an absolute Train-Wreck between Touch and Non-Touch paradigms?
I understand how they can share a common kernel and SOME Frameworks/APIs, and maybe even the (very) occasional GUI concept; but that's where it should end. But it doesn't.
Truth be told, I would bet that not one Application in 1,000 actually benefits more than 10% from a "Unified Codebase". The only product that looks to be designed with this in mind is the Surface Pro 3, And that is not the Game-Changer that Microsoft is touting it to be. Too heavy and expensive for a Tablet; and simply not good enough compared with other Laptops at the same price-point. They keep trying to compare it with Apple's entry-level ultraportable (the one that sacrifices many other things for the sake of "small"; but if you look at the pricing, it should be more-fairly compared with something like a 13 inch Macbook Pro, where these folks say that it loses hands-down.
Nope. I'll give MS some points for trying to rescue Windows 8; but they are suffering from the "Gone too far to go back." syndrome, and it's going to (continue to) bite them, bad. Really bad...
When the going gets tough at Microsoft, they fall back on their oldest practices.
C:\WINDOWS>copy Apple
Redmond, Start Your Copiers!
Shouldn't it be called "WinX"?
Then, we'd know it was on par and lock step with Apple's OS going forward.
Don't laugh, that's exactly what they are trying to mimic.
ON the contrary.... insufficient QA = potentially a hundred million functionally broken machines, vs. perhaps 5 nerds with compromised mac web servers exposed to the internet from not pushing it out.
And 15 million more with CUPS Servers running, and possibly exposed to the internet.
I think OSX uses SystemD, so it is INVULNERABLE!
Actually, it uses Apple's own creation, "launchd", which they Open Sourced.
I hope that's sarcasm. Every other distro had this fixed last week. Apple are only fixing one instance and leaving it broken elsewhere. They're not at risk anyway, no one uses OS X for hosting.
Speak for yourself. Maybe not too often on a commercial scale; but there are many OS X boxen that have one or more "listeners" a-listenin'.
And didn't I read something about CUPS being possibly an attack vector? That makes it only Every. Single. Mac.
And all it takes is someone not understanding how Port Forwarding works, and going "F-it." I'm just gonna put my machine in my Router's DMZ..."
Wouldn't carbon fiber be better than aluminum for the phone body? Or is it too expensive from a manufacturing standpoint?
Talk about "Bendy"...
Or maybe Apple should engineer their products better.
Insightful? Really???
I'm a big iPhone fan (also, for what it's worth, an engineer) but I also carry an Android device -- a Sony Xperia Z Ultra along with my iPhone 6. I can tell you that when I buy a $900 device, "good enough" doesn't cut it.
You say you are "an engineer"; but are you an ME, a metallurgist, or do you drive a train?
If, by chance, you actually are an engineer that is on a team that produces consumer-level products, can you honestly sit there with a straight face and say that your products are regularly tested to the level demonstrated in the Verge article?
I have designed many products that were to survive in the supposedly much-harsher world of an "industrial environment", and I can tell you that not one of them was subjected to the destructive and non-destructive physical testing that the Verge article showed to which Apple products are being subjected. And I don't think the companies I worked for were the exception in the "lack" of testing. In fact, Apple's testing seems almost over-the-top. Probably why almost all of their products have a (deserved) reputation for being extremely rugged, relative to the competition.
Do I think that they have a minor issue with the strength of the case at the point at which the volume-button punch outs are made? Yeah, probably. Is it worth all the hand-wringing? Definitely not.
1. Jobs wa never known for engineering products for form over function with disastrous results -- i.e. the Apple ///, the Lisa, the Cube, etc.
.
Let's take these one-at-a-time:
///. According to Woz (who should know), the Apple /// was a victim of the engineering directive (not Jobs', BTW, but a team-consensus) that it must have 100% compatibility with the Apple ][ (a laudable goal); but, the kicker was that it must not allow any of the Apple ///'s capabilities to be available when in "Apple ][ Emulation mode". That resulted in massive amounts of extra circuitry (remember, this was 1978 when the Apple /// was being developed) to accomplish that goal. The end result was a design that was beyond the PCB manufacturer's capabilities for the day. There was nothing wrong with the design,per se; it just out-stripped the manufacturing capacities of 1979-80. And by the time the Rev. 3 PCBs came around, it was actually a very solid machine (with an incredibly-advanced OS (AppleSOS)). Unfortunately, by then it was simply too late, market-wise. It is interesting to note that the trace-density that was impossible on the Apple /// PCBs is absolutely trivial these days.
1. Apple
2. The Lisa: Nothing at all wrong with the engineering of the Lisa. It's a damned tank!. Have you ever been inside of a Lisa? Probably the best-engineered computer ever. The only problem with the Lisa was the Price. That, and the fact that it was "too far ahead of its time." Seriously. Next! (no pun)
3. The G4 Cube. This one is all on Jobs. It was made impractical by Jobs' hatred of fans (and before they figured out that fans could be made quiet by making them bigger and turning them slower (duh!), and by doing stuff like uneven spacing of the fan-blades (not so "duh"). And secondarily, it was killed by Jobs' longstanding vision of a small-self-contained computer. But I guess he doesn't get credit for pulling that off again and again in the Mac mini, original G4 iMac (the "Sunflower" iMac), the flat-screen iMacs, the MacBook Air, and most recently, the incredible Mac Pro (which of course had to be well into final phases of design when Jobs died), right? No, no credit at all. And then, let's never forget that it was also Jobs and Apple who pretty-much single-handedly, completely revolutionized the phone and tablet. To deny that is to simply deny reality.
Bottom line: Every single company that produces as many "hi-tech" products, for as many applications, for as many years, as Apple, will have some products that are absolutely great, and some, not so much.
The general consensus that Consumer Reports seems to be getting at here is that the results that they observed shows that while the iPhones do bend, the amount of force required to do so results in phones from other manufacturers simply breaking under the stresses involved.
Doesn't this statement pretty much say it all?
Looking back into the past, there have been great feats of engineering that have stood the tests of time and survived admirably, and a large part of that has been due to being "over engineered" than what was technically required, or from a simple lack of knowledge at the time of what really *needed* to be done to withstand the rigors of severe, gail force winds, earthquakes, or the like.
A friend of mine that was an ME for Delco, said something a long time a long time ago that has always stuck with me: "You can always tell when something is built by someone who doesn't know what they are doing, because it will always be 'over engineered'."
So, I guess it is an entire engineering discipline, not just Apple's engineers, that have "Fallen into the fallacy..."
Did you even read the Verge article, which specifically stated that Apple adds stiffeners, sometimes even made of steel or Titanium, when its destructive, and non-destructive, testing shows that is warranted?
Truth is, you can't fix stupid; nor can you design a series of tests that will duplicate every single scenario that a product will encounter in the "real world". That's not making excuses for Apple; it is just the way it is.
The Verge article clearly demonstrates that Apple has done its Due Diligence; but that it is pretty much impossible to make something that is indestructible.
Oh, and BTW: Where was your Righteous Outrage at the makers of the HTC One (M8), that apparently bends with approximately the same force as the new iPhone? Where was the hand-wringing then?
Tip: Before you start programming your super awesome iOS project, you should consult a style guide and review when words should be capitalized.
I capitalize to denote proper nouns, and sometimes just for emphasis.
So, how is that helpful for deciding which language I should use?
IOW, bite me.
FYI, Dalvik (no "c") and its successor, ART (Android RunTime) are a version of Java, so no matter what you do, you'll have to rewrite for Java. There is the option of writing "native" code, but you'll need to compile for ARM, MIPS, and Intel if you want the widest compatibility for your apps.
Hey, my article submission said "Dalvik". Slashdot editors put in the unwanted "c".
apple's proprietrary[sic]?languages
So, you, the Great Programmer, thinks that Objective-C is "proprietrary"?
This proves just how little you know...
Thanks. I think that is the most cogent advice yet.
It's amazing to think there is someone like this in 2014. It's like those stories they used to tell of Japanese soldiers stranded on Pacific Islands, back in the '50s and '60s, who allegedly had no idea WWII had ended. In all honesty, I find it almost easier to believe in the stories about the Japanese soldiers.
Not in the real-time measurement and control world, where the vast amount of my experience lies.
Until very recently (and really only since the advent of the iPhone), Microcontrollers simply didn't have the resources to stand the cycle-stealing overhead of languages like C++; so, the vast majority of devs. that were having to write stuff that had to keep up with the real-world (or else Bad Things would actually happen; not just a Sprite-Draw would be a little late) write in either Assembly and/or C, and most still do.
I still get a chuckle when job requirements for real-time Projects insist on C++. It's usually a sure sign that the requirements were written by HR from a series of Buzzwords; or by a clueless PHB.
As I said, just like the Porn industry drives multimedia capabilities, the smartphone/tablet industry is creating SoCs (can't even call them MCUs anymore!) that, while they are incredibly powerful, are still out of reach, budget and size-wise, for the vast majority of embedded designs.
So, it is you that is an anachronism; because the world you think we live in, and its obligatory Flying Cars, sadly won't exist for another decade, at least. And until then, you are better served as an Embedded Dev. to know C and Assembler, than to know C++, Java, or, quite frankly, any other Object-Oriented Language.
Assembler is the tool. Assembly is the language. You could admit you are the pretender, with hopes and dreams of one day knowing what it is you ... pretend to know - Pretender.
No Poser I.
Not to brag, but I have been an Embedded Dev. For over three decades. I have written tens and tens of thousands of lines of Assembly Language for everything from 8 bit 6502 to 32 bit ARM9 Cortex, and everything in between. Various MCUs and CPUs from Microchip, Mot., Zilog, Intel, ST, Atmel, to name but a few. I have personally rewritten 6502 assemblers to cross-assemble for 6809 and 8051. I am experienced in many, many different IDEs, debuggers, ICEs, etc. My specialty is real-time measurement and control systems, with or without RTOSes.
But sometimes, just like the many Nuclear Physicists that still occasionally slip-up and say "Nuke-U-Ler", I occasionally flip the terms "Assembler" and "Assembly".
So, Mr. terminology-Nazi: You are hereby cordially invited to Bite Me.
OP here.
You are correct, at least partially, Barbara. This IS more of a case of "I have a cool idea..." But I thought I made that clear.
And there is neither the budget nor time to do what you, and others, have suggested; contract it out, as sensible a suggestion as that may be.
But, not every useful App needs a top-notch Developer; and I have been a Developer (and quite often the only one) on enough Projects, for enough disciplines, for enough decades, that I can tell you with confidence that in any reasonable Language, this is a medium-low-complexity Project. The people that have said that I will spend more time mastering the necessary Frameworks than learning whichever Language, are exactly singing to me...
I do, of course, intend to start learning the IDE and APIs (at least for iOS) before I seriously commit to a programming Language; but I just thought I could take advantage of the Collective Intelligence of the Slashdot Community, mainly to see if there was a clear consensus as to whether, at this point in time, there was a clear "winner".
I am intensely grateful that the vast majority of the Posters Responded with thoughtful and non-condescending advice. Too bad you were too busy with your arrogant belittlement and holier-than-thou self-aggrandizement to offer anything worthwhile.
Thanks...
Why not write it in C and ommit Swift/Objective-C?
Perhaps easier to port even, but honestly, if you want to use the Frameworks, try Swift.
There is a reason we have a flodded AppStore market with iOS Apps ... Apples tools are 30 years old, granted. But the rest of the industry simply did not catch up since 35 years.
Using a text editor to write code for a device like an iOS device, that simply displays the weather or a stock price is so ... 1960s?
OP here. Thanks to everyone for all the wonderful info and suggestions!
I didn't think it was "legal" to target an App Store-bound iOS App in anything but Obj-C and now, Swift. Could I hypothetically write an iOS App in ARM Assembly?
I'm not a huge OOP fan in general; so the more I can avoid the Heartbreak Of OOP, the better.
Are there any resources for learning how to use the CocoaTouch APIs from C?
It depends largely on weak web-facing CGI pages that don't sanitise inputs before passing them as arguments to a shell script.
So this is the bash rough equivalent to an SQL Injection Exploit?
Christ, this could turn into armageddon. All these morons were duped into thinking they could get rock solid computer systems for free? WHERE DO I SIGN UP! What could possibly go wrong? Using stuff that people whip up at home for no money is a much better idea than using secure systems that experts were paid to design and code correctly. And then I'll load it up with the company and countries and customers most important information. Never. Fucking. Again. Will. I. Trust. Linux. Or any software that I didn't pay for, to store sensitive data. I hope someone starts filing lawsuits against the companies that get hacked for not properly securing their customer's data.
Wow! The Microsofties are out in force today!
This vulnerability also exists in non F/OSS OSes, such as OS X.
And as I posted above, no MS fan should ever mock a vulnerability in another OS.
Ever.
I guess you cocksucking faggots should have used Microsoft Windows Server instead of something as insecure as Linux.
For best results use Microsoft Windows, faggots!
Excuse me: I'm no Linux fan; but I don't think any Microsoft supporter should EVER be crowing about their favorite OS' Vulnerability-Record.
I've had Android devices for quite awhile, I even have CM11 on a couple and no brick problems. Other bugs to be sure, but no bricks.
And when was the last time you received an OS Update for that Android phone?
Well I guess this blows the whole "Apple it just works" argument out of the water. The new slogan can be "Apple we will patch that patch soon".
I seem to remember Microsoft hastily pulling a Windows Patch Tuesday Update recently, because it was Blue Screening a bunch of Computers...
...and there have been other instances, too...
Then the REPLACEMENT patch had KNOWN issues, too!
So, I guess "It happens".
It's amazing how electronic devices break when the case they are in bends enough. It's also amazing how metal effectively doesn't bend when you use enough of it. (like my iPhone 5...)
Oh, how quickly we willfully forget...