Remember "The Unix Hater's Handbook?" It mentioned the idea of "Worse is better" and the dominance that this phenomenon allowed Unix to achieve in the early 1990s. However, it holds true still (but Windows, and not Unix, is the target of ire) and not just applied to Operating Systems--the x86 processor architecture has killed off nearly all the far more elegant chip designs, RISC and CISC alike, in the last 10 years. x86 is so bad that Intel doesn't even fab "real" x86 chips anymore; they build what I understand to be a sort of ad-hoc load/store architecture and simulate the x86 instruction set through microcode (can you imagine MS cloning Wine, sticking that on top of a Linux distro, and selling the result as Windows 2010?).
WoW works the same way. No one thinks the game is perfect, but each player thinks a couple of features are integral to enjoying a MMOG while others are detrimental. But it's not a zero-sum proposition, since having five good features outweighs having five or even ten annoying ones. Therefore, you get a scenario where everyone plays the game because it has the good features they want, but complains about it because it has many features they hate. They promise they'll move on to whatever game fixes those problems, but invariably every game tries to please people by removing features, and ends up removing enough features that different people no longer have any desire to play the game.
They teach you to think more abstractly, but they don't teach you to think *about abstraction* because they do it all for you and you're pretty much stuck with the abstractions they give you (except LISP; (defun defun nil) anyone? A good example of this is the commutative property of addition. Many high-level languages have overloaded, or allow you to overload, the '+' operator to do string concatenation. This is handy, as "print str1 + ' ' +str2" is a lot easier than "print (str1.cat(' ')).cat(str2)", but it now means that programs using the '+' operator on abstract types can't count on Obj1+Obj2 having the same result as Obj2+Obj1. And how about Obj1+Obj2-Obj2 evaluating the same as Obj1? You could always check to make sure that Obj1 & Obj2 are numbers before making use of mathematical properties by checking their type, but if it's possible for others to derive their own number or number-like classes, then your function might not know about those classes too.
Contrariwise, because assembly are a lot harder to read, write, and debug than high-level languages, you have to think about what sort abstractions you want to make use of, and an efficient way to implement them. Writing a user-space addition function that uses successive iterations of a primitive increment-by-one (++) routine[1] is thinking very abstract... but the performance will be terrible and probably not worth saving the ten minutes it would have taken to write a more sophisticated addition primitive, and let increment-by-one be a special case of that.
[1] Yes, some early LISP implementations would do exactly that.
I wrote a hexdumper in PPC assembler; it used simple READ and WRITE for i/o and statically-allocated storage for data. It worked very well until I broke it trying to add a byte offset at the beginning of every line like most hexdumpers, and I got distracted by other things before ever fixing it.
If nothing else, it made me appreciate how much work format-printing functions do. Converting a string to a number is relatively easy to implement (just divide and subtract successively smaller powers of x, where x is the base), but converting a number into a string representation is very tricky. I've never compared, but I'll warrant it's probably more simple to convert a number to a base-16 representation and then transpose it into base 10 than it is to convert directly to base 10.
Why? Well, hell, it's a learning experience, and if you're obsessive enough (not to mention masochistic) to *want* to program, then you'll probably enjoy it, at least a little.
Also, write at least one non-trivial assembly program. You may never use it ever again for anything real, but it will change forever the way you approach programming.
No, I think they should just stop pandering to kids who forget everything from year to year. The first day of school in September (or these days, August) should pick up right from where the last day of school in May or June left off. Maybe even with a test. If the kids fail, well, that's because they're dumb.
If you let people succeed in school without learning anything then they will. If you don't, then they will either not succeed or they will start learning. It's as simple as that.
In the first place, students are given a lot more leeway in terms of how they actually learn things--the smart kids can figure it out (with a bit of help from the teacher), the middle-range kids get told the answer once and write it down, and the dumb kids get told it over and over until it sinks in. But they do all this at a fairly fast pace.
In the second place, the most academically successful ethnic groups in East Asia derived a lot of their culture from China. China has such an insanely complex system of writing that for a long time it was practically impossible to be very highly literate, which means that for much of Chinese history scholars were the most valued people around, and the virtues most highly prized were scholastic virtues, and this has had strong residual effects on the succeeding generations (pun intended).
One of the best things about studying from philosophy, and in particular from a historical/Continental perspective, is the long-standing tradition of solving seemingly intractable problems by tackling them from a different perspective--Kant solved the rationalist/empiricist debate of whether we can or cannot have ideas that do not come from experience by turning it around and asking instead what the conditions for the possibility of experience were.
Take the Dining Philosopher's problem as a germane example. How much more expensive would it be to give each diner his own pair of forks and let them eat and think as much as they want at their own pace (in other words, why not reorganize the distribution of system resources so that each process can have its own set of resources)? Another is the traveling salesman problem: why does the salesman even need to travel? Can't he use the telephone or the internet or something?
If you answer "But the literal solution to the problem isn't the point", then you've missed *my* point entirely. Coming up with a better algorithm is usually a better way to improve performance than hand-optimizing inner loops, so why not take it to a higher level of problematic abstraction and change the problem you're trying to solve instead of the way you implement a particular solution.
No. Rather, hard disk platters have a whole lot of angular momentum, which means if you move them violently while they're reading or writing they can get wrecked. Solid state memory (is it even technically a disk?) does not have this problem, which means you can be a good bit less careful with it.
If this were a desktop system, you'd be right on. But laptops don't live very long anyway, and in general they see a lot less intensive use than desktop workstations. Furthermore, if you're paying through the nose for a flash-based main disk, getting an extra GB or two of main memory is peanuts.
but it's "I"nternet and there is only one of them.
I see. So this thing is just a figment of my imagination? If you're going to criticize someone for being a dumbass, you'd better be careful not to be a dumbass yourself.
I think we need to switch to a "no lawyers" method, myself. The way they handled it in ancient Greece. You got beef with somebody, you show up in court, in person, and talk for an hour or so to explain why he's guilty. Then he talks for an hour or so and says why he's not. Then the jury decides. Then THAT'S THE END. No appeals, no countersuits, nothing.
I suppose there's a good reason for having lawyers in criminal cases (i.e., findings of fact) since there's a lot at stake wrt evidence and expert testimony, but as far as day-to-day legals affairs go, if people can't understand the law then the law does not serve them.
Nobody asked about software literacy. Besides, that's an easy solution too: write your own. In assembler. Then, you know exactly what the software does because you wrote out all the instructions.
I think it's actually just because Americans are notorious over-exaggerators. I can't tell you how many times I've heard people use the word "literally" when they mean "figuratively", or "for real" when they mean "not really". Remember tall tales and urban legends? Remember the 10,000 people that were supposed to have died in the aftermath of Katrina? The two weeks it would take for bird flu to infect and kill everyone in the entire country? They feed upon the same desire that appears to lurk within all of us Americans to make shit up completely in order to appear credible. So, yes: not listening to me becomes censorship, copyright infringement becomes theft and even piracy, defeat in athletic competitions becomes murder, and so on. It's hardly new, and it seems to be less of a law than a bit of national culture.
You're right on about the other stuff, but as for AIDS, well, if you could come up with a vaccine that would be great. It's pretty much an established fact that viral infections are impossible to cure with drugs, but if a way can be found to prevent it from taking over the immune system, the disease could be eradicated in our lifetime (a la smallpox for the most part).
There is only one thing you need to know in order to be computer literate, but it seems to be the stumbling block for most people. You must understand that, with the exception of genuine hardware bugs, the computer is a 100% deterministic machine. It does only, and exactly, what it is told to do. Not what you want it to do. Not what is sensible or reasonable or convenient or beautiful or ethical or any of those things. It obeys without fail the instructions conveyed to it in machine code, and if those instructions tell it to erase your data or curse at your mother or set the CPU on fire, then by God that is what will happen.
The corollary to this is that if you understand how to communicate with the computer, how to speak its language, you can do anything.
I think a better solution is to have the pop-up say, "An error has occurred loading this program; it contains bug # 23754983 at 0xdeadbeef, and cannot be fixed by Windows." The technically aware would know that this just means that the program is deemed unsafe and should be renamed/flagged/etc as being okay.
Actually, it should probably just delete the file automatically. If your best method for executable distribution is IM, you deserve to lose.
It is actually kind of like he said. In the beginning typefaces styles like Roman, Gothic, and Italic would be chosen for their aesthetic and practical qualities (how easy to read, how many words to a page, etc), and also depending to a lesser extent on the language used (Greek, Latin, etc). Now, however, we use italic, bold, underline, or capital/small capital to indicate words that should stand out from the sentence--usually, for emphasis or because they are from a different language (scientific names may or may not be included in this latter category). Japanese, however, has no equivalent distinction--the closest you can come other than katakan/hiragana is gothic/mincho, but 1) mincho characters are somewhat ugly when they're big, 2) gothic characters are illegible when small, and 3) in some cases there may not be an identifiable distinction between characters.
So the japanese use hiragana mostly to indicate native japanese words (or components of words) for which no kanji exists, or to unambiguously declare the pronunciation of a given word (either in full type or furigana-style ruby), and katakana for 1) emphasis, 2) most loanwords (except tabako, 3) onomatopoeia, and 4) names of animals for which the kanji is no longer on the approved list (e.g. kame*). This coincides neatly with the use of italic in Roman-alphabet-using languages, and more often than not reduces ambiguity and enhances clarity. Although, I do have a rather funny story involving katakana, the Japanese word for poverty, and a couple of hot girls, but this discussion is entirely off-topic as it is.
*: Oddly, the character for kame is on the Joyo list, but only in the third category of characters which are designated for use in proper names (but not apparently in other uses).
There's really no point in complaining that feature X (fixed or implemented in in the source tree) won't be back-ported to the stable branch. If we do retrograde ports of everything in the unstable branch into the stable branch, then the stable branch would become unstable too. You might as well tell people to upgrade to each nightly build of a project as it becomes available. The whole point of stable releases is that they are stable, as in unchanging, as in any bugs or implementation deficiencies, however irksome, can at least be reliably ignored, worked around, or even counted upon until the next release. Furthermore (and this is the important part), anything that's implemented correctly will not be messed up until the next release, so you have a product or service that's stable, too.
I used to hack on xnu. Not a lot, mind you, but I fooled around with a few bits in my spare time at school. For example, I added a bit to the filesystem flags and their user-space friends (chflags, etc) to implement network socket-blocking for individual executables. But then it got squashed with the next upgrade and I never bothered to implement it again.
Slashdot Mirror
Off them $25 and a bus ticket. If they don't go for it, hack into their servers, download child porn, and report them to the FBI.
Remember "The Unix Hater's Handbook?" It mentioned the idea of "Worse is better" and the dominance that this phenomenon allowed Unix to achieve in the early 1990s. However, it holds true still (but Windows, and not Unix, is the target of ire) and not just applied to Operating Systems--the x86 processor architecture has killed off nearly all the far more elegant chip designs, RISC and CISC alike, in the last 10 years. x86 is so bad that Intel doesn't even fab "real" x86 chips anymore; they build what I understand to be a sort of ad-hoc load/store architecture and simulate the x86 instruction set through microcode (can you imagine MS cloning Wine, sticking that on top of a Linux distro, and selling the result as Windows 2010?).
WoW works the same way. No one thinks the game is perfect, but each player thinks a couple of features are integral to enjoying a MMOG while others are detrimental. But it's not a zero-sum proposition, since having five good features outweighs having five or even ten annoying ones. Therefore, you get a scenario where everyone plays the game because it has the good features they want, but complains about it because it has many features they hate. They promise they'll move on to whatever game fixes those problems, but invariably every game tries to please people by removing features, and ends up removing enough features that different people no longer have any desire to play the game.
They teach you to think more abstractly, but they don't teach you to think *about abstraction* because they do it all for you and you're pretty much stuck with the abstractions they give you (except LISP; (defun defun nil) anyone? A good example of this is the commutative property of addition. Many high-level languages have overloaded, or allow you to overload, the '+' operator to do string concatenation. This is handy, as "print str1 + ' ' +str2" is a lot easier than "print (str1.cat(' ')).cat(str2)", but it now means that programs using the '+' operator on abstract types can't count on Obj1+Obj2 having the same result as Obj2+Obj1. And how about Obj1+Obj2-Obj2 evaluating the same as Obj1? You could always check to make sure that Obj1 & Obj2 are numbers before making use of mathematical properties by checking their type, but if it's possible for others to derive their own number or number-like classes, then your function might not know about those classes too.
Contrariwise, because assembly are a lot harder to read, write, and debug than high-level languages, you have to think about what sort abstractions you want to make use of, and an efficient way to implement them. Writing a user-space addition function that uses successive iterations of a primitive increment-by-one (++) routine[1] is thinking very abstract... but the performance will be terrible and probably not worth saving the ten minutes it would have taken to write a more sophisticated addition primitive, and let increment-by-one be a special case of that.
[1] Yes, some early LISP implementations would do exactly that.
I wrote a hexdumper in PPC assembler; it used simple READ and WRITE for i/o and statically-allocated storage for data. It worked very well until I broke it trying to add a byte offset at the beginning of every line like most hexdumpers, and I got distracted by other things before ever fixing it.
If nothing else, it made me appreciate how much work format-printing functions do. Converting a string to a number is relatively easy to implement (just divide and subtract successively smaller powers of x, where x is the base), but converting a number into a string representation is very tricky. I've never compared, but I'll warrant it's probably more simple to convert a number to a base-16 representation and then transpose it into base 10 than it is to convert directly to base 10.
Why? Well, hell, it's a learning experience, and if you're obsessive enough (not to mention masochistic) to *want* to program, then you'll probably enjoy it, at least a little.
Also, write at least one non-trivial assembly program. You may never use it ever again for anything real, but it will change forever the way you approach programming.
No, I think they should just stop pandering to kids who forget everything from year to year. The first day of school in September (or these days, August) should pick up right from where the last day of school in May or June left off. Maybe even with a test. If the kids fail, well, that's because they're dumb.
If you let people succeed in school without learning anything then they will. If you don't, then they will either not succeed or they will start learning. It's as simple as that.
In the first place, students are given a lot more leeway in terms of how they actually learn things--the smart kids can figure it out (with a bit of help from the teacher), the middle-range kids get told the answer once and write it down, and the dumb kids get told it over and over until it sinks in. But they do all this at a fairly fast pace.
In the second place, the most academically successful ethnic groups in East Asia derived a lot of their culture from China. China has such an insanely complex system of writing that for a long time it was practically impossible to be very highly literate, which means that for much of Chinese history scholars were the most valued people around, and the virtues most highly prized were scholastic virtues, and this has had strong residual effects on the succeeding generations (pun intended).
One of the best things about studying from philosophy, and in particular from a historical/Continental perspective, is the long-standing tradition of solving seemingly intractable problems by tackling them from a different perspective--Kant solved the rationalist/empiricist debate of whether we can or cannot have ideas that do not come from experience by turning it around and asking instead what the conditions for the possibility of experience were.
Take the Dining Philosopher's problem as a germane example. How much more expensive would it be to give each diner his own pair of forks and let them eat and think as much as they want at their own pace (in other words, why not reorganize the distribution of system resources so that each process can have its own set of resources)? Another is the traveling salesman problem: why does the salesman even need to travel? Can't he use the telephone or the internet or something?
If you answer "But the literal solution to the problem isn't the point", then you've missed *my* point entirely. Coming up with a better algorithm is usually a better way to improve performance than hand-optimizing inner loops, so why not take it to a higher level of problematic abstraction and change the problem you're trying to solve instead of the way you implement a particular solution.
No, it's 2006, FFS2! Berkeley FFS is already pretty old.
Hey, it beats giving up murdering hookers!
No. Rather, hard disk platters have a whole lot of angular momentum, which means if you move them violently while they're reading or writing they can get wrecked. Solid state memory (is it even technically a disk?) does not have this problem, which means you can be a good bit less careful with it.
If this were a desktop system, you'd be right on. But laptops don't live very long anyway, and in general they see a lot less intensive use than desktop workstations. Furthermore, if you're paying through the nose for a flash-based main disk, getting an extra GB or two of main memory is peanuts.
I see. So this thing is just a figment of my imagination? If you're going to criticize someone for being a dumbass, you'd better be careful not to be a dumbass yourself.
I think we need to switch to a "no lawyers" method, myself. The way they handled it in ancient Greece. You got beef with somebody, you show up in court, in person, and talk for an hour or so to explain why he's guilty. Then he talks for an hour or so and says why he's not. Then the jury decides. Then THAT'S THE END. No appeals, no countersuits, nothing.
I suppose there's a good reason for having lawyers in criminal cases (i.e., findings of fact) since there's a lot at stake wrt evidence and expert testimony, but as far as day-to-day legals affairs go, if people can't understand the law then the law does not serve them.
Nobody asked about software literacy. Besides, that's an easy solution too: write your own. In assembler. Then, you know exactly what the software does because you wrote out all the instructions.
I think it's actually just because Americans are notorious over-exaggerators. I can't tell you how many times I've heard people use the word "literally" when they mean "figuratively", or "for real" when they mean "not really". Remember tall tales and urban legends? Remember the 10,000 people that were supposed to have died in the aftermath of Katrina? The two weeks it would take for bird flu to infect and kill everyone in the entire country? They feed upon the same desire that appears to lurk within all of us Americans to make shit up completely in order to appear credible. So, yes: not listening to me becomes censorship, copyright infringement becomes theft and even piracy, defeat in athletic competitions becomes murder, and so on. It's hardly new, and it seems to be less of a law than a bit of national culture.
You're right on about the other stuff, but as for AIDS, well, if you could come up with a vaccine that would be great. It's pretty much an established fact that viral infections are impossible to cure with drugs, but if a way can be found to prevent it from taking over the immune system, the disease could be eradicated in our lifetime (a la smallpox for the most part).
I think Zoomr should announce that it's going digamma.
There is only one thing you need to know in order to be computer literate, but it seems to be the stumbling block for most people. You must understand that, with the exception of genuine hardware bugs, the computer is a 100% deterministic machine. It does only, and exactly, what it is told to do. Not what you want it to do. Not what is sensible or reasonable or convenient or beautiful or ethical or any of those things. It obeys without fail the instructions conveyed to it in machine code, and if those instructions tell it to erase your data or curse at your mother or set the CPU on fire, then by God that is what will happen.
The corollary to this is that if you understand how to communicate with the computer, how to speak its language, you can do anything.
I think a better solution is to have the pop-up say, "An error has occurred loading this program; it contains bug # 23754983 at 0xdeadbeef, and cannot be fixed by Windows." The technically aware would know that this just means that the program is deemed unsafe and should be renamed/flagged/etc as being okay.
Actually, it should probably just delete the file automatically. If your best method for executable distribution is IM, you deserve to lose.
It is actually kind of like he said. In the beginning typefaces styles like Roman, Gothic, and Italic would be chosen for their aesthetic and practical qualities (how easy to read, how many words to a page, etc), and also depending to a lesser extent on the language used (Greek, Latin, etc). Now, however, we use italic, bold, underline, or capital/small capital to indicate words that should stand out from the sentence--usually, for emphasis or because they are from a different language (scientific names may or may not be included in this latter category). Japanese, however, has no equivalent distinction--the closest you can come other than katakan/hiragana is gothic/mincho, but 1) mincho characters are somewhat ugly when they're big, 2) gothic characters are illegible when small, and 3) in some cases there may not be an identifiable distinction between characters.
So the japanese use hiragana mostly to indicate native japanese words (or components of words) for which no kanji exists, or to unambiguously declare the pronunciation of a given word (either in full type or furigana-style ruby), and katakana for 1) emphasis, 2) most loanwords (except tabako, 3) onomatopoeia, and 4) names of animals for which the kanji is no longer on the approved list (e.g. kame*). This coincides neatly with the use of italic in Roman-alphabet-using languages, and more often than not reduces ambiguity and enhances clarity. Although, I do have a rather funny story involving katakana, the Japanese word for poverty, and a couple of hot girls, but this discussion is entirely off-topic as it is.
*: Oddly, the character for kame is on the Joyo list, but only in the third category of characters which are designated for use in proper names (but not apparently in other uses).
There's really no point in complaining that feature X (fixed or implemented in in the source tree) won't be back-ported to the stable branch. If we do retrograde ports of everything in the unstable branch into the stable branch, then the stable branch would become unstable too. You might as well tell people to upgrade to each nightly build of a project as it becomes available. The whole point of stable releases is that they are stable, as in unchanging, as in any bugs or implementation deficiencies, however irksome, can at least be reliably ignored, worked around, or even counted upon until the next release. Furthermore (and this is the important part), anything that's implemented correctly will not be messed up until the next release, so you have a product or service that's stable, too.
Now all the furries are going to come out and say that what they do is perfectly natural. Damn you, science, damn you.
It's biggest shortcoming is also it's greatest strength: viz., MS Word work-alike-ness.
It's great because it makes a fairly easy drop-in replacement for MS Word. It's bad because MS Word is a terrible, terrible product.
Why doesn't anyone ever try to write a Open-Source version of a decent Word Processor, like WordPerfect or ClarisWorks?
I used to hack on xnu. Not a lot, mind you, but I fooled around with a few bits in my spare time at school. For example, I added a bit to the filesystem flags and their user-space friends (chflags, etc) to implement network socket-blocking for individual executables. But then it got squashed with the next upgrade and I never bothered to implement it again.