Hope you, your family, and all your social networks, have a wonderful holiday season.
My blog rate might be a bit irregular this next couple of weeks.
Friday, December 21, 2007
Thursday, December 20, 2007
In addition to Ubuntu JeOS, he also mentions rPath and the recently announced plans for the Red Hat Appliance Platform as items to watch.
The Ubuntu JeOS 8.04 (Hardy) release ISO image is 130MB. This file contains a manifest, in case you're interested in what goes into JeOS. It seems to contain a few package not really necessary for a virtualized environment. (is wireless necessary?)
A brief scan through the rPath prebuilt appliances shows roughly comparable sizes. The ISO image is hardly a definitive measure of the final footprint, but it puts you in the ballpark.
While was at it, I decided to take a look at the sizes associated with EC2 instances. The small instance comes with 160GB of storage.
I'd much prefer a smaller base - perhaps I'm being a bit fussy.
With a little luck, we might even see another entrant into the arena...
Wednesday, December 19, 2007
The key topic is that the rise in popularity of Twitter coincides with the increased number of outage.
This initially caught my attention because of the recent conversation on Premature Scalaculation.
While pondering Twitter's predicament of success, I was struck by an interesting observation.
Few people seem to be bothered by the outages. While I use twitter on a regular basis, the outages were mere inconveniences. While I have no doubt a serious degradation in the service would cause me to migrate elsewhere, I have no issues with the fact that the service is somewhat flaky. In fact, the associated outage screens seem to humanize the experience. No service? No problem - we're presented with a cute little graphic to acknowledge the fact.
The network wires around the problem. What did I do while Twitter was down? In some cases I used other communication channels. In other cases I simply did without. This is easier dealt with when the producers and consumers are humans. Having said this, it reminds me of the dialog I had with users when doing interviews for disaster recovery planning several years ago.
While there are many mission critical services deserve a sophisticated level of availability baked into the architecture, there are times when the most appropriate solution might be a system of post-it notes and telephones.
Heresy? Only sometimes.
Tuesday, December 18, 2007
Parrot 0.5.1 and a Surprise for Perl's 20th Birthday
- Today is Perl's 20th anniversary - Perl 1.0 baby!
- Perl 5.10 was released today
- Parrot 0.5.1 was released today
Sunday, December 16, 2007
Here's another in the Aloofix series.
hah! Big surprise! Another workbench change!
So here's the story,
I've been noodling with several different distro development tools. I like several of them, but each has at least one attribute or another that drives me nuts.
This brings us to...
Version 0.8 of my workbench.
I ditched the distro builders altogether, opting for a 'hand-rolled' distribution.
To be sure, this is most likely how the other distribution building tools were created. *sigh*
As of this evening, I now have a bootable CD, a set of installation scripts run from the CD, and a HD that boots a basic distro. It's raw, but it works.
The HD distribution currently contains the following packages:
The CD image is 20MB. Approximately 16MB of this is a gzipped cpio payload for the HD installation. The vast majority of the payload is glibc.
Will there be a version 0.9 of the workbench? I sure hope not. With any luck, future revisions will simply be improvements in the level of automation for creating the images. Having said this...
For what it's worth, I did get a complete LAMP stack build using the previous workbench, but I wasn't in the mood to man-handle uclibc to get some of the more interesting scripting languages up and running.
Saturday, December 15, 2007
Friday, December 14, 2007
And be sure to check out the other products.
Thursday, December 13, 2007
Platypus Matt posted a link to a news article about the content of the acceptance speech from Doris Lessing, this year's winner of the Nobel Prize in Literature.
Stop Blugging You Idiots
I understand what she's trying to say, but I was stunned at some of the statements made in the acceptance speech.
I would add some coherent and insightful commentary on the speech but I think I've spent too much time blogging and blugging etc.
Posted by Aloof Schipperke at 9:50 PM
Wednesday, December 12, 2007
I'm only mildly annoyed at the implication in the title... ;-)
No, not the second part... the first part. :-O
Any serious annoyance on my part is tempered by an acknowledgment that the canonical view of architecture is as a harbinger of large things - the choreographers for A Herd of IT Elephants.
This is truly unfortunate.
Often justified, but unfortunate.
The good news is that the big-bang, top-down approach is marked for death.
Care to hazard a guess as to why?
... because it doesn't scale!
This is not to say that big-bang, top-down is always inappropriate, but it's readily apparent that it tends to create non-negotiable, immutable structures.
Sadly, it will probably take years for Architecture to shed the historical dogma of Big.
The irony of the scaling topic and BAUF is that a considerable amount of my tenure as an architect has been focused on curbing some of the natural tendencies of IT organizations to create big things - big things that inherently resist scaling.
Similar to how building architecture and musical styles shift over time, our Architecture discipline seems to be modulating to a form of minimalism/JIT.
Who know, maybe we'll see a time when admitting to improvisation isn't guaranteed to raise a few eyebrows...
Tuesday, December 11, 2007
Consequently, I'm still learning interesting factoids about the area.
Today, a co-worker mentioned something about The Simpsons and Portland street names. She wasn't completely sure, so I did a little research.
Here you go.
The Simpsons Archive: Who's Who? In Springfield - The Portland, Oregon ConnectionTM
Some are a bit tenuous, but what the hey.
I'll never look at Terwilliger Boulevard the same way again. :-)
Monday, December 10, 2007
Robert Scoble has started an Enterprise Software Foodfight.
The core topic is based around the question of why enterprise software is not well covered by bloggers and journalists.
It looks like he struck a nerve.
I've been mulling over the topic. Given that I spend my days with enterprise architecture, I even considered my own stance on blogging about enterprise software.
There are so many potential reasons. I'm guessing the reasons vary for each blogger.
Perhaps it's because many technical people see enterprise software every day at work, and long to see something with more hope.
Perhaps it's because of the age-old problem of reporting on the hand that feeds you.
Perhaps it's because many (most?) enterprise software vendors don't understand how to operate in the world of blogging. Blogging begets blogging. Press releases beget yawns. Most enterprise vendors are still struggling to internalize the read/write web.
Perhaps it's because readers don't want any more input about products from vendors already bombarding us with information and awareness of the products.
Perhaps it's because a considerable amount of enterprise software has a face only a mother could love.
Just a thought...
Sunday, December 09, 2007
In Building a builder for tiny lamps, I described my progress creating an environment for experimenting with Pile of Lamps.
That article left off with plans to build a working default distro with T2, then create a new minimalist target configuration.
Well, I did manage to get a working default distro.
On to creating my own target definition.
I created a new target, started the "death by build iterations", then ran into problems. I'll spare the ugly details, but suffice it to say I spent more time surfing through piles of shell build scripts than creating an actual distro.
This brings us to version 0.7 of my workbench. :-)
I'm still running VirtualBox, but am now using Buildroot, from the uClibc folks, for the toolchain. I used uClibc and BusyBox years ago, and was contemplating its use for this project anyway.
As an added bonus, the builds take considerably less time than with T2.
So where am I at now? Well, I have a booting CD image and am working through the details of turning it into an installation disk.
The CD iso image is just over 19MB, with an installation payload. I have plans to make it smaller. At around 4MB, the kernel modules in /lib/modules are a notable contributor to the size. The virtual machine environment provides a predictable list of required drivers, but I need to go through the exercise of trimming down the list in the kernel configuration.
As for problems, the only one I've run encountered thus far is the fact that Buildroot doesn't include a boot loader in the list of packages available for target environments. Hmm... It's intended for embedded environments, so I'm only mildly surprised. I managed to shoehorn in a statically compiled version of grub, so it's no big deal.
I have a preliminary root filesystem for the hard drive installation. It still needs work, but it's enough to boot from a virtual disk image in Virtualbox.
The current distro installed on a hard drive contains the following primary elements:
- Linux 2.6.23 (need to bump to latest patchlevel)
- uClibc 0.9.29
- Busybox 1.7.2 (not sure why it's not at 1.8.2)
The first order of business is to convert my hard drive installation notes into a script that runs from the CD boot.
I've started to add some additional packages.
installed, but it dumps core - investigating...
- and a scripting language
(sadly, the perl port is very minimal - will need to ponder)
- and a database
(still researching - berkeleydb and sqlite recipes are included in buildroot - will need to ponder)
I'm also considering trimming down some of the BusyBox applets enabled by default. This is not to reduce the size - it's more to reduce the number of moving parts. E.g. fdformat and unix2dos probably aren't necessary. It's questionable whether the filesystem creation utilities are needed as well. The original concept was to only provide enough to perform the task at hand.
With luck I'm hoping my next status update will report an alpha release CD-based installer that produces a ready-to-use minimal LAMP instance. Fun stuff...
I haven't yet decided on a name for the distribution. The tentative name is aloofix. I've love to hear recommendations for a better name.
More to come...
Until next time...
Saturday, December 08, 2007
Those that emjy the business card medium might Jessica Hady's work with index cards at Indexed.
She has a knack for the humorous chart and graph.
This one caught my eye.
I'm sure the fact that I'm trying to sell a house in Arizona was purely coincidental.
One year and counting. :-|
Friday, December 07, 2007
Thursday, December 06, 2007
What would happen if I added a jamming sound track to the presentation at my next architecture pitch session?
It might even save me the need to stand up there and talk about it. Just cue the slides and let the music do the rest.
I'm oh so tempted.
/me adds a can of wet dog food to the grocery list
Tuesday, December 04, 2007
I think I've struck upon a solution for the perennial problem of creating fresh new blog content.
I call it blogging2.0.
It will leverage2.0 the latest trend2.0 by respinning2.0 everything2.0 as fresh2.0 and modern2.0. Everything2.0 I write2.0 will, by definition2.0, be new2.0. No longer will I2.0 need2.0 to be worried2.0 about use2.0 of the term2.0 2.02.0.
What happens2.0 when everyone2.0 starts to mimic2.0 me2.0?
Not to worry3.0. I'll simply change3.0 to keep up with the times3.0.
I'm sure there are a few kinks to work out. Perhaps I should call it blogging2.0-beta.
Getting to work, a co-worker and I walked over to Starbucks for a fresh cup of coffee, one of the universal remedies. It didn't help. After sending out a few email messages I went home for the day.
Upon arriving home, my wife fixed me a bagel and a 7-up. I finished those and went to bed. I fell sound asleep, waking up in the late afternoon.
Still disoriented from the mid-day sleep, I decided to read some blogs and formulate my daily post. My brain was still in a fog. My queasy stomach soured my frame of mind.
Nothing in my feed reader grabbed my attention. I was contemplating skipping the daily blog post.
Besides, it's not like there are legions of readers waiting for my next earth shattering declaration. Why am I even worrying about writing on a regular basis.
My funky day was starting to get the better of me.
Then I noticed an article.
In The hardships of being a nobody 2.0, Seth Eagelfield reminds us that A-list status is relative. It's not the numbers that matter, it's the fact that we select what we read and others select to read our work. It's all good.
If you like writing, Seth's blog provides a nice dose of micro-prose on a regular basis. It's good for what ails you.
And yes, I too couldn't resist tacking on the 2.0 doodad. Seth apologizes for his use of the suffix. Not me. I'm contemplating an all 2.0 blog posting. News at 11.
and now I'm going back to bed, hoping to wake up tomorrow ready to get back on track
Posted by Aloof Schipperke at 9:31 PM
Monday, December 03, 2007
The heart of the conversation is a question regarding how much attention should be paid to scalability when in the early stages of a startup. Dharmesh suggests not worrying about scalability too early. Todd reminds us that scaling is no longer the exotic knowledge of yesteryear and that the travesty of focusing purported precious resources on scaling is an overstatement.
To be fair, Dharmesh is not proposing that problems of scaling be ignored. Rather, he's recommending people avoid prematurely optimizing for scale too early in the process.
It is indeed a delicate balance, as are all interesting problems in architecture and design. Besides, we've all grown up with the warning to avoid premature optimization. It's been hammered into our brains.
Here's my problem.
It's a fundamental mistake to frame scalability as an optimization problem.
Scalability fall into the non-functional requirements bucket. It keeps company with a shady cast of characters - security, maintainability, usability, and all the other *ilities.
The primary challenge with non-functional requirements is they tend to pose the risk of significant rework if not taken into account early in the architectural and design phases of a projects. This is where the real skill comes in. If you're in a waterfall mode, you can hope you do an effective job eliciting an accurate picture of the non-functional requirements. If you're in an agile mode, you can hope you do an effective job refactoring the code as you evolve the idea. In both cases, the primary goal is to avoid the decision of whether to implement dramatic amounts of rework or whether to scuttle the ship.
If a particular operation needs to complete in less than 3 seconds and the initial implementation takes 30 seconds, this is not a problem of optimization - something is flawed. To be sure, you might be able to rationalize that future improvements will shave it down to 3 seconds, but most audience members would suspect breakage rather than a lack of optimization.
If a web service is targeted for a million users, the basic framework must be capable of evolving from the initial user base of two. The design is fundamentally lacking if one cannot provide a rational roadmap between these two numbers.
Optimization seldom crops up as a non-functional requirement, except in cases where initial performance is disappointing. The same cannot be said for scalability.
Ok, here's one more way to illustrate the point.
Fail to factor security into a design. Go ahead, I dare you.
Fail to factor maintainability into a design. You'll sell it before it becomes a real problem, right?
Fail to factor usability into the design. Hmmm... will that affect your user base?
Fail to factor scalability into the de...........
On the other hand, ignore scaling. It makes for minutes of entertainment on slashdot.
Sunday, December 02, 2007
In How much of an OS distro is necessary for a Pile of Lamps, I described my basic environment for exploring ideas related to Pile of Lamps.
I've tweaked the workbench a bit, so I'm now at version 0.6. The primary difference is the addition of a dedicated build server. My laptop, while sufficiently beefy, is somewhat prone to thermal problems. The burden of lengthy compile cycles was too much, so I cobbled up a dedicated server for compiles. As an added benefit, I can continue compiling while the laptop is suspended.
The build server is running the T2 distro. The more I use T2, the more I like it. Thus far, I've only encountered one problem. The installation of perl in 7.0-rc2 appears to be missing quite a bit of /usr/lib/perl5. A forced rebuild of perl rectified the problem.
Ok, so here's the current plan of attack.
I'm initially building the default distro defined by the generic T2 recipes. This is primarily to familiarize myself with T2 and to make sure the entire tool chain works.
I was hoping to have the generic build done this weekend, but the build server took priority. The generic build is compiling as I write this blog article.
Once I have a working generic T2 target, I'll shift my attention to the creation of a new target definition. While my end goal is to create a clean recipe for the desired distro, I might need to toy around with whittling down an existing recipe until I get a handle on the T2 build environment.
Until next time...
Saturday, December 01, 2007
They've posted some product images.
Robert Scoble posted a series of video interviews to his blog.
BugLabs.net’s really cool reconfigurable gadget in depth
This is insanely cool!