With an amazing turn of speed for Apple, the critical SMS vulnerability ahs been patched and is now available for download (corresponding security note coverage):
The iPod firmware images are also available, but with a protected:: URL, whatever that means. I assume it's a HTTP behind the covers too ... (mind you, the iPod doesn't have the SMS vulnerability on account of not having SMS, so maybe no big deal there)
Interesting write up on The Register about a new SSL attack which could allow a man-in-the-middle to impersonate any SSL site by name. Apparently, FireFox 3.5 is the only (current) browser that can detect the malware SSL certificate ... maybe a good idea to temporarily ditch Safari until Apple updates it, in about a year's time.
If you run your own DNS server that is publicly visible, there is a remote denial of service bug that is found in the wild. You should upgrade immediately. Note that whilst this does not allow remote code execution, many services are highly dependent on the DNS servers working properly, and as such, if the service can be taken out it can impact many more services.
Sonatype, the company behind Apache Maven, has recently joined the OSGi Alliance as a full member.
Maven is one of the most widely used build systems for Java applications, and standardises on a Maven repository and the concept of Maven dependencies which has largely allowed Java's ecosystem to grow in a modular fashion. Almost all Java libraries, whether built by Maven or not, are uploaded to the Maven central repository, which means that Java developers only need code a dependency in the Maven manifest file (called pom.xml) and have the dependency automatically downloaded and made available on the classpath. In addition, Maven has one of the oldest concepts of a plugin system which allows dynamically downloadable modules to be inserted into a running build process.
There has already been some support for Maven and OSGi working together; Maven Tycho allows OSGi apps to be built, as well as M2Eclipse, which provides a pom.xml supported development environment for Maven builds. Recently, Pax Construct has been added to the mix which allows simple OSGi applications to be defined in a nested project layout which is so familiar to users of Maven-based projects.
What does the future hold for the de-facto standard modular build system joining the de-facto standard for runtime modular applications hold? It's going to be interesting to find out...
Thanks to the security issue with Adobe Flash/Reader/Acrobat, you should disable Flash and uninstall Reader as soon as possible to prevent your computer potentially being turned into a zombie.
Safari Safari Menu, ensure 'Right-click Flash' is selected. You may need to install SafariBlock if you don't have this option already. Mac PDFs use Preview, which doesn't use the Adobe VM engine (or support RichMedia) so browsing PDFs on Mac with Preview should be safe.
Firefox - Tools, Add-Ons, click on 'Disable' next to 'Shockwave Flash'
Internet Explorer - Go to http://www.mozilla.com/firefox/ and download a real browser
For the specific vulnerability, you should consider explicitly removing files authplay and rt3d from any Adobe products. These will be called:
| Win | Mac | Linux |
authplay.dll |
AuthPlayLib.bundle |
libauthplay.so |
rt3d.dll |
Adobe3D.framework |
librt3d.so |
Adobe Flash and Reader should be considered tainted products until a fix is released, but removing mechanisms to invoke Flash and PDF documents automatically is an absolute essential task.
Virtual machines, used widely by Java and before by Smalltalk, are a great idea when it comes to code that can execute everywhere without needing to have processor-specific (or operating-system-specific) code in an end application. And the main advantage of a virtual machine is that as long as the vm is security bug free, then applications running on top of it generally can't break the security of the system.
Unfortunately, it's not always like this. The Java VM has had, in its life, a few security related bugs (but usually in the 1.3 timeframes). More recently, there were some security bugs in 1.5 which Apple took ages to fix (in fact, over a month to even acknowledge it). It doesn't help that Mac OS X has shipped with old versions of Java installed - even the end-of-life ones. (1.5 is coming up on end of life soon; and since there's no 1.6 on the PPC, I wonder if there will be any further security updates there? Still, Apple has already killed Java)
But the recent VM related problem isn't with Java - it's with ActionScript, otherwise known as ECMAScript or JavaScript, and this time, in Adobe products rather than Firefox. This one is rather serious, as the Adobe security APSA09-03 lists, in that it can enable transparent remote code execution at the Adobe VM layer, which can be triggered by multiple entry points. These entry points include Flash, Reader and Acrobat, but potentially more applications that embed Flash content as well, principally web browsers that execute Flash content in web pages.
Using good security practices, like using FireFox with the NoScript and AdBlock extensions, can help to a certain extent, but trusted websites can be (and have been) hacked so even this isn't a complete security solution. The best bet is to disable Flash completely from the browser, and to un-install Adobe Reader from your systems until such time (end of the week) as a fix is found.
Mac users are also vulnerable to this security problem, because of the VM nature of this attack. It seems that the heap spray is specific to x86 systems (so PPC users may not be affected) but even so, removing this is of critical importance.
Please note that the BBC iPlayer uses Adobe technology so it would be wise to uninstall that, as well as the AIR Player that BBC iPlayer needs to be able to run.
Everyone should disable flash in the browser immediately.
As I posted a few days ago, Google Reader has added a decidedly unpopular feature in that other people show up with their opinions.
The best way of dealing with this (other than letting Google know) is to write GreaseMonkey scripts to make the entry-likers CSS class die horribly. But for those of us using iPhones or other portable browsers who may not be able to use this, there is another way.
Google uses the unique URL of the feed to generate the 'who likes this shit' icon at the top. I noticed this with some URLs that I weren't seeing the crap on. Simple solution ... make the URL unique.
In order to do this, add a URL parameter onto the end of the feed URL. You may need to unsubscribe and re-subscribe to the feed in order to make this work, but for any feed where you've been seeing these icons (say, http://rss.slashdot.org/Slashdot/slashdot) simply add a parameter onto the end that's unique. I recommend something like http://rss.slashdot.org/Slashdot/slashdot?GoogleReader=SteamingPile. Given that no-one else uses this URL, Google won't show you anyone else who likes it (as long as you use something other than 'steaming pile' above, since there's bound to be someone who just copies it verbatim). Feel free to be inventive as you want; most URLs won't take any notice of additional parameters that you add on to the URL. Here's a selection of items you might want to put on:
Feel free to add more suggestions in the comments. For those who track URLs, you might want to add some kind of indication of why you're adding those features to the URL (like GoogleReader=Pants) so when they get a grep through the weblog, they wonder why people are suddenly appending random appendages to their feed requests.
I've got a vague general dislike of the visitor pattern, and I've never really gotten around to writing about it.
The visitor pattern is a way of encoding a visitor which can abstractly walk over an abstract data structure in order to do some kind of processing. This pattern is common in a number of object-oriented languages (less so in functional ones, because it just becomes a function) and the canonical examples are found in Java and C++. However, the pattern is usually described (and adapted from) the GoF book, which used a C++ example in order to get its point across.
So, why do I dislike the pattern? Well, it can be summarised as:
Let's take a look through these in turn.
Double-dispatch, part 1. In the original C++ implementation, a form of double dispatch was used to get around for the fact that C++ is a statically compiled language with no reflection. What this says, in a nutshell, is that the visitor calls a generic accept(visitor) method, which then internally delegates back to acceptSpecificDataStructure(this). Huge swathes of visitor patterns are basically getting around for the fact that the visitor doesn't have any a-priori knowledge of the data structure's type, and so to do so, it needs to ask it how to handle it. It's called double-dispatch, because you're doing 2 dispatches; one to the data structure, and then back from the data structure to the visitor.
Why is this needed? Well, C++ didn't have any concept of performing any kind of dynamic lookup, and so in order to build in knowledge of what the specific data structure was, you had to have some kind of branching logic to do the callback. Since objects naturally form different method calls when invoked with a (virtual) method, using this OO trick to do the first part of the dispatch alleviated that problem. The second dispatch is of course the re-invocation of the visitor's appropriate acceptSpecificDataStructure() call, which given that the visitor itself is usually a subtype, forms a second part of the dispatch.
Whilst that might make sense in the days of C++, things have moved on in the programming world. Java has dynamic methods like java.lang.reflect.Method, and thanks to excessive use by the J2EE servers of the heyday of that platform, was optimised to the extent where it is often more performant than doing a double-dispatch in the first place. Java's only slight weakness comes from the fact that overloaded methods are not done on a signature basis but at runtime, which means that although lexically your code can contain accept(Foo foo) and accept(Bar bar), then an appropriate call to accept(x) will do the right thing, provided that the type of X is known at compile time.
Using reflection can avoid the need to do double dispatch at all. In fact, services like Restlet use reflection to delegate HTTP methods back to their method implementations; GET is mapped to doGet() and so on. But reflection is used as a fallback, so that an HTTP FOO method is mapped to doFoo(), which allows Restlets to support new HTTP methods before the framework does. (This is somewhat reminiscent of Ruby's form-follows-function approach, in which conventions rather than configuration files allow the system to be extended much later in the cycle than with other platforms.)
In summary, whilst most visitor patterns are simply copied over from C++, Java has reflective capabilities which obliviate the need for double-dispatch. Yet these are rarely used, if only because the pattern books all tend to be based from the early GoF beginnings.
Double-dispatch, part 2. So Java doesn't need DD. So? Should you care? Well, in a nutshell, yes. One of the key things that the visitor pattern's DD enforces is not only that the visitor knows about the data structures, but that the data structures must know about the visitor. In other words, you've got a leaky abstraction; your data structure 'knows' more than it should about the way that the data structure should be used.
This isn't an academic observation, though. Using the DD visitor pattern means that a priori your data structure must know that it will be visited at some point. Now, if you control the source code to both the data structure and the visitor (as in most compilers or Objective-C IDEs), this isn't too much of a deal. You just whack in an interface (or abstract class) and let others extend that.
This of course breaks down when you don't have access to the source. For example, want to add a DD visitor to the Swing hierarchy of a view? You can't. Ditto for any other data structure in the base Java libraries.
Typed methods. This is a follow-on from the fact that C++ didn't really support the dynamic method binding/invocation that Java has. In Java, it's perfectly possible to not know the name of a method at compile time and yet be able to run it at run-time. The trick can be used to extend the types that weren't known at runtime, for example, a Visitor can dynamically call visitFoo(Foo) when it finds a Foo object, even if that method isn't know when the parental visitor doesn't know about it. This makes it easier for someone else to extend your hierarchy without knowledge of your specific data structures. Coming back to the Swing example earlier, if I create a BouncyContainer, any visitor isn't going to know about that (since I just created it) but I can put a specific visitation method in and have it called (c.f. the Restlet example above).
Visitation order. One of the problems with the visitor is that the 'visitation order' – that is, which nodes get visited and in which order – is distributed across your visitor tree. Sometimes, it makes sense for a traversal of a data structure to be depth-first; sometimes it makes sense for it to be breadth-first. But having the visitation logic of 'which node to follow next' embedded in each of the visit calls can actually be counter-productive.
What is the case, however, is that for every node that gets visited in the ADT, there are two kinds of nodes:
In fact, these can be generalised into a mechanism which allows you to determine whether a node has children and in which order those children should be visited. In our Swing example, things fall naturally into Container and Component groups. Even in a generic ADT, there's often a getChildren() call or equivalent that determines whether a node has children or not.
Data accumulation. Since the purpose of a data structure walk is to introspect some data from it, there is usually some kind of data that needs to be accumulated, either at the time of the walk or afterwards. In fact, most of the XSLT transformations are just that - transformations of an existing tree-based data structure into another form.
This transformation may require some kind of data to be accumulated as the introspection/walking happens; in most normal visitor implementations, the visitor instance itself is used as the data store. Unfortunately, that doesn't lend itself well to traversals where the walk may be multi-threaded (as in walking a very large parse tree) or where the specific order of evaluation is non-commutatitve. In fact, there may be a number of situations where walking a tree structure needs some kind of state (like evaluating a simple expression language in the context of some binding). For these instances, a visitor is non-optimal way of solving that problem.
Conclusion. The standard Visitor pattern is normally implemented based on constraints of a static language which is missing certain key dynamic features, and as a result, enforces a way of working that is non-optimal in a more dynamic language. Enforcing your data structure to know about the concept of visitors is an unnecessary coupling, both at the data structure layer and at the visitor layer. And finally, having encoded all of the traversal logic in your individual visitor, it makes it difficult to extend or reuse visitor code to traverse data structures in a different order.
Millions of people hate this feature
It seems that a new feature was added to Google Reader recently that sticks a smiley face and tells you how many people you don't care about liked an item. I'm sorry, but I really don't care how many people liked something, and nor do I tell people what I thought of items - I just subscribe to news feeds for things that *I* like. Unfortunately, the people behind Google Reader don't appear to think that way (much like when the much-hated 'share with your friends' feature was added) and instead shove these things down our throats.
Well, it's a free service, and I get what I pay for. But I'm not going to continue to use Google Reader until they get rid of it.
Note: the CSS class is 'entry-likers' - if you have something like GreaseMonkey installed, you can add the below:
.entry-likers { display:none;}
FireFox 3.5.1 has been released, which patches the zero-day vulnerability found that could allow arbitrary code execution if browsing to a remote site. It also fixes startup problems that were created thanks to scanning of multiple disk directories on startup; having run the Mac version through monitoring the file system, then I can confirm that it does as advertised.
If you use FireFox, and you'd installed the 3.5 update, then you should install this update immediately. If you followed instructions to disable the javascript.options.jit.content setting, you might want to re-set this back to 'true'.
Thanks to a lot of good contributions, I'm pleased to announce the availability of ObjectivEClipse 0.2, which allows Objective-C code to be written/compiled inside the Eclipse CDT environment on the Mac.
This version depends on CDT 6.0 and Eclipse 3.5, which are part of Galileo. If you've already got a 3.5 install, you can use the update manager to find and install CDT, or you can download a pre-canned Eclipse CDT package with all the Mylyn goodness built in.
You can get ObjectivEClipse by adding the update site and then choosing the ObjectivEClipse plugin, or by downloading the site as an archive and then installing that. The update site is the suggested mechanism, because if that gets updated, you just need to do an update to get the next build.
So, what's new with ObjectivEClipse 0.2? Well, we've had many good contributions, not the least of which is a parser which is less brain-dead than the one I originally hacked together; so we can now parse interfaces, field definitions, methods (both interface and implementation) and, thanks to built-in CDT support for such things, use code folding and Mylyn. The net effect of all this is it's really starting to feel like an editor that isn't horrible at editing code, though it lacks a lot of the must-haves of IDEs these days still (the lack of indexing means that a lot of things like refactoring and cross-file hyperlinking are a little way off yet).
But it's possible to compile run-of-the-mill Hello World applications, as well as cross-compile to different architecture and different SDK and have the GCC errors hook up to the line in which the problem occurred, as well as using the built-in GDB debugger to step through code.
Here's a screenshot of Mylyn in action on an Objective-C project (with and without Mylyn):
If you'd like to get involved, please start playing with it and giving feedback/ideas/code/coffee/donations to charity. Clearly, it's not a replacement for Xcode, but it's a starting point for developing Objective-C code in an Eclipse IDE.
The last year has been a bit of a tumultuous one, and it's time to take stock of my surroundings and figure out how things have gone on. Looking back a year ago, a lot of things have changed. Credit crunch sounded more like a breakfast cereal; the App Store was a glint in Steve's eye (and he was back at work then, too), and Lehman Brothers still existed. Heck, even Gmail was still in beta. For me, I was getting on with my life until I was diagnosed wtih Leukaemia, which was a bit of a breeze block on the road of life.
At the time, not knowing was probably the most difficult part. In fact, the suspicion that something was wrong was easy to arrive at, with multiple tests and cores taken out of me; actually getting to the diagnosis was therefore a bit of a relief. And the type (hairy cell) is one of the better ones to be diagnosed with.
The immediate consequence of the treatment (rebooting my immune system through chemotherapy) was the development of a fever, which hospitalised me for a couple of weeks (although they did let me out for the afternoon for Sam's birthday). Thereafter, it was a case of repeated blood transfusions (and a major fill-up before heading up to my brother's wedding) and generally feeling quite weak and run-down, before returning to work (electronically) for the Lehman's crash clean-up — although I didn't physically return to work until December.
Whilst I've been relatively normal this year, I think the biggest change has been psychological. For one thing, I'm starting to become a hypochondriac (verging on OCD), although like all paranoiacs, I know that they're coming to get me :-) Getting back onto the road of life has been a bit of a challenge. For one thing, my energy levels have been slowly sliding over the last couple of years. At first, I thought it was due to old(ish) age but looking back on it, I can probably finger the disease as the cause of fatigue.
My energy levels rebounded after treatment, but they're probably not where they once were; so my extra-curricular activities (writing for InfoQ, work on ObjectivEClipse etc.) are going forward at a slower pace than they used to. But I'm also asking myself the question of why I'm doing this — and sometimes I'm not sure. I guess priorities change in life, and as life goes on you naturally drift towards, and away from, things that you used to do.
I'm also missing a certain verve or joie de vivre. I suspect everyone gets this from time to time, especially after returning from holiday, but I hope it's a temporary thing and that it will return eventually. Having a great family and enjoying in Sam and Holly's laughter is certainly medicine for the soul.
And lastly, I wouldn't have been able to do this without the support of friends, family, and the support of my ever-loving wife Amy. She's really been the glue that's held everything together over the last few years, and although our family has gone through hard times, we're still very much a tight unit.
