I have a rather large MP3 collection.  The directories and files are named correctly more or less, but ID3 tags used to be a mess until very recently.  Two applications helped me to bring some order in that mess.

EasyTag, a GUI application, that helped me to fix lots of broken and add lots of missing comments to my MP3 files.  The smart thing about this program is that it can figure out a lot of data from the names of the files and directories, and that it can grab and replicate partial data from within the albums.

The second program that I wanted to mention, I just found out about today (thanks to Michael Stepanov’s delicious bookmarks).  It’s called tag2utf.  It’s a little Python script that converts the encoding of ID3 tags from koi8 or cp1251 (two most widely used Russian encodings) to utf8.  It’s very easy to install (the only requirement my system needed was python-eye3d library, which exists in Fedora repository) and use.  Just run it from the command line with no parameters and it will recursively look in the current directory for any files that have ID3 tags in non-utf8 encoding.  It will then give you a choice of two encodings to select from (koi8 or cp1251), a “skip” option, and a “manual” option.  All you will have to do is take a quick look at the files, and chose to either convert them from one of the two options, skip them or convert manually one by one.  You will have to make this choice for every directory with non-utf8 files.  Optionally, you can specify on the command line which directories to scan.  In case you need to convert from some other non-Russian encoding to utf8, the script is trivial to modify.

Both tools are excellent pieces of software.  It took me practically no time at all to fix my mp3 collection.  Now I can search it better, and all files display nicely in any mp3 player.  Brilliant stuff!

Since we started working on SugarCRM in the office, one of the hardest tasks that we had was solving the deployment issue.  On one hand, SugarCRM comes with some really nice GUI tools, such Studio and Module Builder.  On the other hand, the system is large and complex and should be developed and tested in a separate, non-production environment.

We’ve spent a lot of effort over the last couple of month trying to solve the puzzle.  The problem is that there is a tricky combination of files updates and database changes, some of which can be just copied over while others have to be executed from the destination machine’s administration.

So, what we did first was complete separation of environments.  Each developer had his own machine on which he could install and configure as many instances of SugarCRM as he saw fit.  Also, each developer had a separate branch in the Subversion, so that he could work on his own stuff without being afraid to run into conflict with anyone.

After that, we created a development server with a checkout of common trunk.  For extra insurance, we did a checkout from a system user, who does not have any write permissions in the repository.  In this case, even if someone will accidentally try to commit from the development server, we would be sure that it fails.

Now, each developer had to merge his changes into trunk, and then test them on the development server.  This procedure is very similar to the production deployment and consisted of two parts.  Firts part was updating all the relevant files (a bit more on this in a moment) with svn update.  Second part was logging into SugarCRM and doing Admin -> Repair -> Quick Repair and Rebuild.

The graphical tools that come with SugarCRM are powerful, but a bit confusing.  The biggest confusion for me was (and maybe still is) between Module Builder and Studio.  Studio can be used to customize core modules that are shipped with SugarCRM.  The results of these customizations are stored in custom/modules directory, and when loaded into the database, can be observed in _cstm tables (for example, accounts_cstm).  This is where new custom fields and things like that are going.  Module Builder is a tool which can help you customize existing modules or build the new ones. The confusion here is because both of these tools can be used to do the same things.  But with Module Builder you’d be working closer to the core system and modifying “original” functionality.  You can build your own modules too, by the way.  The results of the Module Builder work with go into modules/ directory, and changes in the database will take place in the original tables.  One thing to remember though, is that you’ll need to push Save & Deploy button every time you are finished with changes in Module Builder.  This is like compiling and building a module.  If you forget this step, then your module will hang in its source somewhere around custom/modulebuilder directory.

Another thing to keep in mind is the sillyness of the machine trying to figure out another machine.  Meaning that Subversion will often have issues trying to figure out the changes from the last commit, and these issues would be often caused by a lot of automatically generated code by SugarCRM.  In most of these problematic cases, Subversion will just merge the changes, and this would often result in a broken system.  I’ve found at least two reasons behind these: small context size that Subversion uses (3 lines or so) confuses it sometimes, bringing it to a wrong place in the file to do the merging; and rather messy automatically generated stuff by SugarCRM - unnecessary reordering and mixed (DOS and UNIX) ends of lines in a single file.  These problems are mostly related to vardef files (vardef.php and anything *def.php) and language dictionaries (anything with *en_us*php, or whatever your locale is).  The solution we are using at the moment is simple, although a bit heavy on the manual work - instead of merging the changes and checking them every time we simply remove old versions of files and add the new ones in two separate commits.  These way Subversion treats the files as completely different ones and real removes and re-creates them instead of trying to merge.

We follow exactly the same procedure now to deploy to the production server.  We just merge code from trunk/ to branches/stable , commit, then update the files on the production server, and then do the Quick Repair and Rebuild.

The thing about Quick Repair and Rebuild is that it takes the update definitions of your forms and layouts and rebuilds compiled templates.  It also compares the structure of the database with the update definitions in the files and, if needed, updates the database scheme too.  Sometimes you’d get an error of missing table (usually custom tables with _cstm suffix) - just create an empty table manually.  Put a couple of standard fields like id_c, date_modified, and date_entered.  After that, field modifications should be OK.  In case you run into a problem with updates to several fields at once, make sure that SugarCRM put a semicolon (;) at the end of each SQL statement that it shows you in a popup window.  For some weird reason, sometimes it just works, and sometimes it tries to execute several queries without separating them one from another.

So far the setup seems to be working for us just fine, but I’m sure that we’ll have a few changes here and there.  I’ll let you know once we find any better way of doing things.  In the meantime, here are some links that might help your development efforts:

• SugarCRM Model-View-Controller (MVC)
• SugarCRM SugarBean
• SugarCRM Vardefs
• SugarCRM Performance Tweaks for Large Systems

After SugarCRM was deployed, we were experiencing some lock ups.  Not frequent or dangerous, but annoying.  About once a week or every ten days or so, SugarCRM would lock up and won’t answer any queries at all.  Not even the login was possible.  A brief investigation showed that somehow it was locking up the MySQL database - about 15 processes (using “show full processlist”) in Locked state, with no data being sent back or forth.  All locked queries were rather complex, with several JOINs.  The load on the system was somewhat high, since we have about a few dozen operators working on it at the same time.

A similarly brief Google search suggested (see here and here) and explained converting MySQL tables from MyISAM to InnoDB.  A test has been performed and everything went OK.  Our SugarCRM database is about 600 MBytes and it was converted from MyISAM to InnoDB in under 20 minutes.  The best part is that it takes even less to convert back to MyISAM, in case you change your mind.

It’s been a few days now since we did the conversion and it looks OK.  Also, the CRM itself feels a bit faster.

We spent a couple of weeks now at work, setting up our Nagios installation.  This is one of those things that one can never finish.  Monitoring is like security - no matter how good it is, it can always be better.

One thing that I particularly enjoyed figuring out was how to monitor dynamic stuff.  Hosts and services are the easy part - they are always there and should be there.  If they aren’t - let me know.  But how to monitor dynamic values, that change based on the time of day or day of week?  How to configure the monitoring so that we don’t need to update the limits every other week?

For example, consider the number of the user registrations through a web form.  If we are to measure this number over any sensible (monitoring-wise) period of time, such as one hour, we’d see that it fluctuates a lot during the day.  Furthermore, this number fluctuates differently depending on the day of the week.  We have three separate pick hours during the day, and we have a great decrease in numbers over the weekend.  Plus the amount of user registrations is linked to all the advertising that company does, so this week might different from the last week and from the next week.  How can we measure it so that a notiification is sent when the number is abnormal?  What is abnormal?

The solution turned out to be much simpler than I originally thought it would.  It is sufficient to get a few samples of the data in same hour last week and a week before.  If current value is more than twice the maximum or less than twice the minimum from the sample data, then we should be notified. This, in fact, works pretty well.  The only time when we get a lot of false positives is when the values in the sample data are small.  With values under 10, it’s very easy to jump over or under the limit.  When the sample values are higher, there is more space between the boundaries and the system works as expected.

We’ll get some more sample data now and we’ll be adjusting the formulat accordingly.  But as I said, even as it is, it’s pretty good.

Point Nine is looking for some talanted people.  They are working in the financial sector, and seeking Python and C++ programmers, as well as Linux system administrators.  They seem to be an interesting company, judging both by their technology stack and hiring techniques.   For example, I’ve spotted their job ad on The Daily WTF.  Cool stuff.  If I wasn’t working where I am working, I would have applied for the job already.

I’ve been a bit quiet for the last couple of month.  That’s because I was leading an ambicious project at my new job - migration of a Microsoft Dynamics CRM version 3 to SugarCRM Community Edition version 5.0.0.  There were only three people involved, non of us could afford to work full time on the project, and we only had three weeks to do it.

Read on for a story on why it took us longer, how we did, and if it was a success at all.

First of all, a little background.  The company that I work for now is in financial services sector.  CRM is one of the two vital systems, with trading platform being the second one.  All processes are tied into CRM - registrations of new clients, incoming and outgoing money, email tracking, and so on and so forth.  The system has been installed about a year ago and has accomodated data for a few thousands of clients.

Another important bit to know is that CRM is used quite a lot 24 hours a day, 5 days a week.  Some data is coming in over the weekends too, but there are no real users who access the system.  Also, since the company is working with global clientele, weekend is really between 23:00 of Friday and 23:00 of Sunday.

By now you probably have this question in your head: “Why migrate?”.  What is so wrong with the existing system that it needs to be replaced so fast and so furious?

The company was preparing for a huge expansion.  Firtst of all, there was a take over of another company scheduled later that month.  That meant an almost sudden expansion of a few thousands of clients to a few tens of thousands of clients.  Secondly, a huge marketing campaign was starting up.  Thirdly, a few key processes were about to be change (the way new clients were registered).  Fourthly, there was a huge need for automation and extended functionality.

With all that, there was a very limited in-house expertise for the existing system.   SugarCRM had this nice advantage of being implemented with LAMP stack (Linux, Apache, MySQL, PHP), which was way more familiar to most of the IT people in the company.  And all the source code was there.

Another big reason for a change, was realization of how tied in the MS CRM is into company’s network.   While considering the upgrade of the MS Dynamics CRM to version 4, most of the people were horrified of the upgrade path.  In order to upgrade the CRM, we first had to upgrade our MS Exchange server.  Which meant that we had to upgrade the operating system of the machine.  Which meant that we had to upgrade the hardware of the server.  And MS Exchange upgrade was strongly suggesting upgrades of quite a few other bits and pieces of software and hardware.  Seemed like a really complicated and dangerous thing to do.

One thing I wanted to note separately, was how easy it was to sell SugarCRM to the management.  An open source stack meant that we were could be in full control of the system.  Independent software pieces meant that we could replace and upgrade them separately.  Fully web based technology aligned very well with many other company tools.  The brief demonstration of SugarCRM got them totally convinced that the system is mature enough and can handle everything the company needs, and more.  The fact that SugarCRM could be easily installed on a laptop in just a couple of minutes helped.  The nice look and selection of themes in default out of the box installation helped.  The selection of modules in out of the box installation helped.  And the possibility to install the system with plenty of sample data helped too.  Overall, it took me less than two hours to convince the management that the system is good enough.  And I wasn’t even trying hard.

So, what’s with the timing?  We were given three weeks.  In fact, it was two weeks for migration and one week for user training.  We had to create a full replica of the existing system.  Migrate all the data and implement all the functionality to support all the company processes.  It took us three weeks to do it.  Because we had no time to train the users, and because the company was on the doorstep of a large take over, we had to suspend the CRM migration efforts.

It took the company about three weeks to integrate all the new data.  Also, quite a few processes were changed.  And the company grew plenty of new staff in all departments.

When the question of the CRM migration was important once again, we had to face quite a few changes.  Much much much more data than we originally tested with.  A lot of changes in the ways things were handled.  More users.  And more automation was needed.  The replica of the old CRM was of no value anymore.

It took us about three more weeks to adjust our installation of SugarCRM to fit the new requirements.  Even now that the migration is officially over, we still have quite a few things to fix and improve.  But that’s going to be a live process from now on.

The project was very challanging for the company, the team, and me personally.  It was a complex thing technically, politically, and socially.  For me personally, it was also quite a new management experience.  I’ve been doing some project management before, but never had to deal with such magnitude, and especially in such tight deadlines.  The good thing though was that I had to pick my own team.

Here are a few things that I’ve learned and a few things that I think are important to share.

Technology-wise, thanks heavens for CSV (file format for comma separated values).  This was the backbone of the whole migration process.  Here is how it works.  MS Dynamics CRM has a very limited exporting functionality.  Getting things directly out of the database don’t make sense at all.  For example, our specific installation had more than 220 tables, all linked to each other.  On top of that there were almost 400 views and something around 60 stored procedures.  There was no way that we could analyze these structures in any meaningful period of time.  So we did an export with entity by entity method.  Gladly, there weren’t that many entities.  There is a way to list all entities in tabular form, with columns upon columns of entity values.  The only sensible format to save that list was in HTML.

Because we had huge sets of data, MS CRM couldn’t handle the listing properly.  So we had to come up with search criterias to separate the listings into smaller chunks of about 10,000 records each.  Now, I’ll give you a second to imagine an HTML file with a table, which has around 10,000 rows and anywhere from 100 to 500 columns.

The way to handle these HTML files was to load them up in MS Excel.  It should also better be a newer version of Excel, that can handle more than 256 columns.  MS Excel is wonderful at pasing those HTML tables, but it doesn’t offer much help in saving them in CSV.  CSV in MS Excel is weird.  So, what we ended up doing was using MS Excel to convert HTML tables into older version of Excel, so that we could open them up in OpenOffice.  OpenOffice is wonderful at saving CSV.  You can pick and choose delimeters, quoting symbols, etc.  The point is to make CSV files which can be parsed by PHP.

Here are two things to remember.  First, older Excel formats can’t work with more than 256 columns.  The trick we were using was the sheets.  Copy data of the extra columns into another sheet of the same file, and it will be much easier to process later.  Second, if you will do several exports of data from MS CRM, remember that columsn won’t necessarily be in the same order.  In fact, chances are that columns won’t be in the same order.  The way go about it is to use hashes, or, sorry, associative arrays.  Take the first row, of data, which has the column titles, build an index array out of it, and then go through data rows, assigning values to appropriate keys.  Don’t use indexes for data, or you will have to inspect the order and adjust your SugarCRM importing scripts on every export.

Another technical issue is the deployment process of SugarCRM.  We are still in the mess with this and haven’t solved it properly.  We used Subversion for the version control of all the files.  But it’s not enough for SugarCRM, since some of the modules are bulit with its own Studio, and loaded with its own Module Loader.  When this happens, the database is modified, and a few local files are changed also.  We sort of have it working now, with plenty of magic and strict procedure involved, but it’s far from perfect, requires too much manual labour, and is very prone to problems still.  If you have any suggestions for this one, please let me know.

Something else worth noting, is a very unpleasant behavior of SugarCRM in terms of usage tracking.  Surely, there is an option to not send anything, but somehow I find it always sending way too much stuff out.  And the worst part is that these things are hidden, and written in a way that makes them hard to find.  have a look in include/utils/mvc_utils.php and in include/utils/tracker_utils.hp .  These are the two ugliest places.  There is another one which deals with update notifications, which I think I found, but didn’t have time to cut out yet.  I am really surprised to see these in an open source project.  And then again, I’m glad to have all the sources and being able to remove this stuff.  Who knows what goes on in closed source applications…

In terms of project management, I’ve learned to talk to people a lot.  Talking to all the people all the time was the bigger part of my participation in the project actually.  I think I’ve spent close to 80% of time just talking.  I was talking to the members of the team, trying to figure out the best ways to approach problems.  I was talking to people who were supporting MS CRM installation, trying to get as much as possible from them regarding the details of the running system.  I was talking to each user and each user group trying to see what they were using, how they were using it, and what they wanted and needed from the new system.  I was talking to the management a lot, trying to figure out where the company was going and what would be the changes in the near, intermediate and far away future.  I was also talking to a lot of  people outside of the company, trying to see how similar problems were solved there, how they managed projects of this magnitude, how they were dealing with their users, developers, and managers.

I know that many projects take a lot of talking, but in this one we had practically no documentation of the existing system and process, and we had very tight deadlines, so talking ended up being a very effecient way of getting information.

Also, talking helped a lot in extending deadlines where needed, and in keeping users calm.  Somehow, people are taking delays and system limitations very much easier if they know why those limitations are in and when there are problems will be solved.  Sometimes I had to go into technical details explaining why certain things weren’t working or were working different from the previous system.  Sometimes I had do a totally non-technical talk showing to people which other departments exist in the company and how they interact, and how things are prioritiezed and why.

As I said, I did a lot of talking.  More than during any other project that I ever handled.  Of course, I was blessed with excellent teammates who were handling the technical parts of the project.  One person was doing everything and anything about SugarCRM.  Another one was working on all the exports, figuring out other systems and getting stuff off of them.  He also helped a lot with integration of SugarCRM with the other company tools.  Great guys both of them!

Now, this pretty much covers the migration process.  But since the SugarCRM saga in our company is just started, expect more stuff posted.  In the mean time, if you have any questions regarding any aspect of this migration, feel free to ask in the comments.

Scobleizer believes in longer videos:

Advertisers also will pay a lot higher rates for those long-form ads.

Why?

Because someone who’ll watch a 30-minute video is HIGHLY ENGAGED. They are far more likely to become a customer than someone who just watches a two-minute entertaining video.

I think that “video” is too broad for this topic.  To consider only educational and entertainment videos, I see a huge difference.  I don’t believe that entertainment videos will become longer.   Entertainment is a sort of thing that doesn’t have to go either deep or long.  Thus it doesn’t need large chunks of time.  Educational video is a totally other story.  While there are many “howto” type of videos, many topics require more than 5 minutes to explain.  Take Google Tech Talks for example.  They are pretty popular and each one takes about an hour.

There is also this factor of production costs.  It’s much harder to create 60 minutes of high quality (and I don’t mean pixels or bytes) video material, than 10 minutes.  Or 5.  Filmmakers know that.  And the audience knows that.   While less and less filmmakers will risk it, and more and more of those who do risk it will produce crapy long videos, the audience will learn the benefit of a short video and will be more inclined into choosing shorter formats.

However, since I am not at all involved in any video production or distrubtion, I might be totally wrong on this.  Judging purely from my own experience.  And my own experience mostly comes from YouTube and Google Video.

Over the last couple of years I’ve been working a lot with these four applications - WordPress, CakePHP, SugarCRM, and RT.  Each of these is beautiful in its own way.  Each of these tools is an Open Source Software. Each of these tools has a large community. Each of these tools has a free and commercial support and development. Each of these can be used in a number of ways to solve a whole range of problems.  Let me briefly introduce each one of them.

WordPress

Most people who have heard of WordPress probably think that it is a blogging application.  It is indeed. But it is so much more.  I’ve argued before that it is a web application framework.  It can be used to build things like classified directories, job sites, address books, booking systems, object management tools, forums, etc.

Just think about these features: database abstraction layer, RSS feeds for everything (including custom objects), tags and taxonomies, themes and plugins support, administration area, user management.

CakePHP

This is one of my recent discoveries.  CakePHP is a web application framework, but on a lower level than WordPress.  With WordPress you get the tools, and you also get some logic in how things are related and how they work.  If that logic doesn’t fit the way you think or the way your application needs to work, than you’ll be better with CakePHP.

CakePHP helps in getting your application out of the way.  You can create prototypes really fast.  It helps you to focus on your main stuff - your application.

SugarCRM

As with WordPress, most people who have heard of SugarCRM probably think that it is Customer Relationship Management tool.  And it is.  But it’s so much more.  It is also a platform.

If you take the evolution of an average business web site, then it will go something like this.  First, we don’t even need a web site.  We’ll just pay for advertising or directory listings all over the web.  Then we’ll need a simple web site with contact information.  Then we want to expand it a bit to have information about the company, a list of products or services, and some other static information. A contact form appears somewhere around here too.  Then we start getting into more dynamic stuff with company news, online shops, etc.  Then web site becomes sort of a primary tool for a business.  It is content management, stock management, communication tool, and more.  At this stage, site’s database holds much more data than can be seen online.

Now if you think about that evolution in terms of software development, you’ll end up in hell.  You started with a clean and simple thing, which grew over the years and became a patched up monster that nobody wants to touch.   Most web sites would be rewritten a couple of times, but that won’t help them much.  Because most web design companies aren’t software development companies.  And though they are slowly turning into software development companies, they aren’t quite there.

SugarCRM helps a lot here.  It is a large and complex application that provides a solution from top to bottom.  So, instead of upgrading the web site and adding a few things here and there, you’ll be downgrading SugarCRM and removing things from here and there.  Depending on which level of evolution the web site is, SugarCRM might be a much better solution than a lot of inhouse development.

RT

Request Tracker is a tool that you’d want to have in any organization what-so-ever.  You’d also want to use it if you are running a project with more than three people.

Originally, RT was just a tool for technical support departments.  Clients raise issues, these issues get assigned and passed around, until they are resolved.  Something like that.

But more and more people use RT for all sorts of tracking.  Anything from managing software development process (together with version control software), to company document infrastructure, to mass mailings.  Flexibility, low system requirements, and excellent community make it a great tool for more things than anyone can imagine.

There is an interesting post at The Open Source Advocate blog - “Win the desktop, and you will win the server“.  Tristan Rhodes, the author of the blog, suggests that in order for an operating system to conquer the server market, it should first conquer (or fight reasonable well for) the desktop market.

I have to admit that when I just read the article, I felt almost like agreeing.  But something kept buzzing me from the inside, so I kept that tab open for a few days.  Now that the post was processed at the back of my brain, I have to say that I don’t agree with that point.

There is, of course, a correlation.  Once sysadmins start using something they like on the desktop, it’s pretty soon that they try to see how well that thing handles server tasks.  So, of course, people using Windows on the desktop were checking out how to make a server out of it.

But.  I don’t think that conquering the desktop is the only way to the server.  Not at all. There are more ways, I somehow feel that those other ways are actually simpler.  For one thing, Linux has never been particularly good with desktops.  However, only the stubbornest and the most ignorant of sysadmins will argue against Linux server superpowers.

Furthermore, real sysadmins (which are, of course, in the minority) clearly understand the differences between a desktop computer and a server.  What’s good for one might not be so good for the other.

And then there is this whole “enterprise” issue.  Big companies (aka “enterprises”) aren’t about desktops.  They are about support services, customizations, and having someone to blame.  If there is someone on the other end of the twisted phone cord, they’ll grab him with both hands.

The historical examples in the Open Source Advocate’s blog post might be related or they might not.  The times were different anyway.  But even if these examples are related, they aren’t as heavy as they seem.  There are many factors to consider (prices, distrubution, documentation, hardware requirements, etc).

What do you guys think?

I have recently upgraded my laptop to Fedora 9.  Those of you who come often to this blog or follow me on Twitter, know that I’ve been waiting for this release like for nothing else.  Two technologies in particular - KDE 4 and Firefox 3 - were the center of my focus.  Of course, I could updated them separately and tried them earlier, but I wanted to follow the path of the distribution.

The upgrade itself went fast and easy.  But starting with the first reboot, I was getting more and more negative towards the new release.  While booting for the first time, I got two messages, notifying me that wpa_suppclient service and CUPS daemon failed to start.  While I don’t care much about printers, wireless connectivity is vital for me, so that was a bit discouraging.

The login screen.  It was changed quite a bit, and I didn’t like it much.  Logging in.  Somehow I ended up in Gnome, even though my desktop environment was KDE for the last 7 years or so.  Logout.  Switch into long awaited KDE 4.  From the first look it was beautiful, even though not quite for my tastes.  Surely, I’d need to reconfigure and change a few things. Not a problem for me at all - even more fun so.

But.  After about 5 minutes I started to realize that KDE 4 was very fresh.  Very unstable.  And very buggy.  As I said, I know my ways around it and I am pretty comfortable with using options, Kcontrol, and even configuration files.  But despite all my efforts, it was simply unusable.  The panel crashed a few times, finally in such a way that there was no way to bring it back even with logout.  Then, icons on my desktop kept loosing their order and locations.  I’d go through the boring process of sorting them around and then the would randomize themselves upon the next login.  Icon properties were weird, and quite a few features were missing, especially from my mostly used KDE application - konsole.

Still fighting with KDE, I was after some help, so I fired my next most awaited application - Firefox 3.  This was a better experience, but still not as shiny and dreamy as I expected it to be.  Out of all extensions that I have installed, more than a half didn’t work.  The ones that worked were mostly for bells and whistles, but I got really worried there for a bit when the tools that I am used to weren’t there any more.  In the meantime, the KDE still refused to pleasure me.

To cut a long story short, I decided to temporarily switch to Gnome.  I used to be a fan of Gnome back in the pre-KDE 3 age, but since then I haven’t used it much.  KDE was perfect for me.  I loved it.  I didn’t want to go back to Gnome.  I wanted KDE 4.  But I’ll have to wait.

Then, I started righting this really long post and I was so negative about everything that I decided to postpone it for a few days.  And now I am rewriting it, and I have to say that Fedora 9 upgrade was one of those things for me that happen for the better.

Gnome turned out to be a really nice desktop environment.  I really really like it now. It’s not love yet, but we’ll grow into each other.  That is if KDE 4 won’t get its act together fast.  Oh, and Gnome has a share of its, sometimes very weird, problems, but it is very usable, fast, and intuitive.   As for Firefox 3, I spent half a day going through available addons and I managed to find enough of substitutes to my old tools.  Some are better, some are not.  Some are my old tools, but in un-official alpha and beta versions.  But overall, it looks like I will survive.

Back to the Fedora 9 release.  I don’t remember what exactly went wrong back when Red Hat Linux 7 was released, but I remember that there were a lot of issues.  My memory has a strong association of Red Hat 7 and Linux distribution release gone wrong.  I think now that association is going to be updated with Fedora 9 experience.

Breaking the much used functionality is bad.  Taking away tools people use is bad.  Releasing unstable software without proper fall-back (and I don’t consider Gnome to be a proper fall-back for KDE) is bad.  I think that both KDE 4 and Firefox 3 should have been offered as options, not as defaults.

Then, only a day after Fedora 9 was released, I had to download 140 packages of updates.  That wasn’t a big problem, but it was yet another sign of how shaky things are.  The updates fixed the CUPS issue, but there was also a new kernel update, which broke GRUB and rendered my laptop unbootable.  Gladly, I had the DVD nearby and I still remember how to use the rescue mode.  But it’s not how things are supposed to be.

As I said, I am finally glad that I got a chance to give a look at other options and use different tools, but I am very disappointed with this release.  Things like this make advocating open source and Fedora Linux harder.  Things like this undermine users’ trust in the distribution.  They should not happen again.

P.S.: I am by far not the only one having issues with this release.  Check comments to the Slashdot announcements or posts on the blogosphere.

P.P.S:  If you are a Fedora user who were planning to upgrade, I suggest to wait until Fedora 10 or at least for a few weeks until updates will fix the most obvous issues.