I’m stuck once again in Broken Feature Hell.
For decades I’ve been working in I.T. doing computer stuff. The whole time has been marked by features that don’t work. Either as ‘bugs’, or as ‘Real Soon Now’ broken promises, or sometimes as “let the customer do QA” (in the Mico$oft model). Sometimes as Sales Guy Hype Not Shipping Yet…
Once, at Apple, I was looking to buy a load of network gear. One Sales Guy had a great product spec. I was ready to buy several and “Make His Day”. Then I said “OK, just bring in a sample and set it up. Show me that it works.”. He was hesitant. Yes, often that is simply because it is a PITA to do the releases and drag the samples out and get the tech guy assigned and all that time he is not selling. But, I was insistent, there would be no sale without a Demo. A working Demo.
So a couple of weeks later they show up with a Demo Unit. We put it on the table. He hands me the manual. I look over the chassis. Nice lights with all the right labels. “OK, plug it in. Let’s fire it up.” says I. He does a sales pitch. “Um, plug it in. Power. Now please.” says I. He looks a bit pained and pale. “Does it work or not? I want to see it run, right now.” says I….
Well, turns out that this prototype unit had worked maybe a few days ago then failed and they were still trying to make it go right back in the lab, but they brought over the nice empty case for me to look at….
A very dramatic case of Broken Feature Hell, in that the whole product didn’t work, and in spectacular fashion, but such is the world of I.T. and new products.
Another time I spent close to a week trying to track down why a client mail server would only deliver mail from outside the company every 20 ish minutes. It worked fine. Just that the mail coming in and going out only happened to move once every 20 minutes or so. For 20 minutes, mail would go out. Often instantly. But no inbound. THen for about 20 minutes, inbound would flow (often instantly) but outbound would not flow. Eventually I worked out that they had 2 “default gateways” set in the configuration. One inside, one outside.
Now the “default gateway” is also known as the router of
resort. That is, there is exactly ONE “LAST” resort. I argued with the client for the better part of a few hours that this was a Very Bad Idea. Eventually, on the Microsoft “support” web site I found a description of this “feature’. Seems that a Windoz box will rotate between multiple “routers of last resort” on about a 20 minute rotation. They stated about this bug “This behavior is by design”…
So with that in hand, I could demonstrate WHY the mail did what it did, and then was allowed to set up the mail server as it ought to have been. A static route to the inside interface for inside corporate mail, and a default gateway that pointed outbound for ‘everything else’. Mail flowed instantly both ways…
All due to a broken “feature”.
Much of my life has been spent in Broken Feature Hell, and I’ve gotten pretty good at navigating the turf. I can see a broken feature being hyped in a sales call faster than most anyone else; and I can smell the fear when you ask about it…
The Present Land Of Broken Features
So I had this “Bright Idea”. Make a Qemu Bigendian system on a chip so that I could make the bigendian parts of GIStemp work on any old PC. Qemu is a free system emulator. It has SPARC support in it (and I’m pretty sure either a SPARC or SGI MIPS was the base system on which GIStemp was run). Easy Peasy…
The first cut of research showed all the right features present. The docs all said it worked on Windows as well as *nix machines (Linux, Unix, POSix, etc.) The features stated it had several bigendian chips emulated (SPARC, MIPS, PowerPC, ARM with big endian set…). OK, looks reasonable. Probably a few Broken Features, but ought to be livable.
I’ve also gotten very good at navigating Broken Feature Minefields and charting the course through them that works. As long as there are “enough” features that work, you can usually find a set that lines up. Even if it takes some exploration.
But sometimes… sometimes not so much. Lots of potential paths, but then after a day or two down that road comes the precipice or the road block. Sometimes it is a small one and you can build a bridge over or around it. Install a package or find the ‘just so’ flag settings that let it work enough. Sometimes it is a hard stop and you back up a few days and try again.
In this case, the number of features is large, and the number that don’t work is large too. LOTS of paths to explore, almost all of them ending badly. It is Broken Feature Hell. All the work, none of the progress.
Do realize that in software development projects a fair amount of Grim Determination is required. An unwillingness to give up. So this Complaint by me does not mean I’m giving up. Not until every path is explored, and marked as a dead end, can you say that Broken Feature Hell has ended in death of the project. For now it is just a bleat from a hot cliff overlooking a dead valley Yet Again.
OK, first up, the Windows support. It’s slim. Yes, I have it running on my laptop. Yes, it works. Yes I have a SPARC emulation running. But several “features” don’t work. First off, the ‘prebuilt’ system images (Debian on a SPARC 32) limit you to Debian Etch. Debian stopped supporting SPARC 32 back in 4.x release land. Now they are at 7.x land. So old code, not updated, no new features. I’m OK with that, I guess. The current Debian wants to support SPARC 64 chips, but doesn’t have it working yet. Yes, I know, free software and free labor making it go, if you want to you can contribute time to it or pay for it. Still, it means that SPARC is not really working all that well.
Then, there’s that small matter of flags to Qemu. The two prebuilts come in windowing and command line. OK, the command line one is fast enough and all I need for GIStemp anyway. It does work. The windowing one works to, after a fashion. As nothing is using any of the graphics hardware, it is God Damn Slow. Painfully so. OK, I could ignore it I suppose. Except…
At the GISTemp source code download page, the tarball is not in FTP land, but in HTML land. No Worries, as wget command gets HTTP files too… but attempt to use it from the command line, while working find on most any other site, give 404 and 403 and other errors on the GIStemp page (depending on what options are set).
So is that a fault of the GIStemp web page? Or of wget? Or of THIS particular Etch version of Debian wget? Or… So a ‘quick’ 20 minute launch and set up of the windowing Qemu SPARC and the browser lets me download the GIStemp code (that I showed in the last posting). OK, I’ve got the code. But…
It is in the windowing prebuilt image, not in the command line image.
No Problem, thinks I, there’s launch options to not do windowing from the windowing version… a few launch attempts later and I realize those “features” don’t work. I can launch it, and it may be running without ANY visible console, but it did not launch a command line version. Sigh. Is there a work around past this? Maybe, hike down those four roads a day or two each and report back…
So I can download the code, or I can have a working command line system that is livable, but not both at the same time…
Yes, I can do things like put the source code on a CD, and find out how to mount the CD inside the command line Qemu (IFF that feature works in the Windows port…). There are plenty more paths to explore.
I’m not giving up yet.
Welcome to Borken Feature Hell where you may spend days wandering in the woods only to find yourself back at the last camp. Again.
So far I’ve found a half dozen or so launch flags that look like they don’t work (including the -k en-us flag to let me make the keyboard a US keyboard instead of the GB one it has as shipped; at present I can’t find the ‘pipe’ symbol vertical bar that is essential to *nix command line use…). I also had a ‘failure to configure’ on one instance (apt-get upgrade) but it worked on another. BOTH running from an SD chip. What was different? Not much… and nothing that ought to matter… so a sometimes randomly broken feature…
I now have a FORTRAN compiler installed, but no code yet. And another image has the code, but can’t install the compiler. And a third has the data… and features that ought to let me boot one the same way as the other don’t seem to work, and the interface to peripherals may or may not work and may or may not let me get the code moved; but are painful to set up in any case (all command line options at boot time when that seems to have a lot of broken features already).
And that is how you know you are in Broken Feature Hell.
There’s just enough options left to try that you keep on searching for The One Path. But so many broken that the odds of that path existing are dancing with zero.
At that point, the Grim Determination starts to be a non-feature as you spend way too much time looking for The One True Path and note enough time asking “Is this sane? Is there a better way?”
Often that is asked just before you find the One True Path… so hope springs eternal.
I’ve not listed all the Broken Features I’ve run into. Things like looking at the MIPS and PowerPC emulations and finding them not all that complete either. This was just a sample for the flavor of it.
I’m not sure exactly what path I’m going to take out of this. Likely continue with the emulator for awhile. I’d been wanting to set up a Raspberry Pi general purpose server (but being little endian it can’t run the last part of GIStemp directly). Networking seems robust on the Qemu SPARC. My current “This Time For Sure!”, is an RPi file server with the sources, and a command line Qemu SPARC to unpack and run time. All the parts look like they work. Just ought to be a matter of doing it. I’d guess about 2 days of work (if done straight through).
Or maybe I’ll just take $100 and buy an old PowerMac and turn it into a Debian box… Forget all the round about stuff and go for straight hardware. Only question being just exactly which of the hundreds of Mac configs actually works well with Debian ;-)
Well, time to get on with the day. Wish me luck as I explore more “features”…