Chances are that if you’ve followed one of our tutorials to jailbreak your iPhone, you might need some help on how to get files on and off. One example of where this might be needed is putting NES Roms on the phone for the NES app that’s available in Cydia.

In this article I will walk you through the entire process of copying files to the iPhone using Mac software. A separate Windows tutorial will be available shortly for non-Mac users — fear not we haven’t forgotten you!

A few things are required to be able to follow this tutorial:

• iPhone/iPod must be jailbroken (see mac or windows tutorials for help)
• Download an FTP Client (see note below for a list of clients)
• iPhone/iPod must be on WiFi (no Edge or 3g for SSH/SFTP)

NOTE: For this tutorial you will need an FTP client that is capable of transferring files using the SFTP protocol. For Mac users we recommend Fetch ($15 / 15 day free trial).

Walkthrough:

1. Download OpenSSH from Cydia (see this Tutorial for help)

OpenSSH is the server that will run on the iPhone that allows us to connect using SSH or SFTP applications. Downloading OpenSSH will not add any icons to your SpringBoard as it runs in the background. In the next step we will download an application that will allow us to turn on and off OpenSSH when it’s not in use.

2. Download Boss Prefs from Cydia

Boss Prefs lets you control different settings of the iPhone/iPod without having to go through all of the settings menus. It also lets us turn SSH on and off easily.

3. Open Boss Prefs / Enable SSH

Boss Prefs has a few switches — SSH is probably already turned on, but open Boss Prefs just to make sure. WiFi may show as off (even if turned on), go ahead and flip the switch to ON, your IP address will be shown in parenthesis next to the WiFi switch. WRITE DOWN THIS NUMBER, you will need it to connect to the iPhone/iPod in the next few steps. (In our screenshot the IP address is the 192.168.1.115 number you see next to WiFi below)

4. Set Auto-Lock to Never

SSH / SFTP sessions require that the phone be connected to WiFi. When the phone locks, in order to save battery, it temporarily shuts off the WiFi connection. Because of this we’ll disable Auto-Lock on the phone for the duration of our session. You might want to re-enable it after you’re done transferring files.

5. Create an SSH session to the iPhone / iPod

Open up your SSH Client and connect to the phone. The first connection will take 15-30 seconds as the phone will need to generate a security key. This is normal. If your SSH Client times out, try connecting again, and your iphone will likely have finished creating the key by the second attempt.

Mac Users use Terminal.app which is built in to the Mac OS

Connect to the iPhone using the address you recorded in step 3

After 15-30 seconds type ‘yes’ when asked to accept the new key

When prompted for a Username type ‘root’
When prompted for a Password type ‘alpine’

You can now type exit and close Terminal.app

6. Create an SFTP session to the iPhone / iPod

Now that the phone has all the required software, and we’ve generated our security key, we can begin transferring files to (and from) it. For the purposes of this tutorial we’ll show you how to accomplish a common request, putting NES Roms on the phone. First, let’s connect to the phone using our SFTP client.

For Mac Users:

Open Fetch

Create a connection to the iPhone using the address from step 3
Use the username and password in step 5 above (root / alpine)
Make sure you select “SFTP” in the Connect Using box

After connecting you will be placed in the folder
/var/root/

When opening the NES app on the phone it tells us we need to put ROM files in the
/var/mobile/Media/ROMs/NES folder

Click Path to change to /var

From /var click through mobile, then Media

You will notice there is no ROMs folder inside of the Media folder, so we need to create it
Click +New Folder to create a folder
Type ‘ROMs’ (Case sensitive) in the new folder dialog

In the ROMs folder we need to create the NES folder
Click +New Folder
Type ‘NES’ (Case sensitive) in the new folder dialog

‘Put’ your .nes file in the newly created folder
Click ‘Put’
Select your rom file (must end in .nes)

7. Disable SSH and turn on Auto-Lock

Now that you’re finished with your SSH connection you can shut it off. This will free up some memory, as well as keep unwanted connections from being made to your phone without your knowledge.

7. Open NES and enjoy your new ROM file!

Summary

Though we used NES emulator as a basis for this walkthrough the steps may be applied to a lot of other tasks.

Some other uses for SFTP on the iPhone are:

• Manually installing applications not available in Cydia
• Transfer voicemail from iPhone to a computer (see this article)
• Removing unwanted applications from the iPhone / iPod

You also have the ability to create a terminal session with the iPhone. From within terminal you can change permissions on files and folders, delete files, edit preferences, and various other things.

Some key things to remember when following this tutorial:

• Set Auto-Lock to Never
• Remember IP Address from Boss Prefs
• Username and Password are case sensitive
• Username is: root
• Password is: alpine
• Turn off SSH in Boss Prefs when done
• Turn on Auto-Lock when done

If you need help, ask questions in the comments below!

After two weeks of all the iPhone apps I care to download, I can say this: most of them are useless. I use a few of them daily (Facebook, MySpace, Loopt, Phonesaber) and a few others occasionally (BoxOffice, Pandora, Twitterific). Most, though, sit unused after testing and are far from being “must-have applications.”

DataCase, though, looks to be different. It will turn your iPhone into a wireless drive for file storage, and includes a viewer for most popular file formats (Office, PDF, etc.). The application has been highly anticipated but is yet to launch - the creator says by email that they want it to be perfect before releasing it.

For now we have to settle for the demo video that they just put up on YouTube and is embedded below. DataCase will cost $7 when it does launch, and I expect a lot of people will buy it immediately. This is exactly the kind of utility application that I need. The ability to email out any file on the phone would be a nice feature add, too.

Crunch Network: CrunchGear drool over the sexiest new gadgets and hardware.

Written by the developer that created AppCleaner and LiteIcon, SecureFiles 1.1.2 is an excellent free application for OS X that allows you to easily create encrypted Disk Images. It uses 128 bit AES encryption to keep your files safe from prying eyes.

FEATURES

• Easy To Use
• Compact The Disk Image Size
• Allow Spotlight To Search The Disk Image
• AES 128 Bit Encryption Used
• Much More

Technorati Tags: Best Mac App, Best Mac Apps, Cool Mac App, Cool Mac Application, Cool Mac Applications, Cool Mac Apps, Cool Mac Freeware, Cool Mac Program, Cool Mac Programs, Cool OSX App, Cool OSX Apps, Coolosxapps, Free Mac App, Free Mac Apps, Free OSX App, Free OSX Apps, Mac App, Mac Apps, Mac Free Download, Mac Free Downloads, Mac Freeware, OSX App, OSX Apps, Create Encrypted Disk Images, SecureFiles For Leopard, SecureFiles For OS X, Top Mac App, Top Mac Application, Top Mac Applications, Top Mac Apps

Google added a new feature to Gmail to always use a secure (https) connection. Switch to the settings/ general tab and scroll down to “Browser connection” to see if you got it already (if not, it may still be rolled out for you). While safer, Google in their blog announcement of this also notes it may slow down your Gmail a bit.

[Thanks Mrrix32!]

[By Philipp Lenssen | Origin: A Safer Gmail With Https | Comments]

[Advertisement] Google books at eBay: background info on Google, AdWords, AdSense, Blogger and more...

Some of you may know Jesse Vincent as the guy who hands out snarky t-shirts like last year's "My free software runs your business" shirt. But today I got to see Jesse's more serious side when I attended his "Prophet, your path out of the cloud" presentation. He started his session by outlining why cloud computing may not be the best idea and then went on to talk about his new distributed database called Prophet.

Since I've been pondering hosting MusicBrainz' web services at EC2, I found his analogy of cloud computing as "digital sharecropping" quite apt. Wikipedia defines sharecropping as: "Sharecropping is a system of agriculture or agricultural production in which a landowner allows a tenant to use the land in return for a share of the crop produced on the land (e.g., 50 percent of the crop)." History tells us that sharecropping didn't work out so well for the farmers and that a lot of the farmers were dependent on the landowners and heavily in debt to them.

In the beginning of computing people ran programs they didn't own on machines they didn't own (mainframes were leased from the manufacturer). People had no control over when these machines got updates and had very little control in general. In the 80's things got better as PCs started appearing, only to lock users into things like Windows. And today people don't need to have servers, software or anything else -- just a web browser to host and run web-sites thanks to cloud computing.

So, what happens when they go down? Your web-site or perhaps your business stops dead in its tracks as we saw last week when Amazon's S3 service went kaputt. Also, how do you trust your service provider to not send a copy of all of your email to the Chinese secret police? What if you get shut out because your service provider disagrees with what you are doing?

In short, if your provider shuts you out, you're screwed! Then what do you do when you're work is tied to that provider (e.g. EC2 AMIs)? Jesse's message is that if you use hosted applications, you're going to get burned. Maybe not today, but at some point it will catch up with you! This thought provided him with motivation to work on a distributed database that needs no hosted servers and can live with data being synchronized via sneaker-net.

Jesse describes Prophet as a grounded database, since it runs on the edge of the network -- not in the cloud! It syncs with services that you already use (mostly bug tracking systems since Jesse is the father of RT). Replicated services are called Foreign Replicas.

Prophet is semi-relational; it is possible to do relational joins, but they are expensive. Prophet follows a similar model to Amazon's Simple DB to keep things nice and simple. But the most significant feature of Prophet is that it is Peer-to-Peer distributed: You can update data in any of its replicated copies and later on re-sync the databases and automatically resolve conflicts between two copies of the data. You can pull from a replica or push to any replica and the changes will propagate properly. Changes can be pushed via rsync or a standard filesystem and pulled via HTTP.

Prophet is also disconnected, which allows replicas to live disconnected from other databases for prolonged periods of time. Not all databases will have constant network connections so Prophet handles this case so that replicas can live on USB keys for instance. Prophet also features versions much like a version control system -- each change to the database has a version number. The entire history of the database is introspectable and replication simply replays changesets into replicas. Operations like create, read, update, delete and search are all atomic.

The most important aspect of Prophet is its ability to semi-automatically resolve conflicts that arise when replicas are sync'ed with other replicas. Since changes can be applied to any replica, it is quite possible for two or more replicas to make changes to the same records, resulting in conflicts during the next sync. Prophet handles this via a voting mechanism where all replicas will get a chance to vote on conflicts. To make this possible, Prophet keeps a history of conflicts and outcomes of conflict resolutions.

Near the end of the talk Jesse reminded everyone that Prophet is very young still -- it was written in the last couple of months. The Perl codebase is fairly small, contains a lot of test cases and all the core functions of the database are working correctly. However, search is currently "half-assed"; several people have promised an index implementation for improved searching. If you're interested in playing with Prophet and perhaps even jump in and help Jesse out, download a copy and start playing!

I haven't had a chance to play with Prophet yet, but I'm excited that Jesse took the time to write this tool. Distributed databases with automatic conflict resolution are hard, which is probably the reason why we haven't seen an established database like this yet. Even though it seems that just about everything is being connected to the net, I can see real value in Prophet and the types of disconnected/decentralized applications that it can enable.

Thanks for Prophet and thanks for the presentation Jesse!

Its good to be back in Portland for my favorite geek convention: O'Reilly's Open Source Conference. The overcast sky in Portland is making it a little easier this year to focus on the plethora of excellent speakers and sessions. The first session to really grip and and speak to me was Rabble and Kellan's "Beyond REST? Building Data Services with XMPP PubSub" presentation.

They started out their presentation stating that they were not "Jabber Heads", but that they were in the business of building web sites. For Rabble and Kellan, Jabber presents one more tool in their huge tool-chest to build web sites. Jabber wasn't designed to be a part of a functioning web site, but they insist that it works great for building social web sites that require many people to be notified of updates.

For example, Kellan talked about FriendFeed, a site that lets their users know when their friends share new items. In this example, Kellan pointed out that FriendFeed polls Flickr 2.9 million times in order to check on updates for 45 thousand users. And of those 45 thousand users, only 6.7 thousand are logged in at any one time. This of course, its a poor way of checking for changed content. Kellan says: "Polling sucks!"

To solve this problem its key to leave standard REST web services behind and find a way to use message passing, which is a direct communication way of notifying users of changed content. The open and mature infrastructure that Rabble and Kellan found to use for this service is Jabber. Jabber has 10 years of experience of passing messages around the internet and has been embraced by many companies including Google.

XMPP, Jabber's protocol, works well for message passing and does not have many of the problems/limitations of HTTP:

1. XMPP works over persistent connections
2. It it stateful (SSL becomes cheap)
3. Designed as an event stream protocol
4. Natively federated and asynchronous
5. Identity, security and presence are built in.
6. Jabber servers are built and deployed to do this stuff.

Given this, Kellan and Rabble decided to piggy-back a notification system on Jabber by sending XML fragments using a PubSub paradigm. In this context, PubSub is a simple method for passing XMPP pubsub stanzas via Jabber. PubSub is nothing more than a convention for how to send XML via Jabber, including a method for embedding Atom fragments in the XML.

Rabble presented using XMPP for FireEagle, Yahoo!'s new personal geolocation service that allows users to provide their current location to other users. For a few users and a few updates you can paginate the data stream into RSS/atom feeds. But once you have more than a few users and frequent updates a paginated stream cannot keep up. What if a user publishes more updates than can an RSS feed can capture? Updates get lost -- and for applications using FireEagle missing an update presents a critical flaw. Using a system like XMPP, FireEagle can rely on Jabber to deliver all the updates -- exactly what Jabber was meant to do.

Kellan also applied XMPP/PubSub to Flickr and how a Flickr update "Firehose" might work. If Flickr sends a ~2k an atom enriched packet for each new public picture posted at a rate of 60 updates a second, it would take roughly a megabit of traffic. Even a normal DSL line can handle one mbit of traffic, so the network effects are manageable on this level, compared to the polling system that FriendFeed uses. (Kellan also points out that FriendFeed is not doing anything wrong at all -- the current web service centric model is simply insufficient for this type of service.)

To deploy your own message passing service based on XMPP/PubSub, you'll need to follow these 4 easy steps:

1. Get a Jabber client library. There are many available for all the popular languages.
2. Set up a Jabber server -- again there are many available to choose from. Turn off the features you won't be needing. (e.g. creating new accounts)
3. Build a component (according to Jabber XEP-0114)
4. Integrate the message passing system in your own site.

Pretty simple, overall! The beauty of this approach comes from the fact that all off-the-shelf components were used to build this new notification system. No new magic technology is being created to enable this system, which is a personal metric of mine for determining the likelihood that a new system will succeed.

It's clear that REST web-services provide the heavy lifting for many Web 2.0 sites, but its also clear that REST and its inherent polling mechanism isn't the best way of building a user notification system. With social networking sites not about to fade away, we're going to see an increasing need for capable message passing sites. And since Jabber is a well established and supported system, it only makes sense to piggyback on this great technology. Thanks for the awesome presentation Rabble and Kellan!

Update: Rabble posted the slides for this talk.

(And a big thanks to Tim O'Reilly for letting me guest blog OSCON here!)

John Allsop wrote a long piece over at Web Directions South with some thoughts on writing native iPhone apps versus web-based iPhone apps.

The obvious flaw in his piece is that he only looked at free iPhone applications and from that subset concluded that almost everything the native apps do could be done with web applications (he explicitly ignored Apple's Remote app; implicitly he must have also ignored Evernote, Pandora, PhoneSaber, Midomi, NetNewsWire--in that it works off-line, Graffitio--which interfaces with the GPS hardware, etc.).

If you've spent some time with some of the amazing free and for-pay iPhone apps as I have, just ignore the bit about those apps not being impressive compared to iPhone web apps and skip to the core of his piece where he makes an interesting assertion: the math of trying to profit from selling small apps in the iPhone store doesn't make sense when compared with (a) the costs of learning the devtools, (b) porting to different phone architectures (vs. one web app code base), and (c) the revenue stream from 37signals-style subscriptions.

Let's say you sell your App for $1.95. You'll need to sell 25,000 copies to make $50KUSD. Hang on, Apple takes about 30% so you'll need to sell 30% more. That's 36,500 copies. If you look at a typical conversion rate of say 3% of downloads to sales (in my experience, good Mac apps can get that kind of conversion), if this were a desktop shareware app, you'd need to have 1.2 million downloads. That's more than 10% of the entire projected iPhone user base for the end of 2008 interested in your app.

OK, let's think about higher price points - at $5, you need to sell 14,000 copies to make $50KUSD, with a theoretical download of 476,000 demo copies. Up this to $10, and we are looking at 7,000 sales, and 233,000 demo downloads. And that's for a single developer. Double this for 2 developers, triple it for a team of three, and so on.

Now, let's compare the “sell the app†business model with the increasingly common “subscribing to a service†model. Let's say we only have customers paying $5 a month. They are already paying $60 a year! So to make our $50KUSD, we'll need around 1000 customers (about 14% of the number of sales of a $10 app). And I've factored in about 12% costs here (transaction and hosting costs, based on personal experience).

Coupled with John "Daring Fireballs" Gruber's recent measurements of increased WebKit Mobile speed, do you agree with John that iPhone Web Apps are a much better business model than native apps?

With the Facebook Developers conference slated for later this week, I thought it would be a good time to give a brief update of a previous post on Facebook demographics. What follows are recently published number of users by country and region, along with growth rates for select regions and countries. Over the last four weeks, the fastest growing regions were South America, Central America and the Carribean:

While Facebook grew double-digits in Asia it did so from a relatively small base (approx. 3.7 million users), in a region with hundreds of millions of potential users. Of the countries in South and Central America, Chile is worth highlighting (up 67.5% from four weeks ago). As several Radar readers predicted, Facebook has grown steadily in Chile where it now has over 2.2 million users (around 14% of the population). In other parts of the Americas, Hi5 and Orkut remain the largest social networks:

Looking closely at the top 30 countries, a few European countries have grown more than ten percent over the last four weeks (France, Spain, Germany, Italy), with France having the most number of users (approx. 2.5 million). Skyrock remains the largest social network in France. Norway saw a decline but is still home to more than a million Facebook users. We will continue to track how Facebook is doing vis-à-vis other leading regional social web sites and whether their disputes with other companies affect their growth rates.

As far as recent trends in the Facebook app platform (the subject of this week's f8 conference), we have detailed reports (here and here) on the subject. At the last Graphing Social Patterns conference, Roger Magoulas provided highlights of our most recent findings. The number of published apps continues to grow steadily (to over 32K) but total usage remains flat. Besides the fact that the top 10% of apps account for 98% of total usage, aspiring Facebook app developers should know that only about 6% of apps average at least 500 active users per day:

(For specific tips on how to launch and build successful Facebook apps, consult this O'Reilly Radar Report.) Finally, as I noted in a previous post, the most popular applications on the Myspace platform continue to account for slightly less users than their Facebook counterparts.

Before Google’s 3D chat world Lively was released, the product was called Google Rooms. Here are some left-over screenshots that we discovered on Google’s servers shortly after Lively was launched:

The Google Rooms logo used in the rooms directory, showing a palm tree from the island room

Selecting an avatar from the directory, which included URL references to Google’s 3D Warehouse

The login dialog for the Goth Room; this looks more like traditional minimalist Google style than the current Lively login dialog

The FAQ part of the long help page that Google had for this service

The avatar dialog, taken from the “Create” section of the Getting Started Guide

The list of character animations, taken from the “Communicate” section of the Getting Started Guide

Also see the Lively FAQ.

[By Tony Ruscoe | Origin: Google Rooms, the Early Lively | Comments]

[Advertisement] Google books at eBay: background info on Google, AdWords, AdSense, Blogger and more...