It seems to me that much of the art of software engineering is in finding a consonance with the business needs of the corporation. Hit that sweet spot, and you'll be blessed with short days and easy updates to your code. Miss the mark, and you'll pay in tight deadlines and difficult relations with your managers.
This, I suppose, is the situation of many technical intellectuals in the First World....
perldiver (aka John Kawakami)
-------------
I quickly read through the `geek' thread last night and this morning. Hmm, speaking of which...
I've been lost in geekland putting in a new hardrive and moving everything around in my main freebsd box. This has taken me about a day and half to do a complete re-install of freebsd and win95.
Here's a short story that sort of relates to this thread.
The problem that hung me up for most of last night was a little subtle. The boot disk manager that handles switching between drives (and therefore OS's), counts the drives plugged into the onboard IDE primary and secondary buses from the BIOS as hard disk# 1, 2, 3... . But the FreeBSD kernel numbers the drives beginning with 0, 1, 2... . The boot manager tells the boot loader, which tells the kernel, the root files are on disk #2. So the loading kernel goes to `wd1' in its numbering system and can't find the root file system because it is mounted on `wd2' (first disk on secondary IDE bus). On the screen what you see are the devices loading, then boom, `can't mount root. panic! error (6). rebooting in 15 seconds. hit any key to abort.'
I did not figure this out. I went to the FreeBSD site, did a search of the newsgroup archives on `error (6)'. There was the above explanation and two solutions. First solution, put the IDE drives in physical order without any blanks: from primary master-slave, to secondary master-slave. (I had two disks both masters, one on each bus and left the primary and secondary slaves blank). If I moved the secondary master over to the primary slave position, that would solve the count problem. This insures that (1,2,3,4) is mapped to (0,1,2,3) one to one onto.
The second solution. During the boot load, there is a ten second delay that allows you to interrupt the sequence and enter commands directly into the boot and kernel load process. The correct command to enter was: `set root_disk_unit="2"'. Once the kernel loads and the system is up, go to the boot script and enter the command in the script. Rather than open the box and rearrange the drives, I hacked the boot script as instructed.
Now I am telling this story for a reason. The only way that this dumb user mistake could be figured out and solved was through something like an open source OS and a community to back it up. There is simply no way I would have figured this out on my own. The solution came from somebody named Jens Schweikhardt at diamnant.noc.dfn.de (obviously a genius and wonderful person, from my point of view).
So, here's a suggestion for Kelley or any one else following this thread. Get an old box and load it up with something like Linux or FreeBSD. This will give you insights you can't get by watching and listening to computer geek and hacker culture. It will also show you in no uncertain terms just how the entire industry and about ninety-five percent of the user world has been screwed by the evil billwitch. His billions are not even half the problem. Your, meaning you all, have no idea just how much effort has been devoted to making and keep you stupid and clueless.
You can read about class war in the information economy and go through all the intellectual property law you want. But, until you actually get down to this other level of struggle, you just can't quite see the battle ground clearly. General computer ignorance or the fuser-luser, is a direct product of the software systems themselves--specifically a direct product of Microsoft and Apple design. In other words, you are rendered stupid by design.
Here is another example. There is a default postscript print filter that comes with most unix systems that converts ASCII text to PS and sends output to a spooler or temporary file. The line printer daemon reads this spool and feeds pieces of the file off to the system printer port. The filter sets default margins, lines per page and font baseline dimensions. The problem is these defaults produce an entire page filled with text out to quarter inch margins. The reason for these defaults is that most PS printers print to within a quarter inch of the edge of the paper.
Now, most of the time applications do their own text conversions and page layout, send the output to the spooler and therefore by-pass the existing system conversion. However, if you want to print something without opening an application to do it, you use the `lp' command, and therefore the system ascii to ps filter.
Since I was in the process of re-setting up the box, I decided to solve this problem. I found the script that runs the ascii to ps conversion program and then pipes it to the spooler--by reading the manual pages (what a concept!). So, I re-set the layout defaults in the script. For the first time ever, I can type `lp <filename>' and get printed output with 48pt margins instead of quarter inch. These margins are a little over half an inch which makes a text box slightly larger than most applications use. If the application sends output to the default system filter with its own margin settings then the application layout will usually fall inside this default text box.
Now anybody who ever struggled with Msuck's postscript print drivers should appreciate the above story. The ascii to ps conversion under unix is completely generic and it doesn't matter which postscript printer you are using. There is no long list of ps printers you have to sort through and select. No screaming, hey, where's my printer? No making that long distance phone call and listening to the asshole customer service jerk tell you that some non-msuck application is the problem. You just find these scripts and tweak them to fit what you want.
Now this got me to thinking about all those so-called printer specific `postscript drivers' in the Microsuck world. They are all the same with minor tweaks just like the kind I did, but they are labeled HP-PS something, Epson-something, and so on. However, the key difference is that you can not open them up and tweak them to fit. I certainly couldn't have opened the Msuck boot script and tweaked that either. If I knew and understood Postscript, I could go find the source code for the ps filter and adjust the text box dimensions and re-compile the filter. But I don't know enough postscript, so I have to tweak the script that was designed to feed parameters to the program instead.
These kinds of little problems show up over and over. In the Msuck world, the only way to solve them is to buy some additional tweak because you can not fix it yourself. That's evil bill's genius: make you buy what you shouldn't need in the first place and then call it an upgrade. This makes it appear that those wonderful business geniuses at Microsoft are making progress and always improving.
So, this brings me back to John K's quote above. That's what dirty Bill does, `hit that sweet spot'. His favorite sweet spot is to keep the customer simple and stupid, as a kind of perversion of the old engineering addage, (KISS), keep it simple and stupid--meaning the design, not the user. And Bill's perversion works, because all the program operations are closed as binaries and hidden behind graphic user interfaces. If you can't point and click `it' you're dead. You have to make that toll call to Redmond and beg. Perfect submission. Msuck in all it's big dick glory gets to tell you what YOUR problem is and then suggest you BUY something that THEY SELL to fix it.
Chuck Grimes
(Just read Kelley's latest. Next `geek' post is on that)