steven n fettig's Jitterin' Thoughts

     The Inquirer has an interesting article on the value (or cost of running Linux on the Desktop). There are two points relating to the article (Can Linux break through to the commercial office desktop?) that I would like to make:
1) Cost, cost, cost... People continue to talk about the small cost difference between running Linux vs. Windows. While there may be a similar cost associated with Windows and Linux for a large company, smaller companies (like the one I work at) are hit hard by the latest pricing scheme for Windows. On top of that, unless support packages are purchased for Windows (on top of the cost of the OS), support is non-existent. Please! Compare apples to apples (and with that, I did not necessarily mean Apple). Essentially, what Microsoft does is sell a car, that has a life-expectancy of 1 1/2 years and no service. The further expectation is that you upgrade software and hardware at intervals defined by them. The issue of Linux having no support is a tricky one, indeed. You overcome this issue by simply ponying up the bucks to pay for a good admin. (In an article I posted to some usenet group a long time ago, I mentioned that it is likely that any good *nix admin will also be a good admin of Windows - this is a gross generalization, but in my circle of friends, it definitely applies.) I think the long-term cost of Linux (or other flavors of *nix) are much lower than Windows, but have yet to see any conclusive studies that would indicate this either way.
2) Application support - i.e. applications that can read the current de-facto standards: This does and does not exist. With the newest versions of Open Office and StarOffice, I have found much better compatibility and navigation, but it still is not Office. But, does that really matter? I have found that 98% of the formatting options available in Office are not used by anyone except presentation nuts. In fact, the more someone needs specialized formatting, it seems the more that one will rely on programs like Acrobat and not Word. So, do we really need ultimate compatibility? My answer, no. What we absolutely need is ease of use... this is something yet to be attained by any system. Just ask my Dad why he hated the switch-over from Win98 to WinXP on our office internet computer... (As I fall asleep at night, all I can hear is, "why the heck do they always have to change things?")
     So, Linux on the desktop? You betcha' - just as small businesses make the economy turn, they will also make the switch to Linux as Microsoft keeps stabbing them in the back with new pricing schemes.

This thought brought to you by: Can Linux break through to the commercial office desktop?

Oh, and by the way, if I didn't own (and like) my Mac PowerBook, I'd already be there...

     I have a new programmer coming to work for the company I am at (he is actually an old friend who I have worked with often in the past) and we will be working on setting up a new manufacturing database. The prerequisite for this new database is that it has to run on Open Source software. Another requirement I have thought hard about was whether or not it will be web based - i.e. the user front end should be a web interface. It will... That way, if we continue to struggle with software costs from Company XYZ, then we can choose to move to another OS and use that default web interface/browser.
     So, here we are working on finishing a project that was started over two years ago (it is a long story why it never was finished) and we have chosen RedHat 8.0 as the development platform - 1) Because he is familiar with Linux and 2) he needs to work with a graphical interface (gui) and I am not willing to learn how to set up Xfree86 on the Via Eden machine we will be using. As I write this, our machine is going through the installation process... we'll see how things go (and you will be the second to know - I'll be the first).
     I am somewhat reluctant to use RedHat again - after the problems that I had with it originally, but my philosophy is to let programmers use what they are most comfortable with. I can't imagine me being forced to work (regularly) on a non OS X machine. I like the chewy interface of OS X and I like being able to hook up my Firewire Hard Drive, DVD drive, etc. without a hitch. The most important aspect of this project is that we stick with Open Source software or software that is well known for inter-OS-operability (like Java). My personal preference would be to have most of this built in perl, but since he is primarily a Java programmer, that's what we will be using.
     Here's to hoping for a more successful run with RedHat!

Okay, I have been putzing with this for months (maybe even longer) and every time I come back to it, I don't get anywhere, so I'm asking for help. If anyone knows how to do a dual-head setup w/ Linux (actually, it doesn't matter if you know how with FreeBSD, Linux, etc - I simply need to figure out the XF86Config file) and a Matrox G450 dual headed adapter, I would greatly appreciate your help. Write me at kaffeelover AT stevenfettig DOT com.
Note: I cannot run XFree86 -scanpci and thus am stuck at finding out the bus ID of the AGP card. I know that the first head is at PCI:1:0:0, but cannot figure out where the second head is. I have tried PCI:1:1:0 and PCI:1:0:1 - neither worked... Everytime I also fail because the mga_xxx driver won't load... Anyway, I'm getting tired of trying with no clue and would appreciate anyone's assistance!

As a follow-up to my SCO Debacle post a while back, I came across this article, SCO Hit by Legal Action in Germany and smiled a bit. I admit that I am very suspect of SCO's claims (I still view this as a ploy for SCO to earn income on something they do not completely retain billing rights over), but at the same time, the real reason for my smile was because they are actually being forced to back up claims with proof - i.e. if they want to make the claim that Linux (in general) has infringed upon their property rights/patents and they are owed money, they need to provide proof. They haven't provided proof, ergo their claims are baseless and misleading. I'm still surprised that the FTC hasn't stepped in to stop them from continuing with the line that Linux has stolen conceptual data from them. It appears to be misleading advertisements to me.
The question of whether Linux code contains SCO owned code is certainly interesting. I don't see how SCO can actually manage to regain control over source code that has already been submitted to the public and is in many cases under the GPL... Regardless, if SCO ends up proving Linux contains proprietary code, I would imagine we would see a swift change in the code-base of Linux that would rid the project of any code that they cannot freely use. ...an arduous task, indeed, but possible nonetheless.

Well, after a few days more of putzing, I finally got things set up correctly. I keep forgetting to leave my workstation on during the day so I can download the config for XF86Conf and show it on this post, so the written details will have to wait. Suffice it to say, however, that syntax and the whole -scanpci switch were my main issues. Firstly, running

I couldn't help but post a link to this thread kerneltrap.org published in a post called Linux: Linus on Choice. I have published elsewhere my admiration of Mr. Torvalds. Although I don't partake in his nihilistic approach to life (as is well outlined in the messages he sent), I still find him a fascinating man. If you want to know a little about a man, read his writing... hence, the posting here.

    Adam has a very good post on not just his take on the SCO/IBM case (which I have been trying to follow in some respects at groklaw), but good reason to back up the claim that SCO is simply on a scavenger hunt for money. My favorite part:

    I have tested this concept on FreeBSD by having multiple terminals open and running 5 or so different port install processes simultaneously, but I have never actually thought much about it until today on OS X. I was initially always very careful to install only one port/application at a time on my FreeBSD machines - I wasn't sure whether the compilation and installation of the software would cause conflicting libraries to be installed, but I found out that the library concept used in Windows is not really the way things work under most *nix distros. So, after some testing of this theory by actually running multiple installations of related and unrelated programs at the same time, it didn't ever appear to effect the end result - i.e. whether or not the program properly ran on the machine. Today, however, I found myself in a slightly different situation and don't know if there is a straight forward answer.
    I was installing Microsoft Office (gasp! - well, I do really need it sometimes for docs sent to me that cannot be properly read by OpenOffice) and at the same time compiling Gimp for the X11 side of my machine (i.e. not the native OS X version that is apparently out there). I was wondering: because one is basically a binary installation and the other a compilation process (very similar to the port installation routine under FreeBSD), is there a way that those installations could conflict with one another, and if so, how? My gut instinct is that the answer is no - but there are always exceptions to the norm and I am wondering what those exceptions might be. For the two people out there who read this weblog, maybe I will be lucky enough to find out without having to do too much research... Comments are very welcome.

    I was going to wait to post until I finished my latest project, but I couldn't help but laugh (geek-ily) as I got an ssh login to work on a Zaurus SL-5500. Now that I can vpn into the office, I have the Zaurus I am working on set up at the office in its cradle and I can ssh into it remotely to do the rest of the configurations I wanted. This is nuts, right?

    All I can say is that this is one of the cheapest mini database servers I have ever built ($250.00). From an environmental standpoint it is a slam-dunk, too - very low power consumption and extremely compact. Ahhh... the joys of success! If I get a chance, I am going to run some load tests on it to see the results. I would also like to tweak apache a bit - but I need to learn how to compile software for the Zaurus first. (Anyone with good references, please let me know.) Anyway, I hope everyone is having a good weekend.

    As mentioned in an earlier post, I am working on a mini database server using a Sharp Zaurus SL-5500 as the hardware. It seems that a lot of the development sites and lists (@ lists.zaurus.com and docs.zaurus.com) are no longer available (it has been the heart of my frustration since prying into the Linux command layer on the Zaurus) - it appears that Sharp has taken down all of the original development sites and is working on a new one. Who knows when the new one will be available, however, and in the mean-time, you can use Google's cached versions. As of two days ago, the only version of Apache (and PHP) I was able to install (without a slew of errors) was one found at: www.choup.net. You need to download an older version - Apache 1.3.19 with PHP 4.0.5 Support (others extensions too). It appears that the newer version is compiled for the OpenZaurus platform and not the original ROM that ships with the SL-5500. Since I am only using the SL-5500 for an internal DB project, I am not so worried about the security flaws in the older Apache and PHP versions. I only tried to install it using ipkg-new and using the internal flash as the install location (you need to use the ipkg command line installer found at h2o.ch/zaurus/sharp/). I experienced a few errors when installing (something relating to not being able to open and copy to the SD card - which I don't have anyway), but I ignored them and tested the server (it works very well!). The ipkg tool has very poor documentation - that I can see - and is therefore somewhat difficult to decipher; especially when I don't understand why it is trying to install the Apache/PHP server to a location that doesn't exist and which I didn't indicate. So, for those of you trying to get this to work, check out the above sites. This, again, is not for the faint of heart. I intend to learn how to compile programs for the original ROM on my Mac so that I can tweak Apache for my own purposes. If allowed by the license, I will then post the ipk file to this site. Anyone wanting to help, please let me know!

     I have been racking my brain trying to figure out how to install the terminal app for the Zaurus. I found the correct URL for the program, put it into the address bar of the older version of Opera that was on the device and tried to download it. I tried as I might but couldn't figure out how to. It kept downloading the ipkg package to the /temp directory. The installer (Add and Remove Software) package could not find the file I just downloaded... and thus I went 'round and 'round. I finally looked up the manual for the Zaurus at Sharp USA (the How to Install Software and promptly saw that you cannot simply load software from the device - you must load it via a removable memory card (SD or CF) or via the sync software. The ironic and most irritating bit about the Zaurus is that it only syncs correctly with Windows. (Those of you who do not understand the inherent irony: the Zaurus is a Linux device... and there is no pre-packaged sync software for Linux... for a Linux device. Crazy!) Luckily, from my last go-around with the Zaurus, I had all of the necessary packages on a CF card in my brief-case. I popped the CF card into the device and started up the install program again. At that point, I was able to see all of the packages I had gathered up until now on the CF card and installed the necessary apps: ssh and terminal. I still am amazed at how difficult the device is to use with other Linux devices. I like it, but I don't like it all the time. Lesson learned: keep a spare CF card around for installing software on the Zaurus. You'll be thankful you did.

     While doing a lot of work on the new Darien-Wifi project, I have also spent a lot of time testing different OS's on the desktop. While extremely happy with OS X - and more so when I wander away and come back - I am still inclined to try different interfaces out of sheer curiosity. Since 1998, I have tried to install and use SuSe at least twice a year. Although happy with much of the RedHat ease of installation (and the fact that they had always offered ISO's for the CD set free to download - which SuSe does not), I always disliked the increasing similarities between Microsoft's OS products and RedHat's distribution of Linux. Too often, the subscription element of RedHat reminded me of the Microsoft update procedure. Although I am here to say that every mainstream and semi-mainstream OS has some sort of update service (OS X's can become as irritating as Window's) that will become annoying at one point or another, I simply don't care for Microsoft's nor RedHat's. Plus, RedHat eventually announced that they were dropping desktop support and going to focus on providing server distros. This year, I am on my third install of SuSe and am impressed. The standard KDE interface is pleasant and it is fairly responsive on everything from my PIII SpeedStep Sony Vaio SRX99 to a P 4 2.5 Ghz Compaq/HP desktop. I wouldn't dare try it on an older PII machine (I can't imagine the gui would be very responsive), although there may be tweaks out there to overcome some of the issues one would have with a slower machine. There are many aspects of power management that I haven't taken the time to get working on the Vaio, but SuSe does work. YaST takes a bit of getting used to, but it has been more intuitive for me to use than RedHat's install tool and package manager. This is not to say one is necessarily better than the other – the install process and application installation process on OS X is by far the easiest and most intuitive for those just starting out on a computer – I think YaST does a better job of telling you what you have installed and what you have for options. On top of that, YaST helps manage many other configuration items on your machine. Now that I have been using it for a while on a desktop (with a big screen), I see how I might have better dealt with problems I had on the Vaio. If you simply want to use your computer for web browsing, emails and word processing, there is no reason why I wouldn't recommend you try it.
     Although I find SuSe very praiseworthy, I would caution those who are not power users who like to tinker a lot. Get a Windows or Mac machine. With Windows your biggest trade-off is security holes and virus threats. But, as with any machine, if you maintain what you have and are careful, you can go through life without virus and security run-ins. If you want a machine that is simple to use, is unlikely to be a virus or security threat target and allows for quite a bit of modification, go with a Mac. SuSe is something I would feel comfortable setting up for my parents behind a hardware firewall/router. I would sleep at night knowing it is unlikely they would inadvertently infect their computer with a virus. It would also give me peace of mind regarding stability. How often does your Linux or Mac crash? Outside of those who really like to muck with the interface and install all kinds of apps that modify the gui and underlying system, it is a rare occurrence for those [Mac and Linux] users who really use our machines as tools. For those of you who are power users, I have heard complaints that SuSe locks you into their way of doing things. I don't know how to respond. The one delightful item that I found while installing the system (on the computer I am using to type this) is that I had a choice between Apache 1.x and 2.x. I lamented over the Apache 2.x issue some time ago with RedHat and was happy to see that I had a choice this time around. I still won't put Apache 2.x on any of my production machines – and I don't know many who would.
     Between the good looks of the interface and the ease at which I was able to accomplish all that I needed (so far), I am impressed. My 2 cents...

Somehow I missed this little gadget, the Pepper Pad (and now Pepper Pad 3) from Pepper Computing. Currently, I'm waiting for v. 1/2 of the Pepper Pad from Amazon/Target to test, as the 3 series isn't yet available. I've been looking for a non-laptop, but close to a laptop device for reading the massive amount of eBooks I've downloaded and bought over the years. For years, I've tried to do with Palm or Palm-like devices (whether the Treo or LifeDrive) and never find them completely comfortable for reading mainly because the screen is too small. I also have a need/want that I can't live without on a computing device: OpenSSH. Yes, that's right, if I'm going to get a PDA or anything between a PDA or laptop, it has to have the capability of running OpenSSH (or a derivative thereof). It is the only program that is able to keep me in touch with the world under any and all conditions (even on a slow 9.6kbps link). (The excuse used to be needing the ability to get into the network gear for Anywhere Technology, but these days it has to do with every connected device I own, including the server farm that now sits in DLS's facilities.) If I have a device that can be considered a computer and it can't run OpenSSH, then it simply isn't worth it.
Well, considering the two needs listed above (i.e. reading eBooks and running OpenSSH) and the fact that I can check facts, lookup ideas and write some basic notes (vis a vis the keyboard), I really like the device (in concept). What I want to find out is whether or not the Pepper Pad (original or 3) is as much of a disappointment in the area of battery life as the OQO +01 I picked up last year (which I've written about before). CrunchGear has a YouTube video that gives a brief, brief overview of the newer of the devices.
(For a written [quick] review, see: PepperPad 3 Hands-On - by the way, it is Pepper Pad, not PepperPad per Pepper Computer's site)

Whoa, was I wrong. The Pepper Pad couldn't have been a worse experience right out of the box. I don't know if I am slowly developing unrealistic expectations when new gadgets arrive at my office, but even if they were/are, I haven't had an experience where only one expectation was met to some degree of satisfaction. Here is the list of items I wanted out of the Pepper Pad (please note, I didn't purchase version number 3 - the website and specific details I have found on other websites do not show that there is really any difference between the two in regards to what I am about to make remarks upon):

Wants:
- crossover pda/laptop - i.e. not a pda and not a laptop
- wireless network access
- a qwerty keyboard (I'll take a non-standard type - I just want one for input, as hand writing is too slow and speech recognition wouldn't even be an option for most times when I want to use the device)
- a web browser that was similar enough to Firefox
- an email client
- decent battery life (nothing less than 2 1/2 hours with moderate or little wifi usage)
- some documentation
- a book reader that was capable of reading Mobipocket's or eReader's eBooks

Successes:
- it is a viable crossover. Some may debate that the size is too large (and it was larger than I was expecting), but it had good heft, felt good in two hands and had a very readable screen.
- qwerty keyboard. It is odd to get used to, but I can see it working well in the long-run.
- wireless network access. It hopped on to a few wireless networks I frequent without any issues.
- web browser. It just so happens to run Firefox.

Failures:
- Battery life was never more than 1 1/2 hours with moderate wifi usage. I know what moderate usage is and I'm being generous by saying my usage was moderate because it was more along the lines of little. I surfed to websites where I spent good amounts of time reading long pages, so I wasn't technically using wifi a lot. To be considered a mobile device these days, one should be able to say that the battery lasts at least 2 1/2 hours. I don't get anything done in less than that time.
- The Email client is a complete failure on two fronts. One, it doesn't handle more than one email account in any easily discernible way. It also doesn't support SSL connections to the server. Shame on whoever left that one out. If this is supposed to be a mobile device that I would use to supplant my laptop for short trips or quick trips to the local cafe, I need some type of security and it doesn't offer any. I can't stress how worthless this makes the device. Of the two most important technical items that a device like this must support, email and web, one failing is not an option. Let us say that I am a normal person and have one email address. Fine, but how is my wife or significant other supposed to use the device, too? I had envisioned getting a few of these to spread around the house for a quick trip on the internet and to check email - for my wife and I. Even one of my original Palm's supported more than one email account.
- The documentation is worthless. I have had it with devices that don't come with or offer access to decent documentation. The support page at pepper.com is an email form to their technical support person/staff (see link). What?
- The last fault is not necessarily Pepper's fault, but when one of the short list of advertised functionalities does not work, then it is a failing. MobiPocket does not work. Without getting into the strange and gory details of how MobiPocket's DRM works, it suffices to say: your device gives you a key (PID) that you use to register said device on MobiPocket's website and then you can open books on said device that you have bought. My key didn't work and still doesn't. I wrote MobiPocket through their forum about this and they thought my key had an i/l/o in it that can easily be confused with a 1/1/0. I wrote back to explain that the key is 2945955ZW and I tried registering it using a few different methods on a few different web browsers on a few different computers and it never worked. I responded in the following post to the suggestion that I was entering it in wrong, but haven't heard back to date.

So, to wrap up, the fact is that there are far too many compromises I would have to make in order to make the device usable. The fact that one does not have easy access to software that is not pre-provided by Pepper doesn't make the list because from the wants list above, it really boils down to three things: battery life, web access and email access. The Pepper Pad fails on two of the three for the reasons given above. Even the market of simple users out there wouldn't be happy with the above limitations and I can't see why anyone would go to the trouble to make it work by compiling needed software for the device. I guess a lot of my complaints are colored by the knowledge that Pepper could have resolved any or all of the worst problems with relative ease: put a higher capacity battery in the device, use a real email client and give us some basic documentation on how things are supposed to work - beyond the pictures of how to turn it on, off, etc.
If you wish to comment or provide feedback to my posting, please email me using the address listed on this website.