Linux off the Desktop

Linux, and open source projects in general, grow in very interesting ways. Because the growth of open source projects cannot be planned. During the Google IO conference, one of my favorite talks was Chris DiBona's Open Source is Magic talk. One of the things explained in that talk was how Open Source software is not planned by a group of executives wearing suits; in fact, it is not planed at all. Most open source software originates with one developer saying "Oh, this would be really cool!", and then implementing the skeleton of that project. Then, Linus's Law kicks in. "Many eyeballs make all bugs shallow." Some developers may be added, and hopefully it is released under one of the licenses that 99.9% of all open source projects use. Although its unpredictability is one of its greatest strengths, it is hard for "industry analysts" to sit down and say that 'Linux is going to go here in five years." Five years ago, analysts had no idea of an eeePC. Of course, this leads to Steve Ballmer saying things like "Linux is a Cancer" on Intellectual Property.

Due to the unpredictability outside of Linux's kernel (which is mostly controlled by Linus and a small group of elite developers) and the current state of the computer market, Linux has grown in interesting ways. Because of its price, it has become an attractive alternative to Windows on low end PCs, because of two reasons: One, these PCs cannot handle Vista's 16GB monstrous installation, let alone its memory requirements, and two, Windows is expensive; even for OEMs it costs about twenty dollars. And in these low-price PCs, every little bit counts.

One of the main attractions of Linux's, and all free licensing, is that there is no implied support. As Chris DiBona said, if you charge any amount of money for your software, you are implying that you are going to fully support it, and you will get emails for help and feature requests. Commercial support for Linux is available, but the community support is just as good, if not better. The community built Linux from the ground up (nearly, see Minix), therefore it is logical that they are the ones that know how to use it the best.

Regardless of the support issues of Linux, it is interesting to see how both Linux and Mac OS X are cornering Windows in the software market; Linux is working its way up from the low end of the scale, with the help of Asus and the likes of the eeePC, and Mac OS X is swiping the "cream of the crop" high end of the market. With the high end users who are likely to pay a lot gone to the Mac, and the plentiful low-cost users switching to a free OS instead of an expensive and draconian rights managed one, Microsoft has no where left to run than be caught in the middle of Apple and Linux. Although Linux is by nature unpredictable, the unpredictability culminating recently may change the scope of the computer industry in the next five years. We just need to wait and see how.

Touching is Believing ... On a Small Scale

Following the iPhone and its success, Microsoft has decided to bring the touchscreen goodness of a coffee table to its next version of Windows. See here. But is this really a good idea?

The idea of a desktop touchscreen is a tricky concept. Once a developer figures out that fingers are not mice, and that user interfaces should not be designed by the developer, they have to realize that the size of a finger pretty much breaks backwards compatibility with menus. Microsoft has built an empire based on vendor lock-ins and corporate we-absolutely-have-to-use-this-piece-of-legacy-software-that-only-works-on-windows-ness, and if they brand Windows Seven as the we're-so-cool-we-don't-need-a-mouse OS, they may become dead in the water.

An open world: Spread Virally

I'm here at the Google IO conference, and have just listened to the open social section of the first keynote. One of the interesting things that I found about Open Social is that once a company has deployed their app on a social network, the app is going to spread with about the rate of a virus. Applications on a social network that are picked up by a lot of individual users off of an enormous select applications screen are no good; a social network applications need to be adopted by one's friends. Of course, app developers are not going to hope that friends either hear about their app by word of mouth or another way, apps on a social network are able to send notifications and "invitations" to join the app and share things with your friends. Once a friend sends a notification to another friend, they can either choose to accept it and move on without using the application, or use the application and "pass it on", or send similar notifications to their friends. This provides the "web" diagram commonly linked to social networking. And this spread model is about the same as a virus.

For example, if you assume that each user sends notifications to all of his or her friends, but only three friends really adopt this new app. (Yeah, small number.)if each of those three friends has three more friends that adopt it, there are fourteen people using the app so far. And the number only gets larger. One more iteration and you have fourty-one users, and one more and you have 122. This is the viral spread of social apps; it forms an exponential curve. And, of course, the numbers only get larger. Social apps are not just each person finding and discovering on their own; they are people finding and discovering, and then passing it on. The heavy integration provided by APIs such as OpenSocial are just vessels to get people to let the apps access a contacts list when they send out notifications, and to position them in a place where they are going to be talked about, and thus spread.

Motion in the Mobile Web

One of the advantages that developers on the mobile web has is, if they are going to pursue separating "desktop" sites from "mobile" sights, is that the mobile web is more up-to-date with regards to standards than the desktop web (Here's looking at you IE and, to some extent, Firefox.) Mobile Webkit nearly passes Acid 2, and I am not sure about Mobile Opera. However, mobile browsers, specifically those based on Webkit and Opera, are more advanced than a certain browser that web developers always have to worry about. Plus, all mobile brosers (sans mobile IE) support CSS rounded corners: Firefox has -moz-border-radius, Opera has -o-border-radius, and Webkit -webkit-border-radius. Rounded corners in the mobile web may become a big thing, as it does not require any more images to load.

Today, Webkit dominates the mobile web. Motorola uses it in their MOTOMAGX browser, Apple in Mobile Safari, Nokia for their default browser, and Android. Because of the recent adoption of Webkit as an engine, the majority of the mobile web now has access to a CSS property that may make their whole experience so much better: -webkit-transition and -webkit-transform. I mentioned these two CSS properties previously in my post about the semantic web. Using these properties, web pages can achieve hardware accelerated animations, which is important in a mobile phone, as every little bit counts. And, because most of the mobile web supports this, auxiliary animations may become the standard, making the mobile web a vastly different experience than the desktop web.

Of course, this ignores Windows Mobile, which had 21 percent of the United States smartphone market with all of the individual hardware makers combined, and less than 6% worldwide. (I don't know the actual statistic, but I know that it is less than the iPhone at around 6%. However, a developer has to accept that the mobile web is a worldwide phenomenon. Webkit is the most popular mobile browser, and people may jump on the opportunity to provide the best experience possible to their users, just as developers focus on Internet Explorer on the desktop. Webkit's animations may become what ActiveX used to be on Internet Explorer, and because they originated in an Open Source application and degrade well in browsers that do not support it, it may become a harmless standard.

The Androids! They're compiling!

I'm here at the Google IO conference in San Fransisco, and in the morning keynote we saw a real android phone. My father thinks that it is an HTC Dream. However, the coolest thing was not the way in which the internal compass communicates with Google Street view to provide a three-hundred-sixty degree street view that depended on which direction the phone was oriented; the coolest thing is that it is relatively fast. This is compiled Java. Naturally, this also makes the footprint smaller, as all of that unnecessary stuff that makes the files human readable have been stripped. This is going to set an example for how mobile phones use Java in the future, no more of these silly slow interpreted things.

One more thing: The Android multiple home screens seem like a Frankenstienian monster of the iPhone home screen and the KDE plasma widgets. It is kind of cool how the background moves half a screen when switching home screens to give the illusion of the widgets being closer to the front. Of course, the idea of using a high res panoramic shot for the background and moving it right and left when the home screen is switched is brilliant in itself.

Web 2.1: Mash-Ups and Agglutination

The next step in the web world of user-generated content is not new ways of generating content, but new ways of consuming more content at once. This new quality of web pages pulling content from different sources and displaying it to the user in one integrated view has become popular with Web 2.0, because a user can see other related things around him, and see how everything connects. An example of a company that nails this is Google. Take a look at any Google Finance page. Google supplies the graph, and a little of the data about the company. However, the majority of it is taken from other places, be it another Google source, such as Google Blog Search, or a non-Google source, such as Reuters statistics. Google makes less work for itself by pulling in data from AOL Finance and Yahoo Finance on its pages, look in the right sidebar. This is also evident in other Google products. Intelligent laziness is a stellar quality in a software developer, and this enables developers and corporations to be lazy and focus on what they're good at (In Google's case, indexing stuff) instead of trying to spread a broad net over every area they could possibly attempt to compete in.

With this new paradigm, there is some risk of confusing the user; all of the other stuff on the page may distract from the main data. However, if the main focus of the page is really big, this should not be an issue. Such mash-ups are made possible by open web APIs and search engines that index everything and then provide that content. It is worthy to note that this is the same strategy that Google uses for online advertising: it displays relevant links next to the content, which the user may become distracted by. If sites use Google's API in this way, it also provides Google with a chance to serve more ads, users are pointed at Google Blog Search and other Google services. Isn't it great that developers can be lazy?

Making the Jump to the Web

Many applications on the web are now considered by the general public to be "semantic" web applications. In this case, semantic means that it is easier to use compared to the "old web"; it is easier to find, collaborate, and share documents. This can be accomplished through AJAX and the like, or through proprietary formats such as Flash and Java. Paradigms which require the user to reload the page or move to a different page to do something are not considered semantic because they remind the user that they are in a web browser. Ideally, a semantic web page provides an interface that the user is used to, such as .mac web mail imitating the Mail.app interface. Some web browsers provide tools for doing this that degrade gracefully, most notably WebKit (the Safari engine) and Gecko (The Firefox/Netscape engine) provide rounded corners through the -moz-border-radius and the -webkit-border-radius tags. Any browser can provide a system-themed dialogue using javascript, for example:

This input will ask a user for their name and provide a box to answer it in, and it adopts the look and feel of the system it is running on. In this way, a semantic web application can provide a method for user interaction that feels integrated with the system.

A browser that goes above and beyond in terms of integration is WebKit. Integration and looking great on one platform sometimes requires sacrifices on others. However, in most cases, WebKit's integration degrades gracefully, leaving a "normal" experience on another browser. For example, if this page is viewed in Safari 3 or another recent webkit-based browser (like the android browser), hovering over the /rc/etc image at top will cause it to tilt and scale. This is done through the -webkit-transition: and the -webkit-transform css tag. This degrades gracefully in other browsers, leaving nothing behind. See here for more information on CSS animations in WebKit.

Another way to provide more seamless integration is through sliders. It just so happens that WebKit provides a gracefully degrading slider as well: the -webkit-appearance: slider-horizontal or slider-vertical. This will degrade gracefully in other browsers by just leaving a text field for users to enter a value in. For example:

Of course, all of this can be applied to mobile web applications as well. Sites targeted for the iPhone and other mobiles with Gecko and WebKit-based browsers can make use of the appropriate tags, because they don't have to worry about other browsers (besides Windows Mobile's IE). This can be a path to smooth transitions on the iPhone by employing JavaScript for the WebKit animations, or other things

What the "iPhone Killers" don't seem to get

So, RIM has a touchscreen iPhone killer, there is an open source iPhone killer, a Samsung iPhone Killer, and a Windows Mobile iPhone killer. All of these devices have a touchscreen. However, all of these devices also have buttons.

Think of how uncomfortable it is to be typing on these devices' virtual keyboards, either with your fingers or with a stylus, and have to either bend your thumb downward in an awkward way or reposition the device in your hand. This is, of course, true for the iPhone as well. However, it makes more sense on the iPhone as well. On the iPhone, one is going to reposition the device when returning to the home screen and switching activities. However, it is more natural to switch positions when switching activities than to switch positions to bring up a menu to do something in the current activity. The iPhone neglects this model entirely, and just doesn't use menus. If it is not important enough for one of the buttons on the screen, it is probably too distant from the actual function of the application. Granted, some options can be grouped into modal dialogues off of buttons, but those represent distinct groups of the same task. With a traditional "menu phone", there is no distinct grouping to the menus, or even any semblance of standardization. In a touchscreen phone, muscle memory is key, and if these small menus are popping up with different things in different places in different applications, muscle memory will not be built up. For those who think that that's not so bad, consider this: phones aim to get something done where a laptop or desktop computer could not be used or would be awkward. This small space also includes time; if a user is going to be working on something for a long period of time, he or she may as well use a laptop. If things are in different places, can a user get a multitude of things done quickly, quite possibly using different applications? A user may gain muscle memory for one application, but this lack of familiarity loses the "learn one, learn all" principle that Apple and the iPhone really get. However, cell phone manufacturers cry the marketing of "more features", rather than a few, simple features. They don't have to be great, they just have to be simple and consistent.

iPhones are using a lot more data

A&T proves that iPhones use more data than blackberries, by a margin of about ten times. iPhone users use on average "'well over' 100 MB per month (compared to Blackberry around 10 MB)" (see this article. It just proves that the easier technology is made, the more people will use it and the more often it will be used. However, the main thing to look at here is not the higher volume of people, but the more time people are spending on the mobile internet. Mobile internet usage is no longer a chore, and when people start enjoying technology instead of waiting for things to load, squinting to try to read size eight antialiased text, and restarting after crashes (Safari has them too, unfortunately), technology starts to seem so much more personal and accessible. This then translates into more use, which AT&T has been seeing. However, their revenue per iPhone user has been about double that of a normal mobile phone user, due to the data plan involved.

Android VOIP?

Because Android is completely open, it has very few regulations on the OS. Even if it does, what's to prevent someone from swapping out the regulation program, just like swapping out the dialer?

I bring this question up because I just thought of something: Apple prevents people through its app store from running VOIP applications over EDGE to save AT&T the horror of losing money just due to iPhones. What's to keep android phones from running VOIP over a data network? If it is their method of app distribution, couldn't that be swapped out as well? If not, open source software is easily modified. It's just a thought, but...

What people don't realize about SOA and Web Applications

Nearly every analyst thinks that web applications are the next big thing in computing. However, they tend not to see the other side of web applications, and all of the turmoil and strife that may come with them.

1. If you have temporarily lost your internet connection, web apps are useless. Gee, this is a big one. Web apps cannot be used when not connected to the web. Although people using Google Gears and Adobe AIR may beg to differ, web apps rely on an at least somewhat constant internet connection. If the internet evolves into two seperate networks: a network of web pages for information, and a network of integrated runtimes under something such as fluid. Then, a browser can return to being just a browser. However, do standards bodies like the W3C want to tie the web to one proprietary standard? There just might be a format war over the web.
2. Web apps have no room for abandonware. When a company goes bankrupt or a software project gets abandoned on the desktop, normally the world moves on. However, in the wonderful world of web apps, when a piece of software gets abandoned chaos ensues. In a world of nearly entirely web apps, do you think people are going to have fun downloading all of their files and either working on them locally or uploading them to another web app service? How about your grandmother? Will people even be able to get their files after a web app goes offline?
3. Web apps using integrated runtimes tie users in to proprietary standards. When you use Google Gears or Adobe Air next, or even play a flash game, consider the company that is providing you with this technology, and consider how they make their money. Do you think that after web apps become ubiquitous the companies are going to let any one write a web app? If this happens, be sure the Free Software Foundation will have something to say about it.
4. Most web apps require a monthly fee. The current model of software can be compared to a candy bar. With a candy bar, you buy it, and you own that candy bar, free to give it away, and if you give it away you no longer have the candy bar. The same is true for software currently. When you buy a piece of software, either in a box or online, you are presented with a license agreement, which absolves the software company of all responsibility for anything you do with the software and anything the software does. With the current model for online services and web apps, you either get something for free and see ads, or pay a monthly fee. This is because the bandwidth and costs for running the app cost money, and the software company does not want the software it sold you to cost it money. With web apps, you cannot easily give software away, you can just use it for yourself.
5. Web apps have an unfamiliar user interface. Web apps do not easily integrate with the theme of the operating system, so users have to find their way around them on their own, with little to no consistency between one interface and the next. Completely cross platform interfaces do not work well either, as can be seen when one tries to launch a java app on a Mac or on Linux. Once again, if your grandmother is used to one interface at the moment, will she be able to navigate the five of the five different web apps she will be using.

Web apps are not always what they are cracked up to be, and it seems that people are willing to look past those flaws to point out the advantages, such as someone else being responsible for hard disk failures, and the fact that web apps provide a convenient way to inspect all of your data and keep it virus-free, the latter being a topic that may become irrelevant soon. However, in the next few lines I am going to make my biggest prediction yet. I believe that we are in the middle of a web app bubble, and that there will be a web app bust similar to the dot-com bust. Look at all of the people investing in companies such as Google and Yahoo, and look at all of the companies trying to implement web apps, such as Microsoft. However, eventually the web apps may bust, for the reasons outlined above or for a different reason, and when that happens, prepare for the latest fad to become really uncool.

iPod Touch + SDK = Tricorder?

The iPhone SDK should be out in June. However, the thing that most people don't realize is that the SDK also applies to the iPod Touch, and the myriad of practical uses. For example, the medical database shown off by Steve Jobs when he announced the SDK. Say your doctor walks in. He looks at your current health, and says he needs your health records. He can now either go off to an archive and find your file, or use his iPod Touch to search for you in a medical database, which will tell him your hereditary dispositions, your past diseases, and the treatments prescribed before for those diseases. Of course, this would require your hospital to have wireless, which most hospitals already do. It also requires a centralized storage database - a potential security risk for your health and identity records. However, if the advantages outweigh the disadvantages, it could work.
One of the reasons I think the iPod Touch is more attractive to businesses than the iPhone is because most businesses already have a phone system, possibly running VOIP over their wireless network. A company's phone system represents a significant investment, and while replacing all of its phones with iPhones would be a great undertaking, the iPod Touch fits into a different category. While mobile phones have absorbed some of the PDA market, they provide clunky interfaces for handling data. The iPod Touch's data interfaces are more sophisticated.
All in all, businesses may see the iPod Touch more as a tricorder-like device, good at managing data like a normal iPod manages songs. A few forward-thinking companies may adopt iPod Touches in a PDA-like capacity, and as the iPod Touch grows and evolves (possibly to allow add-ons in that 30 pin docking port), companies will see the value of having all of the data at your fingertips in less than the great amount of time it takes to use a phone.

On iPhone cell tower triangulation

Did you know that the clock on the iPhone home screen is intelligently synced to the triangulation feature in google maps. A general estimate of location is good enough to set the time zone by. However, triangulation does not work well in a building. Right now my iPhone tells me that it is 2:23 PM. It is currently 10:23. Cool feature, it just has a little trouble with buildings.
Apropos, I have found Google maps triangulation to be present in one other aspect of the system: the pane of the weather widget when the program is started is synced to the location, but only if you have that location in your weather places.

The amazingness of iPhone-Friendliness

Websites can have an icon so that when a person puts that site on their iPhone home screen, they see that icon instead of a snippet of the body of the site. Think of it as a hi-res favicon. Here's mine:


Now, if you put the /rc/etc blog on your home screen, you will see that icon, just with rounded corners and a glossy look. Just one more thing in making my site perfectly iPhone friendly.

On Running Multiple Apps on the iPhone

So, the iPhone won't run multiple apps, due to a restriction by Apple. This is a good idea, as has already been explained many times: multiple apps on a phone with 128 MB of RAM and a processor underclocked to 412 MHz. However, some useful things are also shot down such as,

• The "badging" of icons on the home screen won't be in real time. Apple's mail app listens for when an email comes in, and then displays an update number on its icon. Apple's SMS app listens for SMS messages, and does the same thing when a message comes in. Third party apps won't be able to do this in the background, because they won't be running anything in the background. This will most likely be most damaging for a couple of kinds of apps: IM, Social Networking, Third-Party Email, VOIP. However, VOIP apps also face a special problem, specifically,
• VOIP apps cannot receive calls when they are not running. HUGE downside. According to apple, VOIP can only be used on a wireless network and not over the air, but if I was going to download and install a VOIP app, I would want to be able to receive calls at home using VOIP as well as the cell phone. Either an apple-blessed third party VOIP provider will get to run things in the background, or VOIP on the iPhone will be limited to making calls. As I said, HUGE downside.

iPhone SDK vs. Android

So, engadget published this table comparing the iPhone SDK, the iPhone toolchain, Windows Mobile, and S60. There are some things that appear to be inaccurate, such as no certificate signing and only certificate signing both being bad things. However, they forgot to mention something else still in development, specifically, Android. So, lets see where Android fits in on the table.

	iPhone SDK (Official)	Android
Cost	Free	Free
Wide Availablility	June	2008
Native Development	Yes	Yes
Languages for Native Development	Objective C	Java
Digital Certificates	Required	Unknown
Retail Support	Full, 30% Revenue Sharing	Unknown
Platform Maturity	BETA	BETA
First-party support	Yes	Yes
Community Support	Just getting started	Just getting started
App Installation Method	Direct via App Store, iTunes	Unknown
Emulator Available	Yes	Yes
Remote Debugging	Yes	No models yet
Target Device Variety	iPhone + iPod Touch (Some may argue this is a feature)	Linux phones
Touchscreen Support	Yes	Yes
App availability and variety	None, getting bigger by the minute	Unknown
Underlying Architexture	Cocoa, Mac OS X	Linux

Apple, Open Source, and the iPhone SDK

So, Apple is not going to require that free iPhone/touch apps are delivered through iTunes. Yup, Apple is making a provision for free software? Well, their kernel is based on it, so is the iPhone's browser; and any free software written for the iPhone can always be adapted and built on later for Apple. What will be really interesting is to see if installer.app makes the cut, because package managers may make things more complicated.

A forecast of things to come

I've been thinking about Android, and the iPhone SDK lately, and I have formulated what I think will happen with the mobile industry over the course of the next five to ten years.

• Handsets and providers that provide an excellent all-around mobile experience are going to sell well.This seems like a bit of a given, but I would like to start here. Apple and AT&T provide a complete mobile experience by working together, from registration in iTunes without having to talk to an AT&T customer service rep to the method on the handset's keyboard that lets you type alternate letters. The iPhone provides a complete experience, and what other handset manufacturers and carriers need to get is that multi-touch is only a vessel for making the iPhone experience special. The iPhone could have been done just as well, albeit differently, without multi-touch. The innovative people at Apple would find a good way to make some other input technology suit their needs. There are a lot of handsets embracing new things hardware wise, but not a lot of new things software-wise. The need for deep integration between hardware and software at the mobile level is something that these handset manufacturers need to get in order to be successful as the mobile market evolves.
  One of the things that makes the iPhone experience such a good experience is that it has a fast enough processor to run graphics really, really well. The iPhone is estimated to have a processor clocking in at somewhere around 500 Megahertz, which allows it to show movies, run a compositor, and perform its fancy animations.
• Handset makers will be forced to adopt phones with better processors. Currently smartphones run at somewhere between 100 MHz and 150 MHZ. As the market for mobile phones grows, vendors will be forced to adopt faster processors. The processor used in the MacBook Air may become a mobile phone processor, clocked down to about 1.0 GHz to save power. Handsets will begin integrating video cards by default to run OpenGL accelerated graphics. Handsets will have more power-efficient 3G chips and bigger storage media.
• XMPP will become the new messaging and alert service of choice. The android phone already includes XMPP as a way to get messages. With XMPP, services such as news and weather alerts will become better, an RSS reader-like application will be able to run on the phone, allowing customers to set up specific feeds as to alerts, and unlike current SMS alerts, the alerts can have coherent formatting. XMPP also provides for chat and IM services (jabber), and can send more than just text and small images, making SMS and MMS more obsolete. And unlike SMS and MMS, the jabber services will cost only a monthly data plan.
• More phones will come bundled with data plansAll of the new technology described above requires money to spend on phones. Currently in the United States market, mobile phones are subsidized by the carrier, which is then made up for with a contract for a certain amount of time. As data plans start to become more ubiquitous, carriers will be able to charge more per month for them, enabling greater subsidies. Expensive phones with two year data plan contracts may become as cheap as non-data phones.

In the end, it all boils down to a more complete experience. Integration between hardware and software, good hardware specs backed by subsidies, and XMPP or a better version of SMS that makes use of data will make up the next couple of mobile generations. A laptop processor fits into a phone, and things such as Android and the iPhone drive the market to brave new worlds.

Cold Boot Attacks

There has been a little fuss about cold boot attacks recently, and I've been thinking about it. While it cannot be prevented altogether on the software/firmware side, it can be made harder to orchestrate. First, all macs for a long time now have come with a feature called "Automatic reboot after power failure." It can still be found now under energy saver in the system preferences dialogue. This was achieved by an Open Firmware extension, and with Intel Macs an EFI extension. The logical thing to do to prevent against cold boot attacks that involve booting off of a USB key is to have the power failure extension clear the key from RAM by writing zeros to it if there is an encrypted disk. Since Open Firmware loads before the operating system, the key will be long gone before that pen drive operating system has a chance to load. An even simpler way to do it would be to just set the firmware to clear the contents of memory, commonly known as ECC, or Error Correcting Ram.

Preventing against the transferring to another computer would involve more difficulties, since the cutting of power can't be anticipated. The best way to do this would be to use a kind of volatile RAM that does lose its contents immediately. However, a way to do this software level is to clear the key when the computer goes to sleep, then require the user to enter the password to get the key once the computer wakes up again. Of course, the best defense is still shutting down your machine until it goes into ACPI G3 mode (off).

Thoughts on the iPhone SDK

Well, the iPhone SDK is slated to come out near the end of this month (I'm guessing the 26th). Just some conjecturing about some security things not present in the jailbreak. First, permissions. Nothing will be run as root. Nothing. Why? Because the iPhone user's password is set to null; the hash does not match anything. So, there will be no way to elevate to root on the iPhone? Partially correct. There will be no way to run a process as root on the iPhone, however folders with permissions of root will be writable when the iPhone is mounted in iTunes, just like currently. This will let people load things in /Applications, and currently lets Apple update the firmware.

Second, application distribution. As of right now, all applications for the jailbreak version are delivered through installer.app. There have been theories that Apple will charge a distribution fee for iPhone apps through iTunes. I do not think that this will be the case, because Apple has provided other application directories, including one for the iPhone web apps. What's to prevent them from making a mobile applications page today, and host developer's applications for free, like in their other application directories?

That, of course, brings us to the topic of downloading and installing web apps. My best guess is that web apps will either be delivered as .app bundles, or as a special iPhone installer, such as .ipkg, to avoid confusion between desktop and mobile apps. This would fit in well with my predicted iPhone interface builder files.

Lastly in my conjecture, I think that Apple and its partners are going to release several applications at the same time as the SDK, such as Lotus Notes, a native bejeweled game, and the possibility of a company like Nintendo releasing some great touch screen games.