I’ve always been slightly bemused by the existence of networking over Firewire; on the surface it seems like such a minor corner-case. Well, I’m now very happy it exists…
…on Friday a storm came through and caused two things: the frying of the ethernet port on my rapidly aging PowerMac G4 and the frying of the ADSL part of my wireless modem router. Thanks to Kerry and David, I was able to borrow a replacement ADSL modem but this didn’t help my Mac, only Mary Anne’s PC (no small thing :-).
Last night, however, as I was entering severe podcast withdrawal, I recalled “networking over Firewire” and a glimmer of hope ignited in my mind. Next step, get out my work MacBook, plug it into the (non-wireless) router and grab a Firewire cable. Connect the MacBook and G4 with the Firewire cable, open up Networking in System Preferences on both machines and enable Firewire networking. Next, switch over to Sharing on the MacBook’s System Preferences, select Internet and click start (after first observing that sharing is from Ethernet to Built-in Firewire Port). Final step, disable the MacBook’s firewall and then fire up iTunes on the G4 — success and a large backlog of podcasts to enjoy!
For some reason I feel compelled to add to the last-minute Leopard pre-release speculation. In this case it’s with regard to Time Machine and the reports that it requires an “external disk” to work. Well, Apple says:
You can designate just about any HFS+ formatted FireWire or USB drive connected to a Mac as a Time Machine backup drive. Time Machine can also back up to another Mac running Leopard with Personal File Sharing, Leopard Server, or Xsan storage devices.
I’m wondering if this extends to any HFS+ formatted mounted volume — even a mounted disk image…
During Movember (the month formerly known as November) I’ll be growin a Mo. That’s right I’m bringing the Mo back because I’m passionate about changing men’s health and the fight against male depression and prostate cancer. Why…
* Depression affects 1 in 6 men…Most don’t seek help. Untreated depression is a leading risk factor for suicide.
* Last year in Australia 18,700 men were diagnosed with prostate cancer and more than 2,900 died of prostate cancer – equivalent to the number of women who die from breast cancer annually.
* Men are far less healthy than women. The average life expectancy of males is 5 years less than females.
To sponsor my Mo please go to http://www.movember.com/au/donate, enter my registration number which is 70707 and your credit card details. Or you can sponsor me by cheque made payable to the “Movember Foundation” clearly marking the donation as being for my Registration Number: 70707. Please mail cheques to: PO Box 292, Prahran VIC 3181. All donations over $2 are tax deductible.
The money raised by Movember is donated to the Prostate Cancer Foundation of Australia and beyondblue – the national depression initiative, which will use the funds to create awareness, fund research and increase support networks for those men who suffer from prostate cancer and male depression.
For those that have supported Movember in previous years you can be very proud of the impact it has had and can check out the detail at: Fundraising Outcomes.
Movember culminates at the end of the month at the Gala Partés. These glamorous and groomed events will see Tom Selleck and Borat look-a-likes battle it out for their chance to take home the prestigious Man of Movember title. If you would like to be part of this great night you’ll need to purchase a Gala Parté ticket .
Thanks for your support
Michael
More info is available at www.movember.com.
Movember is proudly grown by Commonwealth Bank, Holden, Schick and VB.
Movember is proud partners with the Prostate Cancer Foundation of Australia and beyondblue – the national depression initiative.
541 * w00t: I’ve just heard that David Hearnden has submitted his thesis “Deltaware: Incremental Change Propagation for Automating Software Evolution in the Model-Driven Architecture” which, amongst many other things, contains a formal semantics for the model transformation language implemented by Tefkat (in an appendix).
While paging through Joe Armstrong’s HOPL III talk about Erlang I was struck by the clear similarity between “supervision trees” (slides 28-30) and the exception model in Breeze, the workflow/choreography language I developed at DSTC in the late ’90s. Ironically, my goals/motivations at the time were to explore simplification of concurrent/thread-based programming models by applying a Java-like exception model to failure handling.
You heard it here first, SNOMED CT classified in 440s (under 7.5 min) based on an optimised version of the Desden Algorithm written in Java.
This is more than three times faster than the best known published result.
A caveat:
- correctness has been checked on small number of examples only
Benchmarking shows (as expected) quadratic time O(n2) and linear space O(n).
Needless to say, I’m pretty pleased with this result.
OMG, I’m not really a gamer – tend to get bored pretty quickly except in social settings (as fellow ex-DSTC Halo players will attest), but I haven’t played anything as addictive as Desktop Tower Defense since Lemmings on my Amiga 1000.
Following my previous entry on Netbeans, I should mention that I was using 5.5, the current stable release, not one of the 6.0 Milestones which are supposed to have a much improved editing environment according to comments in this session 
of the Java Posse Roundup.
With regards the profiler, it was indeed much nicer than the Eclipse TPTP experience, but you need to read the fine print. I can’t say how much time I wasted trying to discover where all my heap was going before I read (my bold):
The total number of objects allocated for each class that Profiler presents (in both “Record Object Creation” and “Record Object Creation and Garbage Collection” modes) is exact, whereas other numbers (such as total object size) and the reverse call graphs are by default obtained statistically.
Ultimately, using a combination of the netbeans profiler, jmap -histo, and the profiler’s ability to record the stack when allocations happen proved to be the most useful approach. The instant illumination of seeing that it’s your Map implementation that’s responsible for all the space, then looking at the allocation stack traces and discovering that it’s actually one particular use of the Map that’s the problem.
Earlier I mused briefly about standard OS APIs based on a REST approach.
It seems that a commercial offshoot of some HP Labs research is actively developing a similar concept.
