Rage Against The Status Quo

I haven’t blogged in ages. Time has moved on since I set out to try to complete 52 projects in a year. It was an exciting effort, but not without difficulty. It is tough to blog. It takes time to write up something worth reading. Couple this with a rapid schedule every week trying to do the project, work, and take care of family. So after about 1/2 way through, I was really behind, and I stopped blogging.

I moved over to twitter (@dkords), which has worked better for me, both in terms of reach and in immediacy. You cannot spend 3 hours writing a twitter post. Well, if you do, you have some serious vanity issues.

I am happy to say I was able to get all 52 projects completed or at least started in some way or form. Most projects included learning a new skill in order to complete some other projects. I spent time on a number of projects. I can’t say I was able to do any big ticket items. I found these challenges in a 52 week diet of projects:
* documenting on the blog takes time
* one week doesn’t allow enough time to complete anything significant when one week usually == 2-10 hours
* jumping in and out of projects (setup, tear down) is draining
* finding a focus for the week can be difficult

So in all, I think my Sao Paulo diet was valuable. It taught me a lot about myself. I know I cannot succeed if I don’t focus on a small set of projects, maybe 3 per month, ongoing, with medium to long term horizons. It’s easier to focus and feel like there is progress. I’ve also discovered I am an obsessive nut about trying out new things. I love installing new linux distros. I love building new open source projects. It is an adrenaline rush, like drinking a Red Bull.

My biggest accomplishment during this 52 week period was of course, having Baby 2.0. She is a great little kid, wonderful personality already. My second big accomplishment was running a marathon. This in itself was a project that could have taken my entire year. But in my fashion, I only started training in March-May, and managed to finish out my training at 24 miles. My marathon completed in 26.2 miles (as was everyone’s) in 4:29.

Looking forward to some good things for this year, and finishing out strong.

I can’t think of a worse user experience than when a big PC/Mac software company decides to drop a turd on Linux/Unix.  I can remember when Adobe used to ship a version of Photoshop on Solaris.  Absolute garbage.  The install was tweaked.  The app was ugly.  It crashed.  But it was all we had so we shut up and used it.

I recently decided it would be useful to get some snazzy looking apps on Linux.  So I went to see if Adobe Air was available on Linux.  Lo-and-behold,Air is available.  I found an article discussing this very topic.  First thing I noticed after the download was that this is not an RPM, a deb package, but a good old binary.  So run the binary from the shell.  Up pops an installer.  Nothing unusual. Finish the install.  No idea where it puts anything.  Then eerie silence. 

What did I just install?  Where is it?  No clue.  So turns out they put it in the /usr/bin dir, as “Adobe Air Installer”.  Note, the spaces.  So how does one install an air app?  Well, you run the Installer App.  Wait, didn’t I just run that?  No, it was the OTHER installer.  You know, for Air. 

Right.  So when you download a .air app, you have to run the Installer on this path to the .air app.  When you do this, it will ask you if you want to install.  Then it’s done.  You of cource, need to be root or have sudo capabilities.

So now you have to find what it just installed.  Where is it.  Check in /usr/bin or /usr/sbin.  I’m not impressed guys.  Adobe, shame shame.  Just hire a linux hacker who does packaging really well, and get them to maintain the air package for debian, ubuntu, fedora, etc.  Sure, it’s not a free package, as the licensing is something adobe proprietary.  But at least be cool and play well with the Linux community.  I can’t think of a worse experience for a commercial app on Linux since I tried another Adobe product on Solaris so many years agao (for which I was responsible for delivering a “live” disk image on Solaris. 

After you’ve got air running, check out a list of 14 really cool Air apps.  Enjoy.

So awhile back, I tried building the CRUX Linux ISO on Crunchbang.  While I abandoned the effort on Crunchbang, I did not abandon the ideas behind CRUX Linux.   I’m pretty fired up about taking the theoretical CS training in operating systems and get into the meat of the Linux Kernel and how a distro is built using the Linux Kernel.  I believe Arch Linux and CRUX lend themselves well to getting under the hood.  By default, CRUX is not easy.   Nor is Arch.  CRUX takes it a step further.  You have to set up your own disk partitions, and you get to configure and build your own kernel too.  No big deal if you know the principles of disk paritions, understand fdisk, disk geometry, and the kernel build process.  The hardest thing I find is knowing the right choices to make when deciding your disk partitions.  There are some rules of thumb to follow, but otherwise there is a lot of personal preference in how to proceed beyond swap and root.

So most people will stop before passing go.  Why even bother with this if you have Ubuntu or Deb?  It’s simple.  You’ll never learn how it works if you don’t get under the hood.  Yes, you can get under the hood with Deb or Ubuntu.  But not by default.  Ubuntu is now about as polished as a windows install, and it generally makes recommendations and suggest defaults when you don’t yourself know what to do.  So preimise one is that you can’t learn when the complexity is hidden.

The other argument is fat.  Ubuntu is a release train like Windows.  There is a question of legacy support and migration of users at the fore of any new release.  And there is the question of what to add to the new release to make it useful and interesting.  I would say that Ubuntu and some of the other richer Desktop Linux distros have a lot of extra stuff they come with that you don’t need, not if you know your hardware in advance and know what you do.

So like Arch, CRUX let’s you configure the packages you need from the beginning.  There is a great article on how to strip it down further to get a 16 second load time with CRUX on a Thinkpad (WOW)!  My Ubuntu takes a couple minutes to load.  Even my Arch takes about 45 seconds to load.  Windows takes 5 minutes ;) 

So how did it go?  Well, I got through it in about 4 hours.  Your root partition has to be big enough to store the initial install of CRUX, obviously.  I messed that up the first time.  Also, your filesystem type used in your partiions may have an influence on the partition sizes.  I stuck with ext2.  I messed something up, either in the Lilo config or in my partitioning scheme.  So I do need to start over.  That’s ok.  I picked up some more KNOWLEDGE.  That’s what life is about!  I learned that your SATA drives show up as /dev/sd* while your regular IDE drives show up as /dev/hd*.  I configured and built my second kernel (first was on Linux Mint to add USB Gadget support).  I’m going to try this again in a few weeks when I have some time. 

I love Firefox.  But I also love to try new things.  I thought it was time to try out flock, a social web browser.  Integration with twitter, flickr, and facebook, is sweet!  Very nice job.  The blog tool is cool.  I have yet to discover other new features, but would love feedback on what else to try.

So one of my gripes with the mac is the lack of a package management system.  It becomes very difficult to know what is installed, where it is installed, and how to uninstall it.  Several projects, like fink, macports, and darwinports, all something similar to BSD ports or debian packages, but the Mac itself doesn’t do this kind of thing, at least, not in a way you can process.  There is a manifest of all installed packages. 

I thought it was time to start tracking what I install myself.  And really track it.  So this is what I’ve put on the new mac.  Nice long list of stuff, all in the last four months.  What I’d like to do is come up with a script to go out and fetch the binaries and automate the install, such that new mac setup time is shortened.  Later, later.

1) quicksilver
2) flock
3) easyeclipse
4) flock
5) iterm
6) yojimbo
7) fink fink commander
9) apple jack
10) flash10 player
11) Neoofice 2.5
12) boinc
13) setup publicvpn.com
14) skype
15) soundflower
16) thunderbird
17) smartsvn
18) GIT UI
19) Eudora
20) Textmate
21) Drawberry
22) omnigraffle
23) Max5
24) ToyViewer
25) VirtualBox
26) MacPorts
27) Activestate Tck/Tk
28) NetNewswire
29) X-Lite
30) The Unarchiver

Working on a project around Doja.  So very interested to learn more about the i-appli content and what it does in comparison with MIDP.  Will report back when I have completed the work.

Working on it right now.  Quickpwn works great, but I can’t activate my sim (ATT).  So I am starting over, trying to use Pwnage.

Will update shortly.  Very excited about the results.

So I may be getting ahead of myself here.  As part of some efforts to branch out at the day job with our expertise in Linux, I thought I’d look at a fairly lightweight distro with a nice, simple packaging system.  It’s called CRUX Linux.  It’s only available on x86, and is really a pure community project.  The distro includes just enough to build a nice light system, and the iso weighs in around 250mb.  Why bother with this one?  Well, they’ve taken a nice BSD style approach with the package system, a collection of community distributed ports.  They are the only linux distro I could find that ships with the pkgmk tools.  It also has a side effort focused on work on ARM targets, and another effort to bring it up on the OLPC.
 

So getting this working on Crunchbang seemed like a snap.  Everything compiles on Ubuntu, right?  Not. 

So here was my first mistako.  I probably should have built this thing on a Crux distro.  Instructions to build are fairly easy.  I pulled the 2.5 tags from git and proceeded to build.  The instructions can be changed to use 2.5 instead of 2.4.  Also, you probably want the 2.5 Handbook. 

The process seemed to cruise along until I got to ports.  The ports started breaking because I did not have the usual prereqs to build.  Here is a short list of what was broken on ubuntu:

• gtk+2.0 (missing on my distro) - need lib dev packages
• dbus-glib
• libgnome-dev
• libsqlite3-dev
• gmp 4.1 or libmpfr
• curl-dev
• uuid-dev
• bcc
• as86 and ld86
• libpcre-dev
• libdb4.7-dev
• libmpfr-dev
• libwrap-dev

After all of this, I had two big packages breaking, gettext, and glibc.  The gettext problem was actually a known bug in 0.17 related to the new syntax for O_CREAT, requiring 3 args.  So really no love here.  The maintainer at Savannah agrees, this is a bug under Ubuntu 8, and will fix for the next release.  So my only option is to pull his latest source and apply his fix, fix it myself, or try to ignore this package.  I can’t ignore the package.  So I pull the latest source and create my own local package for gettext.  After a lot of mistakes, I almost get it right, but still have a problem with the md5sum footprint, as well as the naming, and the expected sources in the footprint.  So it requires time to add new packages, lots of patience, and a bit of know how.  It’s a nice system with Crux ports, possibly better than some of the other distros, but I ran out of time to get this working.  I would still have to deal with problems building glibc as well as perl.

So put this one back on ice.  I spent about 15 hours on it.  Very instructive.  I am interested to try crux on something, maybe for mythtv.

  Firefox can actually do the trick with the encoding without a lot of effort.  If you have an idea of what the general country source of the encoding might be, say Japanese, go to the Firefox->View->Character Encoding Menu, and select Autodetect.  There you can tell it to go ahead and try a best effort guess.  Then open the file in question.  Firefox may prompt you to help it out, but usually it makes the right guess.  Once you know what the encoding is, you can coerce your other tools to open with the right encoding.  Knowing is 3/4 of the battle.

Ever read a file sent to you from someone in Asia?  I work for a Japanese company, and we constantly get text files (.c, .java, etc.) littered with comments in Japanese.  They do not appear very nicely in most cases, usually as a collection of odd characters like this: <82>»<82>«<82>Ã<8e>¿<8d>s<83>

These are the names of the supported encodings on your system.  I was mostly interested in how to read these properly in my text editor, TextMate.  I found a good article discussing how to add a bundle to “Open Encoded File”. 

The result is “all good”.  You can use this little bundle add on in TextMate or use iconv directly to convert to the chosen encoding.  Just make sure your editor can handle it.