Oddly, U.S. Steel didn't have a strike until after Carnegie stepped down. I don't know if that pertains to how he treated his workers. He was much more interested in being a bastard to his competitors.
I don't think so. D^b is harmonically different, but in the diatonic system they are the same. If you play a brass (harmonic) instrument, you can see this for yourself when a harmonic D^b is actually higher than a C^#.
It's pretty well known that Microsoft Research has little to do with Microsoft, aside from the fact that Sponsor #1 is Microsoft. They work on tons of stuff there that is never incorporated into the Borg's products. My dad calls MSR a "watch charm". My opinion is that Gates was a little bit worried about the fact that there was very little R&D going on at Microsoft when he was asked to say that his company is an innovator. Hence, he needed to show that he had a well funded and well stocked research agency. They've got some great personnel there.
Re:It's just that fewer girls are religions loons
on
Want More Geek Chicks?
·
· Score: 1
begin 644 rant
It could be that men simply make better geeks, perhaps they are happier with the very stark right/wrong working/not-working nature of computers.
I'm sorry, are you crazy? Can anyone here tell me that he or she writes only code that is starkly right or wrong? If so, you have never submitted a defect? If you have, then it wasn't starkly right.
I don't think that the solution involves making programming cuddlier, but making the whole process less retarded will probably help. Many women are getting into computer engineering, and many are in chemistry, math, etc. Women don't specifically have a problem with analysis. They do get fed up with the things mentioned in the article: sniffing packets, banging heads, poring over a core file, for a week at a time. Debug, test, debug, test,... Come on, if this is in your nature, I don't want you working for me. Women, I'm sure, would be much better at methodically reviewing their code as they write it, dotting all the Is and crossing all the Ts, prototyping instead of correcting a broken program, and all those other good things that make the process more efficient. It is our responsibility to not encourage women to learn the bad, male habits that go along with being a geek. I'd say women are also more likely to evaluate suggestions about improvement. "Alpha" geeks are more likely to spend all of their time tweaking a routine that is not at the center of an efficiency problem. Perhaps the technology field simply needs fewer of these geeks, and more of the ones who are more pragmatic, the ones who think that programming is the expression of an idea in a language, not a goal in itself.
No, the purpose of copyright in the constitution is to protect artists. Science and technology are protected by the limited monopolies covered by patents, but artists are provided with a very long monopoly because of the durability of their works and the likelihood that their opportunity cost of producing them will not usually be recovered in a few years. The original copyright was for around 50 years.
Software has now presented us with a problem, where it would be more efficient if software lost its copyright within a few years, like 5 or 6. I think that, in many cases, people would have preferred to modify FoxPro 2.6 to suit their needs rather than figure out what to do as dos gets slower and less reliable on their windows-only machines. Software companies either make an economic profit within a few years or they do not make it at all; Moore's law dictates this.
Instead of telling us about H1-B visas and protecting monopolies, the "technology savvy" presidential candidates should be trying to win votes by emending copyright and patent law for the software industry.
What's the point of "opening up the standard" if there is no reference implementation. Closed source does not a reference implementation make. For the interfaces to be specified in a usable way, they must be normative, and not simply descriptive. This would require formal specification, either through example code or the use of a formal specification technique, and then compliance would be decided by ensuring the correctness of the behavior.
This would have the effect of requiring microsoft to either (1) open up some of the internals of one of its current operating systems or (2) provide a "naive" yet correct implementation of everything in windows. Either way is fine for me. What is not satisfactory is the idea of just publishing the MSDN documentation and calling that an interface specification. It's useful information, but it is not a spec.
I am not so sure that microsoft would be able to give real specifications of what all of their APIs actually do without releasing their source code. Just look at their bug lists. They have no idea what's going on in there anymore.
The main difference between the salaried worker and the hourly worker is that the salaried one usually believes he or she is a professional and not a tradesperson/artesan. This is a common (mis)belief of the programming art, as well as engineers, managers, etc.
I have the fortune of knowing various people involved in telecom, such as troubleshooters, network designers, etc., mostly working for Bell Atlantic. These people work hard to avoid promotion, where they would be given management responsibilities and a salary instead of their hourly wage. They seem to like the fact that they can put in extra hours in November and then have a sizable paycheck and the flexibility to take extra time off for the Christmas season.
I have also worked where everyone was on salary, and there was a sad little time compensation package that never panned out to good stuff. If you put in overtime, you would receive "comp time", or paid hours off, which you were culturally expected not to take, especially after you racked up several weeks of it.
I personally liked having a consistent paycheck. It made planning easier, and my hours were erratic to say the least. I also have trouble remembering to fill out my timecards.
In general, I think money is the most limiting factor of business. To answer your question, I think that you may do well to provide both options, and just notify your employees that they have choices. Or, better, you could sit your employees down in a room and have them design the compensation package and its options. I'm sure that the result would be reasonable.
No, I think it's more if he's using some sort of first-amendment case solely for self-promotion then that is bad. Aside from that, you have the right to scare people about anything. If he wants to scare us about our rights, he doesn't need a y2k video.
I don't think it's a career-ending move for the agents either, if it is true. It's just a dumb move.
The Times article mentioned JP's run-in with Pitt CIS. Although I am not affiliated with CIS, I do remember this hoopla.
JP was in a lucky position of being among the first Pitt students to have a dedicated connection in his dorm room. He set up his Anti-Online web page, which at that time contained a little bit of information about Windows insecurity, nothing original, and sought advertiser support and link sharing. Eventually, he had users downloading software from his machine, at Pitt's expense, and advertising revenue from activity at his site.
Understandably, the University noticed this and asked him to stop. Dorm rooms weren't meant to serve commercial sites, in their opinion. They took his connection down because it actually violated the usage code. He claimed it was an important resource. CERT, they said, is right down the street.
Through heat from a friend of his at the Pitt News, there was a commotion made about it and the uninformed urged Pitt to put it back up. We had to read editorial after editorial written by his friend, as though the rest of the PN actually cared. He then dropped out of school with venture funding.
During this commotion he tried to show how punk he really was by demonstrating that there were weaknesses in Pitt's non-production NT system. Pitt ignored these actions, but they didn't have to. The things he demonstrated were things that have been known before NT4 was released. They were things that any respectable NT administrator, especially CIS, would have secured in a production machine. It is highly doubtful in my mind that JP possessed any real knowledge of computer security, he only knew of already-known security exploits.
At best, he demonstrated to Pitt that there are punks who want to prove a point, and Pitt has added superfluous security enhancements just to be on the careful side.
My question for JP is more along the lines of: Do you really think that you're doing any real service, or is the site just ego-perpetuation?
Let me begin by applauding your efforts in controlling the process at your company. I have worked at a number of places that did not believe that there was any engineering in software, and so I know that it can be hard. Let me give you one important tip: never make anyone feel that you think you are better than them. If you do so, it makes it hard to encourage their own improvement.
It's important to be careful with mixing means and ends. Process documentation is one small step toward quality. If it is treated as a solution, the end will be a process document. I think you're right on in saying that engineering is only 10% specialized knowledge. But by calling the rest common sense you could encourage yourself to ignore mistakes in your reasoning. Common sense is non-analytical. It is experience-driven. A bad process is usually founded in common sense, and it is common sense that has made people believe that testing means quality, documentation is expensive, etc.
Edwards Deming said that the problem is caused by bad experiences with improvement ideas that cause the same mistakes to be repeated ad infinitum. With a more scientific study of the workings of process improvements, it is possible to avoid the mechanisms that contribute to the vicious cycle of mediocre processes.
The other 90% of the knowledge that an engineer needs is theoretical, and the engineer has to create that knowledge for himself or herself. At any point in a process, the engineer should be able to make a theory about improving that point. The priority of testing these theories is based on critical-path studies like Gantt charts, cause-and-effect diagrams, and pareto rankings.
In software, the SEI has designated configuration management as one of the first things that a company will have to work on. This view is aggregate, not company-specific. It may turn out that, for your company, requirements management is the most important concern. It is the responsibility of the company to make this ranking.
Documentation is a good place to start, but you should encourage your manager to dedicate space in the budget for it. After a while, the money spent on improvements early in the process can be recovered from cuts later on in the process. Those cuts, of course, should be reflected as more improvement. If you are working feverishly on documentation in extra hours, this would be a signal to a good boss that your time spent elsewhere should be redistributed. Unfortunately, to a bad manager it seems like a good reason to call documentation a failure.
In order to have a really good process improvement program, you have to have start with at least a cursory understanding of:
System theory
Epistemology
Psychology
Statistics and Variation
Most organizations attempting process improvement concentrate on the last item, but the whole bag is required. I'd say the biggest mistake is to believe you know what's wrong and how to fix it, simply because you've identified that you have a problem. Some people don't take this approach, and they say, "I don't know how to fix it, so I'll read this book and we'll do that."
Books about specific process improvements are not based on any sort of universal truth. They are merely the results of case studies, and because some cases are sometimes the same, they have effectiveness in other projects. What makes some books better than others is an approach that sneaks in practices of personal theorization and evaluation for the reader.
But even these books don't go far enough. Think about where revolutionary software practices come from. The Cleanroom environment started as a mere postulate, and IBM let Dr. Mills exercise the practice on a medium-size project. Mills dutifully collected data demonstrating the success and failure of his method, and proposed a better version for the next project. It wasn't one big brain fart that gave birth to a complete set of practices, rather it was an exercise of science.
Your post tells me that you can see past the all-or-nothing concept perpetuated by methodology sages. But there were a few things that worry me, specifically:
Note that this doesn't strictly have to apply only to commercial software, but open source projects typically don't have the money to go out and buy the fancy stuff.
Do you believe that the purchase of a $20,000 case tool would make a methodology work even if no one understands the system? I think that the OSS guys, if they formed quality circles and gave each other more process support than "RTFM", could develop immensely good processes compared to the status quo in both open and corporate software. It wouldn't require consultants and tools, and if they found that a tool would be worthwhile, it wouldn't take very long to build it. OSS is, after all, very good at writing programs for programmers.:) I think, though, much could be learned from the Squeak community where the OSS process is very collaborative and people don't work on non-trivial things without telling other people. In the Linux Community, there seems to be a big drive to be considered a wizard (or a Linus). In squeak, you'll be noticed if you just produce a constant stream of bugfixes and minor enhancements.
There is no optimal operating system. I have been a major fan of various ones, starting with C64/1541, all the way through the gamut (you name it, I can say something good about it), until I started to think outside the box. There is no consumer OS that has been designed for the customer. MacOS used to be, but the link is becoming obscure now. There are so many operating system technologies, but the market is 20 yrs behind research, excluding only the log-structured filesystem. I don't see Linux becoming the great consumer OS. It's not in the genes. I don't see Microsoft or Apple doing it anymore either. They are too concerned with eye candy. If a revolution is to happen, someone is going to have to start observing the consumer.
Apple forced Digital Research (remember CP/M?) to stop producing GEM for the PC. Before that suit, some prominent companies were supporting GEM with products like Ventura Publisher. This is part of the reason for Ventura's initial success in the PC market over Aldus, who put Pagemaker on Win 2.0--Ventura's choice of interface was better written, faster, and easier to use. Later, Ventura had to play a catch-up game with Aldus who bet their DTP business on the Macintosh, a good move at the time. Adobe won by monopolizing DTP.:) When Apple won the suit, we saw multiple sufferings, including Atari's ST line, the original GEM, and the proliferation of Windows, the biggest cause of frustration since [flamebait] Unix.
The "working computer": the Mac II had a very innovatively designed hardware system where you could put any board in and it'd work almost like magic. You could attach any external drive and it'd work. Any monitor would carry with it the necessary information to properly configure with the system, somewhere near 72 dpi, no questions asked. Mac users often called this "plug 'n' play" or "PnP", which were somehow trademarked. The way apple designed their systems was also remarkable. Steve Jobs demonstrated that he could deconstruct and rebuild Mac IIcx in five minutes using one screwdriver. Ten years later, I was still getting bitten by PCs I had to repair. Choosing Nubus with its Euro-DIN connectors that required no stabilizing screw was an example of this commitment to good design. Look at PCI and you'll see that they're still making the same mistakes.
Also, it gets annoying when computers always talk to their users in movies with that oh so pleasant female voice.
The female voice (used by informational computers, of course) is a technical accuracy. Air Force studies found that people prefer to listen to information from a pleasant female voice rather than a pleasant male voice and that they comprehend better as well. Male voices were better for human command and control. There was an interesting PBS show, Nova perhaps, that discussed the tech, including the computers, used by Top Gun.
The cold female voice also sounds more sadistic when the computer "goes awry", like Mother in Alien.
My question is whether the male grade school teachers have lower listening comprehension averages for their classes' Stanford tests. It would be interesting to find out.
What I hate is that scientifically-minded high school girls are encouraged by their teachers and guidance counselors to enter engineering programs. I'm not sure why this is, but engineering people tend to have rather specific life goals, and most engineering washouts simply weren't engineers. (A little education in liberal arts is a litmus test. Non-engineers lose their drive after taking political theory or philosophy.) I'm not so sure that graduating senior girls actually see the engineering profession as their lifestyle, and the often wash out of hard science completely. If the damn teachers would just realize that a successful female scientist is equally as impressive as a successful female engineer, the college-level courses could have more even populations.
I disagree. Moore's law has made it possible to design production embedded systems from COTS components including a real-time operating system, various special libraries, and advanced chips. This explains the success of eCos, pSos, VxWorks, etc. Like in all systems, embedded systems are starting to suffer the costs of completely dedicated design, and using proven components seriously reduces the chances of selling broken goods.
Dorf, Richard C.
Introduction to Computers and Computer Science. (San Francisco: Boyd & Fraser Publishing Co.) 1972
It provides an interesting discussion of the early computers, and includes many interesting pictures. My favorites are the pics of components, which demonstrate that organization is a virtue, and the photographs of IBM installations, complete with attractive models working intelligently at the consoles. The photos demonstrate the IBM "component" dress code, subtlely revealing the corporate culture at the itty-bitty machine company.
I'm not going to reiterate all of it, but Selmer Bringsjord has written and collected a lot of interesting information about robots, Turing Tests, and the state of the art.
I got my first Dvorak keyboard by taking a sturdy, old IBM PS/2 keyboard and changing the replaceable caps. Total investment: $15. Number of annoying Windows keys: 0.
It's not just a better keyboard--it's an impenetrable security device.:)
There was an NYT article like 6 mo. ago about the behavior of ants simulating cellular automata. When the ants approach an obstacle, like a gap between two important branches of trees, they will actually evolve a bridge using simple where-should-I-be-in-relation-to-this-ant tactics. When the bridge is formed, the rest of the ants march over the bridge and then the bridge collects itself back on the other tree.
Cellular automata with genetically-programmed instructions could prove to be a very important field in ten, twenty years.
I wish I could find the article, but I don't quite have the time.
Slashdot Mirror
Oddly, U.S. Steel didn't have a strike until after Carnegie stepped down. I don't know if that pertains to how he treated his workers. He was much more interested in being a bastard to his competitors.
I don't think so. D^b is harmonically different, but in the diatonic system they are the same. If you play a brass (harmonic) instrument, you can see this for yourself when a harmonic D^b is actually higher than a C^#.
C-sharp has seven sharps in the key signature
It's pretty well known that Microsoft Research has little to do with Microsoft, aside from the fact that Sponsor #1 is Microsoft. They work on tons of stuff there that is never incorporated into the Borg's products. My dad calls MSR a "watch charm". My opinion is that Gates was a little bit worried about the fact that there was very little R&D going on at Microsoft when he was asked to say that his company is an innovator. Hence, he needed to show that he had a well funded and well stocked research agency. They've got some great personnel there.
a watt-sec is a joule.
I don't think that the solution involves making programming cuddlier, but making the whole process less retarded will probably help. Many women are getting into computer engineering, and many are in chemistry, math, etc. Women don't specifically have a problem with analysis. They do get fed up with the things mentioned in the article: sniffing packets, banging heads, poring over a core file, for a week at a time. Debug, test, debug, test,... Come on, if this is in your nature, I don't want you working for me. Women, I'm sure, would be much better at methodically reviewing their code as they write it, dotting all the Is and crossing all the Ts, prototyping instead of correcting a broken program, and all those other good things that make the process more efficient. It is our responsibility to not encourage women to learn the bad, male habits that go along with being a geek. I'd say women are also more likely to evaluate suggestions about improvement. "Alpha" geeks are more likely to spend all of their time tweaking a routine that is not at the center of an efficiency problem. Perhaps the technology field simply needs fewer of these geeks, and more of the ones who are more pragmatic, the ones who think that programming is the expression of an idea in a language, not a goal in itself.
No, the purpose of copyright in the constitution is to protect artists. Science and technology are protected by the limited monopolies covered by patents, but artists are provided with a very long monopoly because of the durability of their works and the likelihood that their opportunity cost of producing them will not usually be recovered in a few years. The original copyright was for around 50 years.
Software has now presented us with a problem, where it would be more efficient if software lost its copyright within a few years, like 5 or 6. I think that, in many cases, people would have preferred to modify FoxPro 2.6 to suit their needs rather than figure out what to do as dos gets slower and less reliable on their windows-only machines. Software companies either make an economic profit within a few years or they do not make it at all; Moore's law dictates this.
Instead of telling us about H1-B visas and protecting monopolies, the "technology savvy" presidential candidates should be trying to win votes by emending copyright and patent law for the software industry.
This would have the effect of requiring microsoft to either (1) open up some of the internals of one of its current operating systems or (2) provide a "naive" yet correct implementation of everything in windows. Either way is fine for me. What is not satisfactory is the idea of just publishing the MSDN documentation and calling that an interface specification. It's useful information, but it is not a spec.
I am not so sure that microsoft would be able to give real specifications of what all of their APIs actually do without releasing their source code. Just look at their bug lists. They have no idea what's going on in there anymore.
The main difference between the salaried worker and the hourly worker is that the salaried one usually believes he or she is a professional and not a tradesperson/artesan. This is a common (mis)belief of the programming art, as well as engineers, managers, etc.
I have the fortune of knowing various people involved in telecom, such as troubleshooters, network designers, etc., mostly working for Bell Atlantic. These people work hard to avoid promotion, where they would be given management responsibilities and a salary instead of their hourly wage. They seem to like the fact that they can put in extra hours in November and then have a sizable paycheck and the flexibility to take extra time off for the Christmas season.
I have also worked where everyone was on salary, and there was a sad little time compensation package that never panned out to good stuff. If you put in overtime, you would receive "comp time", or paid hours off, which you were culturally expected not to take, especially after you racked up several weeks of it.
I personally liked having a consistent paycheck. It made planning easier, and my hours were erratic to say the least. I also have trouble remembering to fill out my timecards.
In general, I think money is the most limiting factor of business. To answer your question, I think that you may do well to provide both options, and just notify your employees that they have choices. Or, better, you could sit your employees down in a room and have them design the compensation package and its options. I'm sure that the result would be reasonable.
No, I think it's more if he's using some sort of first-amendment case solely for self-promotion then that is bad. Aside from that, you have the right to scare people about anything. If he wants to scare us about our rights, he doesn't need a y2k video.
I don't think it's a career-ending move for the agents either, if it is true. It's just a dumb move.
Deep Blue II was a very elegant hack, incorporating a wide variety of technologies for one stupid little purpose.
-John
The Times article mentioned JP's run-in with Pitt CIS. Although I am not affiliated with CIS, I do remember this hoopla.
JP was in a lucky position of being among the first Pitt students to have a dedicated connection in his dorm room. He set up his Anti-Online web page, which at that time contained a little bit of information about Windows insecurity, nothing original, and sought advertiser support and link sharing. Eventually, he had users downloading software from his machine, at Pitt's expense, and advertising revenue from activity at his site.
Understandably, the University noticed this and asked him to stop. Dorm rooms weren't meant to serve commercial sites, in their opinion. They took his connection down because it actually violated the usage code. He claimed it was an important resource. CERT, they said, is right down the street.
Through heat from a friend of his at the Pitt News, there was a commotion made about it and the uninformed urged Pitt to put it back up. We had to read editorial after editorial written by his friend, as though the rest of the PN actually cared. He then dropped out of school with venture funding.
During this commotion he tried to show how punk he really was by demonstrating that there were weaknesses in Pitt's non-production NT system. Pitt ignored these actions, but they didn't have to. The things he demonstrated were things that have been known before NT4 was released. They were things that any respectable NT administrator, especially CIS, would have secured in a production machine. It is highly doubtful in my mind that JP possessed any real knowledge of computer security, he only knew of already-known security exploits.
At best, he demonstrated to Pitt that there are punks who want to prove a point, and Pitt has added superfluous security enhancements just to be on the careful side.
My question for JP is more along the lines of: Do you really think that you're doing any real service, or is the site just ego-perpetuation?
Let me begin by applauding your efforts in controlling the process at your company. I have worked at a number of places that did not believe that there was any engineering in software, and so I know that it can be hard. Let me give you one important tip: never make anyone feel that you think you are better than them. If you do so, it makes it hard to encourage their own improvement.
It's important to be careful with mixing means and ends. Process documentation is one small step toward quality. If it is treated as a solution, the end will be a process document. I think you're right on in saying that engineering is only 10% specialized knowledge. But by calling the rest common sense you could encourage yourself to ignore mistakes in your reasoning. Common sense is non-analytical. It is experience-driven. A bad process is usually founded in common sense, and it is common sense that has made people believe that testing means quality, documentation is expensive, etc.
Edwards Deming said that the problem is caused by bad experiences with improvement ideas that cause the same mistakes to be repeated ad infinitum. With a more scientific study of the workings of process improvements, it is possible to avoid the mechanisms that contribute to the vicious cycle of mediocre processes.
The other 90% of the knowledge that an engineer needs is theoretical, and the engineer has to create that knowledge for himself or herself. At any point in a process, the engineer should be able to make a theory about improving that point. The priority of testing these theories is based on critical-path studies like Gantt charts, cause-and-effect diagrams, and pareto rankings.
In software, the SEI has designated configuration management as one of the first things that a company will have to work on. This view is aggregate, not company-specific. It may turn out that, for your company, requirements management is the most important concern. It is the responsibility of the company to make this ranking.
Documentation is a good place to start, but you should encourage your manager to dedicate space in the budget for it. After a while, the money spent on improvements early in the process can be recovered from cuts later on in the process. Those cuts, of course, should be reflected as more improvement. If you are working feverishly on documentation in extra hours, this would be a signal to a good boss that your time spent elsewhere should be redistributed. Unfortunately, to a bad manager it seems like a good reason to call documentation a failure.
Metaphysics? It reads like pop psychology to me. Metaphysics is very much different.
In order to have a really good process improvement program, you have to have start with at least a cursory understanding of:
Most organizations attempting process improvement concentrate on the last item, but the whole bag is required. I'd say the biggest mistake is to believe you know what's wrong and how to fix it, simply because you've identified that you have a problem. Some people don't take this approach, and they say, "I don't know how to fix it, so I'll read this book and we'll do that."
Books about specific process improvements are not based on any sort of universal truth. They are merely the results of case studies, and because some cases are sometimes the same, they have effectiveness in other projects. What makes some books better than others is an approach that sneaks in practices of personal theorization and evaluation for the reader.
But even these books don't go far enough. Think about where revolutionary software practices come from. The Cleanroom environment started as a mere postulate, and IBM let Dr. Mills exercise the practice on a medium-size project. Mills dutifully collected data demonstrating the success and failure of his method, and proposed a better version for the next project. It wasn't one big brain fart that gave birth to a complete set of practices, rather it was an exercise of science.
Your post tells me that you can see past the all-or-nothing concept perpetuated by methodology sages. But there were a few things that worry me, specifically:
Do you believe that the purchase of a $20,000 case tool would make a methodology work even if no one understands the system? I think that the OSS guys, if they formed quality circles and gave each other more process support than "RTFM", could develop immensely good processes compared to the status quo in both open and corporate software. It wouldn't require consultants and tools, and if they found that a tool would be worthwhile, it wouldn't take very long to build it. OSS is, after all, very good at writing programs for programmers. :) I think, though, much could be learned from the Squeak community where the OSS process is very collaborative and people don't work on non-trivial things without telling other people. In the Linux Community, there seems to be a big drive to be considered a wizard (or a Linus). In squeak, you'll be noticed if you just produce a constant stream of bugfixes and minor enhancements.
There is no optimal operating system. I have been a major fan of various ones, starting with C64/1541, all the way through the gamut (you name it, I can say something good about it), until I started to think outside the box. There is no consumer OS that has been designed for the customer. MacOS used to be, but the link is becoming obscure now. There are so many operating system technologies, but the market is 20 yrs behind research, excluding only the log-structured filesystem. I don't see Linux becoming the great consumer OS. It's not in the genes. I don't see Microsoft or Apple doing it anymore either. They are too concerned with eye candy. If a revolution is to happen, someone is going to have to start observing the consumer.
Apple forced Digital Research (remember CP/M?) to stop producing GEM for the PC. Before that suit, some prominent companies were supporting GEM with products like Ventura Publisher. This is part of the reason for Ventura's initial success in the PC market over Aldus, who put Pagemaker on Win 2.0--Ventura's choice of interface was better written, faster, and easier to use. Later, Ventura had to play a catch-up game with Aldus who bet their DTP business on the Macintosh, a good move at the time. Adobe won by monopolizing DTP. :) When Apple won the suit, we saw multiple sufferings, including Atari's ST line, the original GEM, and the proliferation of Windows, the biggest cause of frustration since [flamebait] Unix.
The "working computer": the Mac II had a very innovatively designed hardware system where you could put any board in and it'd work almost like magic. You could attach any external drive and it'd work. Any monitor would carry with it the necessary information to properly configure with the system, somewhere near 72 dpi, no questions asked. Mac users often called this "plug 'n' play" or "PnP", which were somehow trademarked. The way apple designed their systems was also remarkable. Steve Jobs demonstrated that he could deconstruct and rebuild Mac IIcx in five minutes using one screwdriver. Ten years later, I was still getting bitten by PCs I had to repair. Choosing Nubus with its Euro-DIN connectors that required no stabilizing screw was an example of this commitment to good design. Look at PCI and you'll see that they're still making the same mistakes.
Also, it gets annoying when computers always talk to their users in movies with that oh so pleasant female voice.
The female voice (used by informational computers, of course) is a technical accuracy. Air Force studies found that people prefer to listen to information from a pleasant female voice rather than a pleasant male voice and that they comprehend better as well. Male voices were better for human command and control. There was an interesting PBS show, Nova perhaps, that discussed the tech, including the computers, used by Top Gun.
The cold female voice also sounds more sadistic when the computer "goes awry", like Mother in Alien.
My question is whether the male grade school teachers have lower listening comprehension averages for their classes' Stanford tests. It would be interesting to find out.
What I hate is that scientifically-minded high school girls are encouraged by their teachers and guidance counselors to enter engineering programs. I'm not sure why this is, but engineering people tend to have rather specific life goals, and most engineering washouts simply weren't engineers. (A little education in liberal arts is a litmus test. Non-engineers lose their drive after taking political theory or philosophy.) I'm not so sure that graduating senior girls actually see the engineering profession as their lifestyle, and the often wash out of hard science completely. If the damn teachers would just realize that a successful female scientist is equally as impressive as a successful female engineer, the college-level courses could have more even populations.
I disagree. Moore's law has made it possible to design production embedded systems from COTS components including a real-time operating system, various special libraries, and advanced chips. This explains the success of eCos, pSos, VxWorks, etc. Like in all systems, embedded systems are starting to suffer the costs of completely dedicated design, and using proven components seriously reduces the chances of selling broken goods.
One of my favorites has been
It provides an interesting discussion of the early computers, and includes many interesting pictures. My favorites are the pics of components, which demonstrate that organization is a virtue, and the photographs of IBM installations, complete with attractive models working intelligently at the consoles. The photos demonstrate the IBM "component" dress code, subtlely revealing the corporate culture at the itty-bitty machine company.
I'm not going to reiterate all of it, but Selmer Bringsjord has written and collected a lot of interesting information about robots, Turing Tests, and the state of the art.
I got my first Dvorak keyboard by taking a sturdy, old IBM PS/2 keyboard and changing the replaceable caps. Total investment: $15. Number of annoying Windows keys: 0.
It's not just a better keyboard--it's an impenetrable security device. :)
There was an NYT article like 6 mo. ago about the behavior of ants simulating cellular automata. When the ants approach an obstacle, like a gap between two important branches of trees, they will actually evolve a bridge using simple where-should-I-be-in-relation-to-this-ant tactics. When the bridge is formed, the rest of the ants march over the bridge and then the bridge collects itself back on the other tree.
Cellular automata with genetically-programmed instructions could prove to be a very important field in ten, twenty years.
I wish I could find the article, but I don't quite have the time.