Indeed, MS-DOS wasn't modular either. Many operating systems designed with sane control mechanisms have a way of dealing with disk drives coming on-line and off-line...but not Microsoft (nee Seattle Data Systems) software. In some respects, this "simplifies" the code (read: get it out the door faster) because you don't have to test the boundary conditions of changing the status of a device.
Ask the designers of drivers for removable hard drives what hoops they have to jump through to operate in Windows, or in MS-DOS.
Before anyone thinks I'm bashing Microsoft, I worked with embedded computer systems that didn't carry the baggage of loadable and unloadable drivers -- if you change the hardware configuration you had to reboot and let the initialization software do its thing while the initialization software is in memory. Once initialization is complete, you don't need that code hanging around anymore. It meant, though, that the system didn't gracefully deal with hardware "going away"...but then, neither does Windows as I learned this morning when multiple power sags finally did in a system in my farm...
If you look closely, the cardboard used in standard copy-paper boxes is relatively thin. The tops come off very easily (handy) but the tops plus the thin sides make for a flimsy box for stacking books in a storage unit. When you move them, the box will torque because there is no geometric support.
Another problem: the boxes are glued and any water will dissolve that glue, making it a pain to take the books out later.
That's why I suggest standard moving boxes, heavy boxes from the grocery, or equipment boxes with 200-lb or heavier cardboard. And tape it well.
First, don't try for a sealed container like the Rubbermaid tubs. You have as much chance of sealing humidity/mold/mildew in as you do keeping it out. I know, I did this and ended up with damaged books.
For moving books, nothing beats the U-Haul "book boxes" (fan-fold printer paper comes in exactly the same size box) for books. As long as your books aren't clay-coat paper or coffee-table size, they work well. Furthermore, one person can lift them without risking hernia.
To avoid weather damage, shop for your storage unit carefully. Examine the walls and floor for water damage, and reject any unit that has any stains more than 1/4 inch (0.5 cm) up the wall.
A couple of tricks that saved my books from damage even in a flood environment:
Don't put your boxes directly on the floor. If you can find them cheap, use a shipping pallet -- you can usually buy them cheap at a grocery store, perhaps for free. This gives you an easy 4 inches of clearance, so if water comes in it doesn't hit the boxes...and the clearance lets the water evaporate without your boxes in the way (see next tip).
Don't stack the boxes tightly, like bricks. Leave about an inch between the boxes on the ends and on the sides. This gives enough breathing space that any water damage will be kept to a minimum. This puts a premium to packing the boxes well, so that each end of the box can support weight without crushing.
Consider getting a tarp or large piece of plastic to put over the top of your boxes, so that water from any roof leaks (or upstairs neighbor disaster) is routed around your boxes. The covering sheet should be large enough to cover the boxes sufficiently, but not all the way to the floor.
If money is not a problem and you are really paranoid, consider building platforms so that you stack no more than three boxes high on any given shelf. Junk 2x4 and sheathing does wonders, although I've seen people build "frames" exclusively from 2x4 that work just as well. Just make sure you support the middle of the boxes as well as the edges. In one case, I built supports from 1x3s on a 2x4 square frame -- the 1x3s provided edge and middle support, and the 2x4 frame took the weight. Total cost of each shelf was about $20 because I lucked into a lumber sale.
When sealing your boxes, consider running packing tape along all seams. This keeps the bugs out (at least out of those boxes that don't have holes banged into them) and does wonders with keeping moisture from causing problems.
As some of you know, I'm in the process of writing the Second Edition of a Commentary of Linux TCP/IP code as a Web publication. I wonder if I can use the same technology and the same method of publishing a Commentary on the source of the fair_use_decryptor.c source? Remember, this is not any executable or compilable source in its published form but is formatted explicited to be used in commentary and critique.
Before taking this question to my lawyer, I thought I'd get some opinions here.
After all, given the large volume of bug fixes, security alerts/patches, and "Hey wouldn't it be neat to..." accessories such as the power toys, wouldn't Windows itself satisfy the 70,000 number?
As a 30-year practitioner who refused to continue coursework in what passed for "Compute Science" back in my college days (and ended up joining the Association for Computing Machinery to try to clean up the model curriculm) I have a few thoughts:
Writing: I have found that I ended up writing more prose than code once I graduated from a coder position. This was especially true when the company I was working for decided to build their own version of a discontinued minicomputer to preserve 19 man-years of commercial software development.
I was tagged to document exactly how the commercial computer worked, and to write the functional specification for the new computer based on probing. In that effort, I generated and estimated 70,000 words of text -- and during the same period I generated less than 10,000 debugged lines of assembly code.
The ratio of prose to code tipped in favor of the former when I started doing technical team lead tasks. (Part of the reason was we moved to PL/M from assembler for our 8086 work.) At one point, I was generating upwards of 9,000 words per day: in specifications, in detail design reports, in interface specifications, in "application notes", in testing suite documents, and in memos to my team trying to solve knotty interaction problems before they became of concern to management.
Engineering: One of the most sobering statements I ever heard was this one from a long-time manager: "I would rather take an electrical engineer and teach him how to write software than to take a 'software engineer' and teach him cost-effectiveness." Even though this was said in the 1970s, during the minicomputer boom, I'm finding that many CS/CE grads still don't understand how to utilize the hardware effectively, and to select approaches based on cost (development, debugging, maintenance) instead of "niftyness". As an experiment, I took some fresh CEs aside and asked them a few questions:
What is an overlay?
How would you implement a sparse two-dimensional matrix of values, given 10K in each dimension?
If I had a 1200 document per minute scanner (like a bank check reader-sorter) how much time do you have for each document, on average? How would you go about writing software to operate such a beast?
As you might imagine, the answers I received to these questions were far less than satisfactory. No one put forward any scheme for the spare-matrix problem that didn't require huge amounts of RAM. No one knew what an overlay was, let alone how you would implement overlays in the development environment they were supposed to have 3-5 years experience in. And not one of the people I asked got the right answer for the processing time available on that sorter: 20 documents per second, or 50 milliseconds per document.
Am I being hard? I don't think so. Many of the techniques I learned in those days when "8 kilowords is enough" are still valid today. New concepts have been developed as well, and I've integrated them. Any coursework that doesn't include both old and new is, in my opinion, not worth the time.
Which leads me to my last suggestion: the local computer club. Formal coursework is not a replacement for one-on-one discussions with peers, side-by-side experimentation, coding contests, and the society that you will find when you go for the almighty paycheck.
No club? Form one. Check with the student activies office on your campus and find out what it takes to start one.
Just a small point: if you have a Web site that will be handling tons of traffic, and need multiple IP addresses just to handle the large number of TCP connections, how is the new rule going to affect that? I'm in particular thinking about sites that use multiple servers with traffic distributors.
Or is this supposed to fall in the ill-defined "list of exceptions"?
I did this, commenting open-source code, writ large with my book Linux IP Stacks Commentary for the 2.0.34 TCP/IP code. One reason I did it as a book instead of in "open source" is that the work required was huge...and I needed to eat. As it was, it consumed almost a year of my life, and the advance hasn't covered the cost of living during the time the book was being written. I won't talk about royalties to date...
To be honest, the book format was a mistake -- the Linux code is moving altogether too fast for a book to be useful when published. It was what Coriolis offered, though, and I did it.
The job of code documentation done right is not an easy nor quick one, and as a coder myself I can understand why people hate the job.
That said, my co-author and I will be starting over with 2.4.0 (as soon as I get permission to republish the code from Linus) and do it on the Web...but not for free. To do it right, I also need to develop a revenue model that makes the project pay for itself...and I don't think a book publisher will be willing to do that.
I've got one, and unexpectedly I found that when I was trying to fix my trackball that it is a handy flashlight (if you don't mind red light). Damn, the thing is bright.
It's good to know that when it dies I should be able to get a new one...
I once worked for Motorola (one of the ever-growing legion of people that can say that) and can tell you that Iridium was not a contributing factor to the slowness of development, in any area. Each division stands on its own, just as though it were a separate company and Mama Moto, home of the Batwing, was a Venture Capitalist that required each company to shuffle forth meekly and tell the King how it has spent the King's money and when the King will get its taxes...and how much.
Remember that the mantra at the Semiconductor Product Division of Moto is not unlike that of a particular winery: "We shall sell no wine before its time."
(Unlike competition Intel who seems to go by the mantra "We shall sell no wine before it's paid for.")
One of the problems with politics today (both USA and world) is that the number of issues has increased by several orders of magnitude. In the kingdoms of Europe, the issues were pretty much directed at survival and growth. In the Colonies, the issues centered around British remote control, survival, and management of the growth potential that the New World offered.
Now, today, when you look at the Thomas Web site you see thousands of bills that go way beyond the limits of survival and growth [management]. Morality in technology. Ecology. The War on Some Drugs. The War on Some People (think DCMA, anti-discrimination, hate speech). The Welfare of the Corporations. The Business of Government.
And people wonder why the population of the United States is turned off to politics? When politics is focused again on survival and management of growth, then it will become small enough to be grasped by normal people.
We don't need 1/5th of the people and 1/6th of the Gross Domestic Product dedicated to having one person crack the whip over another.
Even religions know better than to expand core teaching beyond a single easily-carried book.
I was the first paying customer of DSL in Northern Nevada. I'm happy with the final-mile portion. Words cannot describe my dissatisfaction with the ISP portion of the service -- I was overpaying at $10/month. Further, when I disconnected from the ISP I got a larger bill from them. I'm taking action, though, as described at the end of this screed.
I didn't wait for the lawsuits to start before I decided to do something about the problem. When several local ISPs got their ATM connections up and running here in Northern Nevada, I switched.
Oh, the complaint list is a long one:
The PacBell mail servers were listed by ORBS for spam mail. When I found my access was blocked to several University sites, I called tech support to complain. Rather than make their large leased-line customers adhere to the then-in-effect Terms of Service agreement, the tech support people suggest I sue ORBS!
I was administratively blocked from SBC newsservers. This condition lasted for more than a month before I pulled the plug. Before that, message propagation sucked -- many news postings that were courtesy-mailed to me never appeared on SBC's newsservers! (Another "satisfied" PacBell user has been regularly posting news server performance on comp.dcom.xdsl.)
During the 1999 Labor Day weekend, I discovered that I was disconnected from the West coast, mostly the San Francisco Bay Area. I spent nearly $100 to discover the source of the problem: a management dispute at a peering point. The peer to PBI was advertising routes to the West coast, but not honoring the presentation of packets. I was forced to bring up a modem connection to Concentric (where I have a dial-up account) and set up a static route for San Francisco locations. Calls to PBI technical support were met with "Sorry, but all the network people are on vacation." Service to the West coast returned on the Tuesday following the holiday -- not Monday.
Outgoing mail was sent to non-ORBS sites at 70-80 percent reliability. When I configured Sendmail on a local Linux box and started routing my mail through that, my transmission reliability jumped to over 95 percent -- lost mail was a rare exception indeed. And when I used my own MTA, the ORBS problem went away completely!
Incoming mail failed more often than succeeded during my initial tests, so I kept my Concentric mail subscription.
Tech support phone hold times averaged 40 minutes and peaked at over 100 minutes. Tech response times (other than the automated autoresponse) required three days. My mail and newsserver problems were not resolved from January to March. Even when I went through the Product Manager for Advanced Data Services at Nevada Bell I got nothing. (The gentleman I was talking with said that "those decisions are made in Texas" referring to SBC's main offices.)
I switch services on March 6, 2000, to an outfit called Pyramid.Net -- and I've been happy with the switch. Things haven't been perfect, but when I call things get fixed. Period.
SBC isn't finished with me yet!I used to be billed $39 for the DSL service and $10 for ISP service. When the total charges went up I took a closer look at my phone bill. There was the DSL charge of $39, which was correct. What wasn't correct was a charge by "Nevada Bell Internet Services" of just under $29.95 for ISP service I wasn't receiving. I never had a dial-up account, yet when I fired NBIS they "converted" my account to a dial-up account...without authorization. I reported the problem in June and again in July. Nevada Bell (the telephone company) says they can't do anything about it because NBIS is a separate company.
Indeed it is a separate company! It isn't listed anywhere -- not in directory service for California, Nevada, or Texas, not in the telephone books, not even on Switchboard.com! I even called the main customer numbers for Pacific Bell (CA) and Nevada Bell (NV) and they had no record of an address or phone number other than the 800 number that I had already unsuccessfully dealt with. When I spent a day tracking down exactly what was going on, I found that all four Internet Service companies in SBC-land are serviced from a single office in San Francisco! And the dispute resolution? That's with Pacific Bell. In San Francisco. California. WHERE I DON'T LIVE.
Now, it's almost the end of August, and the bill dispute is still unresolved.
But that's all right. Because of electrical deregulation here in Nevada, there is a PUCN docket item investigating utility billing and payment practices for all utilities here in the State of Nevada. I am registered on that docket. My input, based on this experience, is simple:any utility that places a charge on a bill needs to be responsible for the charge, have authority to take action on the charge including reversal instantly, and be accountable for the charge. When a charge is disputed, it is removed and the third-party billing company has to deal directly with the customer.
I won't quote the passage, but I really loved how Judge Kaplan danced around the issue that computer program code is both "expressive" and "functional," and that his judgement is based in the main on the functional aspects of code.
So we can't use code to discuss algorithms and processes? Fine. Then let's get the Congress to tell the Courts that they could no longer use Latin or words as defined in Black's Law Dictonary in their oral arguments, legal briefs and judge rulings. Instead, the Court and the lawyers have to use words as defined in a standard dictionary -- I might propose the Merriam-Webster Dictionary (ISBN 0-671-60388-4) as the "offical dictionary" of the Law.
Yes, they can continue to do their job, but the existing lawyers and judges would be hampered and the bar lowered for entry into the legal profession. People with high school diplomas would be able to read all those damn agreements -- assuming they even bother to read the five pages (from one) that the agreements would require.
Wouldn't it be great if words like "heretofor" and "estoppal" were forever banned from contracts, statue, and rulings?
Call me a grouch, but I've read what the law has to say about bankruptsy (I was involved with the Hayes Microcomputer one, and a couple of smaller ones, as a creditor) and I believe the judge had no choice but make the ruling she did. Absent clear guidance in the statutes to the contrary, the judge's job is to preserve assets and generate revenues for the creditors.
The problem I have with the whole thing is that there is precedent with regards to non-disclosure agreements between companies. I consider that the disclosure and privacy statement made by toysmart.com represents a contract between the customer and the company, and represented a contract just as binding as any NDA signed in blood.
I wonder if a class-action suit against the receivership and creditor's committee of toysmart.com would send the proper message?
Alternatively, release of information under promise of non-disclosure could set a counter-precedent that would negate non-disclosure agreements in general in the event of bankruptsy. Knowledge for sale during bankruptsy -- now that's a hell of a way to raise money!
I'm not sure that any of the classic programming languages, with the sole exception of COBOL and derivitives, can claim its roots in English. Oh, the keywords used in the languages are indeed rooted in the British/American wordset, but the overall structures don't fit, not even when you talk about intransitive constructs. (BASIC is more like intransitivie English than any other language, but the Microsoft extensions send it off in a whole new linguistic direction.)
Latin, with its introducing the players before the verb, is very much in the spirit of Reverse Polish Notation. (I might add that Polish notation turns that around: you have the verb and then all the players, which for some reason works only for people who grew up with languages with similar structures. I'm not familiar with any languages that put the subject first, but I'm sure there are some.)
COBOL is structured as though it were English...because it was designed to be. "ADD A AND B GIVING C" makes perfect sense to the English writer, but not to a writer in a language like Latin.
FORTRAN, on the other hand, is based on the notation of classic mathmatics than on any particular language construct.
One thing that shows that English is not the sole contributor to computer languages is the treatment of nested modifiers. English is terrible at compactly describing modifications to modifiers -- the adjective/adverb system sucks when things get complex. Contrast that to Spanish, which sorts out what's modifying what, and far better than English ever will.
The B language (and its child the C language et al) combined assembler language with more human-readable constructs such as the assignment statement popular in ALGOL and to a lesser extent FORTRAN. Many of the "instructions" of the PDP-7 were single-character or dual-character tokens in the B language. The roots of B were in ALGOL and FORTRAN, which were in turn rooted in standard math notation. Many of the Fortran/Algol "built-in language features" were removedand relegated to functions in B/C, thus simplifying the language and also improving portability by eliminating the assumptions made by FORTRAN (unit record input-output) and ALGOL (character-stream input-output).
LISP is a pure-math thing. (All those parens can't have an analog in human language, could they? If it does, I want to see it!)
Food for thought: if Russian was the seed of computer languages, would programs be easier to debug?
I suspect that @Home will now start monitoring connections for encryption (think SSL and TLS), then look at traffic patterns to determine whether it's a secure Web browser or "something else". That means that you might be shut off for using SSL-encapsulated FTP or SSL-encapsulated SMTP (for secure mail transfer). Indeed, I can see where people regularly using PGP encryption on mail content may get a little note from the company.
Hmmm...there is very little difference between a VPN and SSL encrypted services. Could it be that we are seeing something caused by the FBI demands to snoop on mail? A VPN is one way to block Carnivore and ISP monitoring from capturing e-mail traffic. Another way is to use STARTTLS-enabled mail clients to talk directly to STARTTLS-enabled mail transfer agents.
Perhaps it isn't just a bid for money...but then again, I admit I'm paranoid.
Jerry Pournelle wrote in his Chaos Manor series that he had a keyboard that stopped working; he took it and rinsed it under the kitchen faucet and a ton of ants were washed out. As an exercise to the student, find out what attracted the ants. The keyboard worked afterwards.
Pulling the keycaps off the stems and cleaning them separately from the keyboard works. After you pull the keycaps off, turning the keyboard upside-down will let lots of not-good stuff escape. One keyboard, sez the reporter, had a ton of cat-hair from his three American Shorthair cats. Several keys that had been "iffy" started working reliably again. His caution, though, was to watch out for the bales on the space bar.
I've resurrected Macintosh keyboards by disassembling them, washing everything in alcohol, letting everything dry, buffing the contacts with a clean, lint-free cloth, and reassembling. One of those keyboards is still working fine.
I agree that trying to clean $20 keyboards is a lost cause, with the possible exception of pulling keycaps and soaking them.
By the way, for those keycaps that have worn smooth and show nothing but pristine background, try using a fine magic marker ("Sharpies" by Sanford is what I use) to renew the image on the keycaps. One keyboard I have needed this done on three keys. Works.
If you have a membrane or Chicklet keyboard, don't bother trying anything...
Why not just put a small chunk of dry ice directly on the heat sink of the CPU. I would not put it directly of the chip, but on the prongs of the heat sink.
Sometimes the lessons of history are worth looking at.
Remember the water-cooled mainframes? They had networks of heat pipes ducting heat from the chips to a heat-exchanger off the board. The heat-exchanger would transfer the heat to chilled water, which went to a rechiller of some kind. (Many buildings had cold-water systems for the air conditioning, so adding the computer into the building's chiller was a bang-easy deal.)
(Speaking of weird systems, I had the honor of reviewing for Federal Computer Week a military PC, the Deuce by C3 Technologies, which was a computer designed to land on the beach with a platoon of Marines. It was water-proof, sand-proof, and damn near soldier-proof. By necessity, the system case was sealed tight -- no air exchange with the outside at all. Instead, you had an internal fan and a double-sided heat sink that ported heat to the outside of the case. The "portable" computer weighed 33 lbs, most of it in the metal of the case.)
Take the idea of heat pipes to reduce "hot spots" and an active heat-exchange system -- and you can have a much-lowered thermal resistance for your system. Especially if you live where the air temperature gets over 110 degrees F.
Apple was sued some time ago for dropping software support for the Lisa. As I understand it, the case was settled out of court. Whether the settlement included consequential damages, I don't know. The settlement wasn't exactly top news.
Which points up a critical fact: there have been, to the best of my recollection and the limits of my research capabilities, no viable software vendor hauled before a judge because of non-support because no company is stupid enough to let the situation get to that stage. Software vendors knows that it's far cheaper to pay money on technicians, developers, gurus, and consultants to fix the problem than it is to pay lawyers even more money to dismiss the complaint. The fix-the-problem route usually results in a satisfied customer, while the fix-the-law results in a pissed-off customer.
Besides, it's rather easy to see who has the $100,000 required to press such a suit, and sidetrack the legal action. Joe Six-Pack won't have that kind of money, and District Attornies have a high enough case load without taking on "petty problems."
The real problem is not with lawsuits, but the underlying statutes that regulate commercial transactions. The Uniform Commercial Code (UCC) doesn't work well with software and data collections. So there is a push to create a UCC-like statute in the 50 states that does for software and data what the UCC does for tangible products. Unfortunately, the proposed model statute (liked only by the SIIA, formally the Software Publishers Associaton, and hated by a long list of others) is flawed; see CPSR's fact page for more details. From the horse's mouth, the summary by the Uniform Acts Commissioners, as well as a Q&A page on the NCCUSL site.
The proposal would poison DoubleClick's database. This would force DoubleClick to separate its banner-ad operation from its tracking operation...and then guess how long it will take for HTTP proxy packages to start filtering the 1x1 (or smaller than 8x8) GIFs.
Count me out, though. I block all the DoubleClick domains I can in my DNS server, and I see no reason to unblock those domains.
And if a company can't trust the people who work for it, who can it trust?
Since when does a classicly-organized company ever trust its employees? How many organizations have you worked for that tracked your telephone usage, your hours (even for salaried people), your attendence every day?
Ever work for a place that didn't require a "weekly report" or equivalent, even at the manager, director, and even the VP level?
How about expense reports? I was once gigged for "spending too much" when I picked up the tab for a dinner for 12 where the publisher of the magazine I worked for splurged on wine -- the tab went on my AmEx card, and the publisher red-flagged the expense until he was "reminded" about who really made the charge...
Ever get screwed out of compensatory time off because the manager that offered it at the time the "overtime" was necessary to meet schedule goals "wasn't authorized to offer comp time?" I got nailed with that twice (in two different companies) before I learned to check with the policy people before accepting the tradeoff.
Speaking of time, I have yet to see any in-house IT project come on time, on target, and on budget. Indeed, in the early days my consulting business was built on implementating the disasters that an IT department (it wasn't called IT back then) spawned. What amazed me was how simple it was to bring in what the bosses wanted, dumping the frills that IT layered on that weren't on target to the job.
Reminds me of a very old story: a car company's data processing department had screwed up an order generation program that takes car orders and determines when and how much of parts need to be ordered to build the cars on the schedule. A consultant was hired, and he wrote the program on the plane on his way to Detroit. He had the thing keypunched, and it ran right out of the box, at a rate of one car order per second. The MIS department said "Well, our program can run at 150 cars per second." The consultant said "OK, I can beat that" and wrote a 10-line program that read order cards as fast as the card reader would feed them. "But, but, but, that program doesn't do anything!"
The consultant responded, "but neither does yours -- that's why I was hired."
(Before I start, I want it made clear that I'm a Linux user, and prefer Linux and OpenBSD to proprietary operating systems of any stripe: MacOS, Windoze, BeOS, AmigaDOS, HP/UX, Ultrix -- you get the idea.)
From the non-technical business perspective, Peter Firstbrook does have some legit concerns here, even if he dances around the core of the complaint. A businessperson "betting the farm" on technology either has to have a great deal of trust in his/her technologists or in the vendors supplying the infrastructure software.
For the Fortune 5000, trust in support technologists is hard to find -- even in those companies that sell technology, such as HP and IBM. Remember, revenue-generating technology is monitored by a pyramid of management and a gaggle of process, while non-revenue technology doesn't have the same money thrown at it. Frankly, IT-based development for internal use just doesn't have the management oversight that a vendor would provide, and the business people know it.
That's why there is a tendency for business to buy infrastructure solutions from vendors who have "thrown money" at the management of technology, and is willing to take responsibility for the gaffs and fix them. (The fallacy here is that the erring vendor -- think Microsoft -- will indeed fix the problems right and right now.) As a side benefit, repair and upgrade costs can be controlled and predicted, with the vendor taking the risk. The business person will pay for 24/7 if s/he feels that level of support is necessary, but wants a definite cap on the costs. That's why service contracts are such an easy sell to Fortune 5000 types -- the contract may be expensive, but it represents a known expense that can be factored into the financial model.
Contrast that with the unknowns with in-house solutions. They may be cheaper to start, but the chance for "surprises" is very high, very frustrating to business types, and makes for an unworkable financial model for the company. How many projects have you worked on that came in on time and under budget?
Now consider the Open Source model. On the one hand, you have a peer review of the code that can't be equaled in proprietary software -- everyone who uses the system can look under the covers and see what's going on. Something not right? Either fix it and provide a patch, or report the problem and let someone else (on their own time) figure out a fix and patch.
In open source, who do you sue when the bug loses you money? There isn't just "one place" you can aim your lawyers to recoup the lost revenue when something goes very wrong. Even Red Hat isn't a very good target, because they just package Linux, they don't take responsibility for bugs in the kernel.
How about that "tinkering" argument? I believe the argument is in fact a red herring, another boogieman to scare non-technical types. Yes, it can happen. In reality, most IT types don't have the background to even attempt it, let alone make it work. The very few that can pull it off may in fact improve matters, if they are supervised properly. So, let's drop that lame claim.
It's not a question of feasibility, or of "goodness."
It's a question of responsibility, of fixing the blame.
I've read the various stories about cooling computer components/motherboards down using insane ambient temperatures. Many of these guys forget a basic tenant of computer design: the temperature of the silicon die in each package is what is important.
The ambient-temperature specification quoted in the spec sheets take into account the thermal resistance of the packaging in order to keep the die within an acceptable range of temperature. If you keep the ambient temperature at the package at, say, 0 C, and the thermal resistance between the packaging and the cooling method is insanely low, then all components will run within specification and you can overclock until you run into race conditions in the processor itself, or perhaps in support circuitry.
On selected hot-running components like the processor, you might want to drop the ambient temperature a little bit more -- say to -20 C -- to compensate for the compromises that CPU makers make between thermal resistance of their packages and other considerations. The goal here is to run the hot die, not package, at the lower end of its temperature specification.
This does NOT mean that you should subject cool-running components to the same out-of-range ambient temperature, as the cooler-running dies will then be running outside of thermal specification envelope.
In this particular experiment, they cooled EVERYTHING on the motherboard, plus a video card and network card. In their writeup they say that they picked a cool-running card, as opposed to a heat-filled monster. The experimenters subjected all the components, perhaps ineptly, to the same ambient temp of -60 C. Even military components are designed to run above -55 C. Most commercial-grade components are speced to run at an ambient of 0 C.
The result could be predicted: The overclocking of the cool-running Celeron chip was sabotaged by the overcooling of the support chips.
Back in my cubicle-inhabiting days, I was forever fighting glare on my screens. So I put theatre gel (color filters) in the fixtures right over my desk to tone down the white glare. Today, you can buy the gel in sleeves that fit right over the bulbs.
In another situation, a colleague and I removed the tubes from the fixture and used spot lighting in our cubes to achieve the same effect.
If your objection is to the color instead of the flickering, there are special tubes that are available under a number of trade names. Look for a specification that the tube has a color temperature of around 5000 degrees K, and a spectrum that mimics a sunny day at 2 PM. Use a neutral gel if the tubes give out too much light.
In my home office, I have a fixture that uses T-8 tubes instead of the more standard T-12, so I have to use what I can find for tubes. A couple of gels (#813) I had lying around from a theatre job cuts the light down to something bearable, and also cuts some blue out so that I get better contrast from my 19" monitor.
Slashdot Mirror
Indeed, MS-DOS wasn't modular either. Many operating systems designed with sane control mechanisms have a way of dealing with disk drives coming on-line and off-line...but not Microsoft (nee Seattle Data Systems) software. In some respects, this "simplifies" the code (read: get it out the door faster) because you don't have to test the boundary conditions of changing the status of a device.
Ask the designers of drivers for removable hard drives what hoops they have to jump through to operate in Windows, or in MS-DOS.
Before anyone thinks I'm bashing Microsoft, I worked with embedded computer systems that didn't carry the baggage of loadable and unloadable drivers -- if you change the hardware configuration you had to reboot and let the initialization software do its thing while the initialization software is in memory. Once initialization is complete, you don't need that code hanging around anymore. It meant, though, that the system didn't gracefully deal with hardware "going away"...but then, neither does Windows as I learned this morning when multiple power sags finally did in a system in my farm...
If you look closely, the cardboard used in standard copy-paper boxes is relatively thin. The tops come off very easily (handy) but the tops plus the thin sides make for a flimsy box for stacking books in a storage unit. When you move them, the box will torque because there is no geometric support.
Another problem: the boxes are glued and any water will dissolve that glue, making it a pain to take the books out later.
That's why I suggest standard moving boxes, heavy boxes from the grocery, or equipment boxes with 200-lb or heavier cardboard. And tape it well.
First, don't try for a sealed container like the Rubbermaid tubs. You have as much chance of sealing humidity/mold/mildew in as you do keeping it out. I know, I did this and ended up with damaged books.
For moving books, nothing beats the U-Haul "book boxes" (fan-fold printer paper comes in exactly the same size box) for books. As long as your books aren't clay-coat paper or coffee-table size, they work well. Furthermore, one person can lift them without risking hernia.
To avoid weather damage, shop for your storage unit carefully. Examine the walls and floor for water damage, and reject any unit that has any stains more than 1/4 inch (0.5 cm) up the wall.
A couple of tricks that saved my books from damage even in a flood environment:
Don't put your boxes directly on the floor. If you can find them cheap, use a shipping pallet -- you can usually buy them cheap at a grocery store, perhaps for free. This gives you an easy 4 inches of clearance, so if water comes in it doesn't hit the boxes...and the clearance lets the water evaporate without your boxes in the way (see next tip).
Don't stack the boxes tightly, like bricks. Leave about an inch between the boxes on the ends and on the sides. This gives enough breathing space that any water damage will be kept to a minimum. This puts a premium to packing the boxes well, so that each end of the box can support weight without crushing.
Consider getting a tarp or large piece of plastic to put over the top of your boxes, so that water from any roof leaks (or upstairs neighbor disaster) is routed around your boxes. The covering sheet should be large enough to cover the boxes sufficiently, but not all the way to the floor.
If money is not a problem and you are really paranoid, consider building platforms so that you stack no more than three boxes high on any given shelf. Junk 2x4 and sheathing does wonders, although I've seen people build "frames" exclusively from 2x4 that work just as well. Just make sure you support the middle of the boxes as well as the edges. In one case, I built supports from 1x3s on a 2x4 square frame -- the 1x3s provided edge and middle support, and the 2x4 frame took the weight. Total cost of each shelf was about $20 because I lucked into a lumber sale.
When sealing your boxes, consider running packing tape along all seams. This keeps the bugs out (at least out of those boxes that don't have holes banged into them) and does wonders with keeping moisture from causing problems.
Hope this helps.
As some of you know, I'm in the process of writing the Second Edition of a Commentary of Linux TCP/IP code as a Web publication. I wonder if I can use the same technology and the same method of publishing a Commentary on the source of the fair_use_decryptor.c source? Remember, this is not any executable or compilable source in its published form but is formatted explicited to be used in commentary and critique.
Before taking this question to my lawyer, I thought I'd get some opinions here.
After all, given the large volume of bug fixes, security alerts/patches, and "Hey wouldn't it be neat to..." accessories such as the power toys, wouldn't Windows itself satisfy the 70,000 number?
As a 30-year practitioner who refused to continue coursework in what passed for "Compute Science" back in my college days (and ended up joining the Association for Computing Machinery to try to clean up the model curriculm) I have a few thoughts:
Writing: I have found that I ended up writing more prose than code once I graduated from a coder position. This was especially true when the company I was working for decided to build their own version of a discontinued minicomputer to preserve 19 man-years of commercial software development.
I was tagged to document exactly how the commercial computer worked, and to write the functional specification for the new computer based on probing. In that effort, I generated and estimated 70,000 words of text -- and during the same period I generated less than 10,000 debugged lines of assembly code.
The ratio of prose to code tipped in favor of the former when I started doing technical team lead tasks. (Part of the reason was we moved to PL/M from assembler for our 8086 work.) At one point, I was generating upwards of 9,000 words per day: in specifications, in detail design reports, in interface specifications, in "application notes", in testing suite documents, and in memos to my team trying to solve knotty interaction problems before they became of concern to management.
What is an overlay?
How would you implement a sparse two-dimensional matrix of values, given 10K in each dimension?
As you might imagine, the answers I received to these questions were far less than satisfactory. No one put forward any scheme for the spare-matrix problem that didn't require huge amounts of RAM. No one knew what an overlay was, let alone how you would implement overlays in the development environment they were supposed to have 3-5 years experience in. And not one of the people I asked got the right answer for the processing time available on that sorter: 20 documents per second, or 50 milliseconds per document.
Am I being hard? I don't think so. Many of the techniques I learned in those days when "8 kilowords is enough" are still valid today. New concepts have been developed as well, and I've integrated them. Any coursework that doesn't include both old and new is, in my opinion, not worth the time.
Which leads me to my last suggestion: the local computer club. Formal coursework is not a replacement for one-on-one discussions with peers, side-by-side experimentation, coding contests, and the society that you will find when you go for the almighty paycheck.
No club? Form one. Check with the student activies office on your campus and find out what it takes to start one.
Just a small point: if you have a Web site that will be handling tons of traffic, and need multiple IP addresses just to handle the large number of TCP connections, how is the new rule going to affect that? I'm in particular thinking about sites that use multiple servers with traffic distributors.
Or is this supposed to fall in the ill-defined "list of exceptions"?
To be honest, the book format was a mistake -- the Linux code is moving altogether too fast for a book to be useful when published. It was what Coriolis offered, though, and I did it.
The job of code documentation done right is not an easy nor quick one, and as a coder myself I can understand why people hate the job.
That said, my co-author and I will be starting over with 2.4.0 (as soon as I get permission to republish the code from Linus) and do it on the Web...but not for free. To do it right, I also need to develop a revenue model that makes the project pay for itself...and I don't think a book publisher will be willing to do that.
It's good to know that when it dies I should be able to get a new one...
I once worked for Motorola (one of the ever-growing legion of people that can say that) and can tell you that Iridium was not a contributing factor to the slowness of development, in any area. Each division stands on its own, just as though it were a separate company and Mama Moto, home of the Batwing, was a Venture Capitalist that required each company to shuffle forth meekly and tell the King how it has spent the King's money and when the King will get its taxes...and how much.
Remember that the mantra at the Semiconductor Product Division of Moto is not unlike that of a particular winery: "We shall sell no wine before its time."
(Unlike competition Intel who seems to go by the mantra "We shall sell no wine before it's paid for.")
Now, today, when you look at the Thomas Web site you see thousands of bills that go way beyond the limits of survival and growth [management]. Morality in technology. Ecology. The War on Some Drugs. The War on Some People (think DCMA, anti-discrimination, hate speech). The Welfare of the Corporations. The Business of Government.
And people wonder why the population of the United States is turned off to politics? When politics is focused again on survival and management of growth, then it will become small enough to be grasped by normal people.
We don't need 1/5th of the people and 1/6th of the Gross Domestic Product dedicated to having one person crack the whip over another.
Even religions know better than to expand core teaching beyond a single easily-carried book.
I was the first paying customer of DSL in Northern Nevada. I'm happy with the final-mile portion. Words cannot describe my dissatisfaction with the ISP portion of the service -- I was overpaying at $10/month. Further, when I disconnected from the ISP I got a larger bill from them. I'm taking action, though, as described at the end of this screed.
I didn't wait for the lawsuits to start before I decided to do something about the problem. When several local ISPs got their ATM connections up and running here in Northern Nevada, I switched.
Oh, the complaint list is a long one:
I switch services on March 6, 2000, to an outfit called Pyramid.Net -- and I've been happy with the switch. Things haven't been perfect, but when I call things get fixed. Period.
SBC isn't finished with me yet!I used to be billed $39 for the DSL service and $10 for ISP service. When the total charges went up I took a closer look at my phone bill. There was the DSL charge of $39, which was correct. What wasn't correct was a charge by "Nevada Bell Internet Services" of just under $29.95 for ISP service I wasn't receiving. I never had a dial-up account, yet when I fired NBIS they "converted" my account to a dial-up account...without authorization. I reported the problem in June and again in July. Nevada Bell (the telephone company) says they can't do anything about it because NBIS is a separate company.
Indeed it is a separate company! It isn't listed anywhere -- not in directory service for California, Nevada, or Texas, not in the telephone books, not even on Switchboard.com! I even called the main customer numbers for Pacific Bell (CA) and Nevada Bell (NV) and they had no record of an address or phone number other than the 800 number that I had already unsuccessfully dealt with. When I spent a day tracking down exactly what was going on, I found that all four Internet Service companies in SBC-land are serviced from a single office in San Francisco! And the dispute resolution? That's with Pacific Bell. In San Francisco. California. WHERE I DON'T LIVE.
Now, it's almost the end of August, and the bill dispute is still unresolved.
But that's all right. Because of electrical deregulation here in Nevada, there is a PUCN docket item investigating utility billing and payment practices for all utilities here in the State of Nevada. I am registered on that docket. My input, based on this experience, is simple:any utility that places a charge on a bill needs to be responsible for the charge, have authority to take action on the charge including reversal instantly, and be accountable for the charge. When a charge is disputed, it is removed and the third-party billing company has to deal directly with the customer.
I won't quote the passage, but I really loved how Judge Kaplan danced around the issue that computer program code is both "expressive" and "functional," and that his judgement is based in the main on the functional aspects of code.
So we can't use code to discuss algorithms and processes? Fine. Then let's get the Congress to tell the Courts that they could no longer use Latin or words as defined in Black's Law Dictonary in their oral arguments, legal briefs and judge rulings. Instead, the Court and the lawyers have to use words as defined in a standard dictionary -- I might propose the Merriam-Webster Dictionary (ISBN 0-671-60388-4) as the "offical dictionary" of the Law.
Yes, they can continue to do their job, but the existing lawyers and judges would be hampered and the bar lowered for entry into the legal profession. People with high school diplomas would be able to read all those damn agreements -- assuming they even bother to read the five pages (from one) that the agreements would require.
Wouldn't it be great if words like "heretofor" and "estoppal" were forever banned from contracts, statue, and rulings?
Call me a grouch, but I've read what the law has to say about bankruptsy (I was involved with the Hayes Microcomputer one, and a couple of smaller ones, as a creditor) and I believe the judge had no choice but make the ruling she did. Absent clear guidance in the statutes to the contrary, the judge's job is to preserve assets and generate revenues for the creditors.
The problem I have with the whole thing is that there is precedent with regards to non-disclosure agreements between companies. I consider that the disclosure and privacy statement made by toysmart.com represents a contract between the customer and the company, and represented a contract just as binding as any NDA signed in blood.
I wonder if a class-action suit against the receivership and creditor's committee of toysmart.com would send the proper message?
Alternatively, release of information under promise of non-disclosure could set a counter-precedent that would negate non-disclosure agreements in general in the event of bankruptsy. Knowledge for sale during bankruptsy -- now that's a hell of a way to raise money!
I'm not sure that any of the classic programming languages, with the sole exception of COBOL and derivitives, can claim its roots in English. Oh, the keywords used in the languages are indeed rooted in the British/American wordset, but the overall structures don't fit, not even when you talk about intransitive constructs. (BASIC is more like intransitivie English than any other language, but the Microsoft extensions send it off in a whole new linguistic direction.)
Latin, with its introducing the players before the verb, is very much in the spirit of Reverse Polish Notation. (I might add that Polish notation turns that around: you have the verb and then all the players, which for some reason works only for people who grew up with languages with similar structures. I'm not familiar with any languages that put the subject first, but I'm sure there are some.)
COBOL is structured as though it were English...because it was designed to be. "ADD A AND B GIVING C" makes perfect sense to the English writer, but not to a writer in a language like Latin.
FORTRAN, on the other hand, is based on the notation of classic mathmatics than on any particular language construct.
One thing that shows that English is not the sole contributor to computer languages is the treatment of nested modifiers. English is terrible at compactly describing modifications to modifiers -- the adjective/adverb system sucks when things get complex. Contrast that to Spanish, which sorts out what's modifying what, and far better than English ever will.
The B language (and its child the C language et al) combined assembler language with more human-readable constructs such as the assignment statement popular in ALGOL and to a lesser extent FORTRAN. Many of the "instructions" of the PDP-7 were single-character or dual-character tokens in the B language. The roots of B were in ALGOL and FORTRAN, which were in turn rooted in standard math notation. Many of the Fortran/Algol "built-in language features" were removedand relegated to functions in B/C, thus simplifying the language and also improving portability by eliminating the assumptions made by FORTRAN (unit record input-output) and ALGOL (character-stream input-output).
LISP is a pure-math thing. (All those parens can't have an analog in human language, could they? If it does, I want to see it!)
Food for thought: if Russian was the seed of computer languages, would programs be easier to debug?
I suspect that @Home will now start monitoring connections for encryption (think SSL and TLS), then look at traffic patterns to determine whether it's a secure Web browser or "something else". That means that you might be shut off for using SSL-encapsulated FTP or SSL-encapsulated SMTP (for secure mail transfer). Indeed, I can see where people regularly using PGP encryption on mail content may get a little note from the company.
Hmmm...there is very little difference between a VPN and SSL encrypted services. Could it be that we are seeing something caused by the FBI demands to snoop on mail? A VPN is one way to block Carnivore and ISP monitoring from capturing e-mail traffic. Another way is to use STARTTLS-enabled mail clients to talk directly to STARTTLS-enabled mail transfer agents.
Perhaps it isn't just a bid for money...but then again, I admit I'm paranoid.
Jerry Pournelle wrote in his Chaos Manor series that he had a keyboard that stopped working; he took it and rinsed it under the kitchen faucet and a ton of ants were washed out. As an exercise to the student, find out what attracted the ants. The keyboard worked afterwards.
Pulling the keycaps off the stems and cleaning them separately from the keyboard works. After you pull the keycaps off, turning the keyboard upside-down will let lots of not-good stuff escape. One keyboard, sez the reporter, had a ton of cat-hair from his three American Shorthair cats. Several keys that had been "iffy" started working reliably again. His caution, though, was to watch out for the bales on the space bar.
I've resurrected Macintosh keyboards by disassembling them, washing everything in alcohol, letting everything dry, buffing the contacts with a clean, lint-free cloth, and reassembling. One of those keyboards is still working fine.
I agree that trying to clean $20 keyboards is a lost cause, with the possible exception of pulling keycaps and soaking them.
By the way, for those keycaps that have worn smooth and show nothing but pristine background, try using a fine magic marker ("Sharpies" by Sanford is what I use) to renew the image on the keycaps. One keyboard I have needed this done on three keys. Works.
If you have a membrane or Chicklet keyboard, don't bother trying anything...
Sometimes the lessons of history are worth looking at.
Remember the water-cooled mainframes? They had networks of heat pipes ducting heat from the chips to a heat-exchanger off the board. The heat-exchanger would transfer the heat to chilled water, which went to a rechiller of some kind. (Many buildings had cold-water systems for the air conditioning, so adding the computer into the building's chiller was a bang-easy deal.)
(Speaking of weird systems, I had the honor of reviewing for Federal Computer Week a military PC, the Deuce by C3 Technologies, which was a computer designed to land on the beach with a platoon of Marines. It was water-proof, sand-proof, and damn near soldier-proof. By necessity, the system case was sealed tight -- no air exchange with the outside at all. Instead, you had an internal fan and a double-sided heat sink that ported heat to the outside of the case. The "portable" computer weighed 33 lbs, most of it in the metal of the case.)
Take the idea of heat pipes to reduce "hot spots" and an active heat-exchange system -- and you can have a much-lowered thermal resistance for your system. Especially if you live where the air temperature gets over 110 degrees F.
Apple was sued some time ago for dropping software support for the Lisa. As I understand it, the case was settled out of court. Whether the settlement included consequential damages, I don't know. The settlement wasn't exactly top news.
Which points up a critical fact: there have been, to the best of my recollection and the limits of my research capabilities, no viable software vendor hauled before a judge because of non-support because no company is stupid enough to let the situation get to that stage. Software vendors knows that it's far cheaper to pay money on technicians, developers, gurus, and consultants to fix the problem than it is to pay lawyers even more money to dismiss the complaint. The fix-the-problem route usually results in a satisfied customer, while the fix-the-law results in a pissed-off customer.
Besides, it's rather easy to see who has the $100,000 required to press such a suit, and sidetrack the legal action. Joe Six-Pack won't have that kind of money, and District Attornies have a high enough case load without taking on "petty problems."
The real problem is not with lawsuits, but the underlying statutes that regulate commercial transactions. The Uniform Commercial Code (UCC) doesn't work well with software and data collections. So there is a push to create a UCC-like statute in the 50 states that does for software and data what the UCC does for tangible products. Unfortunately, the proposed model statute (liked only by the SIIA, formally the Software Publishers Associaton, and hated by a long list of others) is flawed; see CPSR's fact page for more details. From the horse's mouth, the summary by the Uniform Acts Commissioners, as well as a Q&A page on the NCCUSL site.
The proposal would poison DoubleClick's database. This would force DoubleClick to separate its banner-ad operation from its tracking operation...and then guess how long it will take for HTTP proxy packages to start filtering the 1x1 (or smaller than 8x8) GIFs.
Count me out, though. I block all the DoubleClick domains I can in my DNS server, and I see no reason to unblock those domains.
Since when does a classicly-organized company ever trust its employees? How many organizations have you worked for that tracked your telephone usage, your hours (even for salaried people), your attendence every day?
Ever work for a place that didn't require a "weekly report" or equivalent, even at the manager, director, and even the VP level?
How about expense reports? I was once gigged for "spending too much" when I picked up the tab for a dinner for 12 where the publisher of the magazine I worked for splurged on wine -- the tab went on my AmEx card, and the publisher red-flagged the expense until he was "reminded" about who really made the charge...
Ever get screwed out of compensatory time off because the manager that offered it at the time the "overtime" was necessary to meet schedule goals "wasn't authorized to offer comp time?" I got nailed with that twice (in two different companies) before I learned to check with the policy people before accepting the tradeoff.
Speaking of time, I have yet to see any in-house IT project come on time, on target, and on budget. Indeed, in the early days my consulting business was built on implementating the disasters that an IT department (it wasn't called IT back then) spawned. What amazed me was how simple it was to bring in what the bosses wanted, dumping the frills that IT layered on that weren't on target to the job.
Reminds me of a very old story: a car company's data processing department had screwed up an order generation program that takes car orders and determines when and how much of parts need to be ordered to build the cars on the schedule. A consultant was hired, and he wrote the program on the plane on his way to Detroit. He had the thing keypunched, and it ran right out of the box, at a rate of one car order per second. The MIS department said "Well, our program can run at 150 cars per second." The consultant said "OK, I can beat that" and wrote a 10-line program that read order cards as fast as the card reader would feed them. "But, but, but, that program doesn't do anything!"
The consultant responded, "but neither does yours -- that's why I was hired."
(Before I start, I want it made clear that I'm a Linux user, and prefer Linux and OpenBSD to proprietary operating systems of any stripe: MacOS, Windoze, BeOS, AmigaDOS, HP/UX, Ultrix -- you get the idea.)
From the non-technical business perspective, Peter Firstbrook does have some legit concerns here, even if he dances around the core of the complaint. A businessperson "betting the farm" on technology either has to have a great deal of trust in his/her technologists or in the vendors supplying the infrastructure software.
For the Fortune 5000, trust in support technologists is hard to find -- even in those companies that sell technology, such as HP and IBM. Remember, revenue-generating technology is monitored by a pyramid of management and a gaggle of process, while non-revenue technology doesn't have the same money thrown at it. Frankly, IT-based development for internal use just doesn't have the management oversight that a vendor would provide, and the business people know it.
That's why there is a tendency for business to buy infrastructure solutions from vendors who have "thrown money" at the management of technology, and is willing to take responsibility for the gaffs and fix them. (The fallacy here is that the erring vendor -- think Microsoft -- will indeed fix the problems right and right now.) As a side benefit, repair and upgrade costs can be controlled and predicted, with the vendor taking the risk. The business person will pay for 24/7 if s/he feels that level of support is necessary, but wants a definite cap on the costs. That's why service contracts are such an easy sell to Fortune 5000 types -- the contract may be expensive, but it represents a known expense that can be factored into the financial model.
Contrast that with the unknowns with in-house solutions. They may be cheaper to start, but the chance for "surprises" is very high, very frustrating to business types, and makes for an unworkable financial model for the company. How many projects have you worked on that came in on time and under budget?
Now consider the Open Source model. On the one hand, you have a peer review of the code that can't be equaled in proprietary software -- everyone who uses the system can look under the covers and see what's going on. Something not right? Either fix it and provide a patch, or report the problem and let someone else (on their own time) figure out a fix and patch.
In open source, who do you sue when the bug loses you money? There isn't just "one place" you can aim your lawyers to recoup the lost revenue when something goes very wrong. Even Red Hat isn't a very good target, because they just package Linux, they don't take responsibility for bugs in the kernel.
How about that "tinkering" argument? I believe the argument is in fact a red herring, another boogieman to scare non-technical types. Yes, it can happen. In reality, most IT types don't have the background to even attempt it, let alone make it work. The very few that can pull it off may in fact improve matters, if they are supervised properly. So, let's drop that lame claim.
It's not a question of feasibility, or of "goodness."
It's a question of responsibility, of fixing the blame.
"Installing AOL 5.0 onto your computer voids all warranties."
I've read the various stories about cooling computer components/motherboards down using insane ambient temperatures. Many of these guys forget a basic tenant of computer design: the temperature of the silicon die in each package is what is important.
The ambient-temperature specification quoted in the spec sheets take into account the thermal resistance of the packaging in order to keep the die within an acceptable range of temperature. If you keep the ambient temperature at the package at, say, 0 C, and the thermal resistance between the packaging and the cooling method is insanely low, then all components will run within specification and you can overclock until you run into race conditions in the processor itself, or perhaps in support circuitry.
On selected hot-running components like the processor, you might want to drop the ambient temperature a little bit more -- say to -20 C -- to compensate for the compromises that CPU makers make between thermal resistance of their packages and other considerations. The goal here is to run the hot die, not package, at the lower end of its temperature specification.
This does NOT mean that you should subject cool-running components to the same out-of-range ambient temperature, as the cooler-running dies will then be running outside of thermal specification envelope.
In this particular experiment, they cooled EVERYTHING on the motherboard, plus a video card and network card. In their writeup they say that they picked a cool-running card, as opposed to a heat-filled monster. The experimenters subjected all the components, perhaps ineptly, to the same ambient temp of -60 C. Even military components are designed to run above -55 C. Most commercial-grade components are speced to run at an ambient of 0 C.
The result could be predicted: The overclocking of the cool-running Celeron chip was sabotaged by the overcooling of the support chips.
Just my pair-o-pennies(tm).
Back in my cubicle-inhabiting days, I was forever fighting glare on my screens. So I put theatre gel (color filters) in the fixtures right over my desk to tone down the white glare. Today, you can buy the gel in sleeves that fit right over the bulbs.
In another situation, a colleague and I removed the tubes from the fixture and used spot lighting in our cubes to achieve the same effect.
If your objection is to the color instead of the flickering, there are special tubes that are available under a number of trade names. Look for a specification that the tube has a color temperature of around 5000 degrees K, and a spectrum that mimics a sunny day at 2 PM. Use a neutral gel if the tubes give out too much light.
In my home office, I have a fixture that uses T-8 tubes instead of the more standard T-12, so I have to use what I can find for tubes. A couple of gels (#813) I had lying around from a theatre job cuts the light down to something bearable, and also cuts some blue out so that I get better contrast from my 19" monitor.
Just make sure you can do the entire bullpen...