They lock my games to a single account and that's about it. In exchange, they backup my saves, backup my games, allow me to install my games wherever I wish, provide me with free voice chat services that I would otherwise have to host or pay for, provide me with awesome deals, etc.
Thanks to Steam promotions alone, my game library there has 273 games that cost me an average of $6 each, so I don't know about you, but $6 per game in addition to all the other advantages is quite a bargain in exchange for their "DRM" that is more permissive than what you can usually find in the retail versions of the same games.
Considering how tiny the Mac library is, I doubt it. Porting from Mac to Linux is relatively easy compared to porting from Windows to anything else, but when you speak of Linux you speak of a number of distributions that do not agree about a number of different things, drivers that lack proper support or adherence to established norms, etc.
Can Canonical make a difference with free software where Apple with its tight control over their platform is failing? I don't think so, BUT don't lose hope yet, the Linux client may just as well be part of a bigger plan: the rumored Valve console with PC hardware and peripherals...
"For starters, all C++ sequence containers implement.at(), which is bounds-checked." Why is that the safe one and not operator[]() ??
The only thing specified by standard C++ regarding operator[] is its semantic (a[n] <=> *(a + n)); everything beyond that is unspecified. Two versions of operator[]() (one const, another mutable) are declared for all sequence containers except std::array, which is intended to work like a raw array when one is expected while supporting an interface that makes it compatible with other C++ containers for use in generic programming (these goals are accomplished by making the raw array inside std::array the first member of the class, thus validating all implicit conversions from std::array<T, N> to T[N]). Since the standard does not specify an implementation for operator[]() beyond the aforementioned semantics, implementations are free to do whatever they wish with the edge cases. On my system (Mac OS X 10.7.4), sequence containers are extended when an out-of-bounds access is performed on a mutable sequence container using operator[](), and I agree with this implementation, not only because it makes containers safe, but also because it does so without duplicating the functionality of at().
"both C11 and C++11 support threads." But the compiler still cannot tell whether you accidentally use some global data structures or not.
Doing so is not the compiler's job because objects can represent all kinds of resources. For example: I can have an object representing a TCP connection, which would be unreasonable to expect a compiler to understand, and that is precisely why object-oriented programming exists, so that objects can take care of themselves.
"Even C++ (which implements those concepts) is deemed unworthy" I also deem it unworthy, but for the reason that it is a portable assembler with very little compile and runtime checking as compared to other languages
And that's where you're wrong. C++ is one of the strongest languages when it comes to static analysis, not only because it is a statically typed language but also because it allows you to perform static generic programming, static reflection, and meta programming IN THE LANGUAGE ITSELF. Regarding the lack of safety, you have already been proven wrong: implementations can make standard containers as "safe" as they wish, the standard provides options that are guaranteed to be safe everywhere, and nothing is stopping you from either using the standard smart pointers or implementing your own.
"I try avoid anything written in Java as much as possible." I do so, too and my posts are not meant to promote Java. Rather, something like a hardened Ada with Destructors. Or something like I did myself: https://sourceforge.net/projects/sappeurcompiler/
The only differences between us is that I am comfortable with a flexible language whereas you have to restrict yourself in order to feel safe, as your arguments about C++ not being safe are completely unfounded.
For starters, all C++ sequence containers implement.at(), which is bounds-checked. Secondly, both C11 and C++11 support threads. Third, I'd laugh my ass off if anyone even attempted to write a kernel using a safer language that doesn't implement pointers or the concepts of auto and static duration. Even C++ (which implements those concepts) is deemed unworthy of kernel-code because of the potential performance issues caused by implicit copy constructors used for type conversions, the consequences of semantically-unconstrained abstraction, and the constant need to ensure that all code is exception-safe.
Higher-level concepts are not problem-free either, XSS, click jacking, and SQL injections are all good examples of security issues related to high-level security concepts. Yes, you can address these problems using frameworks, but in the same way you can address your safety issues in C++ using STANDARD containers and smart pointers, or even implement your own.
Programming languages are general purpose tools, so anything that limits a programmer's ability to shoot himself in the foot, limits the language's usefulness, which is why C remains as popular as it does -- it does not get in your way and it does not hide anything from you.
One last thing: as a user, I try avoid anything written in Java as much as possible. Not because Java can't be fast or reliable but rather because most Java programmers (like most C++ programmers) have so little understanding of the semantic implications of what they're actually doing that they end up generating horribly bloated and unstable messes. Every time I have to deal with an application written in Java, be that a servlet, applet, or stand-alone application, I immediately expect it to either crash or grind to a halt if I behave differently from what most people are expected to behave. The main reasons why Java is successful are because, unlike C++, it has always been pushed into the enterprise world by big-iron companies (Sun and Oracle) and it mimics C++, with each version being more C++-like than the previous.
C++ is perfectly safe if you know what you're doing. The great thing about C++ is that it supports everything without ever getting in your way. Standard containers (including std::string) are perfectly safe; if you do shit, you get an exception, not a core dump.
C++ offers all the advantages of higher level language in a language at the same conceptual level as C, which is important for debugability, as the number of tools available to analyze, debug, and profile machine code is far greater than the number of tools available to debug, profile, and analyze byte code; and while you can claim that Java can be compiled to machine code, it differs from C or C++ in that it demands so much from its abstract machine that its own core can not function without a runtime, meaning almost all interactions with the hardware itself have to go through that runtime thus making it much harder to debug without tools specifically designed to understand the runtime.
You can write functional, declarative, statically typed, dynamically typed, event-driven, object-oriented, reflective, and meta code using C++, but you can't do most of these using Java. You can even implement your own allocators, smart pointers with specific garbage collection algorithms, and safe containers with it (if the standard ones aren't good enough for you) without needing another language, and you can link directly with machine object code from other compiled languages as well as export your own functions into libraries usable by other programs. The only thing you can't do very well in C++ is weak typing, but Objective-C++ has that covered, too...
The only problem with C++ are the people who do not really understand the language and approach it as if it was C with objects instead of a completely new language partially compatible with C.
Yeah, and tools have safety standards too. Just because you accept the risk of a car crash when you buy a car doesn't mean you have to accept the risk of your car spontaneously exploding.
That kind of safety is already available in modern implementations in the form of buffer canaries, randomized memory maps, read/write/execute memory protections, and managed memory allocations that are nearly transparent to the users. This is analogous to your car example, in which safety features exist in order to mitigate the negative consequences of a crash but not to limit its functionality.
Furthermore, there are extremely complex problems for which there isn't even a clearly good engineering solution, such as concurrent programming. While an object-oriented programming language would have enough information to assume the safest option (resource locking), such an assumption would prevent you from taking advantage of the benefits of a transactional implementation. The same kind of complication arrises when multiple processes are sharing resources and communicating with each other, in which case you are required to inform your implementation that all shared resources are volatile and take back control of ownership logic, because under such conditions your implementation no longer has enough information to understand the complexity of the entire IPC solution. Speaking of object-oriented programming, while it's a very solid option for synchronous programming, it sucks for asynchronous programming, which is best tackled by event-driven programming, because the object-oriented model is not designed to deal with asynchronous error conditions due to its inability to raise exceptions asynchronously. Speaking of exceptions, while developing under an object-oriented model, you re always required to ensure that all your code is exception-safe, because an unhandled exception during the execution of an instance function can potentially leave an object in an invalid state with no way to recover from that state or generate a relevant exception (required for proper error signaling and self-destruction). It is why you have signals, which are essentially asynchronous exceptions, but signals carry their own problems, a bit like exceptions you need to ensure that everything you call from within a signal handler is reentrant, you may also need to ensure that the signal handler itself is reentrant (if signals are not being deferred while the signal handler is running), and that any global variables changed by a signal handler are volatiles of atomic types, which again requires control.
As you can see, things aren't that simple. Software engineering is a complex monster, and that's why I love it.
You can set it up so that "clicking" with one finger at either of the bottom corner while dragging another over the trackpad does the right-click drag. While you can claim that such a multi-touch gesture is far from being ergonomic, you are exposed to the same kind of interface with a regular touchpad. In any conceivable case, Apple's trackpads surpass everyone else's.
Can you eat with a clean conscience? Living beings are being killed (or prevented from being born) just so you can enjoy a meal! Can you breathe with a clean conscience? Your breathe is polluting the air!
Be rational and don't stress over things beyond your control. If you wish to change the world, seek the power to actually control those things from the top and prove your worth, otherwise just enjoy the convenience of what you have today, because you're only harming yourself by not doing it.
Your post makes no sense. The only reason why they make any money from Apple at all is because Safari defaults to Google for search, nothing else; the interface doesn't change the slightest if you choose Yahoo or Bing instead. They aren't redefining anything, or influencing Apple in any way that's positive to them. As a matter of fact, they are actually antagonizing Apple, to the point that Siri has been implemented with Wolfram Alpha as its backend and Google Maps is slowly getting ditched in favor of both OpenStreetMaps and Apple's own maps, because Google's licensing is making it impossible for Apple to implement a decent Maps app.
Even indirectly, they profit more from iOS, a platform that they don't even waste resources developing. As far as business is concerned, Android is nonsense, they could be doing much better by partnering with Apple rather than antagonizing them.
Find My iPhone can be easily disabled if the phone itself is not locked. Being off is not an issue, because it'll signal its location as soon as it's connected when the option is enabled, but if you just disable the service in iCloud's preferences, or log off from iCloud entirely, then it won't be tracked. Find My iPhone is nowhere close to being the privacy threat that everyone who never actually used it makes it out to be.
No, you couldn't say that, how playerhost.dll got onto your home directory was you saved it there. And even if it was a Linux executable you would still have to perform a numbr of steps to get it to run, as well as supply the root password.
No, I did not save it there, notice the name "c:\playerhost.dll", it was clearly saved by an exploit to the browser or a plugin running on it (most likely Flash). Also, where the hell does your idea that root is needed in order to run executables come from?
Regarding Flash losing support on Linux, I may have been misconceived as I might have gotten it confused with Adobe AIR.
Your train of thought crashed as soon as you failed to realize the difference between research and production. It is perfectly OK to research one platform while using another, there is absolutely nothing wrong with that. I have developed the Linux kernel in the past and that hasn't stopped me from turning into an Apple fag. My understanding of how operating systems work does not make me want to tinker them all, quite the opposite. I am perfectly fine when things just work, that is my goal as an engineer.
Haven't been using Linux for long, have you? I've had such things happen to me in the past, they were just targeted at Windows, but that didn't stop files named like c:\playerhost.dll from ending up in my home directory, on Linux. I guess you can say that I was saved by Linux's lack of popularity on the desktop, nothing else.
You can claim that many of those vulnerabilities are gone now that Adobe has stopped developing Flash for Linux (as well as for mobile platforms), that address spaces are randomized, that compilers have evolved to generate hardened code by default, and that x86 now supports non-executable pages within code segments, but that's not always been the case, and if you're going to judge Windows for what it was, what it did, and what it does, then at least be unbiased in your judgement.
Aerodynamics. A model T with a modern engine would lack adherence and potentially lift off at higher speeds. Beyond safety, aerodynamics also improve fuel efficiency, which is why these designs continue to be tweaked. There is obviously room for esthetics, but the main motivation for today's car designs are aerodynamics..
As I understand it, it was Microsoft that pushed for ActiveSync support on the iPhone, in order to keep themselves relevant against RIM's threat at the time. Don't take my word for it, though.
It's not about idealism, it's about the negative attitude clouding your judgement. As an idealist, I spend my energy demonstrating the strengths of my ideals, not the weaknesses of everyone else's, because this is the only way I can actually contribute with something with the world while respecting people's freedom (which includes the freedom to disagree with me).
If you think you can do better than Apple, by all means go out there and do it! If you have a problem with others using Apple, then I encourage you to introspect about your stance on freedom.
A single example out of how many for Android? The article does not claim that there is no malware for the iPhone, so pointing out a single example does not refute anything.
Wow! What a fair and unbiased comparison! A year old iOS version that anyone with an at least 3 year old iPhone could and should have upgraded from, versus the latest Android version that most people can't upgrade to! Rated Insightful, of course, because there's a lot of circle jerk insight in that nonsense of a post!
This is not even to mention that the article has nothing to do with the security of the platform itself but rather its exposure to malware, but hell, let us make it about security and debate the merits of each platform, shall we?
I find it interesting how ignorant some Android fanboys are regarding iOS' sandbox, which is extremely restrictive and does not, by design, allow apps to do anything too fishy even if all permissions are granted. At most an app may be able to pull up your contacts without your permission or access call information, but not much beyond that without the user being notified unless they pierce through the sandbox. An app can't keep itself running in the background for longer than 10 minutes (unless specific profiles that permit so are chosen and approved by Apple for each app), run any kind of code not present during the approval process (meaning it's not OK to download code unless it's an in-app purchase, which may be free, and this includes interpreting code other than HTML and Javascript on Safari, which is why emulators are not permitted), launch or interact directly with other applications unless they register themselves as resource handlers (even running a secondary executable within your own application will result in iOS completely obliterating it without even bothering to inform any attached debuggers of what happened).
In essence, the article hits the spot by claiming that it is the screening process and its walled gardens that keep the nastiness away. It's simply not worth developing malware for iOS, you don't have much to gain by doing it, either you pierce through the sandbox and your app will be rejected (with potential consequences to your developer and / or publisher certificates) or you can be easily detected by any user. There are exceptions, of course, but compared to Android, they are very few in number.
It has often been remarked that MS dominance was obtained not so much through the success of MS but through the failure of everyone else. Read Apple, IBM and the various home computer makers whose names are lost in the mists of time only remembered by the senile elders.
Typing this from a mid-2011 iMac, with a late-2011 MacBook Pro on my right serving as TV.
And through their failure, we gained the Wintel platform which now turns out to have been insanely open. Imagine MS telling Windows developers how to collect payment, if at all. Does MS tell Blizzard how to collect its pound of flesh of the enslaved? How shareware should be payed for?
Not Blizzard, but they do tell that to console developers, and players pay the royalty tax.
It is not as if MS never tried but it failed so often nobody took them to serious and so the evil that might have happened, never happened. It is like a brutal dictator whose brutality ends up as a kind of cute outburst with throwing chairs instead of the millions dead with efficient dictators. A dictator who fails at being terrible sounds a lot better then a dictator who succeeds... and Apple and Google are certainly trying hard enough.
They've actually never tried it on the PC. While they've been toying with the idea since 2002 (Google "Microsoft Palladium site:epic.org"), it is only now that the conditions are right for Microsoft to actually try it out on the PC, starting with Windows 8.
When you get the phone call to pick up your already boxed personal effects from the guard at the gate, you'll re-evaluate the confidence in that statement.
I won't, I am 95.2% disabled, I can justify my hardware choices and it only takes a little resistance from IT for my responsibilities to be waived. Companies are entitled to benefits for employing me, and as the saying goes: Money talks; bullshit walks.;)
But that doesn't mean any joker who thinks he's smart can just go and violate all policies, bypass all security measures and put the entire corporate network at risk.
The joke's on the policies, as the company was already at risk. It is WRONG to trust mobile devices, PERIOD, so if you're going to do it for whatever reason, at least do it transparently. Nobody's bypassing security that never existed to begin with.
Regarding attempting to connect to a corporate network? Yes, he would know, automatically, and with very little effort, provided that their network is configured appropriately.
We're talking about laptops here. There's nothing on a corporate laptop that I can't emulate on my own. Sorry to tell you, but you're clueless.
And yes, you could get around it, or attempt to, but you might be found out in the attempt.
Slashdot Mirror
They lock my games to a single account and that's about it. In exchange, they backup my saves, backup my games, allow me to install my games wherever I wish, provide me with free voice chat services that I would otherwise have to host or pay for, provide me with awesome deals, etc.
Thanks to Steam promotions alone, my game library there has 273 games that cost me an average of $6 each, so I don't know about you, but $6 per game in addition to all the other advantages is quite a bargain in exchange for their "DRM" that is more permissive than what you can usually find in the retail versions of the same games.
Considering how tiny the Mac library is, I doubt it. Porting from Mac to Linux is relatively easy compared to porting from Windows to anything else, but when you speak of Linux you speak of a number of distributions that do not agree about a number of different things, drivers that lack proper support or adherence to established norms, etc.
Can Canonical make a difference with free software where Apple with its tight control over their platform is failing? I don't think so, BUT don't lose hope yet, the Linux client may just as well be part of a bigger plan: the rumored Valve console with PC hardware and peripherals...
The only thing specified by standard C++ regarding operator[] is its semantic (a[n] <=> *(a + n)); everything beyond that is unspecified. Two versions of operator[]() (one const, another mutable) are declared for all sequence containers except std::array, which is intended to work like a raw array when one is expected while supporting an interface that makes it compatible with other C++ containers for use in generic programming (these goals are accomplished by making the raw array inside std::array the first member of the class, thus validating all implicit conversions from std::array<T, N> to T[N]). Since the standard does not specify an implementation for operator[]() beyond the aforementioned semantics, implementations are free to do whatever they wish with the edge cases. On my system (Mac OS X 10.7.4), sequence containers are extended when an out-of-bounds access is performed on a mutable sequence container using operator[](), and I agree with this implementation, not only because it makes containers safe, but also because it does so without duplicating the functionality of at().
Doing so is not the compiler's job because objects can represent all kinds of resources. For example: I can have an object representing a TCP connection, which would be unreasonable to expect a compiler to understand, and that is precisely why object-oriented programming exists, so that objects can take care of themselves.
And that's where you're wrong. C++ is one of the strongest languages when it comes to static analysis, not only because it is a statically typed language but also because it allows you to perform static generic programming, static reflection, and meta programming IN THE LANGUAGE ITSELF. Regarding the lack of safety, you have already been proven wrong: implementations can make standard containers as "safe" as they wish, the standard provides options that are guaranteed to be safe everywhere, and nothing is stopping you from either using the standard smart pointers or implementing your own.
The only differences between us is that I am comfortable with a flexible language whereas you have to restrict yourself in order to feel safe, as your arguments about C++ not being safe are completely unfounded.
For starters, all C++ sequence containers implement .at(), which is bounds-checked. Secondly, both C11 and C++11 support threads. Third, I'd laugh my ass off if anyone even attempted to write a kernel using a safer language that doesn't implement pointers or the concepts of auto and static duration. Even C++ (which implements those concepts) is deemed unworthy of kernel-code because of the potential performance issues caused by implicit copy constructors used for type conversions, the consequences of semantically-unconstrained abstraction, and the constant need to ensure that all code is exception-safe.
Higher-level concepts are not problem-free either, XSS, click jacking, and SQL injections are all good examples of security issues related to high-level security concepts. Yes, you can address these problems using frameworks, but in the same way you can address your safety issues in C++ using STANDARD containers and smart pointers, or even implement your own.
Programming languages are general purpose tools, so anything that limits a programmer's ability to shoot himself in the foot, limits the language's usefulness, which is why C remains as popular as it does -- it does not get in your way and it does not hide anything from you.
One last thing: as a user, I try avoid anything written in Java as much as possible. Not because Java can't be fast or reliable but rather because most Java programmers (like most C++ programmers) have so little understanding of the semantic implications of what they're actually doing that they end up generating horribly bloated and unstable messes. Every time I have to deal with an application written in Java, be that a servlet, applet, or stand-alone application, I immediately expect it to either crash or grind to a halt if I behave differently from what most people are expected to behave. The main reasons why Java is successful are because, unlike C++, it has always been pushed into the enterprise world by big-iron companies (Sun and Oracle) and it mimics C++, with each version being more C++-like than the previous.
C++ is perfectly safe if you know what you're doing. The great thing about C++ is that it supports everything without ever getting in your way. Standard containers (including std::string) are perfectly safe; if you do shit, you get an exception, not a core dump.
C++ offers all the advantages of higher level language in a language at the same conceptual level as C, which is important for debugability, as the number of tools available to analyze, debug, and profile machine code is far greater than the number of tools available to debug, profile, and analyze byte code; and while you can claim that Java can be compiled to machine code, it differs from C or C++ in that it demands so much from its abstract machine that its own core can not function without a runtime, meaning almost all interactions with the hardware itself have to go through that runtime thus making it much harder to debug without tools specifically designed to understand the runtime.
You can write functional, declarative, statically typed, dynamically typed, event-driven, object-oriented, reflective, and meta code using C++, but you can't do most of these using Java. You can even implement your own allocators, smart pointers with specific garbage collection algorithms, and safe containers with it (if the standard ones aren't good enough for you) without needing another language, and you can link directly with machine object code from other compiled languages as well as export your own functions into libraries usable by other programs. The only thing you can't do very well in C++ is weak typing, but Objective-C++ has that covered, too...
The only problem with C++ are the people who do not really understand the language and approach it as if it was C with objects instead of a completely new language partially compatible with C.
That kind of safety is already available in modern implementations in the form of buffer canaries, randomized memory maps, read/write/execute memory protections, and managed memory allocations that are nearly transparent to the users. This is analogous to your car example, in which safety features exist in order to mitigate the negative consequences of a crash but not to limit its functionality.
Furthermore, there are extremely complex problems for which there isn't even a clearly good engineering solution, such as concurrent programming. While an object-oriented programming language would have enough information to assume the safest option (resource locking), such an assumption would prevent you from taking advantage of the benefits of a transactional implementation. The same kind of complication arrises when multiple processes are sharing resources and communicating with each other, in which case you are required to inform your implementation that all shared resources are volatile and take back control of ownership logic, because under such conditions your implementation no longer has enough information to understand the complexity of the entire IPC solution. Speaking of object-oriented programming, while it's a very solid option for synchronous programming, it sucks for asynchronous programming, which is best tackled by event-driven programming, because the object-oriented model is not designed to deal with asynchronous error conditions due to its inability to raise exceptions asynchronously. Speaking of exceptions, while developing under an object-oriented model, you re always required to ensure that all your code is exception-safe, because an unhandled exception during the execution of an instance function can potentially leave an object in an invalid state with no way to recover from that state or generate a relevant exception (required for proper error signaling and self-destruction). It is why you have signals, which are essentially asynchronous exceptions, but signals carry their own problems, a bit like exceptions you need to ensure that everything you call from within a signal handler is reentrant, you may also need to ensure that the signal handler itself is reentrant (if signals are not being deferred while the signal handler is running), and that any global variables changed by a signal handler are volatiles of atomic types, which again requires control.
As you can see, things aren't that simple. Software engineering is a complex monster, and that's why I love it.
You can set it up so that "clicking" with one finger at either of the bottom corner while dragging another over the trackpad does the right-click drag. While you can claim that such a multi-touch gesture is far from being ergonomic, you are exposed to the same kind of interface with a regular touchpad. In any conceivable case, Apple's trackpads surpass everyone else's.
Can you eat with a clean conscience? Living beings are being killed (or prevented from being born) just so you can enjoy a meal! Can you breathe with a clean conscience? Your breathe is polluting the air!
Be rational and don't stress over things beyond your control. If you wish to change the world, seek the power to actually control those things from the top and prove your worth, otherwise just enjoy the convenience of what you have today, because you're only harming yourself by not doing it.
Your post makes no sense. The only reason why they make any money from Apple at all is because Safari defaults to Google for search, nothing else; the interface doesn't change the slightest if you choose Yahoo or Bing instead. They aren't redefining anything, or influencing Apple in any way that's positive to them. As a matter of fact, they are actually antagonizing Apple, to the point that Siri has been implemented with Wolfram Alpha as its backend and Google Maps is slowly getting ditched in favor of both OpenStreetMaps and Apple's own maps, because Google's licensing is making it impossible for Apple to implement a decent Maps app.
Even indirectly, they profit more from iOS, a platform that they don't even waste resources developing. As far as business is concerned, Android is nonsense, they could be doing much better by partnering with Apple rather than antagonizing them.
Find My iPhone can be easily disabled if the phone itself is not locked. Being off is not an issue, because it'll signal its location as soon as it's connected when the option is enabled, but if you just disable the service in iCloud's preferences, or log off from iCloud entirely, then it won't be tracked. Find My iPhone is nowhere close to being the privacy threat that everyone who never actually used it makes it out to be.
No, I did not save it there, notice the name "c:\playerhost.dll", it was clearly saved by an exploit to the browser or a plugin running on it (most likely Flash). Also, where the hell does your idea that root is needed in order to run executables come from?
Regarding Flash losing support on Linux, I may have been misconceived as I might have gotten it confused with Adobe AIR.
Your train of thought crashed as soon as you failed to realize the difference between research and production. It is perfectly OK to research one platform while using another, there is absolutely nothing wrong with that. I have developed the Linux kernel in the past and that hasn't stopped me from turning into an Apple fag. My understanding of how operating systems work does not make me want to tinker them all, quite the opposite. I am perfectly fine when things just work, that is my goal as an engineer.
Haven't been using Linux for long, have you? I've had such things happen to me in the past, they were just targeted at Windows, but that didn't stop files named like c:\playerhost.dll from ending up in my home directory, on Linux. I guess you can say that I was saved by Linux's lack of popularity on the desktop, nothing else.
You can claim that many of those vulnerabilities are gone now that Adobe has stopped developing Flash for Linux (as well as for mobile platforms), that address spaces are randomized, that compilers have evolved to generate hardened code by default, and that x86 now supports non-executable pages within code segments, but that's not always been the case, and if you're going to judge Windows for what it was, what it did, and what it does, then at least be unbiased in your judgement.
Aerodynamics. A model T with a modern engine would lack adherence and potentially lift off at higher speeds. Beyond safety, aerodynamics also improve fuel efficiency, which is why these designs continue to be tweaked. There is obviously room for esthetics, but the main motivation for today's car designs are aerodynamics..
As I understand it, it was Microsoft that pushed for ActiveSync support on the iPhone, in order to keep themselves relevant against RIM's threat at the time. Don't take my word for it, though.
It's not about idealism, it's about the negative attitude clouding your judgement. As an idealist, I spend my energy demonstrating the strengths of my ideals, not the weaknesses of everyone else's, because this is the only way I can actually contribute with something with the world while respecting people's freedom (which includes the freedom to disagree with me).
If you think you can do better than Apple, by all means go out there and do it! If you have a problem with others using Apple, then I encourage you to introspect about your stance on freedom.
That didn't stop them from comparing it to the latest version of Android, though...
A single example out of how many for Android? The article does not claim that there is no malware for the iPhone, so pointing out a single example does not refute anything.
Wow! What a fair and unbiased comparison! A year old iOS version that anyone with an at least 3 year old iPhone could and should have upgraded from, versus the latest Android version that most people can't upgrade to! Rated Insightful, of course, because there's a lot of circle jerk insight in that nonsense of a post!
This is not even to mention that the article has nothing to do with the security of the platform itself but rather its exposure to malware, but hell, let us make it about security and debate the merits of each platform, shall we?
I find it interesting how ignorant some Android fanboys are regarding iOS' sandbox, which is extremely restrictive and does not, by design, allow apps to do anything too fishy even if all permissions are granted. At most an app may be able to pull up your contacts without your permission or access call information, but not much beyond that without the user being notified unless they pierce through the sandbox. An app can't keep itself running in the background for longer than 10 minutes (unless specific profiles that permit so are chosen and approved by Apple for each app), run any kind of code not present during the approval process (meaning it's not OK to download code unless it's an in-app purchase, which may be free, and this includes interpreting code other than HTML and Javascript on Safari, which is why emulators are not permitted), launch or interact directly with other applications unless they register themselves as resource handlers (even running a secondary executable within your own application will result in iOS completely obliterating it without even bothering to inform any attached debuggers of what happened).
In essence, the article hits the spot by claiming that it is the screening process and its walled gardens that keep the nastiness away. It's simply not worth developing malware for iOS, you don't have much to gain by doing it, either you pierce through the sandbox and your app will be rejected (with potential consequences to your developer and / or publisher certificates) or you can be easily detected by any user. There are exceptions, of course, but compared to Android, they are very few in number.
Typing this from a mid-2011 iMac, with a late-2011 MacBook Pro on my right serving as TV.
Not Blizzard, but they do tell that to console developers, and players pay the royalty tax.
They've actually never tried it on the PC. While they've been toying with the idea since 2002 (Google "Microsoft Palladium site:epic.org"), it is only now that the conditions are right for Microsoft to actually try it out on the PC, starting with Windows 8.
I won't, I am 95.2% disabled, I can justify my hardware choices and it only takes a little resistance from IT for my responsibilities to be waived. Companies are entitled to benefits for employing me, and as the saying goes: Money talks; bullshit walks. ;)
TLDR: I own your ass.
Sounds like you are more interested in punishing people than securing your networks... Your priorities are upside down.
The joke's on the policies, as the company was already at risk. It is WRONG to trust mobile devices, PERIOD, so if you're going to do it for whatever reason, at least do it transparently. Nobody's bypassing security that never existed to begin with.
We're talking about laptops here. There's nothing on a corporate laptop that I can't emulate on my own. Sorry to tell you, but you're clueless.
ORLY?