You have to read this article on the corporate interests behind Arizona’s draconian new immigration law. When the law was passed, I thought that it was a typical example of right wing reactionaries passing a law that persecutes a minority group that they hate. And of course, hatred of undocumented immigrants and the influence of Mexican culture on America was the political fuel that enabled the law to be passed. But of course there’s more to it. The law was conceived by lobbyists for the private prison industry. They want to build more prisons and charge the government for housing inmates, and so what they need is more potential prisoners, and illegal immigration is one source of such prisoners. So they worked with the Arizona legislature to make it happen. This is what evil looks like.
Marco Arment makes the point that the Mac App Store is for developers who aren’t already developing Mac apps. This was the point I was trying to get at the other day when I said:
I can see a future where a sizable percentage of Mac users only use applications that they installed through the Mac App Store.
There are a lot of people who buy Macs, go to the Apple Store and take some classes, and never bother to install anything on their Mac that wasn’t there when they bought it. Maybe they buy a productivity application so they can do word processing, and that’s it.
The App Store is a way to deliver applications to those people, and like Marco, I think it’s going to be very successful in that regard. Anyway, go read his post, The Mac App Store isn’t for today’s Mac developers.
Chris Adamson talks about the strange fact that the number one use of Java desktop applications is to run tools used to create Java server applications:
We know the big use for AWT and Swing, and it’s a terrible irony: measured by app launches or time spent in an app, the top AWT/Swing apps are surely NetBeans and IntelliJ, IDEs used for creating… other Java applications! The same can be said of the SWT toolkit, which powers the Eclipse IDE and not much else. This is what makes this white elephant so difficult to dispose of: all the value of modern-day Java is writing for the server, but nearly all the Java developers are using the desktop stuff to do so, making them the target market (and really the only market) for Desktop Java. If there were other viable Java applications on the desktop, used by everyday end-users, Apple couldn’t afford to risk going without Java. There aren’t, and it can.
This is sort of a weird result of how Java evolved. The original idea behind Java is that it would be a replacement for platform-native GUI toolkits, but of course that didn’t work out particularly well. However, it did make it easy for Java developers to write their tools in Java, and those tools wound up being write once, run anywhere.
That, in turn, contributed to the resurgence of the Mac. If you were a Java developer who used Eclipse, it was very very easy to move from Windows to the Mac. When it became obvious that using the Unix-based OS X was a better deal for Java developers than using Windows, you could just get a Mac, download Eclipse or whatever Java IDE you enjoy, check out your source, and get started.
Adamson’s prediction is that you soon won’t be able to run your favorite Java IDE on a Mac, but I don’t think he’s correct. At least I hope not. The strong negative reaction we’re seeing from the Java community is, for the most part, an expression of this worry. They don’t want to have to choose between their favorite tools and their favorite operating system, especially when they don’t have to right now.
James Fallows captures Fox News in a nutshell in a longer post about the significance of NPR:
“News” in the normal sense is a means for Fox’s personalities, not an end in itself. It provides occasions for the ongoing development of its political narrative — the war on American values, the out-of-touchness of Democrats — much as current events give preachers material for sermons.
Yesterday, I talked about what we might be able to infer from Apple’s decision to deprecate Java and prohibit Java applications from the Mac App Store in terms of the future of the Mac as an open platform. Today, I want to round up some links about the future of the Mac as a Java development platform and as a platform for developers.
Nobody is exactly sure what to make of the deprecation of Apple’s port of the Java Development Kit for the Mac, but a lot of people are rather stressed about it, as you can see from several threads at Hacker News. I am a Java developer and I do all of my work on a Mac. Losing the ability to continue to work in this manner would be a hit to my productivity.
First, Apple announced that the version of the JDK that they maintain is deprecated. A Java developer who is a Mac user emailed Steve Jobs what Apple’s future plans are for Java on OS X. Jobs responded that Oracle maintains the Java released for other platforms, that Apple’s Java release is always behind the latest Oracle (formerly Sun) release, and that keeping Java up to date for OS X is their job. Java creator James Gosling takes issue with Jobs on a number of points, noting that many companies do maintain Java for their platforms, and that Apple in the past chose to maintain the port for a variety of reasons. Former Sun open source evangelist Simon Phipps explains why it would be difficult for Oracle to take over maintenance of the OS X JDK.
Matt Drance says this is the end of Java as a development platform for Macs. The one community that really cares about this is Java developers who use Macs. Here’s his prognosis:
A lot of Java professionals use Macs for development, even if they deploy somewhere else. What will they do? If they’re using Eclipse, I think they’ll be OK. It shouldn’t take long to shim SWT on top of an OpenJDK port, and IBM has shown a lot of initiative over the years. Other “pure Java” IDEs, like JetBrains’ (superior, in my opinion) IDEA, depend on a working AWT, and therefore have some more thinking to do.
And finally, Tim Bray, on Twitter:
Unclench, everyone. There are millions of Java devs, all their tools are in Java, they like Macs, one way or another it’ll be there.
I don’t know what the future of Java on the Mac is, but I think it’s foolish for Apple to turn its back on hosting development environments that they don’t fully control. One of the factors that brought Apple back into relevance as a computer maker was the fact that Apple provided a friendly version of Unix that Web developers could use to get their work done. A few years ago switching from Windows to Mac became a no brainer if you were developing apps that would eventually be deployed on Unix servers. That led to a lot of Macs being sold, not only to those developers but also to the people those developers influence.
Furthermore, I believe that the presence of Macs on the desks of millions of software developers who were doing Java work, or PHP work, or Ruby on Rails work contributed in a big way to the growth of iPhone development. There are huge advantages associated with being the platform of choice for developers. Apple should be very careful before it fritters away those advantages.
Matthew Yglesias makes an astute point about how digital technology makes it easier to create things that promote the general welfare without necessarily creating wealth:
Consequently, the realm of activities with gigantic divergence between measured GDP and welfare value is vastly expanding in ways that I don’t think policymakers and civil society donors are yet responding to in fully appropriate ways. The case for finding ways to directly and indirectly subsidize the creation of such goods is extremely strong. But more generally, I think we should expect the significance of this kind of thing to expand in the future.
The negligible marginal cost of producing multiple copies of digital works is the enabling factor. I think so many people get caught up in the mentality of “monetization” that they fail to step back and look at the sheer number of interesting, entertaining, and useful works that are now being produced simply because people find it fulfilling or entertaining to produce them.
The big question everyone is asking is whether the Mac App Store is a step toward the closing of the Mac platform, making it a walled garden like iOS where you can only install applications by way of the App Store. This was the big worry when the iPad was originally released — is the closed model the future of personal computing? Migrating the App Store model to the Mac platform isn’t very comforting to those of us who like to be able to install and run any software we like on our computers.
Today the App Store Review Guidelines have been leaked, answering one of my big questions, which is whether Apple is going to exercise control over which Mac applications can be distributed via the store. The answer is yes, they will.
The next question is whether Apple is moving toward the App Store being the only way to distribute Mac applications and the only way to install them. I think the answer that is that Apple is not headed in that direction. Here’s one reason why:
Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
Apple is stating flat out that Java applications will not be allowed in the app store. This is important because developers in general, and Java developers in particular, make up a substantial part of the market for Apple computers. Many people migrated to the Mac specifically because it was a nice place to set up a full Web development environment that mirrors what you might use in production — you can install Eclipse (or your favorite Java IDE), Tomcat, MySQL, and Apache and get work done. It doesn’t seem like you’ll be able to install any of those applications in the App Store.
So the question is, will Apple turn its back on developers who use OS X completely? That seems highly unlikely to me.
My sense is that we’re going to see people using App Store apps and traditionally installed apps side by side for a long time. The review requirements make it clear that users will be unable to install the kinds of applications they need for many kinds of work by way of the App Store, so the Mac will need to remain an open platform in order to accommodate those users.
Oddly enough, this gives me some hope for future opening of the iOS platform. The Mac platform is going to be an experiment in running App Store-style managed applications alongside applications that require open access to the operating system to install. If the combination works out very well, it seems like Apple may decide to further open iOS.
I can see a future where a sizable percentage of Mac users only use applications that they installed through the Mac App Store. But I don’t see a future where the Mac App Store becomes the only way to distribute OS X applications. Apple is foreclosing that possibility itself with its review policy.
Today the New York Times Opinionator blog ran a piece by Robert Wright made the following assertion about HTML5:
In principle, HTML 5 will allow sites you visit to know your physical location and will make it easier for them to keep track of your browsing and shopping history.
That assertion is based on this news article from the Times, which says:
In the next few years, a powerful new suite of capabilities will become available to Web developers that could give marketers and advertisers access to many more details about computer users’ online activities. Nearly everyone who uses the Internet will face the privacy risks that come with those capabilities, which are an integral part of the Web language that will soon power the Internet: HTML 5.
All of this talk is about one piece of HTML5, client storage. For the details, check out Mark Pilgrim’s chapter on local storage in Dive Into HTML5.
There are two points to make. The first is that Web sites won’t have access to any information that they don’t have already already. In that sense, the talk about “access to many more details” is misleading. It’s not that Web sites will have access to new information, but rather that they’ll have a new place to store information that they already collect that may make it more convenient for them.
For example, if I don’t share my current location with FourSquare, they won’t suddenly be able to retrieve it if I use a browser that supports local storage. However, if I do give them access to my current location, they could store it in local storage on my own computer rather than using their own resources to store it on their server. In that sense, the information may suddenly be worth storing and easier to access, but it’s information they could already obtain and store on their own servers if they chose to do so. This aspect of local storage subjects users to no real risk beyond the risk already posed by cookies or other vectors for storing information about users.
What’s really gotten people wound up is evercookie (mentioned in the New York Times story), a proof of concept that demonstrates how the variety of ways Web sites can store information on the client can be exploited so that it’s nearly impossible to delete tracking cookies. Browser cookies are one way to store information on the client, as is local storage. Flash Local Shared Objects (also known as Flash cookies) can also store information on behalf of Web sites on your computer. evercookie uses a number of other methods for storing information as well. The nefarious thing about it is that when the information is deleted in one of these locations, evercookie replicates it again from another location where it is still stored. So if I delete my browser cookie, evercookie will copy that information from Flash and put it back in place. If I delete the Flash cookie, it will look in one of the other locations where it stashes information and copy it back again.
Using tricks like this to make it difficult for users to prevent Web sites from tracking them is unethical. Web sites who take this approach should be classified as spyware. But the existence of these techniques has nothing to do with HTML5.
What concerns me is that we’re on a path toward HTML5 being perceived negatively by regular users because the only thing they’ve heard about it is that it is likely to compromise their privacy. This perception could become a major stumbling block on the road to wider usage of browsers with HTML5 support. As developers, it’s important to educate users and perhaps more importantly, the media, so that people don’t conjure up risks where they don’t exist and damage the HTML5 brand in the process.
Today I got to look at the user table in an application with passwords stored as plain text. Out of around 7100 users, over 170 have the password “password.” Around 10 other users had heard that your passwords should contain letters and numbers, and thoughtfully chose the password “password1.” Needless to say, this application should probably store hashes of the passwords rather than storing them in plain text and also use some basic test of strength for the passwords that requires more than just lower case letters. What the experience left me with, though, was a burning desire to thwart users who specifically want to use the word “password” or any variation thereof as a password. I even want to create a special error message just for them, just to let them know that their combination of laziness and cleverness is not appreciated.
Here’s a regular expression that matches many, many variations on the word password:
You too can stamp out the blight of your users using “password” as their password.
Update: Accounted for people who substitute the letter “s” with the number “5.”
Update: Now “[email protected]” is not allowed, either.
I’m just linking to this because I think it’s cool. Today the White House honored students who competed in its first annual Science Fair in the manner usually reserved for champions in the world of sports.