This isn't just about ways of learning. Anyone in diplomatic or intelligence circles should learn by reading history books, case files, briefs, and the opinions of a wide variety of other analysts, not by immersing themselves in the narrow visions of the very small number of people who sponsor and direct the production of these training games. You only have to consider the names of the games to know that the current games are tilted towards crises and short-term consequences. It's bad enough that the average citizen worries only about military aggression and dramatic terrorist threats. If our diplomatic and intelligence analysts tilt that way, who will be left to worry about the other 98% of our foreign affairs: commerce, diplomacy, public perception, energy security...? Are we gearing up for a series of military "victories" that weaken the nation and leave Americans worse off?
In general, the use of video games will narrow the understanding of analysts and place too much power in the hands of a few people to instill ideology and warped visions of the world. Think of the group of wonks you believe have the most warped and simplistic view of the world. Now imagine an entire generation of analysts trained using games designed by those people. All it would take is a run of presidential election success by one party. Does that sound like a good way to train analysts whose job is to pick up on things that their masters failed to predict?
Breaking those pages of code into a bunch of other subroutines solely on some misguided notion that a function shouldn't be longer than N lines Usually people can come up with better reasons than that.
I've worked with code written in the "pages-long function" style. One thing I've found consistently in such code is duplicated functionality. I've even personally seen how this happens: A programmer implements a very large, complex piece of functionality as a function. Later, the need arise to implement a variation on this functionality. It turns out that the variation is quite structurally different, so to implement it by parameterizing the original function would result in spaghetti code. So, a second enormous function is written. The programmer scans the two functions and finds no large sections of code that are duplicated between the two functions, so he calls the job done.
Naturally, code developed in this manner degenerates into an unmanageable mess as more and more variations are added. Anyone trying to program this way in the business world, for example, will quickly drown. However, people tend to get by with this style in the scientific computing world, where there are relatively few variations that cannot be handled by parameterization.
The first thing that must be done to get out of this mode of programming is to assume that such variations will arise. Treat the first problem you solve as merely the first of many variations that you will be asked to solve in the future. (Either that, or make the opposite assumption and then completely rewrite your code when the second variation arises.) Then, analyze each variation in terms of the things it must accomplish. You can categorize things using problem domain concepts, solution domain concepts, whatever, as long as you can put names on things.
(The tendency to think in human terms and give natural language names to things is a hindrance to mathematical insight, but it often generates effective ways to decompose code. Perhaps this is another reason why the "big function" style tends to plague scientific computing.)
Once you have split the original task into conceptually separate chunks that can be given reasonable natural language names, split the program up into pieces that have those names.
Voila, now you have a program made of small chunks that can be understood by other programmers. And, since each chunk has a reasonable name, programmers can limit themselves to reading the name and documentation of most pieces of the program, rather than reading every single line of code. This makes the code effectively shorter and easier to maintain, even if you never reuse the chunks to compose a new variation.
This is why good programmers must be good writers as well. The ability to explain the structure of code, primarily with clear, precise names for classes, functions, and variables and secondarily with comments, is as important as the ability to decompose a program logically. I have seen programs that were twice as complex as they should have been, yet made perfect sense and were easy to hack on, because the code and comments made it easy to understand the original programmer's understanding.
In the interview, Knuth gave one reason why literate programming isn't popular: few people are good programmers, few people are good writers, and literate programming only works for people who fall into both categories. I think he's right. Encouraging people to write more unstructured prose than they feel a need to results in worthless verbiage, and most programmers naturally limit their comments to sentence fragments and the occasional short paragraph. If you have to force people to write, you need to provide structure and clear expectations. That's why Javadoc and similar schemes are so much more valuable in practice than literate programming.
I still suspect, though, that you might own a copy of Atlas Shrugged with the pages stuck together.
I guess the definition of a free-market fundamentalist is someone who believes that a completely free market is the best of all possible markets (and the best solution to every social problem,) and all we have to do is figure out what "free" and "market" mean. I don't believe that.
I think markets are a great tool for many purposes, but they can produce inefficient systems and can reward destructive behavior. We should be careful about subordinating our judgment to markets. They're a bit like computers: we should only trust them with problems that we know they solve reliably, and when they're obviously screwing up, we should rethink our trust. We shouldn't say, "Well blow me down, I never realized raping babies was a good thing until that guy got rich doing it," any more than we would say, "I guess I don't really need my data, because otherwise this program wouldn't keep deleting it."
I tried to read The Fountainhead in high school but couldn't bear to read more than a few dozen pages. It was like a mirror of my own ugly narcissism, and it made me feel dirty to read a celebration of something that I recognized as a personal limitation in myself. Later I managed to get through about half of Atlas Shrugged. Along with The Lord of the Rings (another book that encourages people to embrace their prejudices) I saw it as a necessary initiation into the tribe of narrow, nerdy, alienated white males, which seemed like the only tribe that would have me. I opted out, and now they're cool and getting all these cute pseudo-nerdy chicks:-(
Atlas Shrugged did do me one favor: it confirmed a theory about narcissism that I had developed based on my own personal case. If you only understand your own virtues and ideas, then by process of elimination, you logically attribute all good in the world to the virtues and ideas you possess. The solution to all problems in the world, then, is for everyone to appreciate your virtues and to allow every question to be decided according to your ideas. Atlas Shrugged is Ayn Rand's personal thousand-page exploration of her narcissism. Civilization collapses without her virtues; utopia results from the pure practice of them. A very neat fit to my theory, which made me feel very smart -- I'm sure that's all there is to it;-)
The best you can do is reduce everything to mathematics, and even articles in peer-reviewed mathematical journals contain mistakes. Formal methods are no guarantee of perfection.
Even if you believe the most likely number of bugs in your code is zero, that is not very different from believing that the number of bugs is higher. You should never act on the belief that your code is bug-free.
I'm responding to this old troll because it's the first mention of communism in the thread.
The article's terrible economic reasoning is exactly the kind of folly that dooms planned economies. The defense of established interests is cast as defense of the common welfare, and the economy gets gummed up with mandatory crud that is deemed essential even though nobody wants it.
In a market system, companies aren't be allowed to justify their existence through whining. If a software vendor can't offer something that people want to buy, then they serve no economic purpose.
If you think open-source software "costs" the economy money by displacing commercial software, then I suppose you also think it's a straightforward win to ban cheap, superior imported goods so domestic manufacturers can sell inferior, overpriced goods.
The most remarkable thing about the whole Firefox memory leak issue was how strong the anecdotes and subjective opinions were,and how stunningly rare any actual empirical metrics were. Sorry, I didn't keep statistics about how many times per week Firefox crashed on me before I started preemptively restarting it. I just knew it was about twice a week. And it may not have actually crashed, since I didn't use a crashmeter. It was just my subjective impression.
You realize that we have amazing tools like debuggers, or at a higher level simply process performance metrics, right? You realize that it's the job of developers to use those things, and that the developers who used them found and fixed memory-related bugs, right? In any case, I just googled for a crash-detection utility for Linux that could distinguish between the sudden unrequested disappearance of a process and a true "crash", and I couldn't find one. So why don't you write one, and next time you're calling me deluded I'll use it.
The reason most complaints were shot down
... was that people were asshats, basically. The problem didn't happen for everybody, the bug reports were vague (because it's hard to file a precise bug report that involves opening and closing a couple hundred different web pages in browser tabs), and when somebody did reproduce the problem, they became the enemy as well. And, you know, the actual Firefox developers were (almost uniformly) much more civil than the idiots who simply wished to feel good about themselves by going to bat for an open-source cause. Some of the developers did reproduce specific problems reported by users, and some of the developers simply took users at their word (imagine that!), and they found (and fixed) quite a few real problems... and do you know what the fanboys said? "See? That proves the fucking users were wrong all along! They said 'the memory leak' and it wasn't just a single problem, some of the problems were leaks of other kinds of resources, and some of the problems couldn't properly called 'leaks' at all! Fucking ignorant shills talking about 'the memory leak'!"
Anyway, this should all be in the past. As far as I know, Firefox 2 fixed the last of the completely imaginary memory problems, and by most accounts Firefox 3 is even better than 2.
Memory usage has been the #1 complaint about Firefox since it was called Firebird. "Wahhhhh, I tried Firefox but holy does it use a lot of memory!". Go to any clutching desperately to their copy of IE board So, you're one of the people who thought that Firefox's memory problems were overblown? Firefox 1.x memory usage sucked balls for many people, mainly because of the "leak" which caused Firefox to get bigger, and slower, and bigger, and slower, and finally crash. I put "leak" in quotations marks because I remember how strident partisans deflected every mention of the "leak" with arguments over whether it should be described as a "leak" or not, as if imprecise use of language by users was a more important issue than Firefox swelling up and bursting like the guy in Monty Python's Meaning of Life. It seems that a bunch of Firefox fans (and even some developers) decided that all of the reports were just Microsoft FUD, and dedicated themselves to shouting down users who reported problems. Incidentally, when did you develop this little line of patter:
maybe the morons will have to move onto a different whine to explain their irrational attachment to all things Microsoft I've been using Firefox all along because even in the 1.x days it was easier to restart Firefox every two or three days than to use Opera or Konqueror. The lousy period of fanboys insulting everyone who experienced memory problems with Firefox dragged on long enough. Just put a sock in it.
Desktop managers are designed and made for people who can't use command lines and want something graphically cute. They are designed by people whose minds work in ways that most real engineers can't fully understand.
You're so right! All of those incredibly bland and straightforward themes could not have been produced by an engineering mindset. I'm sure the first thing Dilbert does after installing KDE is say, "Man, this thing needs some pizazz! I'm gonna make it look moody and dangerous!" Or maybe it's nerdy teenagers who do that. I don't remember.
"Linux" will never be ready for anybody; only individual distros will. I don't think this is an unreasonable way to handle it. If you look at the desktop market as a whole, there's no standard. People manage to figure out whether they want Windows or Mac. (A few decades ago they had a bunch more choices, and grown-ups these days have fond memories of the Commodore 64, TRS-80, or Apple IIe they had growing up.) We just have to add Ubuntu in there as a third choice, and add in other Linux distros when they become ready.
Anyway, how could we establish "Linux" as a brand even if we tried? It would be a lie! What happens when some poor user tries to download and install uClinux? Or a server-only distro? (Or, God forbid, Debian stable. "Why are all my apps three years old?!")
No, better not to promote "Linux" as a desktop brand. We would have to exterminate all the wonderful and useful non-consumer-friendly Linux distros, or we would have to explain them all. Neither one is even possible. You can't force embedded systems developers to use Ubuntu, and you can't explain to Joe Consumer that there's a single thing called "Linux" that runs on supercomputers and cell phones and the thing on his desk. Better to let people think, "Mac, Windows, or Ubuntu?" And then in a few years, "Mac, Windows, Ubuntu, or OldBamboox?"
If there is any uncertainty about GUI based apps on Linux being able to run on the desktop each and every time
There is already no question about this with well-packaged software and a decent package management system. Bad software and bad systems will always be floating around, though, unless we go on a crusade to purge the net of amateurish software. It's up to distros to steer users toward vetted and well-packaged software.
I have to re-iterate, KDE, installed during install, made Linux unusable for me each time
And I have to reiterate that it's the distro's job to configure KDE and install stable applications. Without going back in time to examine your only systems, there's no way to know whose fault it was that KDE didn't work for you, but there have been excellent KDE-based distros for at least five years -- I switched to SUSE from Red Hat in 2002 or 2003 and found it to be much more professional and trouble-free. Based on that, all I can say is that your distro(s) failed where others succeeded.
I'm keen to give KDE another try, because it looks amazing but I'm worried it will be bad again.
The latest stable Kubuntu based on KDE3 is quite good. Kubuntu replaces the KDE Control Center with their own slightly less functional control panel, so some configuration options are impossible to find -- but as a GNOME fan I'm sure you won't mind;-) On the other hand, you might as well wait until Kubuntu decides that KDE4 is stable and stops using KDE3 for its stable releases.
In my usage since 2002, I've never seen any instability or weird bugs out of KDE, except some of the KDE applications that were in early stages of development. You must have had the bad luck to try it on a distro that had poor support for it, forced you to install and configure it yourself, or installed alpha KDE apps instead of stable non-KDE alternatives. If you want a desktop that just works, you're better off trying KDE as packaged and configured by a decent distro, such as SUSE (in the old days) or Kubuntu (these days).
I agree with you about RPM. Incidentally, for several years RPM was the package management system used by the vast majority of the polished, user-friendly, point-and-click distros. The GUI front ends presented by Red Hat and especially SUSE were state-of-the-art. If distros had applied your "get out of the marketplace" attitude to package management systems, wouldn't RPM have taken over? Superior polish doesn't always mean the best long-term choice for usability.
it's a UI that is virtually promising that it will be horribly unstable, on account of it's bleeding edge
People who value stability should avoid alpha releases, beta releases, and maybe even first public releases if they're paranoid. It's just a fact of life with software. If GNOME is a temporary exception to this because they're concentrating on polishing the UI instead of making technological progress, that's fine, but it's just where they happen to be right now. No consumer-oriented desktop can afford to sit still and polish for too long, because their users would desert them.
No one should take Linus seriously on this. There is one and only one reason there is no C++ in the kernel: continuity of technical leadership. Linus and the other top kernel guys, and the guys they trust, are C gurus who have much less experience with C++. The success of Linux has a lot to do with the people acting as technical directors and gatekeepers, and it would be insane to create a path into the kernel that bypassed all of their expert critical ability. But Linus loves to stir things up, so he didn't say that. Instead, he said a bunch of snarky things about C++ to ingratiate himself to C programmers and dissuade anyone from pressing him further on the issue.
To address only one issue from his litany of complaints, his criticism of C++ abstraction mechanisms is unjustified. C++ abstractions are just as efficient as the C alternatives; Stroustrup kept a lot of potentially useful things out of the language to make sure that was the case. The few exceptions involve C++ language features that can and would be disabled in a kernel dialect. Also, abstractions are just ways of expressing design decisions. There are just as many design decisions in C as in C++, and design decisions in C get enshrined in code just like in C++. C++ abstractions do not embed design decisions into code more deeply than C abstractions.
I think Linus and many other C coders look at simple, elegant C code and think, "The 'right' way to write this in C++ would involve a inheritance and templates and a bunch of ungodly stuff." It isn't so. To the best of my knowledge, every C++ language feature (with the possible exception of exceptions) was invented to support a recurring design pattern that large-scale systems programmers were being forced to express badly in C. C macros (and other macro languages) were being used to create hackish, broken versions of inheritance, destructors, and templates. C++ language features were created to replace heinous macro and longjmp hackery, and to replace ad-hoc homegrown code generators, not to replace the simple, elegant kind of C code that actually works.
Of course C++ would be wrong for Linux. Continuity of technical leadership is a compelling reason to keep it out, but it would have sounded kind of lazy and conservative to say so. Bashing C++ sounds much more 1337. Frankly, I think it's pretty childish to bash a language just because you don't personally have a use for it. I think if someone abducted Linus into slavery and forced him to write corporate middleware systems in C, he would cry for a little while and then beg for permission to use a more suitable language, even if it was C++.
Unless you're perpetually instantiating objects using reflection, the need to cast is RARE.
Unfortunately, there is a single Java language wart that is single-handedly responsible for rampant casting when dealing with inheritance heirarchies. Here's an example: In the Eclipse framework, if you're using a TableViewer to display a table of items to a user, you can get the current selection (the items selected by the user) by calling tableViewer.getSelection(). The type returned by tableViewer.getSelection() is IStructedSelection. However, the getSelection method on TableViewer overrides a getSelection method defined on StructuredViewer, which is declared to returned ISelection. Therefore, the getSelection method on TableViewer is also declared to return ISelection, and every time you call tableViewer.getSelection you have to cast it from ISelection to IStructuredSelection.
This practice was created to deal with the lack of return type covariance prior to Java 1.5. Before Java 1.5, a method returning ISelection could not be overridden by a method returning IStructuredSelection, even though IStructuredSelection is a subtype of ISelection. Many valuable libraries and frameworks date back to before the fix. and there are probably still lots of Java coders who keep coding the old way out of ignorance. Therefore, rampant casting will be a fact of life in Java for years to come.
Stroustrup's book has passed the test of time. It's the only C++ book I own and I can say (without modesty) that I'm a fairly proficient C++ programmer. The book is the right mix of examples and is a very adequate reference.
Amen. Stroustrup is a brilliant writer and teacher. I didn't realize until much later how lucky I was to have learned C++ from TC++PL instead of from any other C++ book. He teaches the language semantics, the reasons for the language design, what C++ is good for, its shortcomings, and the ideology necessary for using it effectively. He does all of this in a way that made perfect sense to me as a programming neophyte and is still intellectually satisfying to me ten years later as a professional programmer who also does Java, Common Lisp, Python, and Scala.
I particularly like the way Stroustrup teaches the ideology of C++. Most people approach ideology in absolute terms. Either ideologies themselves are evil, or a person has a single ideology which is either correct or evil. Stroustrup teaches the ideology of C++ in a neutral way. C++ is designed to implement programs that are conceived of according to a particular ideology, and if you think in this way you will get the most out of C++. The entire text of TC++PL is dedicated to communicating the C++ ideology, while at the same time making it clear that C++ strives to be agnostic about certain things as well. Of course, you need to be capable of thinking in other ways (or else you are a very limited person), but if you find yourself thinking in a way that is inimicable to C++ while programming in C++, you need to be careful, because C++ may work against you.
This is a very refreshing approach to the ideology of a programming language. Other programming language books are either ridiculously namby-pamby about ideology or attempt to indoctrinate you into a single way of thinking. Stroustrup offers C++ and its ideology without claiming supremacy for it but without apologizing for it either. TC++PL was my first and deepest influence as a programmer, and it taught me (by example) that I should strive to get as much power and insight as possible out of every language I encounter, from Java to Haskell. Stroustrup is completely the opposite of the intellectually sclerotic partisans who bash their own teeth out with a hammer and then scream, "See? See? This is why you should never touch anything but a toothbrush."
The thing is that Java is extraordinarily similar to C++. If you are a competent C++ programmer, you can learn Java in an afternoon (or less). If you are a competent Java programmer, it will take you a little bit longer to learn C++. At least a few days by my estimation.
This is supposed to be funny, right? Java and C++ are vastly different languages. Java was designed to use a similar syntax to C++ and to (kind of) work when treated as a restricted subset of C++, but that was just for the sake of tricking extremely lazy and conservative corporate programmers into giving it a fair chance. Java programmers don't have to know about header files, macros, operators, the distinction between stack and heap objects, destructors, RAII, and techniques for managing heap objects in the absence of garbage collection. C++ programmers don't have to know about classloaders, type erasure, garbage collection, or introspection. The design skills for the two languages are also completely different, since they have different shortcomings.
In fact, I see no real advantage in teaching Java over C++.
On the contrary, they are very different approaches, each with advantages.
Java has two primary advantages: safety and simplicity. C++ has one big advantage: it's a much more flexible language that allows students to explore a much broader subset of computer science concepts.
Students can get up to speed pretty fast in Java. Java has a lot of features that only make sense in the context of industrial-scale programming, but students will learn not to ask why. If they get past that part, it doesn't take long to learn a useful subset of Java. A bright student can conceivably become a language expert in less than a year. Plus, programming in Java is extremely convenient. The debuggers are rich, the errors are informative, and the stack traces come in very handy. That means students can devote more of their brainpower to learning CS instead of struggling with the language. The downside is that Java can only express the very narrow range of concepts that were deemed necessary for mediocre programmers writing industrial-scale software. Java is intentionally restricted in its power and in its style, and those restrictions will be imprinted on the brains of students who are taught mostly in Java.
In C++, you have to deal with memory leaks, corrupted memory, unexplained segfaults, and other issues that sidetrack students for hours and days while they're supposed to be learning basic CS concepts. It's a bit of a lie to teach first-year students in C++ and pretend to be teaching them computer science. Mostly they're learning how to debug C++ programs. On the upside, you can go much farther in C++ than you can in Java. C++ was designed to empower programmers to express as many different ideas and styles of programming as possible while preserving C interoperability and the performance characteristics of C. C++ was designed on the assumption that even though it isn't safe to trust the judgment of the individual programmer, there is no better alternative. Java was designed around the opposite assumption: don't trust the taste of the programmer; shoehorn him into a single, neutered programming paradigm in which he can't do much harm. The design of Java ensures that powerful concepts cannot be expressed in Java by individual programmers but must be layered on top by framework designers.
C++ : Java:: English : a 1000-word subset of Esperanto
It's easy to fool yourself into thinking that students will learn more if they don't have to go through the excruciating process of learning a complex, crufty, logically flawed real-world language that evolved to accommodate the impulses of its users. It's wrong; it's an illusion. An artificially restricted language circumscribes your thinking. I've heard the complaint that teaching students in C++ gives an unfair advantage to those who had an earlier start in the languag
The poster I replied to was trying to equate calling Anonymous assholes with an assault on internet anonymity. The first part of that equation was the moral disapproval in question.
Your reading comprehension stands accused of being utter shit. Based on the evidence against it, I find it guilty. There's a fair and speedy trial for you.
Background: I'm not a WoW player or an FPS player. I generally don't play online games against other people, and I avoid forums set up in a way that encourages casual trolling. I got excellent scores on the verbal sections of the SAT and GRE:-)
I like the words "griefer" and "griefing" and would not hesitate to use them in conversation. They are not redundant with other words that are already in my vocabulary. I know other words like "jerk" and "asshole" and "sadist," but they're a bit different. "Sadist" is similar to "griefer," but even "sadist" describes a person's character more than his actions.
To me, "griefing" suggests something open, superficial, and habitual, while "sadism" suggests something profound that may be entirely hidden. A griefer might leave a broken bottle on an old man's back porch and laugh about it, but would probably feel sick if he saw an old man crying with glass stuck in his feet. A sadist wouldn't bother leaving the bottle if he couldn't watch.
Griefers wish they were sadists, but they aren't. Thus, they must take an industrial approach rather than a hedonistic one -- "How much pain have I caused?" instead of "How much pain have I enjoyed?" The internet is a perfect place for griefing, because you can gloat about a person's suffering without experiencing the empathic response that a real, live, suffering human being might provoke.
Fair Game policy, which states that Scientology critics, or "Suppressive Persons (SPs)", "may be deprived of property or injured by any means by any Scientologist without any discipline of the Scientologist. May be tricked, sued or lied to or destroyed."
So on one side, you have assholes trying desperately to pretend they aren't evil, while on the other side, you have assholes trying desperately to take pride in being evil. I have to give the edge to the Scientologists. They have a shitload of money, a huge organization, and some seriously good-looking people. From the pictures I've seen of the anti-Scientology protests, Anonymous seems to have (at most) a couple hundred chubby kids who really should have brought enough masks for everyone.
If law enforcement can't nail these guys, then they may as well throw in the towel, because it means they lost.
That's a bit of an overreaction. As far as I know, nobody even died in this case. People get away with murder every day. Law enforcement doesn't show any sign of giving up. That would be pretty childish, even for the police.
You can't identify subsets of the group (which is intended), thus you can only talk about the whole group.
You don't have to be Anonymous to be anonymous. Why do people accept the label of Anonymous, organize under that label, and not enable any distinction between themselves and other members of Anonymous? Clearly they wish to benefit from the existing label and its notoriety, which was built on griefing. Just as clearly, their participation in Anonymous helps sustain the meme. It's nothing but wishful thinking to help sustain something and seek to benefit from it while disclaiming moral responsibility for its effects. A structure that obscures responsibility does not erase it.
He misspelled "Anonymous" as "anonymous" and you know it. And do you really think an expression of moral disapproval is a danger to your rights? If that were the case, then our rights would be meaningless. Don't get me wrong; the people who come to take our rights away will doubtlessly lead with moral disapproval. However, if your right to do something means I'm not supposed to condemn you for doing it, that would seriously complicate my feelings about your rights.
In general, it's far better to do no wrong, rather than dream up ways to avoid getting caught. You're not safe using EC2 for criminal activity...
You slept through high school civics class, didn't you? That's not the point. When someone in the government sees you as an enemy, whether it's because
They sincerely think you've done something bad;
You're a business competitor of their friend, patron, or ally;
You support the wrong party in a significant and meaningful way;
You support an organization or proposal that threatens their bureaucratic fiefdom;
Or, they simply think you're hindering them from doing their very important job;
... they will treat you like a criminal who happens not to have been convicted of a crime yet. Most people are incapable of seeing you as an enemy without developing a feeling of moral disgust toward you. That's why we're so paranoid about the rights of criminals in the United States. You don't see nearly as many people bitching about the rights of criminals who have been convicted. (A few people get excited about it, but not as many.) Criminals are fined, confined against their will, forced to wear uniforms, given very limited privacy, forced to report to parole officers, etc. We're fine with that. What we worry about is the rights of criminals before they get convicted, because we know (and you should, too) that every citizen is a criminal in the eyes of somebody in the government.
Personally, I'm probably only a criminal in the eyes of the lady at the DMV who had to admit (after wasting five minutes telling me I was wrong) that a mistake HAD been made and needed to be corrected. She was involved in neither the mistake nor the correction; nevertheless, she was seething with anger because I had persisted in disagreeing with her. If she had the power, she would have suspended my license on the spot. In some countries that would have been possible. Even in the Western world, in the old days, you could be arbitrarily stripped of your rights by an accusation that you were a criminal. It seemed like a common-sense thing to do, but at some point we realized it worked out very poorly in practice, so we used the concept of rights, buttressed by judicial oversight, to prevent abuses.
Now, in the new old days, there's a suggestion that you can be arbitrarily stripped of your rights by an accusation that you are a terrorist. It's an awfully handy tool for an official to have if, say, they wanted to do a favor for one of your business competitors. They could open a terrorism investigation, take a quick look-see through your Amazon EC2 servers, tell your competitor what they saw, and close the investigation with the finding that you weren't a terrorist after all. (See? The system works.) What kind of judicial oversight applies to this? Didn't the Bush administration say that they had the constitutional authority to ignore any laws passed by Congress, and any decisions handed down by the judiciary, that might hinder their ability to fight terrorism? You can't discount the possibility they are living up to their words and entrusting unreasonable powers to government agents, who are just human beings and not beyond the reach of blackmail, bribery, partisanship, and the allure of powerful friends.
In other words, now is a bad time to trust the government to respect your rights. (As if there were ever a good time.) If you harbor any hope that your business or other endeavor will succeed enough to gain the attention of powerful people, you should think like a criminal. Without transparency and meaningful judicial oversight, we're all criminals. And don't we all harbor the dream that someday we'll make a big enough splash that we get some important shoes wet?
To be honest I think this says less about the security of various platforms (after all we have to be slightly impressed Windows lasted so long), but more about the security of open source versus closed source. The operating systems themselves didn't seem to be at fault as much as extra apps (although Safari may be an exception here).
Users follow the normal path of least resistance established by the platform. Users' first tendency is to use the apps that are installed by default, which means mostly open-source apps on Linux and closed-source apps on Windows. When an appropriate application isn't installed, consumer-targeted Linux distributions help steer users toward good open-source applications. Under Windows, you usually end up installing a closed-source application suggested by a web site. Windows application security depends not just on closed-source software but on users' ability to evaluate the credibility of web sites and spot spoofed web sites (like the ones used for phishing, but used for distributing malware instead). Under Linux, those skills are still important, but since the normal method of installing software is to download packages maintained by the distribution, users will be more likely to pay special attention when installing software from other sources.
In sum, what this means is that Windows systems depend heavily on closed-source software and the judgment of individual users, both of which are less secure than the community-oriented "more eyes" approach taken by open-source Linux distributions.
The death of SCSI predicted once again. Everyone keeps predicting it's death, but I can't seem to get rid of it in my serverroom. Guess what the last letter in SAS stands for?
If you read the article.... Oh, sorry, I just realized this thread was created especially for people who didn't read the article. Carry on.
Slashdot Mirror
This isn't just about ways of learning. Anyone in diplomatic or intelligence circles should learn by reading history books, case files, briefs, and the opinions of a wide variety of other analysts, not by immersing themselves in the narrow visions of the very small number of people who sponsor and direct the production of these training games. You only have to consider the names of the games to know that the current games are tilted towards crises and short-term consequences. It's bad enough that the average citizen worries only about military aggression and dramatic terrorist threats. If our diplomatic and intelligence analysts tilt that way, who will be left to worry about the other 98% of our foreign affairs: commerce, diplomacy, public perception, energy security...? Are we gearing up for a series of military "victories" that weaken the nation and leave Americans worse off?
In general, the use of video games will narrow the understanding of analysts and place too much power in the hands of a few people to instill ideology and warped visions of the world. Think of the group of wonks you believe have the most warped and simplistic view of the world. Now imagine an entire generation of analysts trained using games designed by those people. All it would take is a run of presidential election success by one party. Does that sound like a good way to train analysts whose job is to pick up on things that their masters failed to predict?
I've worked with code written in the "pages-long function" style. One thing I've found consistently in such code is duplicated functionality. I've even personally seen how this happens: A programmer implements a very large, complex piece of functionality as a function. Later, the need arise to implement a variation on this functionality. It turns out that the variation is quite structurally different, so to implement it by parameterizing the original function would result in spaghetti code. So, a second enormous function is written. The programmer scans the two functions and finds no large sections of code that are duplicated between the two functions, so he calls the job done.
Naturally, code developed in this manner degenerates into an unmanageable mess as more and more variations are added. Anyone trying to program this way in the business world, for example, will quickly drown. However, people tend to get by with this style in the scientific computing world, where there are relatively few variations that cannot be handled by parameterization.
The first thing that must be done to get out of this mode of programming is to assume that such variations will arise. Treat the first problem you solve as merely the first of many variations that you will be asked to solve in the future. (Either that, or make the opposite assumption and then completely rewrite your code when the second variation arises.) Then, analyze each variation in terms of the things it must accomplish. You can categorize things using problem domain concepts, solution domain concepts, whatever, as long as you can put names on things.
(The tendency to think in human terms and give natural language names to things is a hindrance to mathematical insight, but it often generates effective ways to decompose code. Perhaps this is another reason why the "big function" style tends to plague scientific computing.)
Once you have split the original task into conceptually separate chunks that can be given reasonable natural language names, split the program up into pieces that have those names.
Voila, now you have a program made of small chunks that can be understood by other programmers. And, since each chunk has a reasonable name, programmers can limit themselves to reading the name and documentation of most pieces of the program, rather than reading every single line of code. This makes the code effectively shorter and easier to maintain, even if you never reuse the chunks to compose a new variation.
This is why good programmers must be good writers as well. The ability to explain the structure of code, primarily with clear, precise names for classes, functions, and variables and secondarily with comments, is as important as the ability to decompose a program logically. I have seen programs that were twice as complex as they should have been, yet made perfect sense and were easy to hack on, because the code and comments made it easy to understand the original programmer's understanding.
In the interview, Knuth gave one reason why literate programming isn't popular: few people are good programmers, few people are good writers, and literate programming only works for people who fall into both categories. I think he's right. Encouraging people to write more unstructured prose than they feel a need to results in worthless verbiage, and most programmers naturally limit their comments to sentence fragments and the occasional short paragraph. If you have to force people to write, you need to provide structure and clear expectations. That's why Javadoc and similar schemes are so much more valuable in practice than literate programming.
I think markets are a great tool for many purposes, but they can produce inefficient systems and can reward destructive behavior. We should be careful about subordinating our judgment to markets. They're a bit like computers: we should only trust them with problems that we know they solve reliably, and when they're obviously screwing up, we should rethink our trust. We shouldn't say, "Well blow me down, I never realized raping babies was a good thing until that guy got rich doing it," any more than we would say, "I guess I don't really need my data, because otherwise this program wouldn't keep deleting it."
I tried to read The Fountainhead in high school but couldn't bear to read more than a few dozen pages. It was like a mirror of my own ugly narcissism, and it made me feel dirty to read a celebration of something that I recognized as a personal limitation in myself. Later I managed to get through about half of Atlas Shrugged. Along with The Lord of the Rings (another book that encourages people to embrace their prejudices) I saw it as a necessary initiation into the tribe of narrow, nerdy, alienated white males, which seemed like the only tribe that would have me. I opted out, and now they're cool and getting all these cute pseudo-nerdy chicks :-(
Atlas Shrugged did do me one favor: it confirmed a theory about narcissism that I had developed based on my own personal case. If you only understand your own virtues and ideas, then by process of elimination, you logically attribute all good in the world to the virtues and ideas you possess. The solution to all problems in the world, then, is for everyone to appreciate your virtues and to allow every question to be decided according to your ideas. Atlas Shrugged is Ayn Rand's personal thousand-page exploration of her narcissism. Civilization collapses without her virtues; utopia results from the pure practice of them. A very neat fit to my theory, which made me feel very smart -- I'm sure that's all there is to it ;-)
Even if you believe the most likely number of bugs in your code is zero, that is not very different from believing that the number of bugs is higher. You should never act on the belief that your code is bug-free.
The article's terrible economic reasoning is exactly the kind of folly that dooms planned economies. The defense of established interests is cast as defense of the common welfare, and the economy gets gummed up with mandatory crud that is deemed essential even though nobody wants it.
In a market system, companies aren't be allowed to justify their existence through whining. If a software vendor can't offer something that people want to buy, then they serve no economic purpose.
If you think open-source software "costs" the economy money by displacing commercial software, then I suppose you also think it's a straightforward win to ban cheap, superior imported goods so domestic manufacturers can sell inferior, overpriced goods.
Anyway, this should all be in the past. As far as I know, Firefox 2 fixed the last of the completely imaginary memory problems, and by most accounts Firefox 3 is even better than 2.
Anyway, how could we establish "Linux" as a brand even if we tried? It would be a lie! What happens when some poor user tries to download and install uClinux? Or a server-only distro? (Or, God forbid, Debian stable. "Why are all my apps three years old?!")
No, better not to promote "Linux" as a desktop brand. We would have to exterminate all the wonderful and useful non-consumer-friendly Linux distros, or we would have to explain them all. Neither one is even possible. You can't force embedded systems developers to use Ubuntu, and you can't explain to Joe Consumer that there's a single thing called "Linux" that runs on supercomputers and cell phones and the thing on his desk. Better to let people think, "Mac, Windows, or Ubuntu?" And then in a few years, "Mac, Windows, Ubuntu, or OldBamboox?"
There is already no question about this with well-packaged software and a decent package management system. Bad software and bad systems will always be floating around, though, unless we go on a crusade to purge the net of amateurish software. It's up to distros to steer users toward vetted and well-packaged software.
And I have to reiterate that it's the distro's job to configure KDE and install stable applications. Without going back in time to examine your only systems, there's no way to know whose fault it was that KDE didn't work for you, but there have been excellent KDE-based distros for at least five years -- I switched to SUSE from Red Hat in 2002 or 2003 and found it to be much more professional and trouble-free. Based on that, all I can say is that your distro(s) failed where others succeeded.
The latest stable Kubuntu based on KDE3 is quite good. Kubuntu replaces the KDE Control Center with their own slightly less functional control panel, so some configuration options are impossible to find -- but as a GNOME fan I'm sure you won't mind
I agree with you about RPM. Incidentally, for several years RPM was the package management system used by the vast majority of the polished, user-friendly, point-and-click distros. The GUI front ends presented by Red Hat and especially SUSE were state-of-the-art. If distros had applied your "get out of the marketplace" attitude to package management systems, wouldn't RPM have taken over? Superior polish doesn't always mean the best long-term choice for usability.
People who value stability should avoid alpha releases, beta releases, and maybe even first public releases if they're paranoid. It's just a fact of life with software. If GNOME is a temporary exception to this because they're concentrating on polishing the UI instead of making technological progress, that's fine, but it's just where they happen to be right now. No consumer-oriented desktop can afford to sit still and polish for too long, because their users would desert them.
No one should take Linus seriously on this. There is one and only one reason there is no C++ in the kernel: continuity of technical leadership. Linus and the other top kernel guys, and the guys they trust, are C gurus who have much less experience with C++. The success of Linux has a lot to do with the people acting as technical directors and gatekeepers, and it would be insane to create a path into the kernel that bypassed all of their expert critical ability. But Linus loves to stir things up, so he didn't say that. Instead, he said a bunch of snarky things about C++ to ingratiate himself to C programmers and dissuade anyone from pressing him further on the issue.
To address only one issue from his litany of complaints, his criticism of C++ abstraction mechanisms is unjustified. C++ abstractions are just as efficient as the C alternatives; Stroustrup kept a lot of potentially useful things out of the language to make sure that was the case. The few exceptions involve C++ language features that can and would be disabled in a kernel dialect. Also, abstractions are just ways of expressing design decisions. There are just as many design decisions in C as in C++, and design decisions in C get enshrined in code just like in C++. C++ abstractions do not embed design decisions into code more deeply than C abstractions.
I think Linus and many other C coders look at simple, elegant C code and think, "The 'right' way to write this in C++ would involve a inheritance and templates and a bunch of ungodly stuff." It isn't so. To the best of my knowledge, every C++ language feature (with the possible exception of exceptions) was invented to support a recurring design pattern that large-scale systems programmers were being forced to express badly in C. C macros (and other macro languages) were being used to create hackish, broken versions of inheritance, destructors, and templates. C++ language features were created to replace heinous macro and longjmp hackery, and to replace ad-hoc homegrown code generators, not to replace the simple, elegant kind of C code that actually works.
Of course C++ would be wrong for Linux. Continuity of technical leadership is a compelling reason to keep it out, but it would have sounded kind of lazy and conservative to say so. Bashing C++ sounds much more 1337. Frankly, I think it's pretty childish to bash a language just because you don't personally have a use for it. I think if someone abducted Linus into slavery and forced him to write corporate middleware systems in C, he would cry for a little while and then beg for permission to use a more suitable language, even if it was C++.
This practice was created to deal with the lack of return type covariance prior to Java 1.5. Before Java 1.5, a method returning ISelection could not be overridden by a method returning IStructuredSelection, even though IStructuredSelection is a subtype of ISelection. Many valuable libraries and frameworks date back to before the fix. and there are probably still lots of Java coders who keep coding the old way out of ignorance. Therefore, rampant casting will be a fact of life in Java for years to come.
I particularly like the way Stroustrup teaches the ideology of C++. Most people approach ideology in absolute terms. Either ideologies themselves are evil, or a person has a single ideology which is either correct or evil. Stroustrup teaches the ideology of C++ in a neutral way. C++ is designed to implement programs that are conceived of according to a particular ideology, and if you think in this way you will get the most out of C++. The entire text of TC++PL is dedicated to communicating the C++ ideology, while at the same time making it clear that C++ strives to be agnostic about certain things as well. Of course, you need to be capable of thinking in other ways (or else you are a very limited person), but if you find yourself thinking in a way that is inimicable to C++ while programming in C++, you need to be careful, because C++ may work against you.
This is a very refreshing approach to the ideology of a programming language. Other programming language books are either ridiculously namby-pamby about ideology or attempt to indoctrinate you into a single way of thinking. Stroustrup offers C++ and its ideology without claiming supremacy for it but without apologizing for it either. TC++PL was my first and deepest influence as a programmer, and it taught me (by example) that I should strive to get as much power and insight as possible out of every language I encounter, from Java to Haskell. Stroustrup is completely the opposite of the intellectually sclerotic partisans who bash their own teeth out with a hammer and then scream, "See? See? This is why you should never touch anything but a toothbrush."
This is supposed to be funny, right? Java and C++ are vastly different languages. Java was designed to use a similar syntax to C++ and to (kind of) work when treated as a restricted subset of C++, but that was just for the sake of tricking extremely lazy and conservative corporate programmers into giving it a fair chance. Java programmers don't have to know about header files, macros, operators, the distinction between stack and heap objects, destructors, RAII, and techniques for managing heap objects in the absence of garbage collection. C++ programmers don't have to know about classloaders, type erasure, garbage collection, or introspection. The design skills for the two languages are also completely different, since they have different shortcomings.
On the contrary, they are very different approaches, each with advantages.
Java has two primary advantages: safety and simplicity. C++ has one big advantage: it's a much more flexible language that allows students to explore a much broader subset of computer science concepts.
Students can get up to speed pretty fast in Java. Java has a lot of features that only make sense in the context of industrial-scale programming, but students will learn not to ask why. If they get past that part, it doesn't take long to learn a useful subset of Java. A bright student can conceivably become a language expert in less than a year. Plus, programming in Java is extremely convenient. The debuggers are rich, the errors are informative, and the stack traces come in very handy. That means students can devote more of their brainpower to learning CS instead of struggling with the language. The downside is that Java can only express the very narrow range of concepts that were deemed necessary for mediocre programmers writing industrial-scale software. Java is intentionally restricted in its power and in its style, and those restrictions will be imprinted on the brains of students who are taught mostly in Java.
In C++, you have to deal with memory leaks, corrupted memory, unexplained segfaults, and other issues that sidetrack students for hours and days while they're supposed to be learning basic CS concepts. It's a bit of a lie to teach first-year students in C++ and pretend to be teaching them computer science. Mostly they're learning how to debug C++ programs. On the upside, you can go much farther in C++ than you can in Java. C++ was designed to empower programmers to express as many different ideas and styles of programming as possible while preserving C interoperability and the performance characteristics of C. C++ was designed on the assumption that even though it isn't safe to trust the judgment of the individual programmer, there is no better alternative. Java was designed around the opposite assumption: don't trust the taste of the programmer; shoehorn him into a single, neutered programming paradigm in which he can't do much harm. The design of Java ensures that powerful concepts cannot be expressed in Java by individual programmers but must be layered on top by framework designers.
C++ : Java :: English : a 1000-word subset of Esperanto
It's easy to fool yourself into thinking that students will learn more if they don't have to go through the excruciating process of learning a complex, crufty, logically flawed real-world language that evolved to accommodate the impulses of its users. It's wrong; it's an illusion. An artificially restricted language circumscribes your thinking. I've heard the complaint that teaching students in C++ gives an unfair advantage to those who had an earlier start in the languag
Your reading comprehension stands accused of being utter shit. Based on the evidence against it, I find it guilty. There's a fair and speedy trial for you.
Sigh.
Background: I'm not a WoW player or an FPS player. I generally don't play online games against other people, and I avoid forums set up in a way that encourages casual trolling. I got excellent scores on the verbal sections of the SAT and GRE :-)
I like the words "griefer" and "griefing" and would not hesitate to use them in conversation. They are not redundant with other words that are already in my vocabulary. I know other words like "jerk" and "asshole" and "sadist," but they're a bit different. "Sadist" is similar to "griefer," but even "sadist" describes a person's character more than his actions.
To me, "griefing" suggests something open, superficial, and habitual, while "sadism" suggests something profound that may be entirely hidden. A griefer might leave a broken bottle on an old man's back porch and laugh about it, but would probably feel sick if he saw an old man crying with glass stuck in his feet. A sadist wouldn't bother leaving the bottle if he couldn't watch.
Griefers wish they were sadists, but they aren't. Thus, they must take an industrial approach rather than a hedonistic one -- "How much pain have I caused?" instead of "How much pain have I enjoyed?" The internet is a perfect place for griefing, because you can gloat about a person's suffering without experiencing the empathic response that a real, live, suffering human being might provoke.
He misspelled "Anonymous" as "anonymous" and you know it. And do you really think an expression of moral disapproval is a danger to your rights? If that were the case, then our rights would be meaningless. Don't get me wrong; the people who come to take our rights away will doubtlessly lead with moral disapproval. However, if your right to do something means I'm not supposed to condemn you for doing it, that would seriously complicate my feelings about your rights.
Personally, I'm probably only a criminal in the eyes of the lady at the DMV who had to admit (after wasting five minutes telling me I was wrong) that a mistake HAD been made and needed to be corrected. She was involved in neither the mistake nor the correction; nevertheless, she was seething with anger because I had persisted in disagreeing with her. If she had the power, she would have suspended my license on the spot. In some countries that would have been possible. Even in the Western world, in the old days, you could be arbitrarily stripped of your rights by an accusation that you were a criminal. It seemed like a common-sense thing to do, but at some point we realized it worked out very poorly in practice, so we used the concept of rights, buttressed by judicial oversight, to prevent abuses.
Now, in the new old days, there's a suggestion that you can be arbitrarily stripped of your rights by an accusation that you are a terrorist. It's an awfully handy tool for an official to have if, say, they wanted to do a favor for one of your business competitors. They could open a terrorism investigation, take a quick look-see through your Amazon EC2 servers, tell your competitor what they saw, and close the investigation with the finding that you weren't a terrorist after all. (See? The system works.) What kind of judicial oversight applies to this? Didn't the Bush administration say that they had the constitutional authority to ignore any laws passed by Congress, and any decisions handed down by the judiciary, that might hinder their ability to fight terrorism? You can't discount the possibility they are living up to their words and entrusting unreasonable powers to government agents, who are just human beings and not beyond the reach of blackmail, bribery, partisanship, and the allure of powerful friends.
In other words, now is a bad time to trust the government to respect your rights. (As if there were ever a good time.) If you harbor any hope that your business or other endeavor will succeed enough to gain the attention of powerful people, you should think like a criminal. Without transparency and meaningful judicial oversight, we're all criminals. And don't we all harbor the dream that someday we'll make a big enough splash that we get some important shoes wet?
In sum, what this means is that Windows systems depend heavily on closed-source software and the judgment of individual users, both of which are less secure than the community-oriented "more eyes" approach taken by open-source Linux distributions.