I had the good fortune to see a forerunner of this technology --- 40 years ago, at the AT&T pavilion at the New York Worlds Fair. It was called "picture-phone". Video over a telephone line. Very nice to see that they have finally brought it to market.
Well stated - matches my recollections as well. The price of CD's has NEVER come down since they were first introduced, and it is only because of inflation that their relative price is now on a par with that of record albums from yon times of yore. Taking 1983 as a reference point for what CD's OUGHT to cost, when CDs were a new technology, is just insanity.
For two years I had to enter my department's annual budget into an Excel spreadsheet just dripping with macros. What a nightmare! Errors in the macros could not be fixed. Errors in the preloaded budget codes could not be fixed. Errors that I made could not be caught. Some actions were irreversible. Blech.
The process was then converted to a web-based application. 1000% improvement. All prior problems were solved. Client side support issues dissolved away. New functionality was added.
Elimination of VB will be a step forward for information technology.
"the great thing about VAX assembler was that there was an instruction for everything..."
Yep, however I discovered that complex instructions were implemented internally as as bunch of simpler instructions anyway, so reducing the instruction count in a program did NOT lead to faster execution times. Alas...
"That could be good news for NASA because summer thunderstorms are less likely to be a problem earlier in the day."
Maybe in Florida. Here in the Midwest we can get the flash-boom of T'storms any time of day or night. Nothing like being woken up at 5 am to a power outage.
In spite of UNIX being a commercial product, one of its little known "features" for those having a source code license is that AT&T (and thus now SCO) offer NO indemnification whatsoever for any violations of copyright or patent law by the source code - the end users assumes all risk.
Which is kind of ironic, given that Darl McBride accused Linux exactly the same thing
I do not understand the idea that 8 year old software is OLD. My Jeep Grand Cherokee is 11 years old (1995) and still runs fine - much better than any MS software of comparable vintage. It needs patches now and again - last one was a water pump - but nothing beyond the ordinary. Support is easily available from the shop across town. Why does software, which has no moving parts and has a much larger installed base, seem to decay so much faster?
Indeed, the only thing that the Jeep and Win98 will have in common as we go forward is that neither will be able to run future editions of Firefox. The fact that the Jeep was never able to run any previous version of Firefox is irrelevant to this argument.
Having managed over a dozen budgets and been driven nuts by project managers and bosses who want every cost detail to be accounted for precisely, my mantra has become the following:
"TRUST THE CENTRAL LIMIT THEOREM!"
Any budget or cost estimate is usually the sum of many smaller items. Whether you are dealing with cost estimates or charge accruals, errors will inevitably creep in. Even if the errors for any single item are huge (say, 100%), the central limit theorem tells us that the error in the sum, at least expressed as a fraction, will be much smaller. As a consequence, I maintain that we should not obsess over the details - they will average out in the end. The big picture will take care of itself.
Many years ago we looked at Postgres, and the developer at the time said that "he would not trust his payroll to it."
The database has improved a lot since then, and I currently support two Postgres databases, one on Linux and one on IRIX, both running in mission-critical situations. What that means is that if either one fails, I get phone calls in the middle of the night with complaints. In over 6 years, I have not fielded one phone call attributable to Postgres itself.
None of the issues raised in the article was even remotely a factor in my choice of Postgres. A big (and ultimately deciding) factor in its favor is that it can be compiled and installed on a broad range of hardware and operating system versions. MySQL fared less well in this regard.
I learned to program in the days of punched cards. Think of one card as one line of code. A complete program is a card deck. The card deck is stored in a card box. The box is important - it is your "code repository".
Want to edit some code? Pull out the old cards and store them in the back of the box with a rubber-band around them, then punch in the new code (using a keypunch, of course) and insert the new cards into your card deck. Voila - code repository! CVS! Subversion!
Need to use the code in multiple places? Run the cards through a card duplicator. Voila - code reuse!
Need to save some space but don't want to lose the old code? Run the cards through a card lister that prints them out on a line printer. Voila - archive!
The most difficult problem with storing code, whether in punched cards or another, more modern format, is this: REMEMBERING WHERE YOU PUT IT!
If they go bankrupt, it's not because of me. I tried cancelling a support contract for some really archaic Challenge-L servers that we have been running for years - but no, you can't cancel early, so I am still paying big bucks to them even now.
The funny thing is that SGI was never know for robustness of its hardware (IBM was better) but those old servers must now be 10 years old and they are still chugging along.
At my local grocery store (an independent, no less) at checkout the clerks always ask if I have a frequent shopper card. When I say no, they go ahead and swipe their own card. BINGO! instant savings anyway.
People in my group at work (I sign the requisitions) can have whatever laptop they want. Increasingly, they are
going with a Mac so they don't have to dual-boot Windows and Linux. BSD Unix + MS Office is the killer
combination.
Making bug-free software is much harder than anyone can imagine.
Let us not forget the very modest program IEFBR14 - arguably the shortest program ever written for use in a production environment. It ran on IBM's System/360. (I rans it many times myself.) Its sole function was to exit - nothing else. It was a whopping one machine instruction long - 2 bytes. It was even Open Source (BR14 is the assembly language version of the instruction, which is the standard way programs exited). It was the simplest possible program that one could write. If ever there was a program that was going to be bug-free this was it!
It had a bug.
When a program exits on OS/360, it is expected to have set some bits to indicate any errors. When a program is called, those bits are in an unpredictable state. IEFBR14 had to be modified (doubling its length) to clear the bits first.
Slashdot Mirror
From the article:
... automatically UPDATE[s] itself when ... the customer is using WU ... be NOTIFIED of updates."
"WU
to automatically
Yes, the land of Microsoft is an amazingly magical place.
Inventors: Arthur C. Clarke and Stanley Kubrick
First publication: 2001 A Space Odyssey (Released 1968). Heywood Floyd checks in to the space station:
Female voice: "Thank you. You are cleared through Voiceprint Identification."
http://www.imdb.com/title/tt0062622/quotes
I had the good fortune to see a forerunner of this technology --- 40 years ago, at the AT&T pavilion at the New York Worlds Fair. It was called "picture-phone". Video over a telephone line. Very nice to see that they have finally brought it to market.
Can't say for sure, but it ... er ... *cough* ... has nothing to do with my having an account there.
Well stated - matches my recollections as well. The price of CD's has NEVER come down since they were first introduced, and it is only because of inflation that their relative price is now on a par with that of record albums from yon times of yore. Taking 1983 as a reference point for what CD's OUGHT to cost, when CDs were a new technology, is just insanity.
I couldn't agree more.
For two years I had to enter my department's annual budget into an Excel spreadsheet just dripping with macros.
What a nightmare! Errors in the macros could not be fixed. Errors in the preloaded budget codes could not be
fixed. Errors that I made could not be caught. Some actions were irreversible. Blech.
The process was then converted to a web-based application. 1000% improvement. All prior problems were solved.
Client side support issues dissolved away. New functionality was added.
Elimination of VB will be a step forward for information technology.
No report on computing curriculum would be complete without the topic covered on page 2:
[This page intentionally left blank]
"Bartlett added that he hoped the Compulinx business could continue uninterrupted despite the CEO's legal woes."
Right.
"My first assembly language was VAX."
..."
...
That was my LAST assembly language architecture.
"the great thing about VAX assembler was that there was an instruction for everything
Yep, however I discovered that complex instructions were implemented internally
as as bunch of simpler instructions anyway, so reducing the instruction count in a
program did NOT lead to faster execution times. Alas
Anyone remember "2001, A Space Odyssey?" Heywood Floyd is rocketed from Earth to an orbiting space station, which is ... half-built.
http://dayton.hq.nasa.gov/IMAGES/SMALL/GPN-2003-00 093.jpg
Maybe in Florida. Here in the Midwest we can get the flash-boom of T'storms any time of day or night. Nothing like being woken up at 5 am to a power outage.
Which is kind of ironic, given that Darl McBride accused Linux exactly the same thing
Indeed, the only thing that the Jeep and Win98 will have in common as we go forward is that neither will be able to run future editions of Firefox. The fact that the Jeep was never able to run any previous version of Firefox is irrelevant to this argument.
"TRUST THE CENTRAL LIMIT THEOREM!"
Any budget or cost estimate is usually the sum of many smaller items. Whether you are dealing with cost estimates or charge accruals, errors will inevitably creep in. Even if the errors for any single item are huge (say, 100%), the central limit theorem tells us that the error in the sum, at least expressed as a fraction, will be much smaller. As a consequence, I maintain that we should not obsess over the details - they will average out in the end. The big picture will take care of itself.
The database has improved a lot since then, and I currently support two Postgres databases, one on Linux and one on IRIX, both running in mission-critical situations. What that means is that if either one fails, I get phone calls in the middle of the night with complaints. In over 6 years, I have not fielded one phone call attributable to Postgres itself.
None of the issues raised in the article was even remotely a factor in my choice of Postgres. A big (and ultimately deciding) factor in its favor is that it can be compiled and installed on a broad range of hardware and operating system versions. MySQL fared less well in this regard.
So it is back to being a desktop computer? That sure was a useful exercise.
Want to edit some code? Pull out the old cards and store them in the back of the box with a rubber-band around them, then punch in the new code (using a keypunch, of course) and insert the new cards into your card deck. Voila - code repository! CVS! Subversion!
Need to use the code in multiple places? Run the cards through a card duplicator. Voila - code reuse!
Need to save some space but don't want to lose the old code? Run the cards through a card lister that prints them out on a line printer. Voila - archive!
The most difficult problem with storing code, whether in punched cards or another, more modern format, is this: REMEMBERING WHERE YOU PUT IT!
The funny thing is that SGI was never know for robustness of its hardware (IBM was better) but those old servers must now be 10 years old and they are still chugging along.
At my local grocery store (an independent, no less) at checkout the clerks always ask if I have a frequent shopper card. When I say no, they go ahead and swipe their own card. BINGO! instant savings anyway.
All of the servers that I order (well technically, sign off on the requisitions) have Linux pre-installed. About $1 million in the last few years.
However, these are all from white-box vendors, who may not figure in Gartner's numbers and thus would, in the end, also skew the numbers a bit.
People in my group at work (I sign the requisitions) can have whatever laptop they want. Increasingly, they are going with a Mac so they don't have to dual-boot Windows and Linux. BSD Unix + MS Office is the killer combination.
Happened to me once as well (regular burgers, but what's the difference). Gaaahh! I smell a class-action suit - sign me up!
Making bug-free software is much harder than anyone can imagine.
Let us not forget the very modest program IEFBR14 - arguably the shortest
program ever written for use in a production environment. It ran on IBM's
System/360. (I rans it many times myself.) Its sole function was to
exit - nothing else. It was a whopping one machine instruction long - 2
bytes. It was even Open Source (BR14 is the assembly language version of
the instruction, which is the standard way programs exited). It was the
simplest possible program that one could write. If ever there was a
program that was going to be bug-free this was it!
It had a bug.
When a program exits on OS/360, it is expected to have set some bits to
indicate any errors. When a program is called, those bits are in an
unpredictable state. IEFBR14 had to be modified (doubling its length) to
clear the bits first.
Sigh...
Then send the letter.