* Boot OSX and run the Disk Utility tool. Create a new partition using the free space in your HD. Don’t format it, just leave it as free space.
* Download and install rEFIt. Once you’ve done that, you can setup Linux as the default OS by editing refit.conf and uncommenting #legacyfirst.
* Insert Ubuntu’s CD and restart.
* Hold the ALT key while booting up so you are offered all boot options. Select Ubuntu’s CD and install.
* DONE.

No need for Bootcamp or anything, it’s as simple as that.

Just a note about how I’m installing Ubuntu these days. Read sometime ago somewhere (sorry, no link) about being able to reinstall Ubuntu without losing your data. It goes like this. When installing Ubuntu, choose manual partitions. You need to create 3 of them, in this order:

* System partition: pick up the space you want, but 15 – 20gb should be enough since it’s going to be for the system only. Select “/” as the mounting point.
* SWAP: select it on the combo and pick up at least the size of your RAM.
* Everything else, for the home partition. Select “/home” as the mounting point.
* DONE.

Now, next time you want to reinstall Ubuntu, if you follow the same partition scheme, you will boot up to the new system and all your data will be there. And with “all the data” I mean all the data: bookmarks, browser history, files, subversion sites and credentials…. Since in the Linux world all user data is (or should be) stored in your home directory, and you don’t touch that one when reinstalling, you boot up to a new system with your old data in place. I call that a “dirty” installation as opposed to a “clean” installation when I back up all the files and completely wipe out the hard disk.

As per Ubuntu on the MacBookPro, it’s going fairly well. Haven’t touched the console for the installation. Just used the proprietary hardware drivers manager (System > Administration > Hardware drivers) for the WiFi and the graphic card. Have to say that after trying the NVIDIA closed drivers I’m sticking with the default ones, seem to do the job for me. Only if you want the F keys to work as normal human beings would expect, you go through this (using the .conf file method).

We are developing at ustwo a very interesting internal little project that needs to run 24/7. By default developers should always be very careful with memory leaks and hogging resources, but with an AIR/Flash app running non-stop every detail counts.

To top it up, the app must handle images, SWFs (AS2, AS3) and videos without going through developers. That means marketing can contact one of the designers, ask s/he to produce someething and put it to display without developer approval. Oh, and all assets are in the network, not in the machine. Scary.

Preliminary tests show we are doing OK, we’ve been running the app non-stop for 4 days without a crash or needing it to reboot. The player takes and releases memory when it needs to, transitions and animations look as smooth as the first day, etc.

Check out below some of our thoughts.

FAIL, FAIL, FAIL

Shit will happen, so be ready to fail. Assets won’t load, video will have the wrong codec, image will be 80mb, network will be down….

That’s Google’s approach to servers. Instead of having a big fat multimillion dollar server, they have a farm of 100 mini-servers and they *know* one or two *will* crash everyday. They’ve build their systems to cope with failure and fail gracefully.

Also embed some default content for when everything else fails.

RELEASE, RELEASE, RELEASE

You must release resources. Explicitly remove every single listener you add, use FP 10 unloadAndStop and if you are in AIR don’t hold references to File objects (more about this in another post).

If you are a good dev, the Flash player will behave most of the times…

MONITOR, MONITOR, MONITOR

…but sometimes it won’t. Or something you didn’t even think was possible will happen in-your-face. You can’t prevent all errors, but you can react when they happen.

At the beginning we were trusting our own app to be its own watchdog, but then we got a nasty crash and obviously the watchdog failed as well. So we’ve created a little haXe/Neko app called “the helper” that is automatically called every minute and that checks the state of our app.

At the moment, the helper is being automatically launched using launchd (fancy cron job for OS X), but that has very interesting side effects (again, more on another post).

The helper checks if our app is running using something like:

And parsing the result for a relevant match. If the app is not running, it starts it again using:

Since we are using AIR 2 beta, we could implement a more refined communication system using the new Native Process API, but for the time being checking if the app is running “the hard way” is enough.

UPDATE, UPDATE, UPDATE

Find a good mechanism to auto-update your app. Most 24/7 apps are unattended apps and they might well be in a different room / building / city / country. But even if you are just a few steps away, you still want to be able to remotely deploy a new version.

We decided to implement our own update system based on GIT commits instead of relying on AIR’s update framework.

LOG, LOG, LOG

Log as much as you can. You’ll be happy you did when you need to find out why your app crashed. Believe me, in this case more is more, even if you face huge log files. If you are a little bit consistent you can always build automatic parsing tools for your logs or just run a simple grep to find error traces.

BTW, we settled for a log file per day to avoid massive log files.

WARN, WARN, WARN

As I said before, most of these apps run unattended, so you want to be notified as soon as possible when there’s an error. You can:

* Use a private Twitter account that people subscribe to.
* Send an email. You can do that from Flash using for example SMTP Mailer and a local SMTP server.

Whatever you do, don’t rely on one method only, specially Twitter, in case is down when the app needs it.

REMOTE, REMOTE, REMOTE

You either enable VNC, SSH or both. If you can’t, then be prepared for walking / driving / taking the bus a lot.

–

I’ll leave the details of running your apps using launchd and the peculiar way in which AIR holds “hard” references to files for another posts.

Our current project at ustwo™ is a PureMVC-multicore application. Sounds really fancy, but it’s only a SWF loading SWFs.

To compile those SWFs we have some scripts using Ant, MTASC, SWFMill, Rhino and other tools. Updating from SVN and compiling 18 modules was taking around 90-100 seconds (that’s updating and compiling the whole project, you can compile single modules much faster).

Keep in mind that our compilation process is a little bit more than calling MTASC. We are running some pre-processing, generating exclude files and some other trickery to gain extra performance (we target mobile devices).

Anyway. Got a hint from one of our developers so I did some research to find a way to speed up compilation time. Since most of us have now dual-core machines we should be able to parallelize some of the work, right? Indeed we can.

Finding PPSS was quite easy but understanding how it to works was a little bit more complicated. I’m not going to bore you to death with the nitty-gritty, so this is the flow that adapted better to us:

* In bash parse the list of module folders and create a txt file containing the path to a script passing to it the path of the module as a parameter. One line per module:

* Feed that txt file to PPSS like this:

That’s where the magic happens. PPSS parallelizes each call to the compilation script using both CPUs. When you run it you can see they go all the way up to 80-90% usage, which is kind of the point.

We took some metrics and found a 40% speed improvement, sometimes even more. If you are a compulsive compiler like yours truly, this saves you quite some time.

Going from the serial approach to the parallel approach wasn’t straight forward. Mostly because I had to split the main script into several scripts and that caused some issues due to my bash programming limitations. This is what I learnt:

* If you execute a script from another, the child doesn’t have access to the variables defined by the parent unless you export them…
* … but arrays don’t get exported.
* Also, you can’t “escalate” exported vars from children to parents. The trick only goes from parent to children (security, I guess).

Anyway. Some more command line black magic under my belt, which is great. The console is a very, very powerful tool that can simplify and standardize daily tasks, which is a must when you are on a team of 10 devs. Not that it is the nicest programming language (actually, it’s pretty ugly), but its ubiquity makes learning it worthwhile.

++ Open Script Editor and type this updating the name of the VM you want to launch:

++ Save as Application Bundle and check Run Only.

Off you go.

Thanks.

I think he and many others are right to think that targeting Windows is the most effective way of spreading a virus because it’s present on most computers out there. But the more Linux and Macs grow, the bigger the reward will be for whoever cracks them down. Same old story as with Firefox.

But what the article doesn’t say is that out of the 3 one is Open Source. And that’s a big deal to me. Finding bugs in Open Source projects is indeed veeeeery easy. You can either go to their bug tracking system, check out the change log or simply diff the latest version with the previous one. Piece of cake. Now you know what security bugs they’ve fixed so the only thing remaining is finding out previous version already installed and you are good to crack.

So, what you think it’s more secure, Firefox that makes all this information publicly available or IE with its security through obscurity? I have no doubt.