Preachiness - I think this partly results from the twin facts that a) a lot of C++'s best features were added incrementally, and compiler support came even later; and b) a lot of C++ programmers are really C programmers who never bothered to learn C++ as a discrete language, and whose knowledge of C++ doesn't extend much beyond classes and new/delete. Which is fine, until you have one of these programmers working alongside someone who really knows C++, on the same project. At that point, it's time to adapt or die for the old-schooler, because certain bad old habits are not just ugly, they will actually cause bugs.
As an example, they are right. You should never, ever, ever use malloc() in new code. That's on the level of "don't use goto". If anyone is "preachy" about this point, it is because your indiscriminate use of malloc() threatens their code with insidious, hard-to-track-down memory errors. This is on the level of using static variables inside a function, and requiring client code to call some init() function before every call in order to flush out old static data. I would be equally "preachy" if we were on a work site and you ignored basic safety regulations.
On the other hand, those who preach about object-orientation always being the "right" way need to be smacked. And anyone who preaches to you about how you should write code that they themselves will never have to work with or call out to has too much time on their hands.
Where the hell did that bit of misinformation start? I've been hearing it a lot lately, and there's not a jot of truth to it. Python started out as a fairly limited procedural scripting language with C-style syntax, used for in-house scripting. It was "inspired" by the need to script things.
Since then it has added a few lisp-ish features, but no more so than dozens of other languages. Taking some of the most distinctive features of Lisp:
Code is Just Data Not in Python it isn't. This is arguably the most important feature of Lisp, and it's difficult to see how a language which cannot cleanly manipulate code at run time can be said to be "inspired by Lisp". Even TCL is more like Lisp than Python in this sense.
Lambdas Lambdas were only added relatively lately to Python, and in a severely limited form. In this sense Perl, Ruby, Smalltalk, and even Java (with it's anonymous inner classes) are more Lisp-like than Python.
Continuations Not supported, and I gather that the architecure of the Python interpreter is such that they may never be supported. Ruby, being actually inspired by Lisp (among others) from inception, naturally supports them.
CLOS Lisp has one of the most advanced and flexible object systems around. Python's is feeble and kludgey by comparison.
Tail Recursion One can't do a lot of Lisp-style funtional programming without proper tail recursion. A quick definition of an infinitely tail-recursive function in Python shows that Python lacks this: a "maximimum recursion depth" exception is eventually thrown. I understand this is another of those fundamental architecture issues, another artifact of the the fact that the Python interpreter was designed with strictly C-style programming in mind.
Macros Lisp's usefulness in creating Domain-Specific Languages (DSLs) stems from it's powerful macro system. Python has no such system. Even C's pathetic preprocessor beats Python in this regard.
In short, there is nothing "lisp-inspired" in Python that is not done better in supposedly less lisp-like languages.
Take a hundred-line snippet of Python code. Stick it into a web page. Copy&paste the web page to an email. Post the email to a programming mailing list. Have a lengthy thread about the code, quoting and requoting the original.
Now, let an intermediate Python programmer try to take the mangled code from the end of that thread and reformat it so that it works as intended. If it were in a language with explicit block syntax, chances are it would run as intended with nothing more than the removal of any quoting prefixes that mail clients have added. And a decent programmer would be able to whip up a script that would automate the transformation from mangled code into nicely indented code. Not so for the Python code.
The problem is not so much that whitespace is signifigant by default; it's that there is no way to modify this behaviour in order to generate "portable" code which can survive whitespace mangling.
But frankly, all things considered, whitespace signifigance is by far the least of Python's worries.
Heh... I have a friend who is re-writing Mark Pilgrim's ultra-liberal RSS parser in Ruby. See http://www.alieniloquent.com/rerss/ if you are interested.
Metaclass hacking starts out seeming easy, but then you start running into walls. Usually not insurmountable ones, but eventually the methods of circumvention make it more trouble than it's worth. For one thing, you can't do much serious metaclass hacking without having to resort to eval-ed strings (not blocks; strings), which I regard as a failing. I shouldn't have to drop down to the string-munging level to generate new methods on the fly. Once I've resorted to string-munging I lose all the benefits of compile-time syntax checking, and things become harder to debug. Another thing you can't do in Ruby is to apply "advice" to methods - prepending, appending, or wrapping an existing method with new code. You can do this manually, but it's a pain in the ass - you have to save the existing method with a proc or an alias and then rewrite the method, inserting a call to the original code at the appropriate point.
Ruby does not have the kind of namespace support I'm talking about. I'm talking about namespaces that are orthogonal to the class/module system. Ruby's ability to dynamically extend system classes at runtime is extrememly powerful, but it's hampered by the lack of a crosscutting namespace model. Library writers are discouraged from writing extensions to built-in classes by the fact that they never know when their extensions will collide with some other author's extensions. Supposing Karen writes security extensions module, including a new lock method on the Object class. Supposing Bob writes a concurrent programming extensions module, which includes a Object#lock method which acquires a thread-specific lock on the object. Then supposing I want to use both modules for an application I'm writing. Oops - name collision! There are also subtler errors possible when two different extensions coincidentally use the same name for an internal instance variable. Ruby needs a way to garauntee that methods added to existing classes, either by direct extension or via mixin, can operate safely without worrying about colliding with another method's namespace.
C Let's start this off nice and flameworthy: what is the point of using C anymore? Nearly any valid C program is a valid C++ program, and C++ gives me the option of selectively using much higher-level abstractions than C can support, with little or no overhead, in a much safer and easire-to-debug way than any pure-C approximation. And most of the projects which are coded in C these days shouldn't even be coded in C++; they should be coded in something higher-level like Java or Python.
C++
Manifest typing is so damn verbose! If the compiler's so clever, why can't it do a little type inferencing?
Needs Java's inner classes to do typesafe pseudo-closures
All C++ compilers suck. This in itself is not the problem; the problem is that all compilers suck differently.
Templates are powerful, but ugly
C++ code is full of juicy semantic information, which all IDEs uniformly fail to exploit, making coding far more painful than it should be in such a mature language.
Java
In their haste to throw out every frightening piece of "complexity" from C++, the designers managed to throw out all the expressive power as well. The result is a langauge that is so syntactically impoverished that it is actually less readable than C++, the language it sets out to improve upon. See the bloated maintenance nightmares that are used to work around the lack of enums, just as one example.
Ironically, by eschewing out C++'s "confusing" features, Java actually manages to be more error-prone than C++. For example, by forcing casts to be used everywhere, Java defers to runtime a whole class of errors that would never make it past the C++ compiler. This makes type errors much harder to track down, hardly a net gain for the novice programmer.
Perl
Doing OO in Perl is like... doing OO in C. Sure, you can do it, but it probably won't work with anyone else's OO code, and you have to do a lot of the compiler's work yourself.
Perl isn't as ugly as the Python fanatics claim it is; but there's still a hard limit on how readable it can ever be. Any language where the canonical way to sort an arbitrary list is expressed as @sorted = sort { $a <=> $b } @mylist; has readability issues.
Figuring out what chain of braces, sigils, and arrows is needed to properly dereference a deeply nested data structure is a PITA.
Python By far the biggest problem with Python is the user community. There's something about Pythoneers that make them glom onto the language with religious zeal, and then go around telling every one else that their own language of choice isn't elegant enough. Many Python users have the mistaken impression that Python is a carefully worked-out work of modern programming cleanliness like Scheme. In fact, Python was an unremarkable in-house procedural "little language" that, rather than dying the graceful death that most such languages eventually experience, was hyped to a larger audience and has been loaded down with all kinds of trendy features. Unfortunetely, due to it's humble roots, these features have gone in rather awkwardly. All this would be fine, in fact, it would be similar to Perl's story, if it weren't for the singular nature of Python apologists. Python is perhaps the only open-source language whose users will proudly and vehemently defend a language flaw as a feature. The best example is the post-facto rationalization of the extra "self" argument to methods, which the Python FAQ helpfully explains was simply an artifact of the way OO was hacked into an originally procedural language. This fact doesn't deter the fanatics however, who will happily tell you that it was an intentional feature and that it somehow makes Python better. Other examples of Python's awkward growing pains and the inexplicable attitude of it's users: the fact that Pytho defines private variables as variables whose
C++ suffers from some early bad design decisions. Templates came late. Strostrup knew about templates, and decided not to put them in. This led to great pain and ugly code, templates went in, and it's taken a decade to clean up that mess.
Bjarne wanted to put generics in from the very beginning.
Java was supposed to clean this all up, but now Java is getting generics, which it wasn't supposed to need. So it's going down the same path as C++, but with a new set of mistakes.
Java "cleans up" nothing, it simply strips out all the more powerful features of C and C++ which novices tend to stub their toes on. Oh, and it adds one important feature: inner classes. Unfortunately the result is a language whose omitions actually make it more verbose and harder to maintain than C++.
Other attempts to fix C include Objective C (which still has a following) "C+@" (a Bell Labs product that predates Java), "C#", a Microsoft variant, and several others with tiny market share such as "D". None are enormously better than C.
Neither ObjC nor C# is an attempt to "fix" C; Objective C is an attempt to embed a Smalltalk object system in C, and C# is an attempt to fix Java. Neither of them are applicable to the same problem domains as C.
I'd like to see C++ cleaned up, but the ANSI committee is more interested in putting in obscure features for template writers.
Everything in C++ belongs there, and most of it was intended to go in from a very early stage. The only thing that needs to be "cleaned up" is the C preprocessor. Templates could use easier syntax but no one has come up with anything signifigantly better than the current syntax.
I have the previous edition, and it's IMO one of the classics of UNIX use, up there with UNIX Power Tools. In fact, it's the perfect SysAdmin complement to the more user-oriented Power Tools. It's readable, professional, and it manages to be detailed enough to be used as a reference while still accessible enough to introduce a relative UNIX newbie to the underlying concepts of UNIX. Highly recommended.
I want to like GNOME2. But after years of development, it's still unbelievably slow, feature-free, buggy, and crash-prone on my Debian system. I've never seen Nautilus stay up and running without crashing for more than a few minutes. Whatever development methodology went into the GNOME rewrite, it clearly didn't work out; and I don't blame HP for cutting their losses and staying with something that's at least stable, if butt-ugly.
A real summary of the article: a behind-the-times coder reads up on the current industry literature, and announces: "Gee, you guys really think hard about this stuff, don't you? That programming stuff sure is confusing! After a cuple weeks of reading, I'm really confused, therefore it must be over-complicated and redundant. Okay, I'm gonna go back to making clay pots now."
There has been a long-running thread about a real-time background which represents the weather / time / moon-phase.
Umm, last I checked I could do that under any window manager on my box. It's just a matter of having one of the standard X toys like the daylight globe or moon clock (don't recall the executable names offhand) occupy the root window.
I see this a lot on Slashdot - "who reads blogs?". The people who ask apparently are only familiar with a few obscure blogs, and never bother to actually visit any major blogs and check their sitemeter stats. Here's a suggestion: before asking the question, check something like the Technorati Top 100. Take a look at the blogs listed there, the number of links into them, and their pageview stats (if they keep track of them). Then make up your own mind about whether anyone reads blogs. And who knows, maybe you'll find something there that actually interests you!
instapundit.com (Glenn's original blog) has topped 200,000 daily visits on at least one occasion, and his readership is growing monthly. His fellow top-teir bloggers boast similar numbers. And they're just talking about boring ole' politics and such. "Millions" might still be a long way off, but I don't think it's all that farfetched.
A lot of the comments I've seen so far have been to the effect of "how interesting can a geek on video be?" Probably not very, but consider the source of the article. It's worth noting that the article is by Glenn Reynolds, the most popular true blogger (as opposed to quasi-journalists like Drudge) on Earth. While he's certainly got a geek side - his "chief interest is in the intersection between advanced technologies and individual liberty", and he's been executive chairman of the National Space Society - he's a law professor, established commentator, and author. Tens of thousands of people visit his instapundit.com for his commentary on technology, culture, and politics news every day.
This is the area where video blogs are likely to take off, for the same reason that standard weblogs shot up in popularity in the past two years. People are increasingly concerned with the state of international relations and public policy, and increasingly dissapointed in the established media's ability to keep up with events and to provide coverage that is compelling, insightful, and (perhaps most importantly), honest about it's bias. Many of these people have turned to weblogs to fill this information gap, and I think the same will be true of video blogs. I'd even venture to predict the possibility of the most popular video bloggers "going pro" - just like Reynolds when MSNBC offered him an online slot, perhaps we'll see major news networks give video bloggers space in their online, or maybe even broadcast, video feeds.
These require a plugin to be installed, but most computers come with it already installed if I'm not mistaken. They are also specifically oriented towards interactive graphics.
I read through this novel the other day, and it was one of the best pieces of sci-fi I've read in recent years. Non-silly computer science; interesting explorations of the Three Laws that should satisfy any Asimov fan; compelling characters; and most of all, it still has heart - something too much modern sci-fi seems to eschew as not "edgy" enough.
All that said, if you dont like it the way it is, break out your EMacs, and Write something better, otherwise, quit bitching!
I think if had personally written "your Emacs" (XEmacs, in JWZ's case), as well as a number of the most popular UNIX/Linux programs (Netscape, xscreensaver, etc.), you too would be a little sick of having to write your own program whenever you wanted something done right.
To begin with, I got a lot of useful information out of this book. Bob Toxen knows his stuff, and he does a reasonable, if not superb, job of explaining it.
However...
Had it been on any other subject, I probably would have put it away and went looking for a better book not long after buying it. The only reason it was as useful as it was to me was that at the time, it was the only Linux-specific security book I could find. While there is good information, it is incredibly badly organized. The various tips seem to be haphazardly scattered around the book rather than carefully organized into any coherent scheme; and what's worse, it's redundant. Badly redundant. As I recall, many passages and some paragraphs are repeated word-for-word at different places in the book. Security issues are sometimes covered twice over in different parts of the book, artificially inflating the content. Toxen also comes across as someone who thinks of himself as a real bad-ass cowboy of the UNIX world, which contrasts poorly with the proffessional, occasionally wry tone of the classic O'Reilly UNIX books to which this book must naturally be compared.
Basicaly, the first edition was a good collection of tips and tricks, although no more so than your typical top-teir UNIX security website offers. What it badly needed was the hand of a competent editor to clean up the writing and the organization. Hopefully this second edition recuieved such a treatment.
Unix Power Tools is the book for learning, not just what all those oddly-named UNIX utillities do, but how to use them together to accomplish useful tasks. I've never seen a better book on how to think like a longtime UNIX-user.
This movie (as well as much of Moore's other output) has been discredited time and time again, even by writers on the left who agree with his basic opinions. By all reports it is staged, manipulated, and completely worthless as far as getting unbiased data about the gun-control debate.
In a free market, prices are signals indicating how much a resource costs to produce. Artificially altering this price is the opposite of a free-market system - what you are talking about is a "planned economy", where beaurocrats attempt to achieve certain social aims by manipulating and obscuring price signals. An example would be the various "sin taxes" on things like alcohol and tobacco.
I'm just trying to clarify your terminology - technically this scheme appeals to your inner Socialist, not your inner Libertarian.
I bought this when I decided to learn Java, on the advice of numerous online recommendations, and dutifully slogged through it for a few months. Finally I gave up, and later bought The Java Programming Language and learned everything I needed to know in a couple of weeks. For those who understand basic OO principles, and have at least one language under their belt already, TiJ is extremely slow going. The book is cluttered up with lengthy, tedious, contrived examples that sometimes take up several pages of often highly repetative code. Rather than use code snippets to illustrate new concepts, this book tends to repeat entire programs over and over again with just a few lines changed. Combine this with an enourmous font that causes the code to actually be less readable because so many lines have to be truncated and you have a book that's far thicker than it needs to be.
Bruce himself is a somewhat dubious source for programming know-how, having something of a reputation for jumping onto each passing development fad with a passion and then discarding it with a sniff when the next shiny object comes along. He's also notorious in the Ruby community for publishing a scathing, and completely innaccurate, critique of the Ruby language despite admitting that he hadn't bothered to learn much about it. This is highly unproffessional behavior IMHO, and has colored my perception of anything he's said since.
I do recommend TiJ for a casual programmer who has decided that Java is going to be their introduction to OO programming. It does a good job of explaining OO principles and demonstrating how they can be implemented in Java.
Calling the system in which WorldCom and co. exist(ed) a "Free Market" is a little like calling a Geo Metro a high-performance off-road vehicle. Don't judge a free market unless it actually exists.
Slashdot Mirror
Preachiness - I think this partly results from the twin facts that a) a lot of C++'s best features were added incrementally, and compiler support came even later; and b) a lot of C++ programmers are really C programmers who never bothered to learn C++ as a discrete language, and whose knowledge of C++ doesn't extend much beyond classes and new/delete. Which is fine, until you have one of these programmers working alongside someone who really knows C++, on the same project. At that point, it's time to adapt or die for the old-schooler, because certain bad old habits are not just ugly, they will actually cause bugs.
As an example, they are right. You should never, ever, ever use malloc() in new code. That's on the level of "don't use goto". If anyone is "preachy" about this point, it is because your indiscriminate use of malloc() threatens their code with insidious, hard-to-track-down memory errors. This is on the level of using static variables inside a function, and requiring client code to call some init() function before every call in order to flush out old static data. I would be equally "preachy" if we were on a work site and you ignored basic safety regulations.
On the other hand, those who preach about object-orientation always being the "right" way need to be smacked. And anyone who preaches to you about how you should write code that they themselves will never have to work with or call out to has too much time on their hands.
"Python's design was wisely inspired by Lisp."
Where the hell did that bit of misinformation start? I've been hearing it a lot lately, and there's not a jot of truth to it. Python started out as a fairly limited procedural scripting language with C-style syntax, used for in-house scripting. It was "inspired" by the need to script things.
Since then it has added a few lisp-ish features, but no more so than dozens of other languages. Taking some of the most distinctive features of Lisp:
Code is Just Data
Not in Python it isn't. This is arguably the most important feature of Lisp, and it's difficult to see how a language which cannot cleanly manipulate code at run time can be said to be "inspired by Lisp". Even TCL is more like Lisp than Python in this sense.
Lambdas
Lambdas were only added relatively lately to Python, and in a severely limited form. In this sense Perl, Ruby, Smalltalk, and even Java (with it's anonymous inner classes) are more Lisp-like than Python.
Continuations
Not supported, and I gather that the architecure of the Python interpreter is such that they may never be supported. Ruby, being actually inspired by Lisp (among others) from inception, naturally supports them.
CLOS
Lisp has one of the most advanced and flexible object systems around. Python's is feeble and kludgey by comparison.
Tail Recursion
One can't do a lot of Lisp-style funtional programming without proper tail recursion. A quick definition of an infinitely tail-recursive function in Python shows that Python lacks this: a "maximimum recursion depth" exception is eventually thrown. I understand this is another of those fundamental architecture issues, another artifact of the the fact that the Python interpreter was designed with strictly C-style programming in mind.
Macros
Lisp's usefulness in creating Domain-Specific Languages (DSLs) stems from it's powerful macro system. Python has no such system. Even C's pathetic preprocessor beats Python in this regard.
In short, there is nothing "lisp-inspired" in Python that is not done better in supposedly less lisp-like languages.
Take a hundred-line snippet of Python code. Stick it into a web page. Copy&paste the web page to an email. Post the email to a programming mailing list. Have a lengthy thread about the code, quoting and requoting the original.
Now, let an intermediate Python programmer try to take the mangled code from the end of that thread and reformat it so that it works as intended. If it were in a language with explicit block syntax, chances are it would run as intended with nothing more than the removal of any quoting prefixes that mail clients have added. And a decent programmer would be able to whip up a script that would automate the transformation from mangled code into nicely indented code. Not so for the Python code.
The problem is not so much that whitespace is signifigant by default; it's that there is no way to modify this behaviour in order to generate "portable" code which can survive whitespace mangling.
But frankly, all things considered, whitespace signifigance is by far the least of Python's worries.
Heh... I have a friend who is re-writing Mark Pilgrim's ultra-liberal RSS parser in Ruby. See http://www.alieniloquent.com/rerss/ if you are interested.
Metaclass hacking starts out seeming easy, but then you start running into walls. Usually not insurmountable ones, but eventually the methods of circumvention make it more trouble than it's worth. For one thing, you can't do much serious metaclass hacking without having to resort to eval-ed strings (not blocks; strings), which I regard as a failing. I shouldn't have to drop down to the string-munging level to generate new methods on the fly. Once I've resorted to string-munging I lose all the benefits of compile-time syntax checking, and things become harder to debug. Another thing you can't do in Ruby is to apply "advice" to methods - prepending, appending, or wrapping an existing method with new code. You can do this manually, but it's a pain in the ass - you have to save the existing method with a proc or an alias and then rewrite the method, inserting a call to the original code at the appropriate point.
Ruby does not have the kind of namespace support I'm talking about. I'm talking about namespaces that are orthogonal to the class/module system. Ruby's ability to dynamically extend system classes at runtime is extrememly powerful, but it's hampered by the lack of a crosscutting namespace model. Library writers are discouraged from writing extensions to built-in classes by the fact that they never know when their extensions will collide with some other author's extensions. Supposing Karen writes security extensions module, including a new lock method on the Object class. Supposing Bob writes a concurrent programming extensions module, which includes a Object#lock method which acquires a thread-specific lock on the object. Then supposing I want to use both modules for an application I'm writing. Oops - name collision! There are also subtler errors possible when two different extensions coincidentally use the same name for an internal instance variable. Ruby needs a way to garauntee that methods added to existing classes, either by direct extension or via mixin, can operate safely without worrying about colliding with another method's namespace.
Let's start this off nice and flameworthy: what is the point of using C anymore? Nearly any valid C program is a valid C++ program, and C++ gives me the option of selectively using much higher-level abstractions than C can support, with little or no overhead, in a much safer and easire-to-debug way than any pure-C approximation. And most of the projects which are coded in C these days shouldn't even be coded in C++; they should be coded in something higher-level like Java or Python.
C++
Java
Perl
Python
By far the biggest problem with Python is the user community. There's something about Pythoneers that make them glom onto the language with religious zeal, and then go around telling every one else that their own language of choice isn't elegant enough. Many Python users have the mistaken impression that Python is a carefully worked-out work of modern programming cleanliness like Scheme. In fact, Python was an unremarkable in-house procedural "little language" that, rather than dying the graceful death that most such languages eventually experience, was hyped to a larger audience and has been loaded down with all kinds of trendy features. Unfortunetely, due to it's humble roots, these features have gone in rather awkwardly.
All this would be fine, in fact, it would be similar to Perl's story, if it weren't for the singular nature of Python apologists. Python is perhaps the only open-source language whose users will proudly and vehemently defend a language flaw as a feature. The best example is the post-facto rationalization of the extra "self" argument to methods, which the Python FAQ helpfully explains was simply an artifact of the way OO was hacked into an originally procedural language. This fact doesn't deter the fanatics however, who will happily tell you that it was an intentional feature and that it somehow makes Python better.
Other examples of Python's awkward growing pains and the inexplicable attitude of it's users: the fact that Pytho defines private variables as variables whose
Bjarne wanted to put generics in from the very beginning.
Java "cleans up" nothing, it simply strips out all the more powerful features of C and C++ which novices tend to stub their toes on. Oh, and it adds one important feature: inner classes. Unfortunately the result is a language whose omitions actually make it more verbose and harder to maintain than C++.
Neither ObjC nor C# is an attempt to "fix" C; Objective C is an attempt to embed a Smalltalk object system in C, and C# is an attempt to fix Java. Neither of them are applicable to the same problem domains as C.
Everything in C++ belongs there, and most of it was intended to go in from a very early stage. The only thing that needs to be "cleaned up" is the C preprocessor. Templates could use easier syntax but no one has come up with anything signifigantly better than the current syntax.
I have the previous edition, and it's IMO one of the classics of UNIX use, up there with UNIX Power Tools. In fact, it's the perfect SysAdmin complement to the more user-oriented Power Tools. It's readable, professional, and it manages to be detailed enough to be used as a reference while still accessible enough to introduce a relative UNIX newbie to the underlying concepts of UNIX. Highly recommended.
I want to like GNOME2. But after years of development, it's still unbelievably slow, feature-free, buggy, and crash-prone on my Debian system. I've never seen Nautilus stay up and running without crashing for more than a few minutes. Whatever development methodology went into the GNOME rewrite, it clearly didn't work out; and I don't blame HP for cutting their losses and staying with something that's at least stable, if butt-ugly.
A real summary of the article: a behind-the-times coder reads up on the current industry literature, and announces: "Gee, you guys really think hard about this stuff, don't you? That programming stuff sure is confusing! After a cuple weeks of reading, I'm really confused, therefore it must be over-complicated and redundant. Okay, I'm gonna go back to making clay pots now."
There has been a long-running thread about a real-time background which represents the weather / time / moon-phase.
Umm, last I checked I could do that under any window manager on my box. It's just a matter of having one of the standard X toys like the daylight globe or moon clock (don't recall the executable names offhand) occupy the root window.
It's more likely that localized blackout or jamming in the Iraq region will be used, rather than a global downgrade. See here for more.
I see this a lot on Slashdot - "who reads blogs?". The people who ask apparently are only familiar with a few obscure blogs, and never bother to actually visit any major blogs and check their sitemeter stats. Here's a suggestion: before asking the question, check something like the Technorati Top 100. Take a look at the blogs listed there, the number of links into them, and their pageview stats (if they keep track of them). Then make up your own mind about whether anyone reads blogs. And who knows, maybe you'll find something there that actually interests you!
instapundit.com (Glenn's original blog) has topped 200,000 daily visits on at least one occasion, and his readership is growing monthly. His fellow top-teir bloggers boast similar numbers. And they're just talking about boring ole' politics and such. "Millions" might still be a long way off, but I don't think it's all that farfetched.
A lot of the comments I've seen so far have been to the effect of "how interesting can a geek on video be?" Probably not very, but consider the source of the article. It's worth noting that the article is by Glenn Reynolds, the most popular true blogger (as opposed to quasi-journalists like Drudge) on Earth. While he's certainly got a geek side - his "chief interest is in the intersection between advanced technologies and individual liberty", and he's been executive chairman of the National Space Society - he's a law professor, established commentator, and author. Tens of thousands of people visit his instapundit.com for his commentary on technology, culture, and politics news every day.
This is the area where video blogs are likely to take off, for the same reason that standard weblogs shot up in popularity in the past two years. People are increasingly concerned with the state of international relations and public policy, and increasingly dissapointed in the established media's ability to keep up with events and to provide coverage that is compelling, insightful, and (perhaps most importantly), honest about it's bias. Many of these people have turned to weblogs to fill this information gap, and I think the same will be true of video blogs. I'd even venture to predict the possibility of the most popular video bloggers "going pro" - just like Reynolds when MSNBC offered him an online slot, perhaps we'll see major news networks give video bloggers space in their online, or maybe even broadcast, video feeds.
These require a plugin to be installed, but most computers come with it already installed if I'm not mistaken. They are also specifically oriented towards interactive graphics.
The question specifically stated that the solution must not require anything to be installed, including a JVM.
I read through this novel the other day, and it was one of the best pieces of sci-fi I've read in recent years. Non-silly computer science; interesting explorations of the Three Laws that should satisfy any Asimov fan; compelling characters; and most of all, it still has heart - something too much modern sci-fi seems to eschew as not "edgy" enough.
To begin with, I got a lot of useful information out of this book. Bob Toxen knows his stuff, and he does a reasonable, if not superb, job of explaining it.
However...
Had it been on any other subject, I probably would have put it away and went looking for a better book not long after buying it. The only reason it was as useful as it was to me was that at the time, it was the only Linux-specific security book I could find. While there is good information, it is incredibly badly organized. The various tips seem to be haphazardly scattered around the book rather than carefully organized into any coherent scheme; and what's worse, it's redundant. Badly redundant. As I recall, many passages and some paragraphs are repeated word-for-word at different places in the book. Security issues are sometimes covered twice over in different parts of the book, artificially inflating the content. Toxen also comes across as someone who thinks of himself as a real bad-ass cowboy of the UNIX world, which contrasts poorly with the proffessional, occasionally wry tone of the classic O'Reilly UNIX books to which this book must naturally be compared.
Basicaly, the first edition was a good collection of tips and tricks, although no more so than your typical top-teir UNIX security website offers. What it badly needed was the hand of a competent editor to clean up the writing and the organization. Hopefully this second edition recuieved such a treatment.
Unix Power Tools is the book for learning, not just what all those oddly-named UNIX utillities do, but how to use them together to accomplish useful tasks. I've never seen a better book on how to think like a longtime UNIX-user.
This movie (as well as much of Moore's other output) has been discredited time and time again, even by writers on the left who agree with his basic opinions. By all reports it is staged, manipulated, and completely worthless as far as getting unbiased data about the gun-control debate.
See:
From Spinsanity
From LA Weekly
From the National Post
From the Weekly Standard
From The Globe and Mail
In a free market, prices are signals indicating how much a resource costs to produce. Artificially altering this price is the opposite of a free-market system - what you are talking about is a "planned economy", where beaurocrats attempt to achieve certain social aims by manipulating and obscuring price signals. An example would be the various "sin taxes" on things like alcohol and tobacco.
I'm just trying to clarify your terminology - technically this scheme appeals to your inner Socialist, not your inner Libertarian.
I bought this when I decided to learn Java, on the advice of numerous online recommendations, and dutifully slogged through it for a few months. Finally I gave up, and later bought The Java Programming Language and learned everything I needed to know in a couple of weeks. For those who understand basic OO principles, and have at least one language under their belt already, TiJ is extremely slow going. The book is cluttered up with lengthy, tedious, contrived examples that sometimes take up several pages of often highly repetative code. Rather than use code snippets to illustrate new concepts, this book tends to repeat entire programs over and over again with just a few lines changed. Combine this with an enourmous font that causes the code to actually be less readable because so many lines have to be truncated and you have a book that's far thicker than it needs to be.
Bruce himself is a somewhat dubious source for programming know-how, having something of a reputation for jumping onto each passing development fad with a passion and then discarding it with a sniff when the next shiny object comes along. He's also notorious in the Ruby community for publishing a scathing, and completely innaccurate, critique of the Ruby language despite admitting that he hadn't bothered to learn much about it. This is highly unproffessional behavior IMHO, and has colored my perception of anything he's said since.
I do recommend TiJ for a casual programmer who has decided that Java is going to be their introduction to OO programming. It does a good job of explaining OO principles and demonstrating how they can be implemented in Java.
Calling the system in which WorldCom and co. exist(ed) a "Free Market" is a little like calling a Geo Metro a high-performance off-road vehicle. Don't judge a free market unless it actually exists.