"But more revealing was the scene after the party. Well after the other guests had gone, Jobs stayed to tutor the boy on the fine points of using the Mac. Later, I asked him why he had seemed happier with the boy than with the two famous artists. His answer seemed unrehearsed to me: 'Older people sit down and ask, "What is it?" but the boy asks, "What can I do with it?"'"
PlayBoy's 1985 interview with Steve Jobs.
So, looks like the Nexus S can run MeeGo too :o) have a custom kernel going and booted the OS from a rootfs image on the internal memory (didn't have to flash!), but as you can see the display output is fscked (maybe due to the AMOLED?) and the touchscreen isn't working either.
But… I think this is the first non-Android OS running on the Nexus S so far, so thought it was worth a post! Watch this space…
So if you're insane enough, you can try it yourself right now…
You will need to build a MeeGo rootfs first, in ext2 format. Use my kickstart as a base, it has a few niceties like adb support (i.e. the only way you can interact with it right now). With your image successfully compiled, copy it to linux/rootfs.ext2 on your Nexus S' internal memory (completely safe, no flashing required).
My boot.img is here - you will need to use fastboot to boot it (fastboot boot nexuss-meego-boot.img), or you can flash it to recovery if you want to dual boot.
As seen in the photo, you won't really be able to see anything onscreen, but you can use adb to get a root shell like on any Android device. Poke around, play with it, improve upon it, etc. Actually going much further than this is beyond me unless I can find some talented kernel hackers with Nexus S hardware to test on.
Go nuts!
Matching XDA-developers thread here.
Well, this is more of a side note, but Ubuntu runs fine on the Nexus S using the same process. Check the XDA thread for more info.
While bored today, I decided to take a look at getting MeeGo running on the HTC HD2.
The HD2 is very similar to the Nexus One hardware-wise, and MeeGo is already known to run on that, but as far as I know, nobody had ever got it running on the HD2. I set to work, and a few hours later we were up and running!
I followed the instructions at MeeGo's MSMQSD wiki page as I'd done previously for the Nexus One. I didn't deviate much from the instructions at all, except for having the kickstart file produce an ext2 image.
Using the latest kernel from Ubuntu for HD2, and a slightly modified initrd.gz from the same package, I combined these with the MeeGo rootfs image, and with a little tweaking I got as far as the homescreen.
I cannot get the touchscreen working for whatever reason (I'm a n00b, go easy on me), but I did install Android's adb daemon so I can get a shell over USB (which is how I ran the apps in the screenshots below).
Plenty of things aren't working, the touchscreen being the most egregious, like WiFi, graphics acceleration, etc. But it's a start. Anyway, MeeGo is finally running on the HD2, so I thought I should share the story :-)
The HD2 seems unique in its hacking potential, as it can run Windows Mobile 6.5, Windows Phone 7, Android, Ubuntu and now MeeGo - if you ever get a chance to pick up one of these devices, do!
I have the touchscreen working mostly now, using a different kernel. I'll update this post when I have real info.
Touchscreen and WiFi are now both functioning, but neither are working properly (touchscreen registers clicks as drags, and wifi won't assign an IP address to the interface after connecting). Working on it…
When you run extract2g (-4 -A) against the iPod firmware.MSE file, you end up with nine partitions. Eight of those are encrypted, so not much use right now (asides disk.fw and osos.fw, which you can force-boot using iRecovery). The ninth partition is the resource partition, which is not encrypted, so you're able to extract the contents (a FAT16 disk image, no less).
Use the following command to strip the header and extract the file:
dd if=rsrc.fw of=rsrc.img iseek=2 count=284672
(If you're not working from the 1.0/36A00403 firmware bundle, you can strip the first 1024 bytes from the rsrc.fw file, and run fdisk on it to find the sector count - 'fdisk -e rsrc.fw'. For the 1.0 bundle, the sector count is 284672).
Double-click the resulting .img file on Mac OS X to have it mount so you can browse it. There's not a lot of interesting stuff there (fonts, etc), but there are two files of interest: SilverDB and SilverImagesDB. SilverImagesDB contains all the image resources for the OS; wallpapers, icons, buttons, etc, including some curious leftover pieces like camera shutter images.
'Silver' I presume is the name or codename of the UI framework on the iPod's Pixo OS (similar to how 'Purple' was used to describe iPhone apps).
Maybe once we find a way to flash a modified rsrc partition back to the iPod (remember, it's not encrypted) then you should, in theory, be able to modify wallpapers and other images/resources.
After musing with James Whelton about his iPod nano homescreen hack (http://nanohack.me/), I set out to see if there was anything interesting you could do to the iPod.
Discovered what may be DFU mode: hold down the restart buttons until you get a black screen (it reboots twice) and iTunes sees the device and alerts you.
Afterwards, modified iRecovery to work with the iPod nano (had to add its DFU/Recovery USB ID) and allow it send files, and tested with some files I had extracted from the iPod nano 6G firmware (using the extract2g tool somewhere from http://www.freemyipod.org/ ).
disk.fw and osos.fw work (one boots disk mode, the other boots to a homescreen). The other files make the nano boot to a white screen, but go no further.
So, basically, it seems we can send encrypted firmware files to the iPod, and have them execute, similar to what is used to jailbreak the iPhone. If the nano rejects the file (i.e. unsigned, invalid), it reboots.
While this by itself isn't that cool, hopefully the info will inspire someone else to finally hack this thing and give us custom 'apps'.
Make sure to click '720p' to see what's going on.
Finding the whole 'carriers and manufacturers can have their own app store section' situation on Windows Phone 7 quite interesting.
Basically, the carriers and manufacturers of the devices can offer their own exclusive free/paid apps to their customers only, and have a dedicated category in the Marketplace for such. Furthermore they get access to the native SDK so can do things way beyond what apps built with the public WP7 SDK can do (i.e. DLNA streaming, augmented reality, hardware access, etc).
For example, LG offers an application on the Marketplace (that only their phones will see) that allows you change APN/carrier settings to match any market in which LG has a device; something you can't do with the standard APN settings on Windows Phone 7. There are definitely some other very cool free apps from LG;
You can also re-download any of the bundled apps (that you may have deleted when buying the phone).
It's a fascinating solution to the carriers-have-no-power situation on iOS, and carriers-have-too-much-power on Android. I think it's the perfect compromise.
In late 2009 a rumor floated that Microsoft were going to start from scratch with their Windows Mobile OS. At the time, I thought about how cool it could be, but it didn't sound like something Microsoft would ever do.
Well they did it; in about 18 months they started from scratch and created something wholly original and non-derivative of the iPhone, and it's even cooler than I had ever imagined.
Windows Phone 7 is a fresh start, designed around all the principles that Apple has made essential to the modern smartphone market. High-spec hardware, thoughtful and powerful design, multitouch ingrained into the core of the OS, smooth visual performance and animation, a singular app store model and comprehensive developer support. The UI concept is surprisingly (for Microsoft) thoroughly thought out, with minimal chrome - making the content center-stage. The design language, Metro, used throughout the OS is very modern and beautiful, albeit certainly not for everyone.
Windows Phone 7 'just works' in a way I've never seen a Microsoft product do; add your Google and Facebook accounts to the device, and suddenly your contacts are enriched by data from both services, including pictures, status messages, addresses, contact details and more. No setup required, it's all built-in. Your Facebook timeline is displayed in the Contacts app, allowing you to check up on what your contacts are doing. The entire experience is very pleasant. Similarly, the Photos app will show your albums from Facebook and Windows Live too, as well as a Facebook timeline of photo postings from your contacts, of course allowing you to comment on them. Photos taken with the onboard camera will also automatically upload to your Facebook or Windows Live accounts if you so opt.
While the first-party, native apps on the OS are really great, third-party apps are a bit of a mixed bag. They are created using Silverlight, and themed to match the rest of the OS. As such, while they make a good attempt at it, you can still tell that they're not native apps. Controls work in different ways, keyboard input is slightly sluggish, and performance isn't consistent. Naturally, since this is the first ever version of Silverlight on a smartphone, there's a lot of performance that can be added and issues fixed with software updates in time. The most egregious problem however is multitasking, or the lack thereof. This wouldn't be so much of a problem if third-party apps launched instantly, and didn't quit if you locked the screen, but right now both problems are very obvious - apps can take three or more seconds to launch at their fastest. I have no doubt that Microsoft will enable multitasking along with copy & paste in the next year, but right now it's a frustrating experience. The worst part for me is when you lock the screen while running a third party app: when you unlock the phone, the app will start resuming - if you hit the home button before the app finishes, the app will continue launching in the background and the phone will switch back into the app after it's done (even though you explicitly told the OS to go back to the homescreen). Nonetheless, I have been consistently surprised with the quality of third-party apps on Windows Phone 7, all things considered. Furthermore, even the most badly written app still inherits the charming Metro style and fits in very well with the OS.
I have been using an LG Optimus 7 as my main phone for a few days now, and months ago I spent a few weeks with a prototype LG WP7 device as my primary phone. I would be remiss if I didn't say I adore it; the Optimus 7 is very sleek and feels like a premium device, and Windows Phone 7 itself makes me smile every time I use it, as the Zune HD did (it being the first touchscreen device with an earlier version of the Metro design). The seamless service integration really makes the OS pleasant to use, and, since the iPad is my primary Internet device, I am not missing the iPhone one bit.
Microsoft set out to create a new phone platform that was as good as the iPhone, yet offered a rich choice of devices and form factors so that users can choose the one they want. There are clearly rough edges, but nothing that cannot and will not be fixed in due time with software updates. Microsoft really have bet the house on the idea of a consumer smartphone; this isn't going to appeal to the kind of people who choose Android, but it will appeal to the vast amount of people who don't yet own a smartphone. It may even appeal to many iPhone users (as I said, I adore the OS, no less). For a company whom everyone had expected to fade into irrelevance in the smartphone business, Microsoft has pulled a remarkable 180°. I can't wait to see where this ideology leads them; maybe one day they'll rewrite Windows from scratch too ;-)
Just to keep you informed, Speed and Lights Off are now fully Retina Display ready, joining the previously-updated SameGame.
Aside from that, they have much better support for iOS 4's multitasking, and Speed takes advantage of new features in iOS 4 to be more accurate than ever.
All are free updates, so go get them now!
Until a week ago, I knew virtually nothing about MeeGo. I had known it was an attempt by Nokia and Intel at creating a new OS for Nokia's smartphone line, and that was about it.
This week I attended MeeGoConf on a whim, as it was being hosted in Dublin so I wouldn't have to go out of my way to attend. As a direct result, I have been bitten by the MeeGo bug; there is so much potential here that I never would have expected given its heritage.
MeeGo is less about Nokia trying to be relevant, and more about the open source community creating the future Linux OS for embedded devices (smartphones, tablets, netbooks, in-vehicle entertainment and television). It's a full Linux distribution, a MeeGo 'Core'. For each device platform, there's a corresponding 'UX' (User eXperience); if you install the netbook version of MeeGo you're seeing the 'Netbook UX'. Evolved from Moblin, the Netbook UX is the most far-along and usable of the UXes.
Intel went out of their way at this conference to prove MeeGo to the attendees; what better way to convince someone something is worthwhile than to provide them with it for free and let them just use it themselves? Intel did just that, giving each of the ~700 third-party attendees a free Lenovo IdeaPad tablet netbook running MeeGo (to satisfy the nerdy body of attendees, everyone had to install the OS themselves from provided USB keys; the choice at collection was 'Broadcom' WiFi driver or 'open source' one :o) ).
MeeGo's Netbook UX is really well suited to touchscreen devices, and I was blown away by how smooth and responsive input was (stark contrast to Windows 7 on a touchscreen). I knew this was just the tip of the iceberg however, and I wanted to get the Handset (smartphone) UX up on running on my new tablet. A bit of massaging later (I lie, a *lot* of massaging - I now have the entire filesystem memorized) and I had my IdeaPad set up so I can switch between Netbook and Handset UX at a whim.
I went on a hacking spree after that, forcibly installing MeeGo on both my N900 and Nexus One. Right now, the Handset UX isn't usable for anything. It's just a pre-alpha glimpse of something with great potential. My N900 had previously convinced me that maybe Nokia wasn't going to wither into irrelevance after all (the OS, Maemo, that preceded MeeGo is very slick, and a stark contrast to Symbian S60), but now I'm downright excited to get my hands on a real MeeGo device, like the forthcoming N9.
MeeGo looks like it has legs, and is a distinct, user-friendly OS. But, influenced by the N900 that came before it, MeeGo is also a hacker's dream. A fully open-source OS that has a full Fedora-based Linux distribution under the hood and can potentially run desktop apps without issue (MeeGo's Netbook UX is a better Chrome OS than Chrome OS itself!). There's definitely another 6-8 months work before consumers can be entrusted with it, but from listening to the sessions all week it's clear that the people in charge are on the right track and know what they need to do to match the competition in the user experience space. I only hope that, like the N900, MeeGo handsets retain the Terminal app on the homescreen and the built-in SSH server. :-)
Today, Apple released Mac OS X v10.6.5 which was supposed to bring AirPrint to any printer connected to your Mac. Only problem is, a last minute issue (due to patent trolling?) has caused them to pull support for AirPrint in OS X.
Don't panic! You can return it, but you're going to have to pull some files from a prerelease version of 10.6.5.
The files you need are:
If you migrate those from a 10.6.5 prerelease build (there seem to be many floating around torrent sites and file sharing sites - build 10H542 works; naturally I can't link you to the files themselves, sorry!) to your machine you're just one step away from having AirPrint working.
The final key thing is you have to remove and re-add your printer in the Print & Fax preferences pane. Once you do that (and share your printer in the Sharing preferences pane) it should show up on any iOS devices that support AirPrint.
Nerdy extra info: Basically, doing this should add the image/urf mimetype to your shared printer, and a new Bonjour field 'URF'. Once you have those, it should work. Theoretically, there's no reason someone can't write a server application that broadcasts said Bonjour info and prints for you, so you don't have to use files from a prerelease build. I would expect something like that to appear over the next few weeks.
Thanks to Patrick McCarron for helping me debug this method
Good luck!
On Wednesday, Apple revealed their plans for Mac OS X 'Lion', which will bring a lot of ideas and research from iOS to the desktop.
A lot has been made of Apple's new 'Launchpad' feature; basically a re-imagining of the iOS home screen for the desktop. It makes a lot of sense, application discovery, installation and removal has always been problematic on Mac OS X. But it also signifies something far more interesting for the platform - the idea is to create an abstraction between your 'Applications' and the /Applications folder on your hard disk. Maybe in an OS release or two, you won't even have an Applications folder on disk anymore - all your application access and management will happen through Launchpad.
This signifies, at least to me, a move away from the files and folders model of interaction with computers. As with iOS, the location the applications are stored in becomes an implementation detail. In the very near future, we may not even need a Finder app to browse our hard disk; folders just become metadata, and everything lives in a global 'soup' (Apple Newton users will be familiar with this idea).
According to rumors I've heard, and evidenced in the demo of Lion given, apps in 10.7 also do not seem to differentiate between 'running' and 'onscreen'; there is no indicator in the Dock when they're open, and when you quit them and reopen them they re-launch in exactly the same state you left them. You effectively do not know what's running or not without a window onscreen. It sounds like an insane change, but actually isn't if you think about it: in the near future, there may not be a speed difference between something being 'in-RAM' or on-disk, if the two storage media are equivalent in speed (SSDs, while still a long way off, are getting there). If disk access is as fast as RAM access, what *is* the difference between 'quit' and 'offscreen'? There effectively is no difference. It may be a bit premature for 2011, and perhaps this decision will be reversed by the time Lion is released, but it's an interesting view of the future.
Apple also announced plans for an App Store on Mac OS X, something I've seen coming as a logical conclusion ever since it came to the iPhone. Feelings are mixed about this, but it doesn't matter - in the next few months the App Store is going to become the dominant distributor of Mac applications and developers will be scrambling to retrofit their software to abide by the store's rules. Whether the walled garden is good or evil, there's no doubt that it will change the desktop computing landscape just as it did in mobile.
Right now, you can't use the same application ID for your iOS app and your Mac App Store app. I think it's conceivable that in the future there will be no difference between a Mac and iOS app binary, so I can understand why they don't allow you reuse the same ID across both platforms.
Speaking of App Stores, I find it curious that neither Dashboard Widgets nor Safari Extensions have received an App Store of their own yet; I can definitely see both getting their own integrated stores eventually, as it just makes too much logical sense. I'm totally against putting either in the Mac App Store, however; that would defeat the purpose of a single-purpose, streamlined store.
Still no mention of iBooks on the desktop either - I've always imagined that Preview would gain such capabilities, but it's also possible that a standalone 'iBooks' app for Mac is coming.
Apple devoted quite a lot of stage time to talking about multitouch on the desktop, and saying how their solution is their powerful multitouch trackpad. They reason that touch screens don't want to be vertical, and they're fully right. Unlike many in the media, however, I certainly do not interpret this as Apple saying they won't implement multitouch screens on the Mac line. On the contrary, they kept saying how *vertical* touch screens don't work. This leaves them wide open to introducing horizontal touchscreen Macs, and they have many patents on such ideas so have obviously been working on them. Don't be surprised if in a year or two Apple introduces real touch screens to the Mac.
Lion looks to have much better, integral multitouch gesture support, which is going to be awesome for pro users. Right now the mouse is generally a point and click affair, but with multitouch it turns into something far more like a practical version of the Minority Report UI; every flick, swipe, pinch, rotate has a function in the OS.
This is also a big one - of course, people have defended iOS' unitasking and fullscreen apps saying it allows them focus better on whatever they're working on on iOS. There's a lot of truth to that, and it will be interesting to see how much of a difference it will make on the desktop. I definitely feel more at-peace and relaxed when unitasking on the iPad (this blog post was written on the iPad, for reference).
The contextual UI is something that interests me a lot; quite apparent in the iLife demos, specifically iPhoto, is a lot of contextual UI. It appears when it's needed, just like on iOS. It doesn't clutter the screen when not needed, and it shows up near the object you're interacting with instead of in some global toolbar or sidebar. I believe this is going to be a big thing as Mac OS X assimilates more of the design philosophy of iOS. It's definitely going to be a big deal on smaller screens, like the 11.6" MacBook Air. Mac OS X is also losing the permanent scrollbar, replacing it with a contextual scrollbar (again, just like iOS).
There's so much coming in Lion that they've shown already, way more than I expected. I was expecting Mac OS X and iOS to become far more similar, but not this soon! Even now, it's clear that Lion is going to change the Mac landscape vastly, and the App Store is going to have a huge effect on Microsoft's planning for Windows 8. The stringent rules on the App Store will be a pain in the ass for Mac developers, but it will end up accelerating the evolution of the Mac platform immensely (no private APIs, no external dependencies beyond what ships with the Mac OS, no writing outside of specific locations - it will allow Apple to make huge and rapid changes to Mac OS X without worrying about backwards compatibility).
For the first time in many years, I am actually excited about the future of desktop computers. The iPad hasn't killed the Mac, it's brought it to a whole new level.
I guess it's no surprise that the new iOS-based AppleTV was jailbroken instantaneously on release, but as the former AppleTV plugin developers race to the new platform to disassemble it and get their own plugins up and running on the new system, I can't help but wonder how the future of AppleTV will play out as regards developers.
It's widely rumored that Apple will open up the AppleTV platform and create an 'App Store', allowing developers write apps for the big screen. It seems almost inevitable that they will make this play, if not to compete against Google TV then to at least make the AppleTV a relevant platform; leverage against the movie studios reluctant to agree to Apple's movie rental terms and who knows what else.
What I don't see is an AppleTV SDK being built around BackRow, the current framework that provides the UI on the device. Previous AppleTV plugins have all been built for BackRow, using a framework that is decidedly not very Cocoa-like or developer friendly. They have nonstandard design patterns, and they run as actual plugins to the UI process; a crashed plugin can currently take out the entire UI. From what I've seen (and I've been using it since the original AppleTV hacks back in 2007), the BackRow framework is not fit for third party developers and was never designed to be.
Assuming Apple does launch an App Store, then, how are we going to write apps? The only option I see is UIKit. UIKit is familiar to all iOS developers, is very Cocoa-like, and very powerful. In fact, since iOS 3.2, 1280x720 (720p, or the same resolution as AppleTV) is a supported resolution for developers, mainly for those creating TV-out UIs in iPad apps (Chopper 2 is a great example of this). Developers have already started crafting ten-foot-UI experiences in existing iOS apps, so it would be a no-brainer for that to translate over to AppleTV wholesale. To make it work, Apple would have to build remote control support into iOS… - but hold on a second, Apple already added that in iOS 4! Effectively, all the pieces are in place to build a remote-control driven 720p iOS app. All Apple needs to do is build the distribution mechanism and open the floodgates, and 'Universal' apps would be a definite possibility.
Of course, some people will complain that UIKit isn't the native UI for AppleTV; our apps will look and act differently from the native experience on the device. Point taken, and it's an important one; I think Apple could effectively build an AppleTV UI framework on top of UIKit that internally uses the BackRow APIs but offers the developer a much cleaner way to implement common features. Does it need to happen? No, but it would certainly feel unfinished if they didn't do it. Then again, Apple can be surprising: I'm still astounded they let the iPad ship with that horrific iPhone app scale-to-2x support :o).
Little infographic for you; executive summary - the iPad in its first quarter of sales accounts for almost twice as much revenue as all desktop Mac sales.
Puts the future in perspective, don't you think?
Taken from Apple's financial results PDF.
By now, most developers have got their hands on iPhone 4 and run their old iPhone apps on it. And I'd like to think that they, like me, are appalled at how terrible they look on the new Retina Display. The screen is just so amazingly sharp and vibrant that your artwork will look like crap unless you get it redone.
Cue the sound of a hundred thousand developers' voices suddenly crying out in terror.
Why? Updating your artwork for the Retina Display is a time consuming and expensive process. iPhone artwork often costs thousands of dollars to produce in the first place, and if you have to go back to your artist to get it all redone (possibly from scratch, if they didn't think to design with vector shapes) then you're looking at a significant cost just to get your app to a passable visual state on the iPhone 4.
Those with in-house designers are at an advantage here, but for those of us who work alone it could well be a nightmare.
My plan is to have Retina-Display-ready app updates as soon as possible. I have already redone all the artwork for SameGame myself (and it looks stunning, to be honest), and Grace and Speed will follow with minor updates (in that order). Lights Off will require huge effort, so as of right now I'm not promising any release dates (just as with the Universal update, there's too much going into it to give a timeframe). Hopefully you'll start to see the others soon enough.
For those developers who haven't yet seen their app running on a Retina Display, start freaking out right about now. If you think you can get away with not redoing your art, you are sorely mistaken. :-)
PS: That Retina Display is like nothing I've ever seen. It changes the way you view computer screens forever. You can never unsee pixels on other displays again.
