As you say, Dvorak promotes some runs like th, sh, wh - so why not extend to promote runs longer than two?
A rough argument would be that to get longer runs, you would have to include both consonants and vowels in the same run, which would tend to violate the principle of putting vowels on one side, and common consonants on the other. I believe that without that, you will end up with many words that are awkward (non-run) one-hand combinations.
Also, English isn't that non-random. Ie, it is inevitable that optimizing for longer runs wins for fewer words.
You're right that I don't have evidence, but I have a very strong feeling that there are too many constraints for you to design a keyboard with long one-hand runs, without losing badly in other areas.
In general, my style tends towards "smoothing out" the stretching of fingers and movement of the wrists by predicting the required positions of each hand and moving progressively towards an optimum position for it. I agree that this is unusual, but I think that most people could learn this given time.
You may be right, but I have a gut aversion to any technique that requires more motion and dexterity. When I typed qwerty, I had a self-taught style (that I can't remember in any detail). When I learned Dvorak, I did it by the book, and now have pretty orthodox touch-typing technique. I feel distinctly more comfortable now when I type, and given all the horror stories about typing injuries, that factor ranks very high for me.
"Configuration management" is an industry term for precisely what this product does, which is product revision control, and not source file revision control.
It's still a stupid term. Tell me, where is the configuration that is being managed? Industries have lots of meaningless jargon--doesn't mean us sane folks have to parrot it. "Revision control" works just fine and makes sense.
Liebowitz's article does not debunk anything. It merely gives evidence that some studies were flawed, puts forward its own flawed and ambiguous studies, and entirely ignores the compelling non-empirical arguments for Dvorak's superiority. (Do you not believe anything that has not been established by studies?) Let's not even mention the fact that Liebowitz has a strong prejudice about market efficiency to support (oops, mentioned it!).
Marcus Brooks has a longer rebuttal. I actually do not find it totally satisfactory either, but it should certainly make clear that Liebowitz has little credibility.
I think you have a combination of unusual motor skills and incorrect
reasoning.
Alternating between hands each key is the absolute hardest action to
do quickly. If you have a piano piece which has a segment like this (there's
a few famous pieces like this) it'll either be relatively slow or you'll be
practising it for months. Runs of keys in the same hand are far faster. I'd
say about 5 times faster.
Runs on the same hand are faster than alternation, sure. But alternation is
much faster than arbitrary motions of one hand. Given the variety in
English, optimizing for long runs will win on a very few words, and screw up
the layout for everything else. I challenge you to refute this.
Dvorak does follow this principle for some short runs: th,
sh, wh, rt, nd, and ng are all
nice combinations that move in the pinky-to-index direction on one hand.
But gymnastics with one hand will kill most typists, and alternation is
about avoiding this.
Why are hands not allowed to move left or right? If you have 8 keys to
press, all of which reside to the right of the 'D' key, I move my left hand
right a few keys! What's the point in keeping it where it is and making your
right hand do more work and even stretch to reach the central columns?
This requires incredible foresight and motor skills. For most people, the
key to finding a key quickly is knowing its position relative to a fixed
reference.
Why must all 4 fingers rest on the same row? For a start, your fingers
aren't even the same length! Place your hands naturally on a table, and
compare to where the keys would be. You'll find that they would have been on
"a,w,e,f" and "j,i,o,;". Somewhat luckily, qwerty keyboards have all of the
vowels except "u" under these keys. There's no reason you can't have your
fingers over arbitrary rows. With a bit of hand strength building, this is
easy.
I might agree about the natural position of the fingers (though I suspect
the natural position is actually somewhere in-between asdf and
awef). But the idea that each finger can be on its own row is just
wrong for normal hands. Ask some normal people to try it, and they'll tell
you.
Moving up and down rows is only slow if you "float" above the keyboard
(not resting your wrist on the table/rest) and move your entire arms back
and forward. This would be an awful technique to use and I'd suspect it
would lead to strain problems very quickly. Stretching your fingers forward
and backwards is fast. And with the previous point, this is mostly
irrelevant anyway.
Resting wrists on the table, and stretching fingers without moving the hand,
are both generally recognized as major contributors to CTS and other typing
injuries. When I learned piano, I was definitely taught to keep my wrists
up and move my hands with my fingers (eg, when reaching for a black key, the
hand should advance).
So, why aren't we allowed to use thumbs for typing normal keys?
It's perfect for hitting keys on the bottom row when all the others have
been tied up. Just then, I typed "up." with right hand "2-4-1" (where 1 is
thumb, 5 is little). Why? Because when fingers 2,4 have been tied up on the
top row, the most convenient finger to use is my thumb. Try it.
I tried it. It's a disaster for me. Typing up with 2-4 is hard
enough, requiring an awkward stretch of the ring finger. Getting to. with the thumb requires me to twist my whole arm in addition to
contorting my hand, and hitting a target after such a long travel with such
a fat digit is quite unreliable. Plus, this leaves my hand totally out of
position for any subsequent typing.
I would think that given your claim that different fingers can easily go
to different rows, you would prefer 2-5-4.
My theory about carpal tunnel and other typing related injuries is that
"touch typing" is actually to blame. It encourages stiffening of the wrists
and hands, discourages stretching, and generally leaves your hands as weak
as they were before you started typing.
I'm not a doctor, but this flies in the face of all the medical advice I've
read. What you call "stiffening" is what most people would call making
gentle, comfortable motions. What you call "stretching" is what most people
would call excessive and unnatural motion. What you call "leaving weak" is
what most people would call avoiding strain. Maybe your hands can take it,
but most people's can't.
I can't really agree. Unix seems to be designed for terse abbreviations and acronyms, but I can't find much correlation to qwerty.
Ok, ls is a loss on Dvorak. I used to mistype it as rn all the time, which sucked on systems that had the rn newsreader! I created an alias that printed "You don't really want to run rn!".
But your other examples--ps, pwd, cd--are objectively easier on Dvorak, in my analysis. Not that they would win any prizes on either.
By the way, even the vi keys--hjkl--work pretty well in Dvorak. h is nicely situated below the right index finger, jk are adjacent and easily accessible to the left index finger--and to go right, I'd rather hit space!
I conclude that Ken, Dennis, and Bill were secretly Dvorak users.:-)
the inclusion of the King James Bible and a few other works may have skewed the results somewhat, as shown by the presence of the word "thou" in the most-often used words list.
This is just another variation on the suggestions offered by others. If you want to print at full size on a normal printer, you can print to postscript in the browser, then run the postscript through poster, which will break it into pages that you can print out and tape together.
I actually liked the quote too--it's almost plausible!--and I remember noting that it was the poster and not the editor. Which is why I noticed the mistake.:-)
Yes, all of Hollywood has been anxiously waiting for this code to land, so they can lose their reliance on star-studded, special-effects-laden blockbusters, and focus on original stories, intelligent writing, and quality acting.
What "both companies"? Is Sun one of them? Their support for open source
is highly dubious. For certain, it's hardly in their interests to make
Linux the "ideal" Java platform.
so the community has made sure the integration is tight and optimized
Give one example of how Java is "integrated" into Linux, much less "tight
and optimized". On my system, Java is terribly integrated: I have to
download parts from all over the net and put them together myself. Most of
those parts (like the 50 MB jre) don't feel very "tight and optimized".
Indeed, it is the Java industry's disregard for (or fear of?) open source
that most impedes "the community"'s efforts to make Linux a good Java platform.
the performance of C++ with the ease of use of Python
Java "performance" is still largely vaporware: "just one more technology,
and we'll be as fast as C++". (Not that this matters for most
applications.) And if Java is as easy to use as Python, why am I so
grateful for Jython?
C# and.NET... by all appearances will be to Java what Java was to
Linux, minus X11 and plus COM
Ok, now I think you're just putting us on! Either that, or you didn't do
very well on the analogies section of the SAT.:-)
What can I say, except that I suspect you're exactly right. Particularly, I
had forgotten about the cross-platform part of Ant's appeal (I won't touch a
Windows without Cygwin, but it's no doubt a hurdle for Windows natives),
which I suspect is the biggest factor.
I've gotten used to holding my tongue, but since you started it, I'll put my
rant under yours.:-)
I've used Ant, and concluded that it's only strength is that it comes with a
bunch of modules ready-to-use. (Never mind that most of those modules would
be five lines in a more modular, flexible system like make.) Further, in
several respects, it has several serious regressions compared to other build
systems. In light of this, it seems to me that the main reason Ant is
popular is that it attempts to cover for the deficiencies of common Java
compilers. What a mess!
The first regression is that Ant (by default) doesn't do reliable rebuilds.
The most basic function of a build system is to produce correct output, and
Ant doesn't do it! Its default algorithm for rebuilding is to compile only
those source files that are newer than their corresponding class files. So,
for example, if you change an interface, Ant won't recompile all the classes
that implement the interface. You won't know that they are broken until you
(or someone else) tries a full rebuild.
Ant has a "depend" task that attempts to fix this, by tracking source
dependencies. Unfortunately, because most Java compilers don't do their
part, Ant has to do this in an utterly kludgy way--by parsing class files!
Not only is this slow and has some weird side-effects, it's still not
completely reliable: Only the compiler really knows what files depend on
what others. (For example, if it in-lines a constant, this may not be
evident in the class file.) However, as far as I know, gcc is the only Java
compiler that can output correct dependencies (jikes claims to do it, but is
broken). Even if your compiler does output dependencies, you can't easily
use them with Ant, because it stores its dependencies in a non-standard
format.
Another regression is that in Ant, individual source and class files are not
first-class objects to the build system. You can't easily depend on, or ask
to rebuild, a single class file. It's all or nothing. This too is largely
due to compiler deficiencies: There is no way to tell most compilers to
compile only the given sources; they insist upon compiling everything they
think is out-of-date (again, gcc is an exception). This misfeature takes
control out of the build system's hands, with the result that "recompile
everything that's out-of-date" is the only feasible approach. Another
effect is that parallel and distributed builds cannot be done reliably.
Not to mention,
The organic growth and dynamic flexibility shows how close Java can be to
Lisp.
I don't even know where to start on that one. All Ant shows is that if you
give people a half-working workaround for broken tools, they'll flock to it.
To free software advocates, your patent policy is probably worthless because it does not grant a no-cost license to implement the "inventions" in free software.
In addition, your policy does not include non-discriminatory pricing, which allows you effectively to exclude some parties from use of your patents.
In order for Mozilla to produce a browser for testing purposes going to want it to be a good user interface.
should be
In order for Mozilla to produce a browser for testing purposes, it has to have a user interface. As long as it has a user interface, people are going to want it to be a good user interface.
While the ultimate goal of the Mozilla project is to produce source
code that can be used by other projects and companies, the Open-Source
project Beonex tries to make a browser for end-users out of it.
I don't mean to deprecate your efforts, but I think this "Mozilla isn't
about producing an end-user product" idea has always been wishful
thinking--and is becoming less plausible every day. Mozilla is clearly
destined to become the prominent browser in the free software community and
the web development community, and a popular browser among computer users at
large.
I'm not saying it's a bad idea in principle to separate the development of
the engine and the finish; I just don't see how it can happen in this case.
The core features and the user interface of a browser are not separable
enough. In order for Mozilla to produce a browser for testing purposes
going to want it to be a good user interface. The evidence bears this out:
users file usability bugs in bugzilla, the developers take them seriously,
and as a result, vanilla mozilla has an overall better user interface than
any earlier Netscape browser.
The Mozilla developers seem to agree on the value of a reference user
interface, in order to prevent excessive variation in the interfaces of
derived products. For example, they insist upon limiting the number of
user-configurable variables, which would not make sense if they were only
about the basic technologies. In order for their reference interface to be
credible, they have to invest resources in usability. The way I see it, the
"reference interface" position amounts to a committment to an end-user
product, even if they don't realize or admit it.
On top of this, Mozilla already has all the visibility in the free software
and web development communities. If Mozilla refuses to provide an end-user
product, it will mostly create user confusion. Mozilla has all the
developers. Mozilla has all the infrastructure. It only makes sense for
Mozilla to do the last 10% and provide an end-user product. Maybe someday
beonix or galeon or someone else will overcome this barrier (just as GTK and
QT have finally displaced athena as free widget sets for X), but it will
take a long time.
Of course, in some markets, vanilla Mozilla won't be the king. Among Joe
PC, it will a Netscape or AOL branded version. Users of embedded systems
will get whatever modified version their manufacturer included. But even
the popular computer press reviews Mozilla, so the message that it is not
for end-users doesn't seem to have gotten through. And among the slashdot
demographic, Mozilla is it. Let's face it: how many of us will download
Mozilla 1.0 to "test" it? Most of us want to use it! Mozilla is already a
great end-user browser, and will keep getting better.
It's a beautiful book, and takes basically the approach you outline. I don't have it in front of me, but I believe it treats most of the models you mention, and always focuses on the insights they give you into programs.
It's the standard MIT intro text. Philip Greenspun called it the "one great book on the subject of computer programming". It's even online!
The only caveat is that students reportedly find it hard to absorb on the first pass--even at MIT. (This is second hand information--I didn't read SICP in a class, nor did I go to MIT. I read it after programming professionally for a few years, and loved it.)
The obvious part, which others have said, is don't store credit card numbers. But that can't be the whole answer, because you at least need the credit card number for as long as the order is "active". (I haven't run a store, so tell me if I'm missing something.)
Assuming you need to store a credit card number for at least some period of time, the best way to keep it safe is to store it on a machine that will never give it out--except to local users on a separate network. The web server can send the number to this machine, but cannot ask for it back. Your employees and your order-processing code can access the number via the local network.
If you must store the numbers long-term (to enable that "novel and non-obvious" wonder called "one-click shopping"), they still cannot be accessed from the web server. When the user enters his credit card number, the web server tells the credit card database, "Bob's VISA card is 12345". When the user places an order, he selects "VISA card" from a drop-down, and the web server records in the order that Bob wants to pay with his VISA card. But the web server still doesn't have access to the number itself.
You can take this further by placing additional limitations on what someone who cracks the web server can do. For example, the web server doesn't need access to Bob's password, or even a hash of Bob's password. It just needs to verify it. So store the password on another system that will only verify passwords (and has some rate-limit to guard against guessing). Nor is there any reason to blindly trust the web server when it says "Bob wants to pay with his VISA". Have the password verifier return a random token when the password is correct, and only allow the order if the web server supplies a valid token.
You get the idea--put the important data on a system that trusts the web server as little as possible.
Additionally, I've heard people suggest connecting the web server to the credit card database with something less "featureful" (and thus, hard to secure) than a network connection. A serial cable, for example.
When they say "unmaintainability", this is code-word for "Programmed in Lisp", rather than "Programmed in a sloppy messy spaghetti-like fashion"
Well, I'll just say it: Sawfish is, in my reasonably informed opinion, a well-designed, maintainable program. I read the documentation and looked at the code in order to make some changes of my own (which I never finished...), and I was generally impressed.
So, while I haven't seen enough evidence to be sure, I strongly suspect someone at Sun is afraid of Lisp.
Ever looked at the configuration dialogs for that beast!? They're INSANE.
You set your user lever to "advanced", right? I'm too lazy to check right now, and I don't remember exactly what the setting is called, but I'd bet you did. Set your user level to "beginner" (or whatever the lowest level is), and you won't see such arcana.
Sawfish's configuration infrastructure is beautifully designed. One result is that it's terribly cheap (in terms of coding and maintenance) to add a configurable parameter, yet the front-end can easily manage the complexity exposed to the user. It would have been straightforward for Sun to present the options to their users in a way that they find more suitable. Go look at the design sometime--it's nice.
But who would expect Sun to recognize good design--much less their low-bidding hackers in India?
If you want to test your knowledge of esoteric programming languages, try this
problem from the 2002 MIT
Mystery Hunt.
I was happy to solve 1840, even though I immediately recognized the
language, because it is poorly specified and there is no interpreter. But
that was nothing compared with my teammates, who solved 1183 with nothing
but the problem and pure reason.
Slashdot Mirror
A rough argument would be that to get longer runs, you would have to include both consonants and vowels in the same run, which would tend to violate the principle of putting vowels on one side, and common consonants on the other. I believe that without that, you will end up with many words that are awkward (non-run) one-hand combinations.
Also, English isn't that non-random. Ie, it is inevitable that optimizing for longer runs wins for fewer words.
You're right that I don't have evidence, but I have a very strong feeling that there are too many constraints for you to design a keyboard with long one-hand runs, without losing badly in other areas.
In general, my style tends towards "smoothing out" the stretching of fingers and movement of the wrists by predicting the required positions of each hand and moving progressively towards an optimum position for it. I agree that this is unusual, but I think that most people could learn this given time.
You may be right, but I have a gut aversion to any technique that requires more motion and dexterity. When I typed qwerty, I had a self-taught style (that I can't remember in any detail). When I learned Dvorak, I did it by the book, and now have pretty orthodox touch-typing technique. I feel distinctly more comfortable now when I type, and given all the horror stories about typing injuries, that factor ranks very high for me.
It's still a stupid term. Tell me, where is the configuration that is being managed? Industries have lots of meaningless jargon--doesn't mean us sane folks have to parrot it. "Revision control" works just fine and makes sense.
Heathen!
http://www.independent.org/tii/news/liebowitz_econ omist.html
Liebowitz's article does not debunk anything. It merely gives evidence that some studies were flawed, puts forward its own flawed and ambiguous studies, and entirely ignores the compelling non-empirical arguments for Dvorak's superiority. (Do you not believe anything that has not been established by studies?) Let's not even mention the fact that Liebowitz has a strong prejudice about market efficiency to support (oops, mentioned it!).
Marcus Brooks has a longer rebuttal. I actually do not find it totally satisfactory either, but it should certainly make clear that Liebowitz has little credibility.
Alternating between hands each key is the absolute hardest action to do quickly. If you have a piano piece which has a segment like this (there's a few famous pieces like this) it'll either be relatively slow or you'll be practising it for months. Runs of keys in the same hand are far faster. I'd say about 5 times faster.
Runs on the same hand are faster than alternation, sure. But alternation is much faster than arbitrary motions of one hand. Given the variety in English, optimizing for long runs will win on a very few words, and screw up the layout for everything else. I challenge you to refute this.
Dvorak does follow this principle for some short runs: th, sh, wh, rt, nd, and ng are all nice combinations that move in the pinky-to-index direction on one hand. But gymnastics with one hand will kill most typists, and alternation is about avoiding this.
Why are hands not allowed to move left or right? If you have 8 keys to press, all of which reside to the right of the 'D' key, I move my left hand right a few keys! What's the point in keeping it where it is and making your right hand do more work and even stretch to reach the central columns?
This requires incredible foresight and motor skills. For most people, the key to finding a key quickly is knowing its position relative to a fixed reference.
Why must all 4 fingers rest on the same row? For a start, your fingers aren't even the same length! Place your hands naturally on a table, and compare to where the keys would be. You'll find that they would have been on "a,w,e,f" and "j,i,o,;". Somewhat luckily, qwerty keyboards have all of the vowels except "u" under these keys. There's no reason you can't have your fingers over arbitrary rows. With a bit of hand strength building, this is easy.
I might agree about the natural position of the fingers (though I suspect the natural position is actually somewhere in-between asdf and awef). But the idea that each finger can be on its own row is just wrong for normal hands. Ask some normal people to try it, and they'll tell you.
Moving up and down rows is only slow if you "float" above the keyboard (not resting your wrist on the table/rest) and move your entire arms back and forward. This would be an awful technique to use and I'd suspect it would lead to strain problems very quickly. Stretching your fingers forward and backwards is fast. And with the previous point, this is mostly irrelevant anyway.
Resting wrists on the table, and stretching fingers without moving the hand, are both generally recognized as major contributors to CTS and other typing injuries. When I learned piano, I was definitely taught to keep my wrists up and move my hands with my fingers (eg, when reaching for a black key, the hand should advance).
So, why aren't we allowed to use thumbs for typing normal keys? It's perfect for hitting keys on the bottom row when all the others have been tied up. Just then, I typed "up." with right hand "2-4-1" (where 1 is thumb, 5 is little). Why? Because when fingers 2,4 have been tied up on the top row, the most convenient finger to use is my thumb. Try it.
I tried it. It's a disaster for me. Typing up with 2-4 is hard enough, requiring an awkward stretch of the ring finger. Getting to . with the thumb requires me to twist my whole arm in addition to
contorting my hand, and hitting a target after such a long travel with such
a fat digit is quite unreliable. Plus, this leaves my hand totally out of
position for any subsequent typing.
I would think that given your claim that different fingers can easily go to different rows, you would prefer 2-5-4.
My theory about carpal tunnel and other typing related injuries is that "touch typing" is actually to blame. It encourages stiffening of the wrists and hands, discourages stretching, and generally leaves your hands as weak as they were before you started typing.
I'm not a doctor, but this flies in the face of all the medical advice I've read. What you call "stiffening" is what most people would call making gentle, comfortable motions. What you call "stretching" is what most people would call excessive and unnatural motion. What you call "leaving weak" is what most people would call avoiding strain. Maybe your hands can take it, but most people's can't.
I can't really agree. Unix seems to be designed for terse abbreviations and acronyms, but I can't find much correlation to qwerty.
Ok, ls is a loss on Dvorak. I used to mistype it as rn all the time, which sucked on systems that had the rn newsreader! I created an alias that printed "You don't really want to run rn!".
But your other examples--ps, pwd, cd--are objectively easier on Dvorak, in my analysis. Not that they would win any prizes on either.
By the way, even the vi keys--hjkl--work pretty well in Dvorak. h is nicely situated below the right index finger, jk are adjacent and easily accessible to the left index finger--and to go right, I'd rather hit space!
I conclude that Ken, Dennis, and Bill were secretly Dvorak users. :-)
Here's another dead givaway: 10377 sv
This is just another variation on the suggestions offered by others. If you want to print at full size on a normal printer, you can print to postscript in the browser, then run the postscript through poster, which will break it into pages that you can print out and tape together.
that the name "Wi-Fi" is utter babble?
I actually liked the quote too--it's almost plausible!--and I remember noting that it was the poster and not the editor. Which is why I noticed the mistake. :-)
You've got your attribution wrong. Go back to slashdot 101.
Yes, all of Hollywood has been anxiously waiting for this code to land, so they can lose their reliance on star-studded, special-effects-laden blockbusters, and focus on original stories, intelligent writing, and quality acting.
Both companies support open source
What "both companies"? Is Sun one of them? Their support for open source is highly dubious. For certain, it's hardly in their interests to make Linux the "ideal" Java platform.
so the community has made sure the integration is tight and optimized
Give one example of how Java is "integrated" into Linux, much less "tight and optimized". On my system, Java is terribly integrated: I have to download parts from all over the net and put them together myself. Most of those parts (like the 50 MB jre) don't feel very "tight and optimized". Indeed, it is the Java industry's disregard for (or fear of?) open source that most impedes "the community"'s efforts to make Linux a good Java platform.
the performance of C++ with the ease of use of Python
Java "performance" is still largely vaporware: "just one more technology, and we'll be as fast as C++". (Not that this matters for most applications.) And if Java is as easy to use as Python, why am I so grateful for Jython?
C# and .NET ... by all appearances will be to Java what Java was to
Linux, minus X11 and plus COM
Ok, now I think you're just putting us on! Either that, or you didn't do very well on the analogies section of the SAT. :-)
What can I say, except that I suspect you're exactly right. Particularly, I had forgotten about the cross-platform part of Ant's appeal (I won't touch a Windows without Cygwin, but it's no doubt a hurdle for Windows natives), which I suspect is the biggest factor.
Well, with Cygwin you can. :-)
(I forgot about the cross-platform part, because I subconsciously block out Windows.)
I've used Ant, and concluded that it's only strength is that it comes with a bunch of modules ready-to-use. (Never mind that most of those modules would be five lines in a more modular, flexible system like make.) Further, in several respects, it has several serious regressions compared to other build systems. In light of this, it seems to me that the main reason Ant is popular is that it attempts to cover for the deficiencies of common Java compilers. What a mess!
The first regression is that Ant (by default) doesn't do reliable rebuilds. The most basic function of a build system is to produce correct output, and Ant doesn't do it! Its default algorithm for rebuilding is to compile only those source files that are newer than their corresponding class files. So, for example, if you change an interface, Ant won't recompile all the classes that implement the interface. You won't know that they are broken until you (or someone else) tries a full rebuild.
Ant has a "depend" task that attempts to fix this, by tracking source dependencies. Unfortunately, because most Java compilers don't do their part, Ant has to do this in an utterly kludgy way--by parsing class files! Not only is this slow and has some weird side-effects, it's still not completely reliable: Only the compiler really knows what files depend on what others. (For example, if it in-lines a constant, this may not be evident in the class file.) However, as far as I know, gcc is the only Java compiler that can output correct dependencies (jikes claims to do it, but is broken). Even if your compiler does output dependencies, you can't easily use them with Ant, because it stores its dependencies in a non-standard format.
Another regression is that in Ant, individual source and class files are not first-class objects to the build system. You can't easily depend on, or ask to rebuild, a single class file. It's all or nothing. This too is largely due to compiler deficiencies: There is no way to tell most compilers to compile only the given sources; they insist upon compiling everything they think is out-of-date (again, gcc is an exception). This misfeature takes control out of the build system's hands, with the result that "recompile everything that's out-of-date" is the only feasible approach. Another effect is that parallel and distributed builds cannot be done reliably.
Not to mention,
I don't even know where to start on that one. All Ant shows is that if you give people a half-working workaround for broken tools, they'll flock to it.In addition, your policy does not include non-discriminatory pricing, which allows you effectively to exclude some parties from use of your patents.
In order for Mozilla to produce a browser for testing purposes going to want it to be a good user interface.
should be
In order for Mozilla to produce a browser for testing purposes, it has to have a user interface. As long as it has a user interface, people are going to want it to be a good user interface.
I don't mean to deprecate your efforts, but I think this "Mozilla isn't about producing an end-user product" idea has always been wishful thinking--and is becoming less plausible every day. Mozilla is clearly destined to become the prominent browser in the free software community and the web development community, and a popular browser among computer users at large.
I'm not saying it's a bad idea in principle to separate the development of the engine and the finish; I just don't see how it can happen in this case. The core features and the user interface of a browser are not separable enough. In order for Mozilla to produce a browser for testing purposes going to want it to be a good user interface. The evidence bears this out: users file usability bugs in bugzilla, the developers take them seriously, and as a result, vanilla mozilla has an overall better user interface than any earlier Netscape browser.
The Mozilla developers seem to agree on the value of a reference user interface, in order to prevent excessive variation in the interfaces of derived products. For example, they insist upon limiting the number of user-configurable variables, which would not make sense if they were only about the basic technologies. In order for their reference interface to be credible, they have to invest resources in usability. The way I see it, the "reference interface" position amounts to a committment to an end-user product, even if they don't realize or admit it.
On top of this, Mozilla already has all the visibility in the free software and web development communities. If Mozilla refuses to provide an end-user product, it will mostly create user confusion. Mozilla has all the developers. Mozilla has all the infrastructure. It only makes sense for Mozilla to do the last 10% and provide an end-user product. Maybe someday beonix or galeon or someone else will overcome this barrier (just as GTK and QT have finally displaced athena as free widget sets for X), but it will take a long time.
Of course, in some markets, vanilla Mozilla won't be the king. Among Joe PC, it will a Netscape or AOL branded version. Users of embedded systems will get whatever modified version their manufacturer included. But even the popular computer press reviews Mozilla, so the message that it is not for end-users doesn't seem to have gotten through. And among the slashdot demographic, Mozilla is it. Let's face it: how many of us will download Mozilla 1.0 to "test" it? Most of us want to use it! Mozilla is already a great end-user browser, and will keep getting better.
It's the standard MIT intro text. Philip Greenspun called it the "one great book on the subject of computer programming". It's even online!
The only caveat is that students reportedly find it hard to absorb on the first pass--even at MIT. (This is second hand information--I didn't read SICP in a class, nor did I go to MIT. I read it after programming professionally for a few years, and loved it.)
Assuming you need to store a credit card number for at least some period of time, the best way to keep it safe is to store it on a machine that will never give it out--except to local users on a separate network. The web server can send the number to this machine, but cannot ask for it back. Your employees and your order-processing code can access the number via the local network.
If you must store the numbers long-term (to enable that "novel and non-obvious" wonder called "one-click shopping"), they still cannot be accessed from the web server. When the user enters his credit card number, the web server tells the credit card database, "Bob's VISA card is 12345". When the user places an order, he selects "VISA card" from a drop-down, and the web server records in the order that Bob wants to pay with his VISA card. But the web server still doesn't have access to the number itself.
You can take this further by placing additional limitations on what someone who cracks the web server can do. For example, the web server doesn't need access to Bob's password, or even a hash of Bob's password. It just needs to verify it. So store the password on another system that will only verify passwords (and has some rate-limit to guard against guessing). Nor is there any reason to blindly trust the web server when it says "Bob wants to pay with his VISA". Have the password verifier return a random token when the password is correct, and only allow the order if the web server supplies a valid token.
You get the idea--put the important data on a system that trusts the web server as little as possible.
Additionally, I've heard people suggest connecting the web server to the credit card database with something less "featureful" (and thus, hard to secure) than a network connection. A serial cable, for example.
It's a "sher" win.
Well, I'll just say it: Sawfish is, in my reasonably informed opinion, a well-designed, maintainable program. I read the documentation and looked at the code in order to make some changes of my own (which I never finished...), and I was generally impressed.
So, while I haven't seen enough evidence to be sure, I strongly suspect someone at Sun is afraid of Lisp.
You set your user lever to "advanced", right? I'm too lazy to check right now, and I don't remember exactly what the setting is called, but I'd bet you did. Set your user level to "beginner" (or whatever the lowest level is), and you won't see such arcana.
Sawfish's configuration infrastructure is beautifully designed. One result is that it's terribly cheap (in terms of coding and maintenance) to add a configurable parameter, yet the front-end can easily manage the complexity exposed to the user. It would have been straightforward for Sun to present the options to their users in a way that they find more suitable. Go look at the design sometime--it's nice.
But who would expect Sun to recognize good design--much less their low-bidding hackers in India?
I was happy to solve 1840, even though I immediately recognized the language, because it is poorly specified and there is no interpreter. But that was nothing compared with my teammates, who solved 1183 with nothing but the problem and pure reason.