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.
Monday, November 14, 2011
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.
Thursday, November 10, 2011
Thursday, November 03, 2011
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.