Daring Fireball pointed out John Siracusa’s review of Leopard. Like Gruber, I haven’t spent much time with the land slide of reviews. I’d prefer to experience the upgrade, myself, once my 5-pack arrives from Amazon rather than succumb to other people’s preferences and biases.

Siracusa, though, has done a phenomenally in-depth tour of Leopard. I’m a bit agnostic to some of the UI gripes but his reasoning is consistent and perceptive, regardless. The kernel details are engrossing especially since you don’t have to be a kernel hacker to appreciate what he’s written. Siracusa does a wonderful job of providing sufficient detail to appreciate where the lower levels of the OS have evolved or stagnated and why.

It is a lengthy read, I’ve spent several hours and am still not done, but I think well worth it if you want to speak about Leopard in an informed fashion relative to other operating systems like Windows and Linux and in contrast to what has come before with OS X.

This is a meme that will not die. Just because Joe Average, the business analyst, cannot write his own software, we are in a software dark age. I don’t buy it and I think it is an entirely fallacious argument. To me it is like saying medicine is in a dark age because a pharmacist cannot diagnose, manufacture and prescribe their own medication.

Well, strictly speaking, that analogy is flawed. But my point remains. The typically business analyst cannot specify their way out of a paper bag, let alone engineer a product. And I don’t think there is anything wrong with that. Business analysts, such as they are, have a valid domain interacting with human principals. This requires a different and non-overlapping skill set from crafting the instructions, that is software, that drives machines.

The only motivator I can conceive of to eliminate this divide is cost. If a business can pay a business analyst to both interact with customers and deliver products, they have to pay only one resource, not two. And this urge is not new. The same tired arguments were used around the CASE tool craze. And again with the Unified Modeling Language idiots and now the Domain Specific Language numb skulls.

Blaming the state of software engineering for it is nonsensical. It has always been a bad idea, it always will be a bad idea. Even the most disciplined, highly trained programmers cannot write bullet proof code. How is having a less skilled business analyst trained in an entirely different discipline write the code going to improve that?

Oh, and if you cannot see the snake oil aspect of a guy, Simonyi, trying to sell software that lets analysts write code telling people that things are broken because the tools don’t work and allow just that, well, then you deserve whatever product the idiots you hire give you.

This is actually an interesting suggestion. Not sure it is interesting enough to me to purchase the book, but still interesting. Of course the Slashdot article that pointed me to it distorts the authors claims, but not as much as I would have thought. I do wonder if the notion of “process expression” is actually more complementary to traditional CS, and the algorithm, than the author lets on.

Maybe it can be formulated as a kind of superset? His discussion of operating systems in the article is apt, the set of inputs over time is nontrivially complex and hence unpredictable, although it is foolish to entertain that any kind of software is non-deterministic. That way lies madness.

Usually I am leery of high flown claims such as these, but something about the idea of parsing and expression seems more right than not. Maybe its a false resonance, an unsubstantiable similarity to compiler internals. Maybe thinking about ASTs and parse tokens has yielded a tool biased view that extrapolates out to these process expressions. Not sure.

Maybe I need to check out this book, after all.

Just saw this question up at Slashdot. If you ask me, this is the voice of the clueless. Sure, 80 columns is insufficient in a term window. I typically run mine 110 wide. But that’s not the point of why many coding conventions have a bias towards 80 columns. Well, it may have been originally, but there is far more value to this restriction than ancient termcaps dictate.

Functional decomposition teaches us that to manage complexity code should be digested into manageable chunks. For C-like languages, and many others besides, nesting depth is often a good cue where a particular function is doing to much and should be re-factoring into smaller pieces. If I write a section of code that continuously overflows 80 columns, well, a good bet is it is nested a bit deep. I may also be violation the Law of Demeter by dereferencing too deeply.

The point is that 80 columns is not as arbitrary as it seems. Nor is it strictly a historical artifact. As we code, we need reminders, sing posts, that help us be mindful of what we are doing. Having pulled a couple of marathon hacking runs, recently, the siren song of code is fresh in the mind. If you are too fixated on the source at hand and don’t use these cues to pull back and continuous check and re-consider, well, that’s how smelly code developers.

So keep your code to 80 columns. Understand why you do it, of course. And developer any other practices and tricks that keep you mindful of what you are doing and re-assessing so your code is ultimately the best you know how to write.

Let me count the ways this is an awful idea. It does not even have the amusement value of the hacker that re-implemented Unix in JavaScript. There are already any number of quite good free operating systems. Mozilla already has a free, powerful XML based development platform. The core of Java’s promise, as opposed to C/C++, was platform portability. There are at least half a dozen “Web” operating systems already.

None of these has displaced Microsoft or Google. I honestly do not see how combining aspects of all of these and pressing the fact that it is XML based over and over again is going to make XIOS any more successful than any of its more well considered antecedents.

What incentive is there, really, for developers to build on what I see as more or less just a curiosity? The fact that it is XML based doesn’t really mean much in terms of reducing learning curve. And speculating about developers generating revenue directly for themselves via subscriptions or ads doesn’t do anything for me either. Maybe it is Information Week’s editorial bias, but I didn’t see any compelling evidence of why this would be an improvement for application users over any of the current approaches.

It looks like I was right to be skeptical. A 16 qubit register is still an accomplishment, if it is verified during the peer review to which the vendor says they will submit their work. But the report of the system running slower than a typical home system is a bit surprising. How is this demo worthy? I’ll be a lot more impressed if they make their 1000 qubit goal.

I’ve tried to stay out of this debate. It is pretty non-sensical, as most religious debates are–vi vs. emacs, brace styles, etc. However, Robert Cooper makes some good points for consideration in defense of static typing. The first one, right off the bat, has nothing to do with safety but touches on one of my favorite programming principals: intentionality. His other points are well made and well substantiated.

I even tend to think that his points, if well received, might help improve dynamic languages, in this case specifically Ruby, without having to give up the advantages of dynamic typing. Unfortunately, when the original poster to whom Robert is responding thinks it is realistic or practical to just fire people for making mistakes that a bit more intelligence in the language design could easily help resolve–well, good reception might be asking for too much.

In the podcast from the 21st I talked about Amit Singh’s port of FUSE a nifty user space utility originally developed for Linux. Brian pointed out my omission of a link for a related project, Secure Remote Disk, a Cocoa front end for working with sshfs.

I’ve now had a chance to play with both, as well as trying out SpotlightFS which appears to be the first Mac specific filesystem for MacFUSE.

I’ve wanted to use sshfs since I first read about it in LinuxJournal some time back. It definitely lives up to my expectations, althought both GUI front ends fall short. SRD does not allow specifying a remote directory, as far as I can tell. I may be missing something. sshfs, offered from the MacFUSE project pages does allow this option but does not allow me to specify my own mount point. Again, I may be missing something, but for now, the command line it is.

Not that this turns out to be a major draw back. I have successfully suspended my PowerBook a few times with an sshfs volume mounted and have not had a lick of trouble. This being the case, I can well imagine a .command file to run at login to just go ahead and make the connection for me, pretty much eliminating the need to manually mount the remote systems I use most frequently. For ad hoc access, I suppose SRD is a bit more useable given the limitations.

Yesterday, the MacFUSE project released its first Mac specific filesystem, SpotlightFS. This looks very promising, in the words of the author

SpotlightFS is a MacFUSE file system that creates true smart folders, where the folders’ contents are dynamically generated by querying Spotlight. This differs from Finder’s version of smart folders, which are really plist files with a “.savedSearch” file extension. Since SpotlightFS smart folders are true folders, they can be used from anywhere—including the command line!

Sadly, I have yet to get this to work, as much as I would like to. I have entered a ticket for my troubles and am guess this just didn’t get enough testing before he posted it. It seems to be looking for my mount command in the wrong place, at least going by the error in my console.log. I have picked over the contents of the SpotlightFS.app bundle but haven’t found anything promising. Hopefully remedying this is a conf file edit or a symlink away. I’ll update as I make progress with this filesystem.

Overall, though, I was impressed by the ease of installation and stability of MacFUSE. Given that it is only a little more than a week old, I anticipated lots more front ends, filesystems, and useful apps to come building on top of it, both ports from Linux and BSD and uniquely Mac apps, like SpotlightFS.

Technorati Tags: FUSE, sshfs, SpotlightFS

I hardly call this compelling proof, especially since there has not been any follow up since the posting. Still, I still hold that it is well in the realm of feasibility, it just wants for someone willing to do it. And possible have to fend of cease and desist. Or worse.

I was originally more optimistic, based on how quickly Linux was up and running on the latest generation iPods. But it occurred to me that despite the attraction of the wifi hardware, the ad-hoc DRM may make this a bit more of a snarl. Not technically but that the labels who are partially responsible for this scheme and in a later article that shows the DRM is even more crippled would undoubtedly not understand who running Linux is non-infringing and not a threat.

While this opinion may be obvious to those who have learned and gone beyond Design Patterns, Tim O’Brien’s clear writing and spot on characterization of the problem is still worth the read. It also furthers what is turning into a pretty consistently positive opinion of his contributions to ONJava, as opposed to some of the other contributors.