He's a very accomplished businessman with a record of stealing his way to the top, then buying or squashing the competition to stay there. And the company that brought you pain while it raked in billions through (oft-forced) sales of an unstable, unsecure os is now bullying Android phone manufacturers with legal tomfoolery. If Bill or MS happen to do something to benefit humanity we can recognize that. But the character of this man and his still-abusive empire shouldn't be white-washed when he happens to share a reasonable opinion. Perhaps rather than trying his hand at solving energy and social problems, he should use his money to undo the problems he created in technology.

Well said.

Add to this Apple's strict control of the app store and you have strong incentives to avoid this platform. As a developer, I want the success or failure of my applications to be determined by users as much as possible: I want to diminish the possibility that a controlling entity might eliminate my chances for success. Apple has shown that they are willing to block apps from the market, whimsically remove them, rip them off, or eliminate the niche in which an app succeeds. Developers should opt for alternatives.

Another, and related, reason to avoid Apple's platforms is that they're closed. Open platforms allow for for independent security and other code reviews, and for creative extension. This makes the platform available to groups that have strict security requirements (governments and others) and groups that aim to customize the platform before adopting it. Rather than relying on a single party to keep a proprietary and tightly-controlled platform alive for your app, you allow any group to whom the platform can be useful to maintain it.

... best damned Slashdot comment ever

... and

We should probably give you the benefit of the doubt here because you're pissed off, but you sound like an idiot.

If you're silly enough to destroy your Linux system 3 times with the same steps, and expect that if your Linux server admin buddies can't fix your graphical video-playing problem then no one can, then you're doing it wrong. To conclude that the whole operating system (even though you only mentioned the kernel, you probably meant GNU/Linux + Xorg + Gnome ...) is shit on this basis is also really, really stupid. Next time you post something, you may want to try harder to not sound so much like a dumbass.

No, this Apple policy should prevent people from running their software at all. I don't understand how developers can stomach Apple's modes of control: that the company won't allow their systems to be virtualized, if only for development testing, is egregious. Open standards and free use of software are what have made possible a lot of the technology we rely upon today. Disallowing even virtualization of a proprietary OS is much further than even Microsoft will go.

We need to demand openness from software companies. When a company like Apple doesn't want to participate in this, people (especially developers) should avoid the company's products. Choose to run one of the many fine open systems (Openindiana, BSD, or a Linux distribution), and tell this company to shove it.

>> If you read to the bottom of your own link, FDE works in iSO4.x. The device is properly encrypted, and can be remote wiped as needed.

From the article:

The Apple iPhone can’t fully satisfy the requirements. People should understand that the iPhone 3GS fails to provide full disk encryption (FDE) which renders useless by how the phone manages the protection of the encryption key [4] and that the authentication model for the FDE is also broken.[see recent update].

If there's one thing Apple is not, it's enterprise. iPods, iPads, iPhones and even mac OS are all consumer-grade products designed with the aim to fuse gucci-like sex appeal with simple usability. Where does security, stability, and manageability fit into this? Selling style, luxury, and limited functionality (for the sake of ease of use) has always been Apple's niche and it's worlds away from enterprise-grade software and hardware.

Consider HP SANs or the Solaris operating system: these are highly-manageable, dependable, secure enterprise products. They make up infrastructure that must be relied-upon. The companies who make them provide expert support to ensure proper setup and continuous service. They are complex and well-engineered. These are not qualities of Apple products.

Of utmost importance for enterprise users is security. It seems that Apple often botches this. Consider just the security problems with iPhones that have been discovered in the last year. We learned that iPhone email security is farcical and that their on-disk encryption doesn't really work (c.f. http://marienfeldt.wordpress.com/2010/03/22/iphone-business-security-framework/). We also saw remote execution flaws (http://securitytracker.com/alerts/2010/Sep/1024413.html), and Apple's mishandling of iPhone PKI (http://cryptopath.wordpress.com/2010/01/).

And security isn't the only feature of enterprise hardware and software that is divested by Apple. Apple's software often lacks any remote management software, let alone robust tools for this. Dependability, too, is often not a feature of their products.

To claim that Apple's products can serve the enterprise customer seems ludicrous. I would hope that, over time, the features of well-engineered enterprise products find their way into consumer-level products; deploying Apple products in the enterprise seems to transplant the flaws, shortcomings, and hassle of consumer products into the enterprise. Who desires this?

Your rosy view of an optimized python VM in the future seems to discard current thoughts by the experts about the feasibility of just that:

http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e

And you want to assume that I don't know Python (or "newer" languages). First, I write Python and like it very much for the tasks to which it's suited. Second, Python isn't new, it's been around longer than Java. My argument from the beginning has been that, generally, viable replacements for Java don't exist; specifically, Python can't do Java's job and from the post I linked, it looks like it can't be made to, and for good reasons. This is fine with me, I don't expect Python to do Java's job; it's uninformed people like you who think it can.

Of course python uses an intermediate step (compiling to bytecode and then interpreting that), this optimization step is common in many high-level, interpreted languages. But there are tremendous differences between the JVM and Python's interpreter. A lot of JVM features that are unmatched by Python's interpreter (and other runtimes) are listed in my first post. So, yes, I understand that Python's source code isn't interpreted straight-up, and I also understand that in a strict sense we can say that cpython has a "VM" and that's what executes .pyc files. But it is equivocation to use this loaded term "VM" to conclude that Python's execution environment has the same features as Java's. The fact is that they're much, much different and the differences are essential.

Python's compilation and execution environment are largely the result of the necessity to improve Python's performance, not part of the runtime's security model (as in Java's), and certainly not to provide a common platform for varying languages, which has also shaped Java's VM (c.f. the success of Scala). Java's VM is a robust platform with all of the features I mentioned already and many, many more. Where are the analogs in Python? They largely don't exist, and to invoke the word "VM" and toss a "Python compiles to bytecode too!" volley in the argument doesn't diminish this fact.

It's convenient that the very VM feature you've picked out, JIT, has a mature, stable, efficient, implementation in Java and nothing of the sort in Python. Psyco is an old, near-dead project without a 64bit version. Other attempts at this, pypy, and unladen swallow to name a few, are immature at least.

I really like Python and I think it is a great tool for a lot of jobs, but it wasn't designed to do the job Java was designed to do, and this includes JVM features that are often ignored. Your arguments prove this out: you're willing to advocate the use of Python instead of Java despite its lack of security, and other essential features given by the JVM. You'll even argue that because Python has a "VM" that it really is enough like Java that there isn't a need for that old JVM. Nonsense.

Python, specifically, is crippled by an old-school interpreter unless you're talking about jython which uses the JVM. To get the features of the JVM that my post argues are essential when picking a replacement for Java, you must run python on Java's JVM! I fail to see how jython can be an alternative to the JVM when it uses it ...

Again, this isn't about the differences between the Java *language* and the Python *language*. The difference (as I argued before) is in the JVM: Python's (or Ruby's or whatever) code could be the prettiest code around but I still can't use it instead of Java because it doesn't have the features I mentioned.

Yours is precisely the kind of silly anti-Java argument I find ridiculous: it doesn't even approach the point.

I'm sick of reading slashdot stories and comments that compare dissimilar languages with Java. What makes Java interesting, useful, and modern is the JVM; these comparisons between language features alone are ridiculous. Most of the languages suggested as alternatives in Java-related posts in the last month are merely interpreted. Python, ruby, perl, etc. are all modernish, high-level languages with dynamic typing. They all run (primarily) on their slow, crippled interpreters. This has numerous drawbacks including problematic multithreading (c.f. the arguments about python's GIL and workarounds over the years), if it's even attempted (in perl, separate processes are the only reliable way to do concurrent programming).

And now Slashdot compares Go to Java. Go is certainly interesting, but it's not in the same space as Java. Java is a portable, networked, object-oriented *application* language. It removes a lot of hassles not necessary to tinker with when writing applications. It has useful, established APIs (servlets, EJBs) for building large-scale enterprise applications. Go compiles to machine code and is therefore not portable. Go doesn't allow inheritance. Go is a language that tries to solve a different problem than Java has solved. Go is no replacement.

Java is by no means the end of all languages and runtimes, but it has set the bar pretty high. It would be wonderful for other projects to adopt Java's features and improve and extend them. It'd be awesome if such an efforts weren't completely nullified by having Microsoft as its boss.

For the naive (and the dude who argues that python is a suitable replacement for Java), below is a list of features Java provides:

Java's JVM does true multithreading. The memory model is tight, efficient, and predictable. The language includes useful mechanisms for writing for concurrency (everything from traditional locking mechanisms to concurrent data structures and the convenient "synchronized" keyword). Productive, predictable concurrency is possible in Java and not in many other languages.

The JVM offers other benefits, including security. The class verifier can sort out malicious code before it's executed. The class loader can check roles granted to a piece of code and a cryptographic signature and decide not to run code on that basis. Even if a piece of code gets loaded and executed, it's sandboxed. Talking about these features is usually relegated to discussions about java applets, but their relevance to other applications is noteworthy.

Java includes a lot of well-organized, stable libraries for doing everything from handling HTTP requests and crafting responses to doing cryptography. Its collections API has many data structures that just aren't present in other languages without looking to a third party.

Finally, the JVM makes naive code fast. One can write reasonably expressive, straightforward code and expect that the hotspot compiler will optimize it. It's a boon for getting maintainable, quality code out-the-door quickly.

I too am bothered by Oracle's litigiousness, but running away from Java isn't a solution. We need alternatives, that's for sure, but the availability of such is a lot more limited than the average slashdotter seems to think.

TheNetAvenger's analysis is clearly inept, but there's a deeper problem here than that he or she doesn't understand GNU/Linux technologies. The deeper problem is that he or she - along with many others in our industry - doesn't understand the near necessity for government agencies to use free or public domain software.

The cost of alternative, proprietary systems is immense both up-front and over time. Worse, when one buys into proprietary software, one puts the dictates of a profit-driven software company in control of one's IT decisions. These reasons should be enough for a government like Switzerland's to decide that using proprietary software in its infrastructure is a bad idea.

The public sector needs reliable, unchanging software that isn't obsoleted because a company needs to sell new products. The public sector needs UIs that are easy-to-use and unchanging so it can hire even the technology-retarded as employees and know work can still get done. Finally, the public sector needs software that is open: it needs to leverage the work of other organizations - who have solved similar problems and make the results available for free - and make contributions itself.

I am a software engineer and contractor of the United States Department of Defense and marvel at the amount of money they throw away - even within my fringe area of influence - on Microsoft software specifically. They pay through-the-nose for software that doesn't fit their needs and for which no source code is available. As a result, they can't modify the software to meet their needs and can't perform security audits. Instead, they hack out silly augmentations of Windows systems (c.f. the gold disk) and end up with crippled systems. They spend gobs of tax money to make Microsoft richer and simultaneously make their IT infrastructure more brittle, closed, harder-to-use, and subject to artificial obsolescence. This is maddening to me.

It is clear that governments, non-profits, and others need to work with the open source community to get the software they need. A tremendous amount of exceptional open source and public domain software already exists: given some help from the community, some money and time spent to get development done in areas of weakness, and given the commitment to use open products, these organizations could build secure, useable, lasting systems. Basic desktop computing and office software shouldn't cost Solothurn, California DMVs, Unicef, Burton Middle School, or anyone else more than the price of a DVD. That linux adoption in Solothurn didn't work is disappointing, but moving to Windows 7 is a definite failure.

Just because buying this Apple garbage is opt-in doesn't mean we shouldn't complain about its problems. It's important to remind consumers why Apple products are a problem, especially given that purchases of Apple products are on the rise. As we saw with Microsoft Windows use in the last decade, shady business practices and crappy technology can still dominate the IT landscape if consumers put up with it. Perhaps if consumers knew the facts, and were given other ways to think about the Apple problem, they would quit buying it and we could lead some of these companies to make open, innovative, secure, useful products instead of this closed, buggy, entertainment-centric nonsense.