I’ve gone through this process quite often, and most times its pretty fun to see new things become available that solve particular eccentricities or minor flaws in the tools I use already.

Recently, I’ve been on the “Am I documenting things as efficiently as I can?” kick.

First of all…  I’m not a fan or wikis.  Actually, I dislike wikis.  Most of them are atrocious, with very few exceptions.  I find directly editing HTML easier than editing wikis, with their ridiculous markup language — come on,  two single-quotes for italics; i.e., ''italics'', three single-quotes for bold; i.e, '''bold''', and FIVE single-quotes for bold+italics; i.e., '''''bold+italics'''''?  Really?  That’s 10 mofreakin SINGLE quotes to make something italicized and bold!  HTML?  Much easier.  <i>italics</i>. <b>bold</b> and <b><i>bold+italics</i></b> Ok, maybe not so much easier, but definitely less confusing.  So, when creating documentation that typically lives on a webpage, are wikis actually easier?  I’m inclined to think they’re not.  But editing isn’t the only reason.

I have a philosophy on systems administration documentation, which I’ll get into later, but in essence it overcomes the chicken-and-egg problem.  Basically, if there is documentation for system administration about how to properly set up a wiki, where should this information be stored?  In a wiki?  Most wikis, like Mediawiki, store the information in a database.  Systems administrators need documentation about how to properly set up databases.  We just multiplied our chicken-and-egg problem by 2.

1. Set up a database as a prerequisite to have a wiki
2. Document how to set up a database properly
3. Set up a wiki to hold the documentation
4. Document proper set up of a wiki

Where does the information from #2 and #4 live?

HINT:  “Inside the wiki” is the wrong answer, and if this isn’t obvious to you, you should consider another career field because you are bound to have other more pressing problems than where to store your documentation.

Back to my periodic re-evaluation of tools…

In scouring the Interwebs for new and better tools for documentation, I found this abstract of a talk from a Linux conference in 2008.  It speaks directly to the chicken-and-egg problem I’ve been pondering:

Most professional teams will have some form of team documentation used as a reference by existing team members but also as a means of getting new staff up-to-speed. System administrators are no exception, but have their own set of additional requirements: lots of diverse, complex systems mean lots of procedures to recall. It’s also no good having procedures for repairing a database server stored in a database table.

I recently undertook a project to migrate Newcastle University UNIX team’s internal documentation from a simple filesystem-based scheme to a web-based wiki system using “mediawiki”, the software that powers Wikipedia. Once I had achieved this, it became apparent procedures and tools were necessary to help manage the continued review and updating of the documentation. I also became aware of several issues with the approach that impacted us specifically as systems administrators.

The talk itself was probably much more detailed, but the issue is relatively simple.  You need to be aware of any circular dependencies you’re creating, and try like the dickens to avoid them.  Also, everyone relying on the documentation needs to be well aware of the limitations of the documentation system.  Sure, you can devise a documentation system that doesn’t store its information in a database, but there are other dependencies as well — documentation about how to fix a broken web server might not be best suited inside a wiki, since all wikis rely on web servers to operate.  Granted, you may be able to quickly erect a web server, but this itself creates an unnecessary complexity that needs to be overcome in order to access procedures detailing how to fix a different problem.

Most things in systems administration deal with these types of issues, which I’m going to try not to get into except to say that if you can deal with these types of problems you will probably be a very good systems administrator and not paint yourself into a corner of dependencies.

Back to documentation.  In the abstract of the talk, it mentions a “wiki compiler” as a possible solution to the documentation chicken-and-egg problem.  The concept is that it isn’t strictly a wiki itself, but a method to construct a wiki dynamically based on files on disk.  If the web server explodes, you still have the files.  The files aren’t stored in a database, so that dependency is removed as well.  Also, the files can be under a version control system, so if an author makes a mistake somewhere this can be easily and quickly reverted.  One such “wiki compiler” is ikiwiki, apparently.  The more I read about this concept, the more I like it.  I’m still researching documentation tools, but this is definitely one that I will be exploring more, if only because it seems to make the documentation itself less complex.

My systems administration documentation philosophy is also considerably simple.  Systems documentation basically consists of only 3 types:  online, offline, and hybrid.

• Online systems documentation should only consist of procedures, concepts, ideas, and notes that have zero dependency on web servers, and not depend on any other part of an infrastructure needed to access the documentation itself.  A good example would be procedures about how to create a user account — creating a new user isn’t dependent on the wiki, the web server, or being able to access the documentation within.
• Offline documentation is system details and procedures needed that deal directly with portions of the infrastructure that may be offline or broken; e.g., disaster recovery procedures.  This type of documentation is offline primarily to simplify the review/update process needed to keep the documentation current.  If procedures to restore data from tape are online, of course copies can be printed to use when/if a critical file server needs to be restored.  However, if the data is moved to a different location or the restoration procedure is modified in some way, the documentation needs to be updated.  If this information is kept online, the new information should be added, and then printed again, making sure to destroy the previously printed copies to avoid confusion.  Keeping critical information online quickly becomes a complex procedure in itself because the information needs to be kept offline on paper in the event of an emergency, and updating the information in multiple locations is prone to error and confusion.
• Hybrid systems documentation is a mixture of offline and online.  Hybrid docs are normally created offline, converted or translated into online format, then added somewhere to be available online as well.  They are never edited online, to avoid having multiple conflicting documents that would cause confusion in an emergency.  DocBook is a good example of hybrid systems documentation:  a single source document is created from which other versions can be generated in HTML, PDF, PostScript, plain text, etc.

Anyone that puts an important file with an encrypted password on more than a dozen computers, with permissions of the file being world-readable, doesn’t really understand the ramifications involved.

Since then, I have been trying to “crack” the password through regular means.  Given their usage pattern, I’m fairly certain the password is 8 characters long, at least one capital letter, one number, and one special character.  Sadly, only that much information probably won’t be enough for me to crack it without throwing more compute power at it.  The tough part is that its a salted hash, so I can’t really use Rainbow Tables, and I’ve already tried dictionary attacks with Webster’s Dictionary.  So, I’ve resorted to brute-force automated guessing.  JTR seems pretty good at this, but even so it will probably take months to obtain the plaintext password.  It has been running for 11+ days so far.

The encrypted password in question is: {SSHA}KZhA0wzX4AThn9CkxBgYDmmy42pNY9ME

Salted SHA-1, of course.  If you know encryption algorithms, you already know what this is likely used for, but I won’t give that away.  I won’t tell you what its used for, or who it belongs to, or what you might do with it once you’ve cracked it, suffice to say the plaintext password in the wrong hands could cause some damage.

If you know of a quick way to crack such a password, other than what I’ve tried so far, drop me a line.

Recently, a Slashdot submission in this context was:

“Lately I’ve been rethinking my personal security practices. Should my laptop be stolen, having Firefox ‘fill in’ passwords automatically for me when I go to my bank’s site seems sub-optimal. Keeping passwords for all the varied sites on the computer in a plain-text file seems unwise as well. Keeping them in my brain is a prescription for disaster, as my brain is increasingly leaky. A paper notepad likewise has its disadvantages. I have looked at a number of password managers, password ‘vaults’ and so on. The number of tools out there is a bit overwhelming. Magic Password Generator add-in for Firefox seems competent, but it’s tied to Firefox, and I have other places and applications where I want passwords. And I might be accessing my sites from other computers that don’t have it installed. The ideal tool in my mind should be something that is independent of any application, browser, or computer; something that is easily carried, but which if lost poses no risk of compromise. What does the Slashdot crowd like in password tools?”

The response is filled with witty replies and interesting views and suggestions as per usual.  Nothing really new usually surfaces when someone asks this on Slashdot, since it seems the capacity to have passwords for online banking, social networking, work computers, home computers, blogs and whatever else grows and evolves faster than the ability to keep track of them all efficiently (and securely).

A while back, I wrote about my solution to this problem after having tried to solve it different ways.  In that post, I detailed my evolution from a Java application on a USB keychain to a website called Clipperz.

Well, I have been using Clipperz for almost 2 years now.  It is immensely useful and efficient.  I have had ZERO problems.  Yes, none, nada. NO problems whatsoever.  How many things can you say that about?

Clipperz does seem to be growing in popularity, since the last time I remembered the question asked on Slashdot, hardly anyone recommended Clipperz.  This time, a few people mentioned Clipperz on Slashdot.  However, its been 2 years and Clipperz still has the “beta” status.  Granted, Google Mail was in beta for years until they became “production”, but still…

Not just oh-we’ll-find-a-way-to-fix-or-deal-with-it bad, we’re talking a downward spiral that slopes deeper the further we decline until we have reached “terminal velocity”.  The bottom is not yet in sight.

Why?  Well, I’ll tell ya why…  in a minute.  First, I’ll put things into perspective by shedding a bright historical light on the subject.  This is not to mean that the history of email is dark or bad — but the present state of email certainly is, compared to its early days.

Email (not E-mail, since words that are introduced into the English language are often comprised of multiple words that stand on their own, separated by hyphens, normally lose their hyphens as the new words gain wider acceptance) as we know it today, was originally created in the early 1970’s, purely as an experiment, though in a slightly different form.  To put this into proper context, we’ll go back just a bit further. Email (at this time E-mail, or “electronic mail”) only existed in self-contained systems.  People would log into one specific machine (a time-sharing device, which was basically a big expensive computer that a group of people shared at different times) to perform their work, and would occasionally leave messages for one another to read whenever the next person would log in again.  This concept of “self contained” email would eventually evolve into other implementations of the same use — such as Microsoft Mail, which was designed as a central system, namely in an office building, that people would use to talk to only other people in the same office.  I digress…  but, even in its first use case, Email (and E-mail) was used as a convenience.  Some would say, a luxury tool — to save people from leaving yellow sticky notes somewhere, or picking up a phone to talk to someone that may not have time to talk to you.  In tech-geek-speak, email is asynchronous communication:  I can talk to you as much as I like, and you can reply back to me, but it is pure coincidence if we happen to talk to each other at the same time  (there is a variable delay between one person talking and the other person replying).

From being an easy way to leave messages for other people sharing the computer, it turned into a way of leaving messages for people using other computers — no longer “self contained” email, but networked email.  At this point, email diverged into two uses:  local “self contained” messaging on one computer, and “networked” messaging.  The two remained distinct for quite a while, as there were people sharing central computers that had very little need to communicate with people sharing other computers, yet there were people that had a valid need for such distant communication even if “distant” meant “the computer right next to mine in the same room”.  Still, it was viewed as leaving an electronic sticky note on the screen for whenever that person logged in again.  As such with StickyNotes, eventually the glue on the paper dries and at that point it no longer sticks to anything, falling off the surface to become lost when the cleaning lady vacuums the floor.  This was the expectation for early email — “Joe, I left you a quick message about the widget, if you have concerns just give me a call.”  If the email message was lost, deleted accidentally, or was never delivered, it was no big deal because the communication was eventually going to take place in person anyway, and there was no guarantee the intended person would ever read the message in the first place.

As the novelty of communicating with other people on other computers evolved, so did the implementation of email.  To send an email message to someone outside the shared computer, a person needed to know *which* other computer the recipient used.  The @ was born, since that seemed like the most logical delimeter to distinguish “user” from “computer”, and since neither could contain the @ symbol.  For similar computers, the method was “user@computer”, to properly address an email message.  For different systems, it wasn’t so clear.  In fact, it became downright complicated and confusing.  If a person needed to send a message to a distant computer, but the distant system could not accept “user@computer” (possibly it used the @ for something other than a delimeter), the sender of the message needed to know not only who to address the message to, and *which* computer that user used, the sender also needed to know the path the message would take when it was sent from computer to computer to computer.  UUCP (Unix-to-Unix-Copy) was born.  Imagine instead of smith@accounting it was  !cenvax!westnode!accounting!smith.  Gateways from one type of email system to another type had to be erected, to handle the messages and translate one address into another.  Yet, even then, email was still viewed as “fire and forget” in the sense that whenever the recipient got the message, IF they got the message, they will eventually acknowledge by replying in some fashion as courtesy.

Back in my early days of email, I worked in the military in the computer support office.  Then, email was more a novelty than a necessity.  I vividly remember a sergeant I worked with would get daily phone calls after creating a new email account for someone.  Someone would normally call him up to complain “its been 3 days since you created my email account, and I haven’t got any email yet.  I think its broken.”  He would always reply with the same thing:  “you have to send email to get email”, which basically was his smartypants way of saying “it isn’t broken because you didn’t get anything.  You probably didn’t get any email because no one knows you have an email address, or they have nothing to say to you, or all the people you want to talk to don’t have email themselves.”   He would hang up the phone and we would have a chuckle, then I would joke about how the first person in the world with a fax machine probably wondered why he invested so much money in a device that strangely never prints out any faxes.

Slowly, email became the “killer app”.

[For the uninitiated, a "killer app" is an application (a program or function) that is just so utterly cool and awesome it is NEEDED so much that the purchase of an expensive device is justified, simply to use the application.  The other programs and software are bonus, and not needed as much, compared to THE reason the computer was purchased.]

Everyone seemed fascinated with the ability to talk to ANYONE (as long as they were “on email too”) for FREE.  Its better than long distance calling!!  No more busy signals or answering machines!  And its FREE!!

“Move over word processor, I’m going to communicate with the world!!  Shrink yourself into a microscopic icon, Mr. Spreadsheet, EMAIL is the real reason I have a computer!  Now, if only I knew what to say, and who to talk to.  Maybe someone will figure out how to contact me, so we can send messages back and forth.”

Today, no one really needs to know the path a message takes to reach its intended recipient (in some instances, even the recipient need not be known) because we address email to “user@something.somethingelse.com” and we trust the system to do the Right Thing to deliver the message.  To the right person.  At the right time.  “When it absolutely positively needs to be there…”  within the next 15 seconds else I’m going to wonder what the HELL is taking so long, and why haven’t they replied yet because I just got a message that says they’ve read it and it better not have been marked as spam because it wasn’t spam!!

Email has become the primary method of daily communication.  No longer do you “need to send mail to get mail”.  If your email address is on a web page, business card, or if you have ever used your email address to log into a website, YOU’VE GOT MAIL.   Whether you want it or not.  We email each other about meetings, to talk about email.  We email appointments, contact information, political opinions, love letters, chain-messages, advertisements.  The type of content goes on and on.  The problem is no longer about how we communicate with the right person on the right computer, but how to silence the noise to get to the legitimate messages that we need to read.

In the past, whether it was “self contained” or sent from the other side of the continent, each message was read and discarded soon thereafter.  Lately, email is received and almost immediately archived for “safe-keeping”, sometimes without it even being read.   It seems the focus now is not the immediate meaning of each message, but that a potential need might arise in the future where we might need to re-read the message.  Email used to consist of one file, appended to whenever new messages arrived — older mail was at the top of the file and newer mail was at the bottom/end.  Email now has folders, sorting, searching, tagging, categorizing, filtering, and archiving of all types.  We rarely, if ever, delete email that we’ve read.  Sure, it was really nifty when Google unleashed GMail to the world with its “2GB and growing” size limit on the amount of email one person could have, but if we’re only talking about purely text-based messages it amounts to billions of messages. (By the way, it is no longer only 2GB — its more like 7 or 8GB now.)

Email is no longer just the “killer app” in the sense of being able to communicate with anyone.  It is a presentation moniker; an address with @gmail.com is not as prestigious as it once was, but an address with @yourreallastname.com is.  It is a storage mechanism; people have figured out a way to use free online web email accounts to store documents, MP3s, and photos.  It is a calendar; if you’re using a particular email system that is tied into a shared calendar, you can send/receive appointments, and reminders of upcoming events.  It is a ToDo list; some people have an email folder with messages they have sent to themselves containing the errands they need to perform in the course of a day.  It is a webpage; modern email software will accept HTML in the body of an email message and interpret the language of webpages, even in the sense that images need not be attachments to the email but can be referenced to elsewhere on the Internet.  It is submissible legal evidence; there is legal precedence where email messages are a form of evidence, able to be subpoenaed by a court of law.

How did we get this way?  What changed so radically that “e-mail” could come from an experiment on the ARPANET (a solution looking for a problem), to “email”, a common term of the layman’s vernacular so much that it is no longer a privilege but a rite?   How could a function of computer networking change the way we communicate, yet itself change so little?

How is it that email is no longer a novelty method of asynchronous communication, but is now a basic human necessity in the modern world, measured not in its content of communication, but in cosmetic appeal of its address and in its storage size limit?

I haven’t even got to the bad part yet.

SMTP, or Simple Mail Transfer Protocol, was basically an afterthought in the broad historical map of the creation of the experimental networks that were the grandfathers of the Internet we know today.  SMTP is the most widely accepted and “standardized” method of sending and receiving email.  It was essentially created to bridge the gap between unlike electronic messaging systems, back when “e-mail” was growing in popularity and usefulness.  The unfortunate part of the story, though, is that SMTP was created back when there was no real malicious threat or intent proliferating through the networks.  Users basically trusted other users in the sense that everyone followed the same rules because that was what it meant to “be connected”.  After all, if you behaved badly on the network, people would want to network with you less, until eventually you would be partitioned from everyone else in such a way that you gain a decreasing benefit from being part of the network.  It was a self-governing system, yet relatively unofficial.  “Netiquette” dictated good form and respectable practices toward other network-citizens, which mainly consisted of college students and faculty among connected higher education organizations.  SMTP was very trusting back then, and still is.

To this day, anyone can still send email as anyone else — so easily that specialized software is of little concern.  Simply connecting to a mail server with a bare terminal (Telnet), typing the correct sequence of commands and syntax, and voila!  You just forged an email message.  If you’re lucky, someone will believe they’re talking to whom you pretended to be.

What does all this mean, then?  Put together all what I’ve said so far, and it paints a rather dark and confusing portrait.  Email is *everything*, yet flimsy in it being unreliably verifiable.  Email messages pass from machine to machine across the room, or across the hemisphere, and yet they are “essential communications”.  They are submissible in a court of law, yet easily forged.  Messages are quickly and easily created and more easily deleted, yet we archive them for years or even decades with the possibility that we might need them later even though we already know what each message means, resulting in a liability if they are ever subpoenaed, and requiring constantly increasing storage.

How do we end this accelerating downward spiral, or at least slow it down so we might recognize and begin to approach the problem?

When will added functionality, storage space, and guarantees of quality be enough for this old and simple luxury of slow and insecure communication?  When will we finally realize that we have already outlived email’s usefulness and begin using the next electronic communication “killer app”?

If anyone reading this knows the answer to any of the above, drop me an email. 

[3 Oct 2009 Edit: I JUST found out about Google Wave!!  Go here, here, or here to learn more about it.  It is in closed invitation beta right now, but I hear its going to be released this year.]

Anyway…

I’m actually still in the initial stages, in the overall context of the project.  Basically, to create a Linux distribution (from scratch, as I am doing), it begins similar to a chicken-and-egg problem.  You have to use an existing system to create building blocks, and use the building blocks to create a complete toolset.  Then, you use the toolset in a limited environment, which makes zero assumptions (a “chroot” environment, for geeks out there), to begin construction of the target system.

While doing this is actually pretty straightforward, usually, the difficulty and complexity enters the stage when thoughts about the future begin to crop up.  Issues such as future maintenance and automation complicate matters because while there might be a working toolset to construct a target system, no one wants to have to manually create the target system each time something changes.  Also, if something changes within the toolset itself, the component will need to be rebuilt, or worse, the entire toolset will require rebuilding such that the whole thing remains cohesive.

This is similar to around the time when man first thought about hunting and killing for food.  He realized he could fashion a tool to make a weapon.  Next, he used the tool to create the weapon, which was then used to hunt and kill for food.  As evolution continued, he created more efficient tools, to in turn create better weapons that would enable him to hunt and kill more exotic food.  The same general principle exists when creating a Linux distribution — though, we’re not depending on the need to eat in our software toolchain, we are depending on the ability to make more software available, which will comprise a Linux distro.  The tricky part is to know how to manufacture tools in such a way that when a component in the process breaks, it is trivial to fix it so much to the point that if a tool very deep in the toolset breaks there is less need to re-manufacture everything that was built with it.  Henry Ford had a very good idea, with small replaceable parts.

At this point, I’m at the point that I have the toolchain built.  Before I go much further, I need to figure out a sensible way to maintain this toolchain so that if/when something becomes stale or breaks, I will spend less time repairing the toolchain and more time tending to the actual Linux software in the distribution.  Also, since the toolchain itself was build manually and painstakingly, I also need a system to churn out software using the toolset I have.  Perhaps a framework/system could be used for both maintaining the toolset, and maintaining the distro?

I’m quite sure this is not entirely a brand new problem — major Linux distros would have had to flesh this out very early on.  The trouble is, though, whatever they’re using to handle this type of framework, they’re not very up front in saying exactly what they use, what it does, or where it came from.

I know what I want my system to do.  I have a general idea how it should fit all together.  My dilemma is that I’m splitting my time between searching the Internet for any existing software to satisfy the need, and planning how I might create my own toolchain/distro maintenance framework/system.  There are, actually, existing systems that do something along these lines, but they were designed for very specific purposes, and implemented with specific needs in mind, which resulted in assumptions that require specific platforms.  Not very useful in my case, because I’m creating from scratch with no assumptions.

Eventually, I will have an automated system that will:

• institute modularity wherever practical
• automatically rebuild (with dependent software if necessary) anything that needs updating/fixing
• handle both the toolchain itself, and the target Linux software

The site, now released to the public, is Suse Studio.  The concept behind the service is that you can remotely create, per your preferences, a Linux distribution, based on a recent Suse flavor — basically, either OpenSUSE or SUSE Enterprise Linux.

How does it work?  You login (with OpenID, or after creating an account), select a base to begin with;  GNOME, KDE, generic X, text only, etc.  You can select 32-bit or 64-bit.  Then, you can select software to be installed down to the specific package.  You can even upload your own packages — rpm, .tar, .tar.gz, .tgz, .tar.bz2, .tbz, or .zip, specify particular software repositories, or choose from over 300 pre-existing software repositories (some with rarely found packages, such as ATI or nVIDIA drivers).  After selecting software to be installed, you are brought to a configuration webpage that allows you to completely configure the system prior to building it, with the added option of uploading your own customized files.  After building the system, it can be tested via “test drive” — completely able to log into the newly built system via the website.

Once the system has been built (and optionally tested), it can be downloaded and installed as either:  Disk image, LiveCD (ISO image), Xen virtual machine, or VMware appliance.

The service is intelligently laid out, and quite intuitive, enabling the user to create systems within minutes.  Suse Studio routinely clears out built systems, but keeps the meta-info such that systems specified previously can be re-built easily and quickly.

It really seems to be a well thought out service.  I have experienced other web services that allow the user to build a Linux distribution, but never anything this detailed.

But, Dave…  There are well over 800 Linux distributions out there already.  What makes you think you can compete?

Competing is not the point.  The point in mountain climbing is not to see who can reach the top first, but to learn something about yourself, and generally “because its there”.  If my Linux distro gains momentum and ends up being something more than just a hobby/pasttime, great!  If it doesn’t, that’s fine too.  I’m not going to make any promises to anyone, at first, because this will be to used fulfill my own needs which don’t necessarily apply to anyone else.  If I later discover that other people have needs similar to mine, we’ll talk about where to go from there.

Basically, there are two approaches in creating your own Linux distribution:  building from scratch, and basing it on existing.  Some Linux distros are based on other Linux distros.  For example, Ubuntu was created out of re-building software packages from the Debian/GNU Linux distribution, but Debian was created from scratch by hundreds of volunteers.  Ubuntu itself has spawned derivative Linux distributions; Kubuntu, Xubuntu, Ubuntu Studio, and Mythbuntu to name a few.  Both methods have their advantages and disadvantages, and both are equally valid (and probably equally popular).

A few existing Linux distros come with their own “roll your own” application that will automagically create a customized ISO image that you can use to modify/install/spin/fold/mutilate to your heart’s content.  Yes, the method bases it on a specific Linux distro, but it will be relatively different depending on the customizations you’ve set in place.  For example, Fedora has Revisor.  There are also non-distro-specific utilities on the web such as Instalinux, as well as complete Linux distros based on customization and optimization in which everything is built from source — Gentoo.

The other method is to construct a Linux distribution completely from scratch, appropriately named Linux From Scratch (LFS).  While this approach isn’t entirely difficult initially — its just building binary files from source files — it is time-consuming.  It is also recursive, meaning that software you compile in the beginning stages are depended upon by other software you build later, and you’ll have to start over from the point of contention if you discover something broken.  This is termed “building the toolchain”.  Building software so that you can build other software with it, that software becomes dependent on the initial software build, which is then used to build even more software — creating a chain of software used to create a system, which will be bundled together to form an installation, and a Linux distribution.  That’s the easy part.  The hard part isn’t in building the software; its in maintaining the whole thing such that when a bug is discovered it is easily and quickly patched/fixed and the remaining components of the toolchain remain relatively unaffected or are automatically rebuilt using the new link in the toolchain.

Whatever method used to build the Linux distribution, there still needs to be some point to the exercise, else time invested is wasted in making an exact copy of something that could have been simply downloaded to begin with.

My goals:

• Hybrid approach, mixing Linux From Scratch with useful tools from established distributions.
• A practical level of security in the system, without sacrificing usability.
• An agnostic mindset for software packages, trying not to rely on one set of software built for one distribution.  A best of breed path would be ideal, taking the best software from well known distributions, and possibly introducing software that is not available in any Linux distro.
• Initially, aim at the desktop and see how that goes before configuring things for a server platform.
• Simple for the user, but without the cost of being difficult or complicated for the system administrator (who is often the user also).

I’ve had quite a few discussions with friends about what I should name it. After all, that’s the most important aspect of a Linux distribution, right?  Amazingly, in the discussions about naming my distro, no one ever asked me what I wanted it to do — but everyone has suggestions for a name.  I guess in the age of Google, and Yahoo, the name doesn’t have to be related to what it does.  I have a pretty good idea what I want to name it, but that may change later.  Considering there are over 600 distributions of Linux in circulation, a few hundred discontinued, and a few hundred more about to be announced (some of which might be discontinued in a few months), the name doesn’t matter that much to me as long as it isn’t completely ridiculous.  Douchebag Linux doesn’t smack of “Download me!  Use me!  I’m useful!”  On the other hand, Master of All Linux sounds good, but is probably just a tad too ambitious.

I wish there was a quick way to check if a name is already taken.  Like a global registry, or something that I could search for to determine if a name is used.  Distrowatch.com is good, but there is a 90 day waiting period for a Linux distro to be added to the list because “this is to discourage submission of new projects that start with great enthusiasm only to vanish in a few short months”.  Like I said…  Easy to start, difficult to maintain.  Incidentally, ParanoidLinux is on the waiting list to be added to Distrowatch.  Its not mine, but I get quite a few people that read this blog after searching for that particular distro.  I wonder why…

I’ve been putting my photos on Flickr for a while now, but Flickr never seems to do the photos any justice (not just mine, but in general).  Every now and then I post them here on this blog, but they usually contradict the “Linux Ninja Geek” theme, since the photos aren’t actually related to Linux, or ninjas or even technology.

So, I have created an entirely new blog.  A photoblog.

Just in time, too, since my new Strobist gear was delivered today, which more than likely means I’ll be taking MANY more photos that have very little to do with the theme of this blog, and more closely related to photography.

So, if you’re interested in the photos I take, head over to http://photo.mysticmorph.net.  I hope to see you over there.

There is a stretch of the highway along my commute, near my house, that has blooming flowers each Spring.  The flowers seem wild, but they aren’t.  They are an introduced species, named Carpobrotus edulis, or Ice Plant, which is a succulent plant originally planted in Southern California to help stabilize the soil and reduce erosion.  The flowers are rather nice, to be driving along and see waves of different shades of purple and pink flowers along the roadside.  I’ve often wanted to take a photo (or two) of the flowers during the day as well as when the flowers close during sunset.

So, that’s what I decided to do.  Right after my son’s soccer practice, I dropped him off at home, grabbed my tripod and camera and headed back out.  I picked what I thought was a rather nice location to capture the closing blooms right as the sun went down in the west.  I was a bit late, because by the time I got set up and started shooting, the sun had already dropped behind the mountains.  I had got only about 6 shots done, low to the ground right next to a 30-foot lamppost that was just out of frame, when a California Highway Patrolman pulled up behind my truck.

Well, I was done at that point.  He was in the shot I wanted to take, and CHP don’t normally stop to admire the flowers or make idle conversation.  As soon as he got out of his vehicle, I picked up my gear and told him “Okay, I’m leaving.  I just stopped for about 5 minutes, but I’m going now.”

He motioned for me to stay, with his overgrown masculine/overcompensating flashlight/nightstick.  “This is for emergency stopping only”, he shouted at me over the roar of the highway traffic passing by, as he drew closer. “I don’t think taking pictures is an emergency.”

“Well, no, its not.” I replied.

Before I could get another word in, he asked me for my driver’s license, registration, and proof of insurance.

“Sure, hang on, I’ll get it,” I said as I took my license out of my wallet and handed it to him.

I started digging in my glovebox for my registration and insurance paperwork, when he shined his pole vault pole of a flashlight into the glovebox (presumably to make sure I wasn’t packin’ heat).

“Havin’ trouble?” he asked me, as I rifled through my glovebox looking for the paperwork to fulfill his request.

“I have it all here, somewhere,” I told him. There is a lot of stuff in my glovebox.  None of it could be considered a weapon.  I pulled out my registration from 3 years ago, and another from 2 years ago, and yet another that expired last month.

He saw that I had multiple registrations from years ago, looked at the ones expired in 2007, 2008, shook his head, and saw the one dated 2009.  He said, “Ah, there ya go.”

I noticed it had expired last month, and pointed that out to him.

“Yup.  You’re right.  Have a current one?”

“Well, I’m sure I do,” I said, “just give me a minute, I know its here somewhere.”  Finally, I pulled out the current registration, which is actually smaller than a 3×5 card, believe it or not.

“Proof of insurance?”

“Oh, right.  Sure, hang on.” I replied, as I continue rummaging through all the stuff my glovebox has collected.

I managed to hand him GEICO insurance papers from 4 years ago, 3 years ago, 2 years ago, and last year, but couldn’t find the current piece of paper that said I was insured.  Crap!  “I know I have it somewhere, but I just can’t find it at the moment.”

“Well, make sure to tell them that in court,” he said with a sideways smile.

I continued to put my photo gear away while he went back to his squad car to make sure I wasn’t a sereal killer, wanted in multiple states, or had a record for random acts of violence.  After I put my stuff away, I noticed that he started writing, and occassionally would glance over at me while I leaned against the side of my truck while I waited.

Finally, he came back over to me and explained that I am not allowed to stop on the side of the highway unless it is for an emergency.  He pointed out that I could be hit by a drunk driver, or worse.  I calmly retorted that it was barely 7:30pm, that I was next to a 30-foot lamppost, and that I could easily run up the embankment to dodge anything coming at me.

“No, that wouldn’t help ya.  I’ve seen everything,” he bragged.  “So, what are you taking pictures of, anyway? Flowers?”

“Flowers.  Sunset.  I even got parts of the road, to make a scene.”

“Its cloudy.  And the sun went down.  These flowers close up after sunset,” he explained to me, as if I was out of my mind.

“Well, yes.  That was my plan.  Overcast clouds tend to subdue the sun, making it seem larger but not brighter.  Sunset, coupled with the flowers closing up for the night alongside the cars passing by might make a nice photograph.”

He shrugged and restated that it was dangerous to be parked on the side of the road.  I wanted to ask him that if it was dangerous to be parked on the side of the road, and if it is for emergencies only, why shouldn’t we move, but I decided to not say anything because I didn’t want to get into an argument.  What I had planned to be a 10 minute photo shoot ended up taking me half an hour, and didn’t want to make things worse.

The citation was for … and I’m not sure since I can’t read his handwriting …   parking in an emergency zone (side of hwy), and not having proof of insurance.

I asked him, “So, I guess this is a fine?”

“Yes.  Its a fine.”

“I see,” I said.  “How much are we talkin’?” I asked him.

“Oh, I don’t know.  That’s something that’s specific to the county,” he told me.

See, the California Highway Patrol only operates, and has jurisdiction over, the state highways, which run through different counties in California.  So, depending on where and which highway they stop you, you may be subject to different fines and/or court process.

Well, seeing as I hadn’t really accomplished what I set out to do, have a citation to boot, and I didn’t even have time to look at the photos I had already taken, I was anxious to get home.  So, I left.

As it turns out, after looking over the 7 photos I managed to capture, they weren’t horrible.  Not entirely what I wanted, but they didn’t make me vomit.  I should’ve changed lenses and taken slower shots with more exposure, to brighten up the flowers and sky.

Over my years of photographing (over 20 years now), I learned that photography is not just the study of light.  It is the capture of something that most people either take for granted or simply don’t notice.  It should provoke an emotion, and draw the viewer into the photograph so that they can feel what was felt at the time it was taken, or feel something different altogether.

What I was going for was: the flowers closing during sunset, while people whizzed by, most of them paying very little notice.  I’m not sure if I got that much in the photo.  What I get by looking at the photo is “that one time I got a ticket near my house for taking a photo of flowers.”

A Picture is worth a Thousand Words, and 1 Traffic Citation