"I still can't believe there will be a 32-bit version."
I still can't believe people's obsession with Long Mode.
Well, actually, I can, simply because 64 is larger than 32, and thus 64-bit equates to "better" in the eyes of lots of people. But lots of people are fools, too.
But seriously, the majority of computer users have absolutely no need for Long Mode. They do things like browse the web, forward email, watch YouTube, and look at porn. You barely need Protected Mode for that.
The scenarios benefiting from Long Mode would be:
Servers
IT lab/admin types who want to run multiple concurrent VMs with large memories
Engineering workstation users who actually need to work with datasets larger than 2^32 bytes (4 GiB)
That's about it, really.
Most people are concerned solely with the amount of memory Windows reports in the System Properties dialog, and get their panties in a bunch over 700 MB or so of "missing" RAM. While I can understand wanting one's OS to be able to use all the RAM one paid for, most of these people aren't actually ever going to use that much of RAM. They just want their number to be bigger, because that obviously reflects on the size of their testicles. That's why they bought 4 GiB of RAM in the first place.
But even then, Long Mode is not needed to win the penis-length contests. Proper support for PAE would solve the problems. Just about any Intel-compatible CPU made in the past ten years supports PAE. With PAE, the processor can directly address up to 64 GiB of RAM in i386 Protected Mode, even though each user task (process) is still limited to a 4 GiB virtual address space. But it's very rare for a single task to actually need that much.
Of course, on Win i386, it's a little worse than that. Processes are limited to 2 GiB of user address space (with the kernel having the same 2 GiB in every process). But even 2 GiB is a lot of memory. Even Firefox only needs half a gig or so.;-)
Win i386 actually uses PAE, sort-of. It needs to obtain the NX (No Execute) bit in page tables, for "DEP" (Data Execution Prevention). But Win i386 still limits physical addresses to under 4 GiB to keep crappy drivers from crashing the system. Since Microsoft's all about driver signing these days, they could just add an flag to the driver signature indicating it's qualified to work above 4 GiB, and have an OS boot option or something which allowed all memory to be used. Refuse to load PAE unqualified drivers in that mode.
Meanwhile, Long Mode is not without drawbacks. Long Mode, for those who don't know, is the processor mode AMD introduced which enables native 64-bit virtual addressing. But when in Long Mode, the processor can't do 16-bit Virtual Mode at all. There's still a lot of Win16 code floating around in the Windows world, sadly. Long Mode also means potential compatibility issues with crappy 32-bit code. Sure, it's crappy code, but I've found most code is crappy code. There can be performance costs, too (64-bit everywhere means more stuff than 32-bit most places), although they're minor and may be offset by equally possible performance gains (instruction architecture improvements such as more general-purpose registers).
Since this is Slashdot, I have to mention that Linux i386 supports PAE just fine, and has no problem working with more than 4 GiB of RAM, making Linux x86-64 even less interesting than Win x86-64. Linux also doesn't manage memory the same way as Windows, so the user/kernel split doesn't apply. So Linux x86-64 has all the compatibility problems of Long Mode, with even fewer benefits.
Does not Apple support target-mode with USB these days?
"Target Disk Mode" with USB is not possible with present computer hardware.
Unlike FireWire, USB is directional. That is to say, with USB, ports are either "Host" (A connector) or "Device" (B connector). You cannot connect a Host port to a Host port, or Device to Device. So you cannot simply wire up a cable with two A connectors (the rectangular one) and plug a computer into a computer. The hardware and protocol do not support it.
FireWire had no such issue; all bus nodes were peers. You could build a simple computer network with nothing but ordinary FireWire cables.
A standard for something called "USB-To-Go" (UTG) was created later, but it is almost never implemented. UTG lets a Host detect when it has been connected to another Host, and switch itself to act like a Device instead. It was created mainly for mobile devices (e.g., PDAs) which sometimes plug into computers, and sometimes plug into devices (flash drives, cameras, printers, etc.). UTG requires both special hardware and software support. It's a kludge.
So unless the market finds a reason to implement UTG in computers, Target Disk Mode will never be possible with USB.
I'm not going to comment on the rest, but this seems bogus:
For one, it's easier sometimes to get a change approved in an application than it is to talk someone into approving a change -- any change -- in the database schema, no matter how trivial...
Either way, we are talking about making a change that could impact the quality of the results given. So either change control on the database side is too strict, or change control on the application side is too loose. Either way, the problem is with the change control procedures in use, not with the adoption or avoidance of database-level intelligence.
Um, your computer is way underpowered or your IT department sucks because 15 minutes to boot in crazy.
Symantec Anti-Virus Corporate Edition and Microsoft Windows Update after the MSKB 927891 hotfix seem to have some kind of pathologically bad interaction during/immediately-after startup, where the disk thrashes like crazy no matter how much hardware you have. The computer can be almost unusably slow for one to five minutes after boot. Microsoft blames Symantec, Symantec blames Microsoft, I get nowhere. Since we can't jettison Windows (oh, how much I'd love to), we're jettisoning Symantec at the end of our current contract, but that's still several months out. In the mean, we're just telling everybody to leave their PCs on. Nice, eh?
I've always wondered why we don't see the IT industry adopting the telephone company model for power. Telcos run everything directly off a 48 volt battery plant. The batteries are continuously trickle charged. In a power outage, the batteries just stop charging for a little while. So you don't need a separate UPS with charger, inverter, and so on. You don't need separate surge protection -- the AC->DC conversion gives you more than adequate isolation. If it was a 12 volt battery plant instead of a 48 volt one, you've be able to build smaller, cheaper power supplies in the PCs, since you'd only need a 12->5 and 12->3.3 volt DC/DC conversion. Seems like a no brainer to me.
I guess voltage drop would be a concern (12 volt DC won't go too terribly far), but the telcos seem happy solving that problem with big ass bus bars; would the same work for PCs?
Wikipedia's mission is to be an encyclopedia of verifiable, established facts. Publishing original research is outside the scope of that effort.
Of course, having a comprehensive Free Content encyclopedia available could well enable progress by being a useful resource to people doing original research.
Excel used to have an error that read "Error: Not Enough" and the dialog box had only an "Ok" button.
I always preferred old-school X programs, which tended to label the button in error dialogs "Dismiss". As in, dismiss the error message. Clicking "OK" in response to an error just seems so... wrong. Back in 1995, I was playing around with the then-new Windows 95. I monkeyed with the SHELL setting, and the following error message appeared on restart:
Could not start Explorer. You must reinstall Windows.
[ OK ]
I refused to click the OK button. That was not okay. (I instead hit the RESET hardware switch. The bad SHELL setting was easily fixed by editing WIN.INI from DOS mode.)
Just because no one ever has, doesn't mean that no one ever can.
You misunderstand. It isn't about verifying the results of the research, like one would verify a reported scientific experiment. This is about verifying the fact that it occurred at all, not that the research is right or wrong or true or false. So you cannot describe original research -- research you have done yourself, and no-one else has. Once the research has been reported in a secondary source, it can be included in Wikipedia. The standard for inclusion is verifiability, not truth.
vi is emitting a beep character (ASCII 7 BEL). Your terminal is flashing the window when it gets that character, rather than making a noise. It's called "visual bell". In a room full of terminals (or even with just one), all the beeping can get quite annoying, so visual bell is the default on many systems.
The Raytheon RDS 500's of the 1970's sometimes gave the following compiler error:
Eror
That was it. Nothing else. Couldn't even bother to spell the word properly. It meant that somewhere in your 10,000 cards(!) of Fortran there was an error.
You had error messages?;-)
Our local LUG was once privileged to have Doug McIlroy speak at one of our meetings. (For those who don't recognize the name and don't want to RTFA, he was there during the invention of most of what we consider computers. He was helped test the first FORTRAN compiler (and thus the first compiler). He was Ken and Dennis's boss when they were creating Unix and C. He's credited with the concept of modular software (i.e., not every program has to be written from the ground up to do everything). In short, he's a computer demigod. And a real nice guy. But I digress...)
Anyway, he described the behavior of the early FORTRAN compiler when it encountered an error: It would stop (halt) the machine. The operator would then look at the program counter to find the instruction address it halted at. That address told them where in the FORTRAN compiler itself the machine was running when the problem was detected. They had a big binder, called the "stop book", that listed addresses and what a halt at that address usually meant. He described one of the messages as, "Duplicate identifier, or some other problem".
And I thought Microsoft Outlook's diagnostic messages were bad.:)
I seem to remember a few times getting all four: Abort, Retry, Ignore, Fail. Ah, DOS.
Yah. ARF came from the DOS "critical error" handler. Problems that required operator intervention were termed "critical errors", since the system could not proceed without help. When a BIOS or DOS system routine encountered such a problem, they invoked a software interrupt. The theory was that a good program could hook the interrupt and put in a more useful error handler. Obviously, not many programs did so.
Abort killed the running program or command, and returned you to the DOS prompt. Retry had DOS try again, without returning control to the caller. Ignore meant control was returned to the calling routine, as if nothing had gone wrong. Fail meant control was returned to the running routine, with an error status indication.
"Fail" might seem like a good idea, but it turns out that a lot of code didn't check the error status, leading to erratic behavior and/or just calling the same routine again.
There was some rhyme or reason to when which choices were displayed when, but I've long since forgotten it. Some of it might have had something to do with some commands being internal to COMMAND.COM and some being external programs, but the service routines all invoking the same "critical error" software interrupt.
One day I got a call from engineering that told me they where getting a error in a vb application.
Where I work, we used to have an in-house, custom program for test automation, written by a guy named Bob. (In a language called Rocky Mountain Basic, no less.) Bob was fired a long time ago. On occasion, the program would pop up the error message box:
How is this original research? The computer is a publication, is it not?
Exactly. Information on Wikipedia must be verifiable. Everything else stems from that. Original research -- research that someone has done for the first time, and that no-one else has done -- is not permitted, because it cannot be verified. The behavior of the first Mac computers is easily verified.
the error pre-dates PS/2 keyboards, and the older keyboards with the larger connectors were hot-swappable
The IBM-PC and PS/2 keyboard interfaces were not designed to be hot-swappable. However, it tended to work anyway, provided POST completed initialization of the i8042 first. On occasion, though, a cheap clone would have a mobo that fried the keyboard controller if you tried to hot-swap it. Back in those days, new motherboards were *expensive*...
To be fair, it should had said "Error: keyboard not found. Connect a keyboard and press F1 to continue." But then, each byte of ROM was expensive once.
That error message dates back to the early days of the IBM-PC (possibly the first model, although I couldn't swear to that). Every expected possible failure during POST (Power On Self Test) had a corresponding error code and message. They all used the same output routine, which displayed the error code, the error message, and prompted the operator to press [F1] to continue. They simply didn't create a special case for keyboard errors -- it displayed the same way all the others did. There were other errors which left the system effectively inoperable, but still prompted to press F1. The keyboard error was just the most commonly encountered, of course.
I've seen the following in the Windows "Event Viewer" logs. (Reproduced from memory, so it's not verbatim, but it's pretty close.)
The following problem occurred during installation of Microsoft Office 2003: Success
(Apparently, when installing via GPO, MSI sometimes reports an error despite everything being okay. So the message gets logged. It can happen with any package. I just liked the double entendre from when it happened to Office.)
(BTW, the subject line comes from this essay. If you haven't read it, you should. What's worse than failure? Success. HHOS.)
Having obnoxious sound clips attached to every event you can think of was the epitome of the early 90s.
So true. It had its drawbacks, though (aside from the obvious drawback of being totally fscking annoying):
1. I was once on a tech support call when suddenly my PC yelled out -- "Help! Help! I'm being repressed!". From the phone, there was a long pause, and then the guy on the other end went "Ohhhhkay." Obviously not a Python fan.
2. I had the Windows "critical error" sound set to a noise that consisted of something like a Star Wars laser-blaster battle, followed by a massive explosion. It was... loud and abrupt. I had been hacking on some code for several hours, and it was well into the early morning. Everything had been silent four hours. Suddenly a critical error occurred. I nearly jumped out of my skin. Remembering what it felt like still gives me the twitches.
No copyright protection? So they are only releasing music that is in the public domain!?
I'm glad I'm not the only one who noticed this. How sad is it that in the music business, copyright lust is so pervasive that "copyright" is confused with attempts to abbridge fair use rights.
Or did the newspaper screw up, and mean to write "no copy protection"?
I prefer the term "copy restriction". This isn't about protecting copies, it's about restricting the ability to make copies. Just like "DRM" isn't about digital rights.
... the Amiga OS is a bit different from BeOS and OS/2... Amiga PCs were everywhere
Speaking of fans with a reality disconnect...
The Amiga never reached critical mass in the general computer market. (At least, not in the US. I've read it was a different story in Europe. But the US was really the only computer market the mattered, at the time.) Yes, it had niche penetration in a few segments, like video production. So did OS/2. Banks, in particular, loved it. I can't find hard figures for either, but random Internet blurbs seem to suggest OS/2 unit sales were roughly comparable to Amiga unit sales -- somewhere in the very low tens of millions.
I'm just chiming from my observations but wasn't OS/2 great for digital phone systems in the 90s and early 2000s before Linux products took the crown? This is of course well before VOIP.
Of course. Heck, OS/2 is still in use in a lot of ATMs, voice mail systems, and so on today, although it's being phased out due to lack of support. But there are ATM's in my area that I know are running OS/2. Our Nortel Norstar voice mail unit at work runs OS/2. In the 1980s and 1990s, OS/2 was very commonly used when you wanted to embed a general-purpose computer system into an "appliance" scenario. That's because it was, to a large extent, the only acceptable option.
Consider, it's 1990, and you want to build some kind of computerized "appliance". Maybe it's a voice mail system, or a bank ATM, or an electronic message board, or whatever. You want to use a general-purpose computer, because that lowers costs and enables third-party "layered product" options. GP hardware is cheaper, software development on a GP platform is easier (since the test target can be the same as the development environment), and there's a bigger third-party community to tap.
So what are your choices? Linux doesn't exist yet. Commercial Unix platforms (SGI/Irix, SunOS, HP-UX, DEC/Ultrix, etc.) are very expensive. BSD is tied up in legal wranglings, and support for commodity micros (IBM-PC, Mac) is limited at the time. DOS barely provides disk services and is useless for everything else, so you'd practically have to write your own OS. MS Windows runs on top of DOS and is basically just a GUI -- inappropriate for most embedded applications -- and has stability issues. Win NT doesn't exist yet. Xenix is a joke. SCO Unix is painfully clunky and hideously expensive.
And then there is OS/2. It's a preemptive multitasking, protected memory OS. It runs on IBM-PC-compatible computers, the platform with the biggest market presence and the most third-party support -- and also the cheapest hardware. It's from IBM, the single biggest name in computing. IBM and Microsoft both say it's the wave of the future. It's relatively inexpensive when purchased in bulk. Seems like a no brainer, right?
Obviously, looking back with 20/20 hindsight today, OS/2 seems like a strange choice, but at the time, it made perfect sense.
Slashdot Mirror
"I still can't believe there will be a 32-bit version."
I still can't believe people's obsession with Long Mode.
Well, actually, I can, simply because 64 is larger than 32, and thus 64-bit equates to "better" in the eyes of lots of people. But lots of people are fools, too.
But seriously, the majority of computer users have absolutely no need for Long Mode. They do things like browse the web, forward email, watch YouTube, and look at porn. You barely need Protected Mode for that.
The scenarios benefiting from Long Mode would be:
That's about it, really.
Most people are concerned solely with the amount of memory Windows reports in the System Properties dialog, and get their panties in a bunch over 700 MB or so of "missing" RAM. While I can understand wanting one's OS to be able to use all the RAM one paid for, most of these people aren't actually ever going to use that much of RAM. They just want their number to be bigger, because that obviously reflects on the size of their testicles. That's why they bought 4 GiB of RAM in the first place.
But even then, Long Mode is not needed to win the penis-length contests. Proper support for PAE would solve the problems. Just about any Intel-compatible CPU made in the past ten years supports PAE. With PAE, the processor can directly address up to 64 GiB of RAM in i386 Protected Mode, even though each user task (process) is still limited to a 4 GiB virtual address space. But it's very rare for a single task to actually need that much.
Of course, on Win i386, it's a little worse than that. Processes are limited to 2 GiB of user address space (with the kernel having the same 2 GiB in every process). But even 2 GiB is a lot of memory. Even Firefox only needs half a gig or so. ;-)
Win i386 actually uses PAE, sort-of. It needs to obtain the NX (No Execute) bit in page tables, for "DEP" (Data Execution Prevention). But Win i386 still limits physical addresses to under 4 GiB to keep crappy drivers from crashing the system. Since Microsoft's all about driver signing these days, they could just add an flag to the driver signature indicating it's qualified to work above 4 GiB, and have an OS boot option or something which allowed all memory to be used. Refuse to load PAE unqualified drivers in that mode.
Meanwhile, Long Mode is not without drawbacks. Long Mode, for those who don't know, is the processor mode AMD introduced which enables native 64-bit virtual addressing. But when in Long Mode, the processor can't do 16-bit Virtual Mode at all. There's still a lot of Win16 code floating around in the Windows world, sadly. Long Mode also means potential compatibility issues with crappy 32-bit code. Sure, it's crappy code, but I've found most code is crappy code. There can be performance costs, too (64-bit everywhere means more stuff than 32-bit most places), although they're minor and may be offset by equally possible performance gains (instruction architecture improvements such as more general-purpose registers).
Since this is Slashdot, I have to mention that Linux i386 supports PAE just fine, and has no problem working with more than 4 GiB of RAM, making Linux x86-64 even less interesting than Win x86-64. Linux also doesn't manage memory the same way as Windows, so the user/kernel split doesn't apply. So Linux x86-64 has all the compatibility problems of Long Mode, with even fewer benefits.
Does not Apple support target-mode with USB these days?
"Target Disk Mode" with USB is not possible with present computer hardware.
Unlike FireWire, USB is directional. That is to say, with USB, ports are either "Host" (A connector) or "Device" (B connector). You cannot connect a Host port to a Host port, or Device to Device. So you cannot simply wire up a cable with two A connectors (the rectangular one) and plug a computer into a computer. The hardware and protocol do not support it.
FireWire had no such issue; all bus nodes were peers. You could build a simple computer network with nothing but ordinary FireWire cables.
A standard for something called "USB-To-Go" (UTG) was created later, but it is almost never implemented. UTG lets a Host detect when it has been connected to another Host, and switch itself to act like a Device instead. It was created mainly for mobile devices (e.g., PDAs) which sometimes plug into computers, and sometimes plug into devices (flash drives, cameras, printers, etc.). UTG requires both special hardware and software support. It's a kludge.
So unless the market finds a reason to implement UTG in computers, Target Disk Mode will never be possible with USB.
I'm not going to comment on the rest, but this seems bogus:
For one, it's easier sometimes to get a change approved in an application than it is to talk someone into approving a change -- any change -- in the database schema, no matter how trivial ...
Either way, we are talking about making a change that could impact the quality of the results given. So either change control on the database side is too strict, or change control on the application side is too loose. Either way, the problem is with the change control procedures in use, not with the adoption or avoidance of database-level intelligence.
Um, your computer is way underpowered or your IT department sucks because 15 minutes to boot in crazy.
Symantec Anti-Virus Corporate Edition and Microsoft Windows Update after the MSKB 927891 hotfix seem to have some kind of pathologically bad interaction during/immediately-after startup, where the disk thrashes like crazy no matter how much hardware you have. The computer can be almost unusably slow for one to five minutes after boot. Microsoft blames Symantec, Symantec blames Microsoft, I get nowhere. Since we can't jettison Windows (oh, how much I'd love to), we're jettisoning Symantec at the end of our current contract, but that's still several months out. In the mean, we're just telling everybody to leave their PCs on. Nice, eh?
I've always wondered why we don't see the IT industry adopting the telephone company model for power. Telcos run everything directly off a 48 volt battery plant. The batteries are continuously trickle charged. In a power outage, the batteries just stop charging for a little while. So you don't need a separate UPS with charger, inverter, and so on. You don't need separate surge protection -- the AC->DC conversion gives you more than adequate isolation. If it was a 12 volt battery plant instead of a 48 volt one, you've be able to build smaller, cheaper power supplies in the PCs, since you'd only need a 12->5 and 12->3.3 volt DC/DC conversion. Seems like a no brainer to me.
I guess voltage drop would be a concern (12 volt DC won't go too terribly far), but the telcos seem happy solving that problem with big ass bus bars; would the same work for PCs?
Is there something I'm missing?
How does this enable progress?
I expect it doesn't.
Wikipedia's mission is to be an encyclopedia of verifiable, established facts. Publishing original research is outside the scope of that effort.
Of course, having a comprehensive Free Content encyclopedia available could well enable progress by being a useful resource to people doing original research.
Excel used to have an error that read "Error: Not Enough" and the dialog box had only an "Ok" button.
I always preferred old-school X programs, which tended to label the button in error dialogs "Dismiss". As in, dismiss the error message. Clicking "OK" in response to an error just seems so... wrong. Back in 1995, I was playing around with the then-new Windows 95. I monkeyed with the SHELL setting, and the following error message appeared on restart:
Could not start Explorer. You must reinstall Windows.
[ OK ]
I refused to click the OK button. That was not okay. (I instead hit the RESET hardware switch. The bad SHELL setting was easily fixed by editing WIN.INI from DOS mode.)
Just because no one ever has, doesn't mean that no one ever can.
You misunderstand. It isn't about verifying the results of the research, like one would verify a reported scientific experiment. This is about verifying the fact that it occurred at all, not that the research is right or wrong or true or false. So you cannot describe original research -- research you have done yourself, and no-one else has. Once the research has been reported in a secondary source, it can be included in Wikipedia. The standard for inclusion is verifiability, not truth.
For more information, see: http://en.wikipedia.org/wiki/Wikipedia:Verifiability
vi beeps? I've only seen it flash.
vi is emitting a beep character (ASCII 7 BEL). Your terminal is flashing the window when it gets that character, rather than making a noise. It's called "visual bell". In a room full of terminals (or even with just one), all the beeping can get quite annoying, so visual bell is the default on many systems.
My favourite error message is when the Linux kernel encounters an NMI error
Other good kernel error messages (not source comments) include:
Aieeee! Killing interrupt handler!
and
Open inodes after filesystem unmount. Self-destuct in 5... 4...
The Raytheon RDS 500's of the 1970's sometimes gave the following compiler error:
Eror
That was it. Nothing else. Couldn't even bother to spell the word properly. It meant that somewhere in your 10,000 cards(!) of Fortran there was an error.
You had error messages? ;-)
Our local LUG was once privileged to have Doug McIlroy speak at one of our meetings. (For those who don't recognize the name and don't want to RTFA, he was there during the invention of most of what we consider computers. He was helped test the first FORTRAN compiler (and thus the first compiler). He was Ken and Dennis's boss when they were creating Unix and C. He's credited with the concept of modular software (i.e., not every program has to be written from the ground up to do everything). In short, he's a computer demigod. And a real nice guy. But I digress...)
Anyway, he described the behavior of the early FORTRAN compiler when it encountered an error: It would stop (halt) the machine. The operator would then look at the program counter to find the instruction address it halted at. That address told them where in the FORTRAN compiler itself the machine was running when the problem was detected. They had a big binder, called the "stop book", that listed addresses and what a halt at that address usually meant. He described one of the messages as, "Duplicate identifier, or some other problem".
And I thought Microsoft Outlook's diagnostic messages were bad. :)
I seem to remember a few times getting all four: Abort, Retry, Ignore, Fail. Ah, DOS.
Yah. ARF came from the DOS "critical error" handler. Problems that required operator intervention were termed "critical errors", since the system could not proceed without help. When a BIOS or DOS system routine encountered such a problem, they invoked a software interrupt. The theory was that a good program could hook the interrupt and put in a more useful error handler. Obviously, not many programs did so.
Abort killed the running program or command, and returned you to the DOS prompt. Retry had DOS try again, without returning control to the caller. Ignore meant control was returned to the calling routine, as if nothing had gone wrong. Fail meant control was returned to the running routine, with an error status indication.
"Fail" might seem like a good idea, but it turns out that a lot of code didn't check the error status, leading to erratic behavior and/or just calling the same routine again.
There was some rhyme or reason to when which choices were displayed when, but I've long since forgotten it. Some of it might have had something to do with some commands being internal to COMMAND.COM and some being external programs, but the service routines all invoking the same "critical error" software interrupt.
One day I got a call from engineering that told me they where getting a error in a vb application.
Where I work, we used to have an in-house, custom program for test automation, written by a guy named Bob. (In a language called Rocky Mountain Basic, no less.) Bob was fired a long time ago. On occasion, the program would pop up the error message box:
Call Bob!
Man am I glad that program was finally retired.
How is this original research? The computer is a publication, is it not?
Exactly. Information on Wikipedia must be verifiable. Everything else stems from that. Original research -- research that someone has done for the first time, and that no-one else has done -- is not permitted, because it cannot be verified. The behavior of the first Mac computers is easily verified.
PC LOAD LETTER... what the FUCK DOES THAT MEAN?!?!
Paper cartridge -- Load letter sized paper.
"I know you don't care, I'm just trying to annoy you."
"A system call that should never fail has failed."
I have been told that some versions of SunOS had a kernel panic message that read:
Shannon and Bill say this can't happen.
the error pre-dates PS/2 keyboards, and the older keyboards with the larger connectors were hot-swappable
The IBM-PC and PS/2 keyboard interfaces were not designed to be hot-swappable. However, it tended to work anyway, provided POST completed initialization of the i8042 first. On occasion, though, a cheap clone would have a mobo that fried the keyboard controller if you tried to hot-swap it. Back in those days, new motherboards were *expensive*...
To be fair, it should had said "Error: keyboard not found. Connect a keyboard and press F1 to continue." But then, each byte of ROM was expensive once.
That error message dates back to the early days of the IBM-PC (possibly the first model, although I couldn't swear to that). Every expected possible failure during POST (Power On Self Test) had a corresponding error code and message. They all used the same output routine, which displayed the error code, the error message, and prompted the operator to press [F1] to continue. They simply didn't create a special case for keyboard errors -- it displayed the same way all the others did. There were other errors which left the system effectively inoperable, but still prompted to press F1. The keyboard error was just the most commonly encountered, of course.
It was error code 301, by the way. :)
I recall using a JOVIAL compiler in the 1980s. My favorite message was:
COMPILE COMPLETE: NONE OF THE ERRORS WERE DETECTED.
I once heard tell of a Pascal compiler that could produce the error message:
You lied to me when you told me this was a program.
Actually, I've had "ERROR: No error" before.
I've seen the following in the Windows "Event Viewer" logs. (Reproduced from memory, so it's not verbatim, but it's pretty close.)
The following problem occurred during installation of Microsoft Office 2003:
Success
(Apparently, when installing via GPO, MSI sometimes reports an error despite everything being okay. So the message gets logged. It can happen with any package. I just liked the double entendre from when it happened to Office.)
(BTW, the subject line comes from this essay. If you haven't read it, you should. What's worse than failure? Success. HHOS.)
Having obnoxious sound clips attached to every event you can think of was the epitome of the early 90s.
So true. It had its drawbacks, though (aside from the obvious drawback of being totally fscking annoying):
1. I was once on a tech support call when suddenly my PC yelled out -- "Help! Help! I'm being repressed!". From the phone, there was a long pause, and then the guy on the other end went "Ohhhhkay." Obviously not a Python fan.
2. I had the Windows "critical error" sound set to a noise that consisted of something like a Star Wars laser-blaster battle, followed by a massive explosion. It was... loud and abrupt. I had been hacking on some code for several hours, and it was well into the early morning. Everything had been silent four hours. Suddenly a critical error occurred. I nearly jumped out of my skin. Remembering what it felt like still gives me the twitches.
Actually, substitute the ?s for loud beeps and strange letters flooding the screen, and you've got vi.
"vi has two modes -- the one that beeps, and the one that doesn't" -- Unknown
No copyright protection? So they are only releasing music that is in the public domain!?
I'm glad I'm not the only one who noticed this. How sad is it that in the music business, copyright lust is so pervasive that "copyright" is confused with attempts to abbridge fair use rights.
Or did the newspaper screw up, and mean to write "no copy protection"?
I prefer the term "copy restriction". This isn't about protecting copies, it's about restricting the ability to make copies. Just like "DRM" isn't about digital rights.
... the Amiga OS is a bit different from BeOS and OS/2 ... Amiga PCs were everywhere
Speaking of fans with a reality disconnect...
The Amiga never reached critical mass in the general computer market. (At least, not in the US. I've read it was a different story in Europe. But the US was really the only computer market the mattered, at the time.) Yes, it had niche penetration in a few segments, like video production. So did OS/2. Banks, in particular, loved it. I can't find hard figures for either, but random Internet blurbs seem to suggest OS/2 unit sales were roughly comparable to Amiga unit sales -- somewhere in the very low tens of millions.
I'm just chiming from my observations but wasn't OS/2 great for digital phone systems in the 90s and early 2000s before Linux products took the crown? This is of course well before VOIP.
Of course. Heck, OS/2 is still in use in a lot of ATMs, voice mail systems, and so on today, although it's being phased out due to lack of support. But there are ATM's in my area that I know are running OS/2. Our Nortel Norstar voice mail unit at work runs OS/2. In the 1980s and 1990s, OS/2 was very commonly used when you wanted to embed a general-purpose computer system into an "appliance" scenario. That's because it was, to a large extent, the only acceptable option.
Consider, it's 1990, and you want to build some kind of computerized "appliance". Maybe it's a voice mail system, or a bank ATM, or an electronic message board, or whatever. You want to use a general-purpose computer, because that lowers costs and enables third-party "layered product" options. GP hardware is cheaper, software development on a GP platform is easier (since the test target can be the same as the development environment), and there's a bigger third-party community to tap.
So what are your choices? Linux doesn't exist yet. Commercial Unix platforms (SGI/Irix, SunOS, HP-UX, DEC/Ultrix, etc.) are very expensive. BSD is tied up in legal wranglings, and support for commodity micros (IBM-PC, Mac) is limited at the time. DOS barely provides disk services and is useless for everything else, so you'd practically have to write your own OS. MS Windows runs on top of DOS and is basically just a GUI -- inappropriate for most embedded applications -- and has stability issues. Win NT doesn't exist yet. Xenix is a joke. SCO Unix is painfully clunky and hideously expensive.
And then there is OS/2. It's a preemptive multitasking, protected memory OS. It runs on IBM-PC-compatible computers, the platform with the biggest market presence and the most third-party support -- and also the cheapest hardware. It's from IBM, the single biggest name in computing. IBM and Microsoft both say it's the wave of the future. It's relatively inexpensive when purchased in bulk. Seems like a no brainer, right?
Obviously, looking back with 20/20 hindsight today, OS/2 seems like a strange choice, but at the time, it made perfect sense.