Since its inception, LightCube Solutions has run on a custom-built Linux machine. Being a former LFS developer, I hail from the Linux world of ‘Do It Yourself’, and so I prefer to use self-configured servers, tuned and set exactly the way I like. This is no Fedora or Ubuntu where a host of unnecessary packages are forced on you and custom configuration files mask the generic and standard configuration files that come with the original software. This is ultimate flexibility.

But that flexibility does come at a price. Maintaining an LFS system can become a chore. Installing a new package always means compiling from source. Staying on top of security updates is entirely left to you. The system is only as good as your personal understanding of its internals. A balance somewhere in between would be ideal:

  1. A lightweight system that is known to be stable and secure.
  2. The possibility of complete configuration is given to the end user.
  3. The focus of the system is tight, and therefore higher quality (in terms of stability, functionality and reliability) can be achieved.
  4. All the while the system benefits from security updates and testing derived from a community of users and developers.

And so, having realized that I needed to move beyond my personal build scripts and start packaging the system (at the least, for my own sanity) it was decided to create a distribution based on our own needs for Linux-based web services. Voila! LightCube OS is born. The basic outline of the distro’s goals are this:

  • Provide a lightweight, fast, stable and secure LAMP application server.
  • As close as possible, adhere to the GNU principles of free software in the packaging and distribution of the system.
  • As nearly as possible, provide a ‘vanilla’ system. In other words, don’t create obscure custom configuration schemes. Allow as much manual configuration by the end users as possible.
  • Focus on packaging software that is reasonably used with production LAMP servers. (E.g., there’s no reason to build an X desktop environment for a server housed remotely and accessed mainly through ssh. Make the system geared towards advanced command line users. As much as a good GUI is nice, there’s no reason for a remote server to run one locally.)
  • Make the base system streamlined, optimized and small. While it is realistic to package a few variations of software (E.g., nano vs. vim, Exim vs. Postfix), the core system should focus on one basic set of core packages.

These are the main ideas behind LightCube OS. The build scripts and the core package specs are already under development. And the distro’s project site/infrastructure has been put in place: http://www.lightcubeos.org. Volunteers are welcome to join in the development.

In the meantime, what are your thoughts concerning the above? What advantages/disadvantages do you see to such a distribution? Do you have any comments or suggestions that will help improve its appeal or usability? I welcome your comments…

“If you don’t measure it, you can’t manage it!”

All too often we encounter small business clients who feel their IT infrastructure is operating just fine. When asked, “how is your IT infrastructure working”, they roll their eyes to the sky and think back to their personal computing issues over the past week. The answer is often, “things are okay…I guess”.
Then it happens…
“My computer crashed!” 
“Are you able to get e-mail?”
“I can’t print, can you print?”
“Why is the internet so slow?”
“My home computer is faster than this.”
With almost inborn instinct the victims hit the power button and pray for normalcy. If the situation is not resolved with a reset and the frustration level is high enough, a call for support is made. Since these issues typically happen sporadically they are often swept under the mental rug.
But lets examine this with business basics – Time Is Money! If we chalk down the lost time of the underrated comments above into dollars, the loss would be startling. This is where a small business owner with limited IT support needs insight into their infrastructure with simple “Key Metrics”.
Key Metric 1: “How many times a week, month or quarter have I experienced an outage, failure or issue?”
Key Metric 2: “How long was each outage, failure or issue?”
Key Metric 3: “How much did this on average cost me in dollars and cents?
The metrics are no more complicated than 5th grade math class, but pack the same power as E=mc
If the financial loss because of the issues approaches 40% (for arguments sake) of the cost of the hardware, software, or service being used its time to take action. Setting aside a little effort measuring IT outages (among other things) can save a bundle. A small business owner can use the information to target potential system failure, plan for hardware upgrades and more important have peace of mind.