What I Think About the iPad

Yesterday, a friend asked my opinion of the iPad (“If it can’t print what’s the point..?”), and this morning, Michelle asked me about whether it would be a good device for teaching, working on documents and presentations, etc. My answer to both is: It depends.

For one, it’s difficult for me to provide a completely objective review – this device is intended to evoke emotion and that’s exactly what Steve Jobs wants – you are *supposed* to fall in love with the iPad. Secondly, I do not own an iPhone nor an iPad – I’ve played with other people’s iPhones quite a bit and have not seen an iPad in person, yet. So, if you absolutely adore your iPhone, compare every other handheld device to it, and within 30 seconds declare that all other handhelds are bred of lesser mobile genes, sleep with it not just on the nightstand, but perhaps under the pillow, then you may wish to stop reading.. I have an opinion or two.

First and foremost, Apple is crazy brilliant at marketing. Everyone is iPad-caffeinated right now because deliveries have started and people now have these devices in their hands and flooding the twitterverse with their excitement – same has happened with each iPhone hardware and software release. There is love in the air, and Apple loves you for loving them. People do not do the same with ThinkPad hardware releases and Windows updates (unless MS breaks shit, which happens..)

There is a lot to love with the iPad! I don’t want to be a party-pooper, far from it – I want an iPad, too! The form factor is killer – this type of device will definitely change the way people interact with the web, social media, medical patient rounds, watch movies, etc. The physical hardware engineering – the beautiful touchscreen, the weight, the *feel* (yeah.. when I actually get to feel one), the applications – these type of devices *will* change the Internet world, so I would like one, too, please.

Will I buy one? Should you? That depends.

I probably won’t – not unless Apple comes out with a compelling Gen2 iPad.. Look around at some of the (non-iFanBoy) reviews in the last couple days: no camera (the chassis has the identical insert as iPhone’s camera CCD, so it will eventually get one), no multi-tasking, difficult data transfer, etc. For me to be compelled, at the very least, Apple needs to allow me to run more than one application at a time, if I would consider it anything more than a browsing toy. I think the #1 design failure of iPad was basing the OS off the iPhone OS, as opposed to a mobile port of OS-X, but I understand the business decision. The iPad is a fantastically gorgeous toy and if that’s your thing, it is something you should absolutely have! Go get one! Just don’t expect to do any actual work on it, unless your work is directly related to the social media arena – even then, I would almost guarantee that you will still do most of your *real* work on a laptop or desktop. After all, Apple doesn’t want to kill their laptop business, do they?

http://www.businessinsider.com/i-really-hate-what-apple-is-trying-to-do-with-the-ipad-2010-4

“If it can’t print what’s the point..?” – Can your iPhone print? Yeah, that’s what I thought. With the Gen1 iPad, you get essentially a neutered iPhone (it can’t make calls and no camera) with a big screen and a few extras like a very, very cool eReader and the potential to run iWork. You can absolutely work on documents, presentations, etc., but you can do that efficiently only if you do it the Apple way. If you have existing documents you wish to load up on the iPad, I understand from second-hand knowledge that it is rather difficult. Things will get better, and people will figure out how to do some work on the iPad (do you *work* on your iPhone?) – there will be some cool apps that make interesting use of the screen real estate, for sure, but..

The apps.. you really only get one choice of where to shop for your applications. And the iTunes App Store has full control over the extent of your freedoms. If you keep your entire music and video media collection in iTunes, and if you are fine with paying for almost every song and every piece of software you use (some are free), and if you either you don’t know anything about, nor understand, nor really care about software freedom, then by all means keep doing what you are doing – it is a system that really does work well. Apple does this very well – the Apple ecosystem is very functional, very pretty – even sexy, but you are bound to it by design. This ecosystem (and that’s really what it is – a technological island environment with a wonderful array of cohabitating hardwares and softwares that compliment one another – if you have the ability to build your own boat and can brave the waters, you can do some cool things outside of Apple Island) does not go well with my philosophy and beliefs in Open Source Software (google it, non-techies..) and the extreme idiocy of a great deal of software patents granted in the last 10-ish years. (sidenote: New Zealand is considering a patent reform bill that bans some forms of software patents)

http://computerworld.co.nz/news.nsf/news/thumbs-down-for-software-patents-in-nz

So where I am going with this.. buy an iPad, but don’t expect it to be something that it is not. You might want to wait until they come out with the next version – the iPhone 3G kicks the pants off the original.

I truly believe that this type of device is the perfect (although not yet perfected) device for non-technical users – I’m fairly convinced that my mom would learn to love it. You really don’t have to think much, once you figure it out; the UI and the UX are wonderful; the hardware/software island leads to little (I hope) in the way of trouble from trojans and other exploits.

As a good schizophrenic, yeah, I would love to have an iPad. I love computing devices and I could certainly find ways to use an iPad that suit it’s design very well and it would be fun. Most likely I would hack it – I’ll build my boat (using boat plans of more talented boat designers than I), see how far I can travel off the island, and wave back at the curious looks from the sheep on the beach.

I’d guess that more likely, if I decide to spend money on a keyboardless tablet, I will get something in the same form factor, but one that allows me to have the ability to use Open Source Software, one that allows me to run an email client *and* browse the web at the same time(!), and most definitely one that has a kick-ass SSH client (is there a good one for iPad?) – much of what I do is on remote servers, so SSH is an absolute must.

Update: I understand there are a couple really good SSH apps – this alone might be the “killer app” for me.

http://eu.techcrunch.com/2010/03/19/apple-ipad-how-about-a-little-german-innovation-instead/

I’m a bit of a nutcase when it comes to free software (free as in speech, not beer) – just ask my mom how fired up I get in conversations about technology.. I breath it. I tattooed it on myself. So take my words with a grain of salt, if you wish – these are only the opinions of a highly opinionated technology advocate.

Debian Tattoo

PmWiki Clean URLs on nginx

Building on yesterday’s post on setting up PmWiki on nginx, I figured out the nginx configurations for PmWiki Clean URLs.

First, copy the example config.php out of the docs/ directory to the root of the PMWiki site, in my case, I installed to $DOCROOT/pmwiki/:

cd $DOCROOT
cp pmwiki/docs/sample-config.php pmwiki/config.php

Following the Clean URL notes, in pmwiki/config.php I set:

$EnablePathInfo = 1;

then I hit the wiki front page and started to look at the resulting link URLs like http://wiki.example.com/pmwiki/index.php/Main/WikiSandbox – they all 404 at this point, but this gives an idea of what I want to do next. I want to get rid of the /index.php/ bit, first, so in pmwiki/config.php I set:

$ScriptUrl = 'http://wiki.example.com/pmwiki';

This worked – the resulting URLs are like http://wiki.example.com/pmwiki/Main/WikiSandbox – but, let’s make that a little more portable for other vhost names or aliases and set it to:

$ScriptUrl = 'http://'.$_SERVER['HTTP_HOST'].'/pmwiki';

This works perfectly – now to take care of all the 404s with nginx rewrites. From yesterday’s config, I added the “location /pmwiki” and “location @pmwiki” blocks – here’s my complete nginx server configuration:

server {
  listen 80;
  charset utf-8;
  server_name wiki.example.com;
  access_log /var/log/nginx/wiki.access.log;
  root /var/www/wiki;
  index index.html index.php;

  location /pmwiki {
    error_page 404 = @pmwiki;
    log_not_found off;
  }

  location @pmwiki {
    rewrite ^/pmwiki/(.*)$ /pmwiki/?n=$1 last;
  }

  # configs from pmwiki .htaccess files
  location ~ ^/pmwiki/(cookbook|local|scripts|wiki.d|wikilib.d) {
    deny all;
  }
  location ^~ /pmwiki/docs {
    autoindex on;
    types {
      text/plain php;
    }
  }

  # pass PHP scripts to FastCGI server listening on 127.0.0.1:8080
  location ~ \.php$ {
    fastcgi_pass 127.0.0.1:8080;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
  }

  # deny access to all .dot-files
  location ~ /\. {
    deny all;
  }
}

If PmWiki is installed in the document root of the site (not under http://…/pmwiki/), then adjust the ScriptUrl in config.php:

$ScriptUrl = 'http://'.$_SERVER['HTTP_HOST']'';

and the nginx config blocks above to:

  location / {...}

  location @pmwiki {
    rewrite ^/(.*)$ /?n=$1 last;
  }

  location ~ ^/(cookbook|local|scripts|wiki.d|wikilib.d) {...}

  location ^~ /docs {...}

PmWiki on nginx

I’ve been looking at a few wiki packages for a project and found PmWiki to my liking – under active development, a nice default skin, easily customizable, and it does not require a database. My personal choice is ikiwiki, which I run on my laptop for quick notes, but since this project is for a non-technical user, I decided to look first at end-user ease of usability, the availability of free themes, and possible integration with WordPress in the future.

The vast majority of web software packages assume that the admin is running Apache. It is always fun and interesting to sort out how to incorporate the various configurations for nginx, when most of the software packages only document mod_rewrite rules or just throw things in .htaccess files.

This is a very simple install of PmWiki focused only on getting the nginx configuration right. This assumes that you already have an nginx site configured to run PHP scripts through fastcgi – I’m not documenting that here.

Grab the source tarball from the Download page on http://pmwiki.org/, or use Subversion to fetch the latest stable release ($DOCROOT is your site document root):

cd $DOCROOT
svn export svn://pmwiki.org/pmwiki/tags/latest pmwiki --force

Now, hitting the URL in a browser ($HOST is your site, of course) – http://$HOST/pmwiki/pmwiki.php – you should see a little note about PmWiki needing write access to the document store directory – a quick permissions change:

chmod 2775 pmwiki/

Then hit the URL again – you should see the Main page of PmWiki after it does it’s configuration 🙂 but no so fast! Secure that directory now that we are basically done installing:

chmod 0755 pmwiki/

Follow the notes for adding a one-liner wrapper index.php if you like.

OK, so PmWiki should be working, but probably has some hidden configurations:

$ find pmwiki/ -name .ht*
pmwiki/scripts/.htaccess
pmwiki/cookbook/.htaccess
pmwiki/local/.htaccess
pmwiki/docs/.htaccess
pmwiki/wiki.d/.htaccess

Yep.. each of those .htaccess files, except pmwiki/docs/.htaccess, is a “Deny from all” so that files in those directories cannot be accessed publicly. I also added the directory pmwiki/wikilib.d/ which has the default local PmWiki documentation files and other local wiki pages – OK.

pmwiki/docs/.htaccess is a modification of mime type, so that any files in that directory ending in ‘.php’ will be rendered as plain text – ah, the sample config.php is in there – OK.

Here is my resulting nginx vhost configuration for wiki.example.com (replace with your own server_name and site root directory):

server {
  listen 80;
  charset utf-8;
  server_name wiki.example.com;
  access_log /var/log/nginx/wiki.access.log;
  root /var/www/wiki;
  index index.html index.php;
  
  # configs from pmwiki .htaccess files
  location ~ ^/pmwiki/(cookbook|local|scripts|wiki.d|wikilib.d) {
    deny all;
  }
  location ^~ /pmwiki/docs {
    autoindex on;
    types {
      text/plain php;
    }
  }

  # pass PHP scripts to FastCGI server listening on 127.0.0.1:8080
  location ~ \.php$ {
    fastcgi_pass 127.0.0.1:8080;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
  }

  # deny access to all .dot-files
  location ~ /\. {
    deny all;
  }
}

This should give a working default PmWiki site running on nginx with the same functionality and secured directories as if you installed on Apache – make sure this basic setup is working right before moving on.

Next configuration steps for my install will be rewrite rules for shortened clean URLs.

Update: here’s the next post on PmWiki Clean URLs on nginx