You're closer than most, but not completely right.
Moore's original observation was about the number of transistors on a chip. That means both transistor density and die size are relevant. Improved process technology enables larger chips, because yield depends on both the defects/area and the area/chip.
This guy concludes that StarOffice is a perfectly adequate replacement for MS Office. That's fine. But then he includes $8000 dollars in the budget for the Win2K solution to upgrade to the latest version of MS Office.
Since StarOffice runs under Windows, why is he charging the Microsoft OS for the cost of the Microsoft applications? His $10,000 savings is actually closer to $2,000, if StarOffice really is as good as Office2K.
I think there's some bias here.
Code built like houses, houses built to code
on
Software Aesthetics
·
· Score: 1
While there may be a lot of sloppy construction out there, there is a minimum standard for houses (construction codes) that is enforced during design (permit process) and construction (building inspectors).
Software has no equivalent, and it shows. Typically, no one reviews a software design before implementation begins. (Hell, you're lucky if a design exists before implementation begins!) There are no minimum standards for the quality of the components (e.g., programmers routinely create a new linked list implementation instead of using a standard library). There are very rarely inspections during the building process (go ahead, try to get code inspections adopted at your work site).
The result is that a sloppily built house, barring actual dishonesty by the builders or officials, is unlikely to collapse unexpectedly, leak uncontrollably, or explode without warning. Newly "finished" software programs, sadly, are likely to do all of those.
I agree that "People cut corners if they think they can get away with it." In the construction arena, we don't just wring our hands about it; we put mechanisms in place to deal with it. In software, we just look for excuses.
I think this is good research, but I have a complaint with the way the results are presented. There are two kinds of spam: mail from people you have some business with, and mail from strangers. The article downplays this difference, but it should not.
It's no surprise that people you do business with (even if it's just a free service) don't want to piss you off. They want your business (cash or eyeballs) and they won't get it if they send crap you don't want. They are seeking quality over quantity.
That's completely different from the true spammers, the people who buy and sell lists, use fake return addresses, open one-time ISP accounts for flooding, and almost often tell you that their mail complies with a years-dead US "law" on unsolicited email that never got out of committee.
I get "spam" from Amazon recommending CDs, DVDs and books I might want to buy based on my past purchases. I don't think of it as spam because I know that Amazon will stop sending it if I ask them to. Because it's infrequent and because I know that I can stop it if I want to, I don't mind it. That's the real difference between the two kinds of spam.
The original article leaves out a key part of the law, the part is that is most relevant. The law says:
Any person who knowingly threatens to use a weapon of
mass destruction, with the specific intent that the statement, made
verbally, in writing, or by means of an electronic communication
device, is to be taken as a threat....
Since the law requires intent to threaten, the state of mind of the defendent is material. Jokes that are not meant to be taken seriously do not violate this law.
Two questions:
Are we being bamboozled into thinking this law attacks legitimate free speech, when it doesn't?
Did the defense attempt to introduce "context" rely on on vague free-speech rights or the text of the statute?
There's stuff to worry about, but it isn't as cut-and-dried as it's being portrayed in the original posting.
All software should be written by the people who use it.
There's just one small problem--the corollary:
No software will be written for people who can't program.
I suspect that, for too many people, this is what they truly want in their heart of hearts. For all the talk about smashing the corporate hierarchy, too many hackers still believe that computers should be reserved for the knowledgeable, the initiated--the priesthood.
Let's face it. A lot of free software is like a ride at a theme-park with a sign that says, "You must be as tall as this sign to go on this ride," only instead it says, "You must be as good at programming as the author to use this software." Lusers need not apply.
As long as the vast majority of people who want to use computers are not programmers, software written for programmers will not make a dent in the market.
He tried his kids (8, 10) on the sample ballot. He gave them 20 seconds to indicate "how do you vote
for Gore". Then he asked them "how do you vote for Buchannan", and at this point, the 8-year-old
had to ask how you spell Buchannan. Both were able to pick the right dot.
Your friend is doing a very bad job of usability testing. Here's why:
He chose to test on people very different from the target users.
Why would you expect children to be confused by the same things that confuse adults?
His test focused attention on the area of potential confusion.
This means the subjects were primed to concentrate on one aspect of the task, rather than the whole task.
He did not ask the subjects to perform the task!
This is the most egregious failure. He asked the subjects how to perform the task instead of asking them to perform the task. This forces the subjects to reflect on the process, drastically altering their behavior.
If you ask my wife which exit to take from the freeway to get to our house, you'll never get the wrong answer. If you ask me which exit to take from the freeway to get to our house, you'll never get the wrong answer. If you ask me how to get to our house, you'll never get the wrong answer. Once in a while, however, I take the wrong exit!
Is there anything new that Linux has added, beyond the model? (Which it just borrowed from the FSF, anyway!) Yes! The aforementioned CODA is a good example.
According to the Coda documentation,
Coda was originally implemented on Mach 2.6 and has recently been ported to Linux, NetBSD and FreeBSD.
So, Linux didn't contribute anything to Coda except a means of distributing the work. Also, Coda is more than ten years old as an idea (the first paper is from 1987), which is in line with Pike's claim that research has been stagnant for ten years.
Come up with a good reason why Nokia should be able to trademark some beeps and a perfume company shouldn't be able to trademark its scent...
The difference between these two (and the reason that the tennis balls are more like Nokia than Chanel) is that, for perfumes, the scent is the product. Nokia or Intel could sell the same product using different trademarks. Chanel couldn't sell the same product using a different scent.
If you accept this argument, the important question would be, does the smell of the tennis ball make it a different product? I think the answer is yes--the smell isn't just identifying the maker, it's part of the product.
In effect, I'm arguing that this should not be eligible for trademark protection, but might be patentable. (That'll make me more popular on Slashdot!)
I worked with (not on) OpenDoc while I was at Apple, and the two biggest problems I could see were the learning curve and the oversold "cross-platform" nature.
The learning curve was so steep in part because OpenDoc was amazingly flexible. That flexibility made for many concepts with inadequate introductory documentation. Also, the OpenDoc developers adopted a strict "OpenDoc is not a framework" rule, which meant that they would supply no default behaviors at all. Every part-editor developer had to start from scratch and understand the full API in order to create a "hello world" part editor. The OpenDoc Development Framework eventually filled this gap, but it came too late.
The "cross-platform" nature of OpenDoc was a big disappointment to developers, because, while it abstracted out the event loop and the document storage facilities, it didn't include drawing. So, "cross-platform" part editors still needed massive ifdefs to do the stuff the user would see. Again, ODF eventually filled that gap, with recycled bits of the long-promised cross-platform "Bedrock" system co-developed with Symantec.
I believe that OpenDoc could have caught on with developers if it had been easier to turn existing code into editors, or if the cross-platform promise had been fulfilled from the outset.
One last thing. OpenDoc wasn't a failure at the time it was killed. When the NeXT crowd took over Apple, they loudly proclaimed, "We already have a component-based system," by which they meant NextStep. They apparently had no understanding whatsoever of the difference between a system of components that developers use to build programs, and a system of components that users use to build documents. One of the things they killed was a prototype reimplementation of OpenDoc in Java that worked surprisingly well--and might have made both technologies more exciting with a true cross-platform component system.
The closest thing to OpenDoc alive today is Netscape plug-ins. Sad.
Now we just need OpenInventor open sourced, and there will be a real chance of DirectX biting the dust. (Novices find it far easier to put together interactive 3D apps with a decent scene graph implementation).
An open-source alternative to Inventor is Quesa. Quesa implements the Quickdraw 3D API, which includes a nice hierarchical scene system.
A library represents everything which is proprietary and wrong with the information distribution of the world.
I think you may be undervaluing some aspects of the physical library that go beyond the mere organization of information. Libraries include a social aspect, for one. Having a place that's just for reading says something important about the value of information and education in our society. Also, encountering other people who take information seriously has a strong benefit.
In addition, the physical and logical organization of a library is powerful. We separate fiction from non-fiction (as best we can), which the net doesn't even attempt to do. We find related information nearby, but there's no search engine I've seen that understands how optics and quantum mechanics are "close" to each other. And, finally, we meet people who are interested in the same things we're interested in, which is a little hard to do with search-voyeur functions.
Finally, libraries have the physical persistence that bits lack. Perhaps, someday, there won't be such a thing as pages that disappear and servers that are recycled. Until then, you can be confident that sufficiently popular work was preserved in a library. And you won't have to worry about never being able to find the first version of something that's now in its twenty-third.
One last thing: serendipity. The library is likely to have "recent acquisitions" section, and a pile of books waiting to be reshelved. These allow you to discover things you didn't know you wanted to know.
Slashdot Mirror
You're closer than most, but not completely right.
Moore's original observation was about the number of transistors on a chip. That means both transistor density and die size are relevant. Improved process technology enables larger chips, because yield depends on both the defects/area and the area/chip.
Since StarOffice runs under Windows, why is he charging the Microsoft OS for the cost of the Microsoft applications? His $10,000 savings is actually closer to $2,000, if StarOffice really is as good as Office2K.
I think there's some bias here.
Software has no equivalent, and it shows. Typically, no one reviews a software design before implementation begins. (Hell, you're lucky if a design exists before implementation begins!) There are no minimum standards for the quality of the components (e.g., programmers routinely create a new linked list implementation instead of using a standard library). There are very rarely inspections during the building process (go ahead, try to get code inspections adopted at your work site).
The result is that a sloppily built house, barring actual dishonesty by the builders or officials, is unlikely to collapse unexpectedly, leak uncontrollably, or explode without warning. Newly "finished" software programs, sadly, are likely to do all of those.
I agree that "People cut corners if they think they can get away with it." In the construction arena, we don't just wring our hands about it; we put mechanisms in place to deal with it. In software, we just look for excuses.
It's no surprise that people you do business with (even if it's just a free service) don't want to piss you off. They want your business (cash or eyeballs) and they won't get it if they send crap you don't want. They are seeking quality over quantity.
That's completely different from the true spammers, the people who buy and sell lists, use fake return addresses, open one-time ISP accounts for flooding, and almost often tell you that their mail complies with a years-dead US "law" on unsolicited email that never got out of committee.
I get "spam" from Amazon recommending CDs, DVDs and books I might want to buy based on my past purchases. I don't think of it as spam because I know that Amazon will stop sending it if I ask them to. Because it's infrequent and because I know that I can stop it if I want to, I don't mind it. That's the real difference between the two kinds of spam.
Jeez, I hope your 6 year old understands that if he dials 911 on that phone he will be connected to an emergency operator.
Since the law requires intent to threaten, the state of mind of the defendent is material. Jokes that are not meant to be taken seriously do not violate this law.
Two questions:
There's stuff to worry about, but it isn't as cut-and-dried as it's being portrayed in the original posting.
I suspect that, for too many people, this is what they truly want in their heart of hearts. For all the talk about smashing the corporate hierarchy, too many hackers still believe that computers should be reserved for the knowledgeable, the initiated--the priesthood.
Let's face it. A lot of free software is like a ride at a theme-park with a sign that says, "You must be as tall as this sign to go on this ride," only instead it says, "You must be as good at programming as the author to use this software." Lusers need not apply.
As long as the vast majority of people who want to use computers are not programmers, software written for programmers will not make a dent in the market.
Why would you expect children to be confused by the same things that confuse adults?
This means the subjects were primed to concentrate on one aspect of the task, rather than the whole task.
This is the most egregious failure. He asked the subjects how to perform the task instead of asking them to perform the task. This forces the subjects to reflect on the process, drastically altering their behavior.
If you ask my wife which exit to take from the freeway to get to our house, you'll never get the wrong answer. If you ask me which exit to take from the freeway to get to our house, you'll never get the wrong answer. If you ask me how to get to our house, you'll never get the wrong answer. Once in a while, however, I take the wrong exit!
If you accept this argument, the important question would be, does the smell of the tennis ball make it a different product? I think the answer is yes--the smell isn't just identifying the maker, it's part of the product.
In effect, I'm arguing that this should not be eligible for trademark protection, but might be patentable. (That'll make me more popular on Slashdot!)
Nope. The only public evidence it ever happened is at the author's personal site.
The learning curve was so steep in part because OpenDoc was amazingly flexible. That flexibility made for many concepts with inadequate introductory documentation. Also, the OpenDoc developers adopted a strict "OpenDoc is not a framework" rule, which meant that they would supply no default behaviors at all. Every part-editor developer had to start from scratch and understand the full API in order to create a "hello world" part editor. The OpenDoc Development Framework eventually filled this gap, but it came too late.
The "cross-platform" nature of OpenDoc was a big disappointment to developers, because, while it abstracted out the event loop and the document storage facilities, it didn't include drawing. So, "cross-platform" part editors still needed massive ifdefs to do the stuff the user would see. Again, ODF eventually filled that gap, with recycled bits of the long-promised cross-platform "Bedrock" system co-developed with Symantec.
I believe that OpenDoc could have caught on with developers if it had been easier to turn existing code into editors, or if the cross-platform promise had been fulfilled from the outset.
One last thing. OpenDoc wasn't a failure at the time it was killed. When the NeXT crowd took over Apple, they loudly proclaimed, "We already have a component-based system," by which they meant NextStep. They apparently had no understanding whatsoever of the difference between a system of components that developers use to build programs, and a system of components that users use to build documents. One of the things they killed was a prototype reimplementation of OpenDoc in Java that worked surprisingly well--and might have made both technologies more exciting with a true cross-platform component system.
The closest thing to OpenDoc alive today is Netscape plug-ins. Sad.
An open-source alternative to Inventor is Quesa. Quesa implements the Quickdraw 3D API, which includes a nice hierarchical scene system.
I think you may be undervaluing some aspects of the physical library that go beyond the mere organization of information. Libraries include a social aspect, for one. Having a place that's just for reading says something important about the value of information and education in our society. Also, encountering other people who take information seriously has a strong benefit.
In addition, the physical and logical organization of a library is powerful. We separate fiction from non-fiction (as best we can), which the net doesn't even attempt to do. We find related information nearby, but there's no search engine I've seen that understands how optics and quantum mechanics are "close" to each other. And, finally, we meet people who are interested in the same things we're interested in, which is a little hard to do with search-voyeur functions.
Finally, libraries have the physical persistence that bits lack. Perhaps, someday, there won't be such a thing as pages that disappear and servers that are recycled. Until then, you can be confident that sufficiently popular work was preserved in a library. And you won't have to worry about never being able to find the first version of something that's now in its twenty-third.
One last thing: serendipity. The library is likely to have "recent acquisitions" section, and a pile of books waiting to be reshelved. These allow you to discover things you didn't know you wanted to know.