===========================================================================
 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

• The same support questions were being asked over and over again, using various factoids (irc automated answering systems). This struck me as a very poor use of irc support efforts.
• I started to see that there were a finite set of primary causes for dist-upgrade failures:
  1. Failing to shut down Xorg prior to upgrades.
  2. Failing to apply a fix because the person didn't know about it (in other words, the person has a life that extends beyond tracking Debian package problems day in and day out, or reading the sidux/kanotix forums).
  3. Possibly most important: expecting someone to look for an answer to a question they don't even know exists! This is a very common problem in advanced technical user circles, nobody remembers their own learning curve, and starts to think that highly specialized technical knowledge is somehow something that people should know.
• Asking end users to apply confusing and extremely non-intuitive patches and fix scripts delivered via irc or links in irc.
• Expecting users to actually keep up with every single issue, from first report, to final solution, if any.

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.

• Script Start Tests - Initial script start up, checks for issues, system support, etc. The first time you run smxi it will also ask you some preference questions, which it stores for future reference.
• Sync Apt - Initialize apt by running apt-get/aptitude update. This lets it discover the latest kernel version in apt, either for sidux or Debian, depending on your choices and selections, and what system you're running.
• System and Upgrade Information - Show your system information, including when the last time you ran smxi, the last dist-upgrade/upgrade using smxi, and the last time apt itself was used. This information is also available any time, in or out of X, by running using this command: smxi -v
• Kernel Install - Next, unless you have selected to skip it in options, comes kernel install. Kernel install is skipped until after the upgrade if the installed kernel version is 2 major versions under the newest (ie: 2.6.27 is latest, 2.6.25 is installed). Kernel install lets you pick from a range of kernel/module install/remove options.
• Upgrade Warnings - After kernel install, if you opt to continue, which you probably should do normally, you see the current warnings and alerts. These have 3 conditions, green, yellow, and red. Debian Sid/sidux users will almost never see the green condition, Debian Testing/Stable users will see it frequently. So don't worry if it's yellow and you're using a Sid system, that's normal, just make sure to read the alert message. If you forget it, you can always go to another terminal, and do this command: smxi -W w to see the latest alerts without actually starting smxi again.
• Pre Upgrade Fixes - Once you decide to do the upgrade (or you can skip it here), the pre upgrade fixes, if any, will run, as well as pre upgrade hold/install tests, if applicable (mostly these are for Debian Sid systems).
• Config Files and Start Upgrade - After the fixes run, you will see a list of config files to answer y/n to. Take a note of these, if you forget them, you can use smxi -W c in another console session to review them at any time.
• Main Upgrade - Then the upgrade will run. Always check to see if anything suspicious is happening before saying 'y' do the dist-upgrade/upgrade.
• Post Upgrade Choices - After the upgrade, you'll get some more options, to repeat it, try to fix something that broke, etc. Then you can continue on. Sometimes, rarely, a fix will run after the upgrade as well.
• Post Upgrade Options - Next you come to the main script library module function handler, the Post Upgrade Options section, which offers a range of choices. You can do a variety of actions here, including:
  • Package Install - a variety of package install options, in groups, ie: utilities, non free stuff (like Opera or Flash), OpenOffice.org installer (check it out, it's quite complete), servers (nfs/samba/apache/php/mysql) and so on.
  • Package removal - remove packages, clean up your system of unwanted packages, like wifi stuff, isdn, etc.
  • Cleanup - cleanup system, kernels, system cruft.
  • Miscellaneous Tweaks - a wide variety of different options, check them out, or see the navigation page for full listings.
  • Virtual Machine Installer - Starts svmi, which lets you pick some popular options, like vmware player or virtualbox ose / non-ose.
  • Kernel Options - Same as you saw prior the upgrade, but you can access it from there too if you prefer, or need to, install your kernel after the upgrade.
  • Continue to Graphics - for non free graphics driver install. If you don't use a non free graphics driver like nVidia or Fglrx, you can exit, (to reboot etc), here, or start your desktop, if you didn't get a new kernel installed.
• Graphics Install Question - The last real step in smxi is the graphics installer question, which starts sgfxi with the proper driver, or whatever option there you select. Gives a range of options depending on your card type, if it's free or non free drivers, etc. If you need more fine tuned options, you can always start sgfxi directly, after you check out its sgfxi -h help menu for a full current list of options.

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.

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.