The Story of smxi :: And Other Related Matters

 How did smxi start - what is it for?

The initial creation of smxi revolved around solving a few key problems I'd noted while participating in the sidux irc support channel (irc.oftc.net / channel #sidux). After a while, I began to notice a few things, all of which struck me as totally non-scalable in the way the support was working.

The core problems that needed a solution

After watching these problems for a few months on irc, I realized that a programmed, scripted solution would be a perfect fit for these repeating problems.

Programming, after all, is designed to do things automatically, to free you to do more productive things, and not make you waste your brain learning things you don't want to know, or don't care about.

du-fixes-h2.sh is born

The first version of smxi, du-fixes-h2.sh was launched around March, 2006, using Kanotix Debian Sid as its base distro, to help deliver a solution to a fix (xorg patch), and to force the users to dist-upgrade out of X. This basic first script was fairly short, and just checked that the user was out of X, that X/kde was shutdown, and that they were root.

It also made sure to run apt-get update, another common user error, forgetting to update before running apt-get dist-upgrade.

From there it quickly began evolving, until it had a series of modules and options, many added by user request. smxi, since its first days, was built to either solve a problem for end users, or to do things they requested. As such, it was always a community based application.

 When sidux split from Kanotix

Update: As of September 2010 sidux became Aptosid, since they just don't seem able to get along with anyone. The problem group this time? Sidux Ev, though the communicate breakdowns reported correspond exactly to what I've seen the guys do time and time again, so I have my doubts about the official sidux version of that story...

As time went on, the Kanotix project began to lose its direction, and, due to a variety of factors, pretty much all the Kanotix developers left Kanotix and formed sidux (end of November, 2006).

We (I had decided to join sidux when it formed, as a founding member, but I had never been part of the Kanotix group) basically all pushed very hard from November 2006 - January 2007 to get something out and running.

du-fixes-h2.sh was an integral part of pulling all Kanotix users who wanted to switch to sidux base, which evolved rapidly. The first roughly 1 or 2 months of siduxes existence, the only way to install or run sidux was using du-fixes-h2.sh/smxi to do the conversion.

It was this rough conversion library, which lay dorment for about 1.5 years, that was morphed into a true Debian conversion tool in the summer of 2008, after a few other people and I had talked about that possibility for a year or so.

After a short while, du-fixes-h2.sh was renamed to sm, but then a Debian guy took that name, so we had to change the name again, to smxi, which is what it will remain.

Factoid: all the smxi script libraries are called sm-.... because of this initial sm name. I never changed the library names because the shorter form is easier to type.

During the first months of siduxes existence, most of the kernels served to sidux users were served by the smxi servers, the ones your donations help keep running. After about 6 months, sidux got mirrors for the kernel zips, then, about 6 months later (January, 2008), sidux switched to normal apt based kernel install, which is where everything remains now.

 The current state of smxi - features and options

smxi has undergone a few key rewrites and major upgrades:

  1. The first was the summer before sidux split from Kanotix.
  2. The second was in the Winter months of 2006/2007, when smxi/du-fixes-h2.sh underwent major internal rewrites to adapt to the very quickly evolving changes of the new sidux project.
  3. The third was moving from the old zip kernel files as default install method to using apt kernels, which was a very big change. This laid the groundwork for adding not just sidux apt kernel support, but also Debian apt kernel support, which was the first major step in opening smxi up to the larger Debian world.
  4. The last major change, in the summer of 2008, was making smxi a truly Debian compatible script, by adding a much more robust conversion library, adding aptitude support, and adding upgrade/dist-upgrade options (sidux supports only apt-get and dist-upgrade), as well as better distro ID processes.
  5. Due to a nice donation I received, in November, 2008, I setup smxi.org as a standalone site. Previously, all the the script components had been hosted on my main site, techpatterns.com, where you can still find the script support forums.

The last 2 changes, coupled with the apt kernel install method, are what enabled smxi to become a true stand-alone Debian script and project, which is when I also quit the sidux project.

Each step also involved tightening the core methods and tools, and building up more and more internal tools to let me manage the increasing power and utility contained in the core scripts.

Current Main Features and Options

The changes above prepared all the scripts to support a far wider range of features and options, which just goes to show, sometimes things work out for the best.

smxi lets you navigate around it fairly freely, so you can almost always go back, until you've actually started some process or other, so don't be afraid of snooping around. Most major steps will also ask you to reconfirm before they proceed (ie, install kernels, etc).

smxi and related scripts now support the following major options. If you want to learn more, read the primary smxi navigation documentation page. What follows is just a brief overview of the core functionality of smxi, listed more or less in the order the stuff happens in the script.

That's the basic outline of what the scripts do, whether you run them alone or as standalone doesn't really matter, but it's generally easier to just run it all directly from smxi I find, but each to their own.

 Is smxi part of sidux/Aptosid? Why isn't it in sidux/Aptosid?

The short answer is that neither smxi nor its predecessor, du-fixes-h2.sh, were ever part of kanotix or sidux. I did join, for a while, the sidux team, but have since resigned.

However, while smxi itself was at no time ever a part of sidux, at one point the smxi stub-installer was.

The stub installer, which allowed you to automatically download and run smxi, svmi, and sgfxi, was a hugely popular feature with the people who used sidux and smxi, but it was not the scripts themselves, and never did more than simply download and run the programs if they were missing.

While this issue was discussed ad nauseum, and continues to come up now and then, the bottom line is that the sidux developers decided they didn't want to support these scripts since they couldn't get write access to them, ie, svn write privileges, so they removed the stub installer, which was actually a good thing, since it left smxi and sgfxi free to once again worry about the needs of the end users, which are not always fully in synch with those of the developers.

Since the developers (towards the end) neither liked, nor generally used these scripts, except sgfxi, let alone had any idea how the stuff worked, the idea of them getting write access was not something that was in the picture. Generally, you join projects because you like and use them, and want to work on improving them, and that isn't any different with these scripts: you really should use and know the programs (and ideally, like them), if you want to be part of the projects.

In a perfect world this should be completely obvious, but unfortunately life isn't always perfect.

Today the sidux guys have moved on to form Aptosid, and smxi has moved on to support Debian, any distro that is truly based on Debian, and that's that. So I don't care about these derived distros any more, if they are Debian compatible, smxi will work on them, if they aren't, it won't, to the degree they aren't.

 Any Debian Distro can Use the Stub Installer

Any truly Debian based distro is free to use the stub installer in their distro (as AntiX is now doing), although of course it's a good idea if they get in touch before doing so to make sure everything is in good working order for them, and to open up lines of communication to make sure we are all on the same page.

 Project Autonomy

Since one reason these scripts work well for their users is that they are written from an outsider's perspective, it's very important that whoever maintains them be able to think through problems outside of the narrower perspective of their specific distros, in order to maintain enough autonomy to make decisions over time that users like, or request, or which will help them in some way or other.

For me, being almost part of kanotix, and officially part of sidux, was enough, from now on, I'll just work on this stuff as I always have, autonomously, while welcoming any like minded individuals, either connected with other distros, or independent, to contribute to whichever project they are interested in. My future plans do not include ever being a team member of any distro again.

I now consider all the projects I'm connected with as being upstream from any distro that uses them. And of course, as such, any distro is welcome to use them if they find them to have some utility for their end users.

The Guiding Idea Behind smxi is Free Software

I really like this quote, from the Free Software definition, because I think it embodies everything good and valuable about Free Software in general, and is a point that is sometimes lost in that oddly corrupted notion of Open Source Software.

The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run a program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her.

As long as I keep doing smxi, it will continue to follow this primary purpose, serve the end user, you. It's easy for me to do this, because I run smxi on every single Debian type system I manage or own, which means that I'm also an end user of the scripts, and I want them to work as well as possible, just like I assume you do.