BSD VM

I'm reasonably familiar with the virtual memory systems on classic UNIX, Solaris and current Linux.  However, now that I'm even more a Mac user and (back) in the BSD world, I find myself trying to recall the specific details of memory states, active, inactive, free, wired.

Here's a good reference.  It's not the most lucid discussion but it's accurate.

Chapter 7.  Virtual Memory System, from the FreeBSD Architecture Handbook, The FreeBSD Documentation Project at freebsd.org.

Astroid 2005 YU55 Fly By

from Sky and Telescope.

Faster Than Light Neutrinos?

Nope.  From @Endgadget.

Gemini 12

was launched on 1966-11-11.  Story from Universe Today.

Amazon Kindle Fire

reviewed at The @Verge by Joshua Topolsky.

Knocks aside, I do like the general aesthetic and feel of the Fire. After using this device and then going back to the iPad 2, I was struck at how big and bulky Apple's tablet feels. This size and shape might very well be the sweet spot for many users, and since most people have never seen or used a PlayBook, the Fire should be a relatively new experience for them from a design standpoint too.

Minor complaints aside, my main takeaway from the Fire on the process of finding and purchasing content is this: Amazon has done it better and more elegantly than anyone else in the space right now, and I hope the competition follows suit.

There are some bright spots, like the use of tabs, but overall I was underwhelmed with browser performance.

Furthermore, because the Fire is on Android 2.3, many of the applications offered feel like glorified phone apps. That works sometimes, but often it feels clunky and cheap.

Scenes from Autumn

Standing in the checkout line at Burt's Pumkin Farm hoping the price of the pumpkin I have is $8 and not infinity.

The Reengineering of Facebook Messages

From IEEE Spectrum.

Robot Riding Bicycle

In @TechCrunch.  [VIDEO]

Oh great, not only do we have to worry about these things chasing us through the woods on foot, but now they have bicycles!

The Mac App Sand Box

This posting on Naming Things bemoans the new required sandbox for App Store apps on Mac OS.  They may be right but I think this is a move in the right direction.

I don't know about you, but it's become clear to me that putting user data into files on systems and putting system data into the same types of files on systems has led to many of the troubles we have with system security today.  User data should never have been allowed to mix with system data.

In general, sand boxing in various forms works to prevent this problem.

In the article, the author complains about not being able to grab screen shots or not being allowed to communicate with another process.  In fact, a better model than shared files is for the system to provide a service which apps can access.  The system could provide a screenshot service that can take a screen grab from the display system and offer it to a client app.  Interprocess communication services have been there all along.

There's a long rant in the article about plugins.  I'm not sure how important plugins are, but I can see a service that registers and stores plugins if a plugin needs to be shared by multiple apps.  If it doesn't, if a plugin is app-specific, then there should be a service that allows each app to register and store it's own plugins.  They don't need to go into files.  No data does.  Files just contain data and the data can just as easily be stored other ways.

An architecture like this is actually better all around and doesn't preclude functional software.   In fact, a service-based architecture like this provides for more easily moving parts of the architecture to other machines, if the communication can occur over a network.

I, for one, welcome our new service-oriented architectures.  If there's a down side, it isn't clear to me yet.