Re:Spielberg annoys to the end
on
Minority Report
·
· Score: 2
Then you should go and watch a comedy.
Not every movie is supposed to be depressing. Not every movie is supposed to be uplifting either.
There are some movies where a happy ending just doesn't fit, and where "trying not to be so depressing" takes away the whole point of a movie.
A story is meant to provoke a certain emotional and intellectual response; compromising that response at the expense of the movie assumes that your viewers didn't want to watch that story in the first place. Why make that movie then?
A Philip K Dick story with a happy ending is not a PKD story.
The same thing happened with Brazil and Blade Runner. What's the point of the existential angst of characters in a dystopia if at the end you're going to say "well, but it wasn't so bad after all"? What would be the point of "1984" if, for example, in the end there is a revolution that deposes the "Big Brother"? (hint: the story is supposed to be a warning against said "solutions")
I don't want to be depressed every time I read a book either. Well, guess what, I don't read "1984" every day!
"Minority Report" may or may not be a Spielberg story, but then a Spielberg story would do much better by being itself, in its predictable sappiness, rather than sticking its nose at the end of someone else's rant against the universe. The problem is, it was publicized as a dystopian movie, and the story is mostly a dystopian story.
That would make it a mediocre dystopian movie, as opposed to a competent action blockbuster (such as "Matrix", which takes a different angle). You can't turn the movie around after a certain point, and the end is most certainly after that point.
I would think they would only care about someone misrepresenting the name UnitedLinux; that is, pretending to be a distributor that provides/transfers the year-of-service contract along with the copy.
Anyone will be able to take the CD, copy it, and give it as a "copy of the UnitedLinux distribution", but they would not be able to call it "the UnitedLinux product" because what they are selling is not the software per se, it's the software + support.
I guess it will be similar to OEM generic electronics sold by part-number and retail versions. You can resell them and trade them, but putting them in a nice box with some cables and selling them as the "ATC GraphicBoom 8080" or the "Crux PC2100 RAM with eternal warranty" would be fraud and probably a trademark violation. You will have to sell them as generic or provide a lot of information that differentiates them from the retail product.
I would think Intel, and to some point AMD, would sell slightly more than predicted if the PCs are custom-built.
Every time I build a computer I use AMD processors, but if I were building it for someone else, I would use Intel. It would not be my choice, it would be the client's, because trying to explain to them that the processor doesn't have to be a "Pentium" would be a futile waste of time and would not save ME any money.
People want a little bit of brand recognition when they don't know what they are buying, and the people that make any difference in the statistics do not. If they are buying a Dell, they will be confident with whatever is inside, but if they are buying a PC assembled in some local shop, they will want to make sure it's a "Pentium computer" and that it runs "multimedia".
Companies like Dell and Compaq have more leverage to push non-traditional processors in order to save money. As far as I know, there are consumer products using the Crusoe. But a white-box assembler will try to minimize risk and stick to what they can advertise to the customer, Intel and now AMD processors, which are mainstream.
Of course, that doesn't mean they are buying the processors Intel and AMD want them to buy. A cheap Duron or Celeron running at 1Ghz may be more convincing than that Pentium 4 Intel is dying to sell.
Because throughout history almost every government has proven itself utterly uncapable of figuring out what information is relevant or not to identifying you as a threat.
They have this tendency to think that because someone reads a particular author, teaches or studies a particular subject, belongs to some demographic group or simply has friends/neighbors/relatives to whom any of the above apply, he or she is actively plotting against the government.
This happens most often in dictatorial regimes, but democracies are not immune, and the US has its history (cold war? remember?).
And then there are the times when they can't figure out that something is a joke. Like the FBI investigating bonsaikitten.com. I wonder if Tom Clancy is under constant surveillance...
Some I have found helpful/interesting
on
General IT Books?
·
· Score: 2
I noted some in the Misc should be categories themselves:
- A couple of Data Structures books are essential. Mine is Weiss' "Data Structures and Problem Solving" and "Data Structures and Algorithm Analysis", available "in" different languages (C++, Java, at least).
I think they're great, but then again, I took that class with Weiss and the book was heavily recommended anyway. I'm sure there are other outstanding books out there I don't know about.
- An Operating Systems book is essential. I have the "Dinosaur book", however it's called. It's not bad, but it's not great either. I heard good things of Tannenbaun's "Modern Operating Systems" and it's on my buy list, but unless you're in OS development only one competent book is necessary.
- A hardware book is essential. Tannenbaun's "Structured Computer Organization", for example.
- An SQL reference is essential, and a good theoretical introduction to relational calculus as well. For the first, almost any decent SQL reference is good enough (O'reilly has a bunch of PL/SQL books) and some "Enterprise" references include 80% of what you'll ever need in some appendix. For the second, you need a good database class.
But the point is that SQL is not exactly "programming", although it may be hard to explain to someone who's not a programmer (HR departments included). It's relational calculus, which deserves a whole category by itself, and solves different problems than what we normally call programming.
In Design:
- "Design Patterns" by the GoF. It's essential. Even if you don't get into the hype of Patterns, a student will learn a lot of neat solutions to complex problems without stumbling his/her way through at first. Which, incidentally, is what the hype of Design patterns is all about.
- "Refactoring" by Martin Fowler.
Refactoring is not yet another experimental methodology, it's something we will probably do sooner or later, and doing it sooner and having a methodology just makes life that much easier. This book is great.
In Programming:
- "Thinking in *" by Bruce Eckel, where * is whatever language you want to learn.
Not only is it free, and online, I think it's one of the best series of introductory books I have read. I learned Java with it and found it the only reference for the core language that I needed... my college's required book (Dietel & Dietel) is still collecting dust.
I keep both the Java and C++ versions as references on my hard disk, and plan to learn Python from "Thinking in Python" at some point.
I recommend these because they're good "learning to program" books. Having a basic reference for each language your using is essential, but every student should have a good "basic programming" reference, whatever the language it uses. They're two different kinds of books, the latter is harder to find.
- "Programming in SML" by Robert Harper. There should be at least one functional programming book in the student's bookshelf. You may want a theory-oriented book too, but I think a practical manual for the language and lots of experimentation are what is essential to grasp the concept, SML is a good choice, and Harper's book is a great reference. It will help anyone to develop better in any modern language.
Things that are useful but should not be considered essential:
- Wireless books. Useful if you're interested in the subject, but not essential and a bit too specialized for "basic knowledge". For the interested student it is vital, but for the typical student it will not make a difference.
- Graphics: same as above.
- "Mastering Regular Expressions" (O'Reilly). Regex can save a lot of programming time and provide simple solutions for some common needs.
- For J2EE and web-development references, "Web Development with Java Server Pages" (Manning editorial) is my favorite book in the subject, with "Server Progamming in Java" (Manning again) for heavier, more general stuff and "Core Servlets" (Sun) for reference.
But that's only if that's of interest to the student. I would recommend getting familiar with the concepts, but it would only be part of the "core library" if it's part of what they want to do.
- Cryptography: "Applied Cryptography" is the book to get. But for most people it's an obscure subject and should be dealt with as a black box. Too specialized to be considered "basic".
A good security book should cover all that really matters in the application of cryptography (when to use it and how) anyway.
But it's hard to convince someone trying to make money that their programmers, regardless of previous experience, will not be productive from the first day at work because they need to be coached into the company's own standards.
They would prefer to have them producing code that works, as soon as possible, even if it means bringin into the code repository their own habits, good and bad, picked from their previous jobs, school or their intestinal tract.
If a manager at a construction company is building a bridge, it is likely he will not be satisfied JUST because the bridge seems solid. If the bridge looks unlike anything he has ever seen, its structure defies comprehension, and he's not entirely sure the thing stands by anything more than chance or will survive the touch of a maintenance crew, there will be hell to pay.
On the other hand, if the software works, the manager is probably satisfied.
This may not have as much to do with the programmers' or managers' discipline, but with two other simple facts:
a) Everyone knows how a bridge should look, and if it looks any different (new design), they will be extra-paranoid about it. Soon the new design will join the ranks of ways a bridge should look, and there are not that many. b) Most of the bridge's features can be seen at first glance, without a peek at the designs.
On the other hand, concerning software:
a) No one knows how software should look. There are a million gurus who think they do, with a million different versions. Given a piece of code and an expert, he will be unlike to tell you if it looks solid or not at first glance, so a non-expert will judge by whether it executes or not. b) Most of the software's structure is hidden from view in the final product because software is not physical. It's all design. Judging the quality of software, even if you knew what to look for, will depend on a through review of the designs (code) which is as likely to happen as a voluntary visit to the dentist.
It could have been called ML#, or M# if you really need the one letter thing. But now by calling it F# they have inflicted terrible damage on the community.
Sure, it's F-unctional/imperative, but there are other Functional/imperative languages, how come they got the priviledge on the F? It's a non-intuitive choice for something based on ML, and it takes over the F...
How many headlines in SatireWire et al could have been based on that F#? How many inside jokes, idiomatic expressions? An important piece of the.Net culture has been removed before it had time to blossom.
Can you use "this F# S# is not compiling!" anymore? No, because it might not be implemented in F# and would confuse your co-workers, who would have otherwise understood your feelings exactly. We will see, ad nauseam, co-workers mocking poor F# developers with jokes that, in the pretense of sophistication,will get old very quickly: "so, I hear you're using that F# language? Am I going to have to read that F# S# when you're done? I hated debugging that when I was in college, my prof was a F# A#".
Confusion in the workplace will stifle any creative idiomatic use of F#, nagging by co-workers with repetitive jokes will stifle any creative alrogithmic use. F# will die and will kill the F# with it.
Saying just "piece of S#!" is not the same. And how long before even that is removed, when they implement Smalltalk in.NET? What's next, A# for Algol?
... promoting fish fillets for all Dragon Masters.
I guess that's what happens after two days with no sleep and watching that Triumph video a couple times too many.
Not everything is a front-page story
on
Blogging for Dummies?
·
· Score: 5, Insightful
That's not necessarily a bad thing.
It doesn't take an in-depth analysis of the news story to make journalism. It only needs to be true, correct, and competently addressed even if it's little more than a footnote.
Not everything in a newspaper is a front-page story, you know? News companies have limited space and resources to create and publish those marvellously researched pieces you're so fond of. There are also columns, socials, and those collections of AP/REUTERS notes that you find almost as a margin to the "big news" and compose 90% of what's happening in the world.
"Online news sites" are similar to these last. They condense information as much as possible while trying to give a non-misleading picture of what it is about (and usually fail), so that interested readers can do their own research and find out more.
Blogs with active comment systems are a mix of these with "open-eds" and "letters to the editor".
But Blogs may also be more than just a collection of links. While Slashdot follows this pattern, it's mostly because that's what it does best and/or what the community values (witness the popularity, on the other hand, of Jon Katz).
Kuro5hin, for example, follows more closely the pattern of a magazine or publication. MLPs are similar to the link collections (or AP notes), while the rest of the site is often populated by articles where the links are secondary to the argumentative content... which is in some cases not entirely about the current emotional state of the poster. Original content that is not a substitute for group therapy is possible in a blog, after all.
The advantage of blogs is that they provide an immediate source for the reader to do their research, so they don't necessarily have to accept the incomplete, inevitably misleading piece of news they were given. Users can interact with each other and with the author exchanging sources of research, and even correcting intentional and unintentional errors in the article.
The disadvantage is that, being posted by amateurs, they degenerate into diaries with links... that is, a throughly unentertaining and unresearched "opininion column" on electronic media.
Communities formed around these throughly biased weblogs (witness Slashdot), and will react against the removal of that bias because it gives them "a sense of community". They enjoy the non-journalistic flavor of the blog, but that does not mean a journalistic endeavor cannot benefit from the blog format. Rather, it means it must resist the temptation of pandering to the public which is probably greater than in other formats because of the greater level of feedback.
A journalistic "blog" should not foster that bias and would probably be unable to provide any "sense of community" while being competent in the journalistic sense, but one or many biased communities could be "resident" in a journalistic blog, though, much in the same way Clans or Guilds are specific to some online games.
I agree with you, though. Blogs are not the future of journalism, nor should they be. Hyperlinks are the future of journalism and should be the present; Blogs are just one of the ways of getting that into the heads of stubborn journalists half a century too late.
Make sure the parents are not only allowed to come in anytime they want to see what the kids are doing, but that they can sit down and play with their kids if they want to.
It may not be very "cool" for some of the kids, but it will get the parents on the good side ("quality time") and they will almost never really do it anyway.
And get games that parents would be hard-pressed to disapprove.
Civilization and Alpha Centauri have already been recommended, but that cannot be emphasized enough. Show any sane parent the Civilopedia and he will fall in love with the game.
Chess is an obvious necessity. Partly because of legitimacy, and partly because if you get some kids interested into chess you will have them competing over the network and improving in no time. Hard to disapprove of that.
Playing chess (or Go) with the adults may prove to be an event that involves the parents and actually doesn't suck for those involved (there would be some Freudian satisfaction in defeating your parent at chess, and those adults willing to play chess with their kids will probably be respectable opponents).
SimCity is also a great game to encourage. Almost any good Sim-style game is a good idea, even Tropico (as a Latin American, I find it hilarious). RailRoad Tycoon is a very good Sim-business game with a historical background...
Sports games are usually accepted by parents even if they don't understand or encourage strategic games, simply because they are an extension of real-life games they approve. It's also a good way to get kids unfamiliar with computers to look at them without the geeky label.
The idea is to get parent support for the stuff the parents don't understand, through stuff they do understand.
An exmaple of things they don't understand but would be a good idea:
Install level-editors/scripters/whatever for all the games you can find them for.
If you let the kids play with Mods or whatever, you can get some of them familiarized with programming, 3D modelling, graphic design, or all of them combined. This is a good thing.
I think the difference Open Source makes is not the amount of developers dedicated to the project, but the pool of developers from which these will be chosen.
Basicly, there can only be a limited number of people in any reasonably sized project before they start stepping on each other's toes. Other people can only give very limited help (report bugs, mostly) without breaking their stuff, which is not too satisfying.
The thing is that when these people disappear or lose interest, there is a greater pool of people aware of the project and with knowledge of the code who can step in and take their place.
The problem with "that" degrading cryptography is:
- You cannot predict "when" is your cryptography going to be broken, unless you make it breakable (for someone with enough horsepower) in the present.
Since your original purpose was to make it unbreakable in the present, you're not going to do that.
But if you make it strong enough to be confident it's presently secure, you lose the certainty it will be crackable in, say, 20 years or less. Sure, quantum computing may prove to be practical and available... or not. Maybe Moore's Law will allow traditional computing to break it... if the factor suddenly increases by 10.
Enigma was considered "improbable to be broken", not "unbreakable". The same can be said of 48-bit ciphers. We know better than that now.
We can have confidence, based on mathematical theorems, that a particular code cannot be broken unless we try all the alternatives... and that will be a fact until either the theorem is disproved, or something makes it incredibly cheap to compute the alternatives. By increasing the key's length, we can make the second factor irrelevant taking into account the Moore's Law (we're still vulnerable to breakthroughs like quantum computing, but they cannot be predicted... and yes, we can make algorithms hard to break for quantum computing). Then the system rests on the theorem's security, and mathematics is notoriously slow in developing revolutions.
So no, I'm afraid trusting the "no encryption is secure, someone will be able to break it in the future" doesn't work. It's as blind as the "no system is completely secure" and has the same problem: they only apply if the system/algorithm was designed or used under ignorant and unrealistic expectations of what "secure" is. Both are trivially true for most cases, but fail to understand the problem and are false for the important cases.
We would have more success trusting the bug rate than Moore's Law for this case. Most vulnerabilities in properply designed, analyzed and tested algorithms are in the implementation.
Maybe if we calculate some statistics on the bug rate of encryption software, we can predict that some vulnerability will probably be found in X program by Y time that will allow the recovery of the key, and trust the statistics.
As a Java geek, I was going to reply to your post much in the spirit of this thread, but you are completely right.
Re:Perl's had it's day - It's become like COBOL
on
Apocalypse 5 Released
·
· Score: 2
Point 3 is irrelevant to either the "like Perl" issue (causality is backwards).
Point 2 is arguable: what do you mean by reusable? what do you mean by "it"?
If "it" is: - Perl: that's what a programming language is. Of course you can use it again and again. Applies to any programming language. - X_Module: that's what a module is. Of course you can use it again and again. Applies to any other decent module. - Your_Code: do you mean reusable by you, or reusable by everyone else? The main criticism of Perl is that code is hard to read and maintain, which makes it hard to reuse by someone else.
If your code is being reused only by yourself, the advantage is meaningless. Anyone with a decent familiarity with their own code (any coder with good memory) will reuse their own code in any language, even BASIC.
Point 1: Valid point, but only if it does not interfere with Point 2. You see, part of what makes Perl "fun" is because it's "neat" in the figurative sense. It's a language that encourages cleverness over intelligence.
Cleverness may be welcome ocassionally in programming, but having it as the constant culture in a programming language is problematic to say the least. If cleverness gets in the way of solving the problem, it may be as welcome as a practical joker in an overworked hospital's emergency room.
I'll rant a bit (it's Slashdot, after all) trying to figure out a way to avoid this in the first place:
My first instinct is the really low-tech alternative: hire a lawyer to deal with your confidential information when you die. Just like any other "unsolved business" with your state, your passwords,etc. would be given to someone you deem capable of dealing with the issue...
But almost no one prepares for death that way either, so what are the technical alternatives?
- A cron job of sorts? Would depend on the server running indefinitely until some stipulated date when it would release the information... if it used some distributed system, it could avoid the vulnerabilities that come to mind at first sight. But a system that requires you to identify yourself and register would require almost as much preparation as the lawyer, and an anonymous system would be too open to abuse (heck, the first too).
- Some kind of "degrading cryptography"?
It may seem like defeating the purpose of cryptography in the first place, but assume that we don't want to keep the information secret forever, just for some years... not only do we not care if the information is revealed then, we DEMAND it is revealed at a particular point in time.
Is there some way to encrypt data such that it can demonstrably be decrypted only after X amount of time?
I imagine it would be extremely hard to figure out something like that, but maybe someone already has. I can only think of three approaches to not-depend on processor power, both perhaps impossible:
i) A method that collects information from some constant (data is reliable and at a constant rate) source of information (solar flares?) and needs to collect X amount of information before decrypting the key and revealing it.
The problem is that in order to ensure this information will make the decryption possible you have to be able to anticipate it. Then anyone can simulate the information at an accelerated pace and get to the key...
Maybe if we can use the key to select which information to process, and use a source of massive amounts of data, we can make unfeasible to accurately simulate all the data. But that would be trusting our current technical limitations to hold, wouldn't it? Unless we can prove simulating the source is an NP problem...
ii) Having a system that creates a unique algorithm for the key that needs to be run for X time in order to "degrade" to the key. The idea would be to escape the dependence on external information of the first problem. But even if it's possible, we would need to depend on an external source for a trusted "beacon" or "ticker" that tells how much time has passed.
iii) Perhaps the only sensible solution (and the last I thought of, obviously): Would it be useful to have digitally signed time measurement on the Internet? An atomic clock owned some trusted government or international entity that officially tells you "today is time X"?
You encrypt the key to be decrypted only when a message digitally signed by agency Y confirms a certain date has been reached. When agency Y makes the message "today is time X" public on the Internet, your boss gives that message to the system and the system pops out the password you need. "time X" and "agency Y" could (and would) be made public to all interested parties, but unless "agency Y" cheats, no one can do much about it.
This could also provide an automated means to publish confidential material whose confidentiality has an expiration date. Declassification would then not require too much work on the part of agencies that have no great interest in declassifying in the first place: once the time is reached, the keys are available and people can decrypt it.
Not so much that Verisign is acting "wisely", but that the problem should not be dealth with at the Verisign node, and that this is probably wise while the problem has not been dealt with.
As long as US law makes it disturbingly easy for different agencies to get a wiretap on a private citizen, such wiretaps will happen. If said wiretaps happen, it would be nice if only the FBI were listening to your calls and there were no mistakes in the process.
If going wiretap crazy creates a logistics problem for the telcos, and the results of the telcos' messing up is more likely to be more private information flying around (I would think it more probable than cancelling the wiretap), I'd prefer them to outsource the effort to someone with a higher level of commitment to the task.
The telcos' business is not wiretapping. If they screw up, they don't lose business. It would be Verisign's business, however, not to screw up... plus I expect they would be under constant surveillance by the ACLU and similars.
There's a good possibility that's true. But if the PDA is in a network, suddenly the processing power bottleneck MIGHT be somewhere else...
It all depends on whether the PDA has the power and the bandwidth to send whatever you say in some format to the NEC server, which could have some big iron running these things by the thousands per second.
If the article is well-written and insightful, it could use COBOL for all I care.
What makes you think that slashdotters do not care to read a good programming article just because it uses examples in a language some of them do not use? What makes you think that when they do care, they categorically refuse to use M$ implemented languages?
I have seen more jihads on Slashdot between Java-C than between C++-VisualC++, and remarkably few rants against VB (which was a broken language even by microsofties judgement).
People don't put aside information because it comes packaged in a language used by a company they don't like that much. If you want Slashdot to reject a technical article because your ideological beliefs don't let you read a few lines of code... well sir, that would be idiotic. It's not like the code will virally infect you or anything.
But if it makes you feel better: there are many in Slashdot that are interested in Mono, which would provide ample justification for you to understand C# without working for the "dark side". The same would go for VB.NET, I think, which by the way, seems like a remarkably non-broken language compared with its predecessors.
Just remember that funny as it is, it actually happens. As a college student I annoyed countless lines of customers by consistently paying my 50 dollars in groceries in a chaotic mix of 1-dollar bills, quarters, pennies, lots of dimes, and "yes! I knew it was there!" a 10 or 5 dollar bill. More than once did I pay over 15 dollars in quarters.
Then if the poor cashier lost track of what I was doing, she had the choice of trusting me or counting that mess all over again.
Well, let's see what happened to series that tried to tell a continuing story:
- X-Files tried and very successfully told a good story through its mythology episodes. Guess what: what people complain about the X-Files are the mythology episodes. They demanded more independent episodes, "alien or freak of the week" stories. Their words are typically along the lines of "I can't skip it for a week or two because when I come back, I don't know what's going on".
So the X-Files ended up being a mixture of independent episodes, independent mythologies (so you could pay attention for only a season), and weird malabarisms to tie the mythologies of each season together. This was partly done to keep the audience interested as mentioned above, and partly to keep milking the series after each mythology ended.
A problem with good storytelling is that, in order to tell a good story, you need a beginning, development, and an ending. Unless you're remarkably inspired that's hard to build on-the-spot, but if you tell the networks you plan to finish the series in exactly 3 seasons they are not going to be happy. If the show is bad, they'll cancel it before, but if the show is good, they want to keep it running for as long as possible.
- Millenium tried to do the same as the X-files mythology. It had great character development, a good story to tell, great production values... and no one watched it because they didn't understand what was going on.
- Babylon 5 was the most ambitious series in that sense of storytelling. Continuous story, almost no isolated episodes, pre-planned five seasons... and is considered the geekiest show ever because you either have seen all of it from the beginning, or you don't know what the big deal is about.
Mainstream interest degenerated in a direct correlation with the development of the story, in spite of big compromises to try to bring new viewers to the series.
On the other hand, Star Trek has been successful mostly because it does not depend on real storytelling. Almost every episode is completely independent of each other, and each issue is either completely resolved in an episode, in a series of two-three episodes, or will never be resolved. Watch TNG any time, in any order... you'll notice it just has better execution of the "hit the reset button".
I agree with you with the need for decent storytelling, and that this depends mostly on continuity, as it is really hard to pack good stories and character development in a couple of episodes.
Unfortunately, the general public does not.
They don't have the time or the will to pay attention to a story periodically for that long, and the networks know it (they would probably be reading books if they did). Continuity helps to build a cult out of people who cares, which helps to hype something up to the mainstream media, but the networks are careful not to overdo it, as alienating the mainstream in preference is a bad market move.
They will put up with the storytelling in the movies because, in order to go to the movies, they have planned already to dedicate their attention to that story for as long, and only as long, as the movie takes.
Basicly, they are willing to read a book in one sitting, but if they have to stop at a particular chapter, and then remember what they have seen by the time they watch the next chapter, they get annoyed... or worse.
This is a fundamental problem with television which may or may not be solved with Tivo and similar systems, where the rythm to watch the story is not as imposed.
I also enjoy that about Anime: it tends to have a sense of story, as opposed to the recurring sketch that is a modern sitcom. But that is just more common in Anime, not prevalent. Some of the most popular Anime series have no story development whatsoever, and that happens to be their main appeal (Ranma comes to mind, Slayers), have a background story that is completely irrelevant/accesory (late Dragonball Z), or are just plain crap (too much to mention).
So just don't put all your hopes on Anime, if you haven't been exposed to that much of it you might be really disappointed. It's just a new market where you might find a bit more of what you're looking for. You may be lucky, or not, but you probably still have to search a bit.
Series I recommend for storytelling (in case you haven't seen them yet): Lain, Evangelion, Shojo Kakumei Utena, Noir, Escaflowne, Cowboy Bebop...
This is the first semi-Insightful comment I have read on Slashdot in the last couple of months.
And it's a signed "Anonymous Coward" comment which no one will probably read because they think "microsoft sucks" comments with +5 represent the smartest people here.
Which, at this rate, they probably do. They talk about the "Great Blackout", but isn't the exodus of insightful commentary to better blogs something that has been happening for a long time, and yet an indication that commentary does not matter to what Slashdot is anymore?
I think according to the MSFT license, they would not have had the right to receive it (the European entity didn't have the right to license it), therefore they would not have had the right to relicense it under the GPL even if they didn't see the MSFT license.
Therefore, their code would be illegal. Charges could not be pressed, but once informed they would have to stop redistributing the code.
It may sound stupid, but I think this would actually be the only way to get people to care about the absurd state of the Patent Office.
Face it: patents, for non-geeks, sound like an incredibly dull subject. They will find it preposterous and silly, but they won't stay tuned long enough to realize the damage it does to the economy. How many typical Joe Americans stay tuned for more than 30 seconds to a political analysis on NPR, C-SPAN or PBS?
Unfortunately, the patents are a "pure real issue". That is, they cannot be reduced to partisanship, a scandal or a psychological "hot button" (like "help the poor", racism, Big Government, abortion, Christian Decency, taxes, gun-control, etc) which seems the only way to gather support for an issue these days.
It takes some real thinking to figure out the role of IP on the economy, and then the role of the Patent Office in there, and then the difference between trademarks, patents, copyrights (because someone will ask about the "patent on Mickey Mouse or Shakespeare").
Even among geeks people care because it has become a psychological hot-button, with most geeks being "for-IP" or "against-IP". If they didn't already advocate one side, they wouldn't probably tune in either.
Now, put ESR or RS on Jerry Springer in a show about "Absurd Patents and the Outrageous Government that Grants Them!" and you'll see more people being aware of the subject than if you throw a rationalistic national campaign. After they already have a position, they might be willing to be convinced.
Slashdot Mirror
Then you should go and watch a comedy.
Not every movie is supposed to be depressing. Not every movie is supposed to be uplifting either.
There are some movies where a happy ending just doesn't fit, and where "trying not to be so depressing" takes away the whole point of a movie.
A story is meant to provoke a certain emotional and intellectual response; compromising that response at the expense of the movie assumes that your viewers didn't want to watch that story in the first place. Why make that movie then?
A Philip K Dick story with a happy ending is not a PKD story.
The same thing happened with Brazil and Blade Runner. What's the point of the existential angst of characters in a dystopia if at the end you're going to say "well, but it wasn't so bad after all"? What would be the point of "1984" if, for example, in the end there is a revolution that deposes the "Big Brother"? (hint: the story is supposed to be a warning against said "solutions")
I don't want to be depressed every time I read a book either. Well, guess what, I don't read "1984" every day!
"Minority Report" may or may not be a Spielberg story, but then a Spielberg story would do much better by being itself, in its predictable sappiness, rather than sticking its nose at the end of someone else's rant against the universe.
The problem is, it was publicized as a dystopian movie, and the story is mostly a dystopian story.
That would make it a mediocre dystopian movie, as opposed to a competent action blockbuster (such as "Matrix", which takes a different angle). You can't turn the movie around after a certain point, and the end is most certainly after that point.
I would think they would only care about someone misrepresenting the name UnitedLinux; that is, pretending to be a distributor that provides/transfers the year-of-service contract along with the copy.
Anyone will be able to take the CD, copy it, and give it as a "copy of the UnitedLinux distribution", but they would not be able to call it "the UnitedLinux product" because what they are selling is not the software per se, it's the software + support.
I guess it will be similar to OEM generic electronics sold by part-number and retail versions. You can resell them and trade them, but putting them in a nice box with some cables and selling them as the "ATC GraphicBoom 8080" or the "Crux PC2100 RAM with eternal warranty" would be fraud and probably a trademark violation. You will have to sell them as generic or provide a lot of information that differentiates them from the retail product.
I would think Intel, and to some point AMD, would sell slightly more than predicted if the PCs are custom-built.
Every time I build a computer I use AMD processors, but if I were building it for someone else, I would use Intel. It would not be my choice, it would be the client's, because trying to explain to them that the processor doesn't have to be a "Pentium" would be a futile waste of time and would not save ME any money.
People want a little bit of brand recognition when they don't know what they are buying, and the people that make any difference in the statistics do not. If they are buying a Dell, they will be confident with whatever is inside, but if they are buying a PC assembled in some local shop, they will want to make sure it's a "Pentium computer" and that it runs "multimedia".
Companies like Dell and Compaq have more leverage to push non-traditional processors in order to save money. As far as I know, there are consumer products using the Crusoe. But a white-box assembler will try to minimize risk and stick to what they can advertise to the customer, Intel and now AMD processors, which are mainstream.
Of course, that doesn't mean they are buying the processors Intel and AMD want them to buy. A cheap Duron or Celeron running at 1Ghz may be more convincing than that Pentium 4 Intel is dying to sell.
Because throughout history almost every government has proven itself utterly uncapable of figuring out what information is relevant or not to identifying you as a threat.
They have this tendency to think that because someone reads a particular author, teaches or studies a particular subject, belongs to some demographic group or simply has friends/neighbors/relatives to whom any of the above apply, he or she is actively plotting against the government.
This happens most often in dictatorial regimes, but democracies are not immune, and the US has its history (cold war? remember?).
And then there are the times when they can't figure out that something is a joke. Like the FBI investigating bonsaikitten.com. I wonder if Tom Clancy is under constant surveillance...
I noted some in the Misc should be categories themselves:
- A couple of Data Structures books are essential. Mine is Weiss' "Data Structures and Problem Solving" and "Data Structures and Algorithm Analysis", available "in" different languages (C++, Java, at least).
I think they're great, but then again, I took that class with Weiss and the book was heavily recommended anyway. I'm sure there are other outstanding books out there I don't know about.
- An Operating Systems book is essential. I have the "Dinosaur book", however it's called. It's not bad, but it's not great either. I heard good things of Tannenbaun's "Modern Operating Systems" and it's on my buy list, but unless you're in OS development only one competent book is necessary.
- A hardware book is essential. Tannenbaun's "Structured Computer Organization", for example.
- An SQL reference is essential, and a good theoretical introduction to relational calculus as well. For the first, almost any decent SQL reference is good enough (O'reilly has a bunch of PL/SQL books) and some "Enterprise" references include 80% of what you'll ever need in some appendix. For the second, you need a good database class.
But the point is that SQL is not exactly "programming", although it may be hard to explain to someone who's not a programmer (HR departments included). It's relational calculus, which deserves a whole category by itself, and solves different problems than what we normally call programming.
In Design:
- "Design Patterns" by the GoF. It's essential. Even if you don't get into the hype of Patterns, a student will learn a lot of neat solutions to complex problems without stumbling his/her way through at first. Which, incidentally, is what the hype of Design patterns is all about.
- "Refactoring" by Martin Fowler.
Refactoring is not yet another experimental methodology, it's something we will probably do sooner or later, and doing it sooner and having a methodology just makes life that much easier. This book is great.
In Programming:
- "Thinking in *" by Bruce Eckel, where * is whatever language you want to learn.
Not only is it free, and online, I think it's one of the best series of introductory books I have read. I learned Java with it and found it the only reference for the core language that I needed... my college's required book (Dietel & Dietel) is still collecting dust.
I keep both the Java and C++ versions as references on my hard disk, and plan to learn Python from "Thinking in Python" at some point.
I recommend these because they're good "learning to program" books. Having a basic reference for each language your using is essential, but every student should have a good "basic programming" reference, whatever the language it uses. They're two different kinds of books, the latter is harder to find.
- "Programming in SML" by Robert Harper. There should be at least one functional programming book in the student's bookshelf. You may want a theory-oriented book too, but I think a practical manual for the language and lots of experimentation are what is essential to grasp the concept, SML is a good choice, and Harper's book is a great reference. It will help anyone to develop better in any modern language.
Things that are useful but should not be considered essential:
- Wireless books. Useful if you're interested in the subject, but not essential and a bit too specialized for "basic knowledge". For the interested student it is vital, but for the typical student it will not make a difference.
- Graphics: same as above.
- "Mastering Regular Expressions" (O'Reilly). Regex can save a lot of programming time and provide simple solutions for some common needs.
- For J2EE and web-development references, "Web Development with Java Server Pages" (Manning editorial) is my favorite book in the subject, with "Server Progamming in Java" (Manning again) for heavier, more general stuff and "Core Servlets" (Sun) for reference.
But that's only if that's of interest to the student. I would recommend getting familiar with the concepts, but it would only be part of the "core library" if it's part of what they want to do.
- Cryptography: "Applied Cryptography" is the book to get. But for most people it's an obscure subject and should be dealt with as a black box. Too specialized to be considered "basic".
A good security book should cover all that really matters in the application of cryptography (when to use it and how) anyway.
But it's hard to convince someone trying to make money that their programmers, regardless of previous experience, will not be productive from the first day at work because they need to be coached into the company's own standards.
They would prefer to have them producing code that works, as soon as possible, even if it means bringin into the code repository their own habits, good and bad, picked from their previous jobs, school or their intestinal tract.
If a manager at a construction company is building a bridge, it is likely he will not be satisfied JUST because the bridge seems solid. If the bridge looks unlike anything he has ever seen, its structure defies comprehension, and he's not entirely sure the thing stands by anything more than chance or will survive the touch of a maintenance crew, there will be hell to pay.
On the other hand, if the software works, the manager is probably satisfied.
This may not have as much to do with the programmers' or managers' discipline, but with two other simple facts:
a) Everyone knows how a bridge should look, and if it looks any different (new design), they will be extra-paranoid about it. Soon the new design will join the ranks of ways a bridge should look, and there are not that many.
b) Most of the bridge's features can be seen at first glance, without a peek at the designs.
On the other hand, concerning software:
a) No one knows how software should look. There are a million gurus who think they do, with a million different versions. Given a piece of code and an expert, he will be unlike to tell you if it looks solid or not at first glance, so a non-expert will judge by whether it executes or not.
b) Most of the software's structure is hidden from view in the final product because software is not physical. It's all design. Judging the quality of software, even if you knew what to look for, will depend on a through review of the designs (code) which is as likely to happen as a voluntary visit to the dentist.
It could have been called ML#, or M# if you really need the one letter thing. But now by calling it F# they have inflicted terrible damage on the community.
.Net culture has been removed before it had time to blossom.
,will get old very quickly: "so, I hear you're using that F# language? Am I going to have to read that F# S# when you're done? I hated debugging that when I was in college, my prof was a F# A#".
.NET? What's next, A# for Algol?
Sure, it's F-unctional/imperative, but there are other Functional/imperative languages, how come they got the priviledge on the F? It's a non-intuitive choice for something based on ML, and it takes over the F...
How many headlines in SatireWire et al could have been based on that F#? How many inside jokes, idiomatic expressions? An important piece of the
Can you use "this F# S# is not compiling!" anymore? No, because it might not be implemented in F# and would confuse your co-workers, who would have otherwise understood your feelings exactly. We will see, ad nauseam, co-workers mocking poor F# developers with jokes that, in the pretense of sophistication
Confusion in the workplace will stifle any creative idiomatic use of F#, nagging by co-workers with repetitive jokes will stifle any creative alrogithmic use. F# will die and will kill the F# with it.
Saying just "piece of S#!" is not the same. And how long before even that is removed, when they implement Smalltalk in
Why, Microsoft, why?!
... promoting fish fillets for all Dragon Masters.
I guess that's what happens after two days with no sleep and watching that Triumph video a couple times too many.
That's not necessarily a bad thing.
It doesn't take an in-depth analysis of the news story to make journalism. It only needs to be true, correct, and competently addressed even if it's little more than a footnote.
Not everything in a newspaper is a front-page story, you know? News companies have limited space and resources to create and publish those marvellously researched pieces you're so fond of. There are also columns, socials, and those collections of AP/REUTERS notes that you find almost as a margin to the "big news" and compose 90% of what's happening in the world.
"Online news sites" are similar to these last. They condense information as much as possible while trying to give a non-misleading picture of what it is about (and usually fail), so that interested readers can do their own research and find out more.
Blogs with active comment systems are a mix of these with "open-eds" and "letters to the editor".
But Blogs may also be more than just a collection of links. While Slashdot follows this pattern, it's mostly because that's what it does best and/or what the community values (witness the popularity, on the other hand, of Jon Katz).
Kuro5hin, for example, follows more closely the pattern of a magazine or publication. MLPs are similar to the link collections (or AP notes), while the rest of the site is often populated by articles where the links are secondary to the argumentative content... which is in some cases not entirely about the current emotional state of the poster. Original content that is not a substitute for group therapy is possible in a blog, after all.
The advantage of blogs is that they provide an immediate source for the reader to do their research, so they don't necessarily have to accept the incomplete, inevitably misleading piece of news they were given. Users can interact with each other and with the author exchanging sources of research, and even correcting intentional and unintentional errors in the article.
The disadvantage is that, being posted by amateurs, they degenerate into diaries with links... that is, a throughly unentertaining and unresearched "opininion column" on electronic media.
Communities formed around these throughly biased weblogs (witness Slashdot), and will react against the removal of that bias because it gives them "a sense of community". They enjoy the non-journalistic flavor of the blog, but that does not mean a journalistic endeavor cannot benefit from the blog format. Rather, it means it must resist the temptation of pandering to the public which is probably greater than in other formats because of the greater level of feedback.
A journalistic "blog" should not foster that bias and would probably be unable to provide any "sense of community" while being competent in the journalistic sense, but one or many biased communities could be "resident" in a journalistic blog, though, much in the same way Clans or Guilds are specific to some online games.
I agree with you, though. Blogs are not the future of journalism, nor should they be. Hyperlinks are the future of journalism and should be the present; Blogs are just one of the ways of getting that into the heads of stubborn journalists half a century too late.
Make sure the parents are not only allowed to come in anytime they want to see what the kids are doing, but that they can sit down and play with their kids if they want to.
It may not be very "cool" for some of the kids, but it will get the parents on the good side ("quality time") and they will almost never really do it anyway.
And get games that parents would be hard-pressed to disapprove.
Civilization and Alpha Centauri have already been recommended, but that cannot be emphasized enough. Show any sane parent the Civilopedia and he will fall in love with the game.
Chess is an obvious necessity. Partly because of legitimacy, and partly because if you get some kids interested into chess you will have them competing over the network and improving in no time. Hard to disapprove of that.
Playing chess (or Go) with the adults may prove to be an event that involves the parents and actually doesn't suck for those involved (there would be some Freudian satisfaction in defeating your parent at chess, and those adults willing to play chess with their kids will probably be respectable opponents).
SimCity is also a great game to encourage. Almost any good Sim-style game is a good idea, even Tropico (as a Latin American, I find it hilarious). RailRoad Tycoon is a very good Sim-business game with a historical background...
Sports games are usually accepted by parents even if they don't understand or encourage strategic games, simply because they are an extension of real-life games they approve. It's also a good way to get kids unfamiliar with computers to look at them without the geeky label.
The idea is to get parent support for the stuff the parents don't understand, through stuff they do understand.
An exmaple of things they don't understand but would be a good idea:
Install level-editors/scripters/whatever for all the games you can find them for.
If you let the kids play with Mods or whatever, you can get some of them familiarized with programming, 3D modelling, graphic design, or all of them combined. This is a good thing.
I think the difference Open Source makes is not the amount of developers dedicated to the project, but the pool of developers from which these will be chosen.
Basicly, there can only be a limited number of people in any reasonably sized project before they start stepping on each other's toes. Other people can only give very limited help (report bugs, mostly) without breaking their stuff, which is not too satisfying.
The thing is that when these people disappear or lose interest, there is a greater pool of people aware of the project and with knowledge of the code who can step in and take their place.
The problem with "that" degrading cryptography is:
- You cannot predict "when" is your cryptography going to be broken, unless you make it breakable (for someone with enough horsepower) in the present.
Since your original purpose was to make it unbreakable in the present, you're not going to do that.
But if you make it strong enough to be confident it's presently secure, you lose the certainty it will be crackable in, say, 20 years or less. Sure, quantum computing may prove to be practical and available... or not. Maybe Moore's Law will allow traditional computing to break it... if the factor suddenly increases by 10.
Enigma was considered "improbable to be broken", not "unbreakable". The same can be said of 48-bit ciphers. We know better than that now.
We can have confidence, based on mathematical theorems, that a particular code cannot be broken unless we try all the alternatives... and that will be a fact until either the theorem is disproved, or something makes it incredibly cheap to compute the alternatives. By increasing the key's length, we can make the second factor irrelevant taking into account the Moore's Law (we're still vulnerable to breakthroughs like quantum computing, but they cannot be predicted... and yes, we can make algorithms hard to break for quantum computing). Then the system rests on the theorem's security, and mathematics is notoriously slow in developing revolutions.
So no, I'm afraid trusting the "no encryption is secure, someone will be able to break it in the future" doesn't work. It's as blind as the "no system is completely secure" and has the same problem: they only apply if the system/algorithm was designed or used under ignorant and unrealistic expectations of what "secure" is. Both are trivially true for most cases, but fail to understand the problem and are false for the important cases.
We would have more success trusting the bug rate than Moore's Law for this case. Most vulnerabilities in properply designed, analyzed and tested algorithms are in the implementation.
Maybe if we calculate some statistics on the bug rate of encryption software, we can predict that some vulnerability will probably be found in X program by Y time that will allow the recovery of the key, and trust the statistics.
As a Java geek, I was going to reply to your post much in the spirit of this thread, but you are completely right.
Point 3 is irrelevant to either the "like Perl" issue (causality is backwards).
Point 2 is arguable: what do you mean by reusable? what do you mean by "it"?
If "it" is:
- Perl: that's what a programming language is. Of course you can use it again and again. Applies to any programming language.
- X_Module: that's what a module is. Of course you can use it again and again. Applies to any other decent module.
- Your_Code: do you mean reusable by you, or reusable by everyone else? The main criticism of Perl is that code is hard to read and maintain, which makes it hard to reuse by someone else.
If your code is being reused only by yourself, the advantage is meaningless. Anyone with a decent familiarity with their own code (any coder with good memory) will reuse their own code in any language, even BASIC.
Point 1: Valid point, but only if it does not interfere with Point 2. You see, part of what makes Perl "fun" is because it's "neat" in the figurative sense. It's a language that encourages cleverness over intelligence.
Cleverness may be welcome ocassionally in programming, but having it as the constant culture in a programming language is problematic to say the least. If cleverness gets in the way of solving the problem, it may be as welcome as a practical joker in an overworked hospital's emergency room.
I'll rant a bit (it's Slashdot, after all) trying to figure out a way to avoid this in the first place:
My first instinct is the really low-tech alternative: hire a lawyer to deal with your confidential information when you die. Just like any other "unsolved business" with your state, your passwords,etc. would be given to someone you deem capable of dealing with the issue...
But almost no one prepares for death that way either, so what are the technical alternatives?
- A cron job of sorts? Would depend on the server running indefinitely until some stipulated date when it would release the information... if it used some distributed system, it could avoid the vulnerabilities that come to mind at first sight. But a system that requires you to identify yourself and register would require almost as much preparation as the lawyer, and an anonymous system would be too open to abuse (heck, the first too).
- Some kind of "degrading cryptography"?
It may seem like defeating the purpose of cryptography in the first place, but assume that we don't want to keep the information secret forever, just for some years... not only do we not care if the information is revealed then, we DEMAND it is revealed at a particular point in time.
Is there some way to encrypt data such that it can demonstrably be decrypted only after X amount of time?
I imagine it would be extremely hard to figure out something like that, but maybe someone already has. I can only think of three approaches to not-depend on processor power, both perhaps impossible:
i) A method that collects information from some constant (data is reliable and at a constant rate) source of information (solar flares?) and needs to collect X amount of information before decrypting the key and revealing it.
The problem is that in order to ensure this information will make the decryption possible you have to be able to anticipate it. Then anyone can simulate the information at an accelerated pace and get to the key...
Maybe if we can use the key to select which information to process, and use a source of massive amounts of data, we can make unfeasible to accurately simulate all the data. But that would be trusting our current technical limitations to hold, wouldn't it? Unless we can prove simulating the source is an NP problem...
ii) Having a system that creates a unique algorithm for the key that needs to be run for X time in order to "degrade" to the key. The idea would be to escape the dependence on external information of the first problem. But even if it's possible, we would need to depend on an external source for a trusted "beacon" or "ticker" that tells how much time has passed.
iii) Perhaps the only sensible solution (and the last I thought of, obviously): Would it be useful to have digitally signed time measurement on the Internet? An atomic clock owned some trusted government or international entity that officially tells you "today is time X"?
You encrypt the key to be decrypted only when a message digitally signed by agency Y confirms a certain date has been reached. When agency Y makes the message "today is time X" public on the Internet, your boss gives that message to the system and the system pops out the password you need. "time X" and "agency Y" could (and would) be made public to all interested parties, but unless "agency Y" cheats, no one can do much about it.
This could also provide an automated means to publish confidential material whose confidentiality has an expiration date. Declassification would then not require too much work on the part of agencies that have no great interest in declassifying in the first place: once the time is reached, the keys are available and people can decrypt it.
Not so much that Verisign is acting "wisely", but that the problem should not be dealth with at the Verisign node, and that this is probably wise while the problem has not been dealt with.
As long as US law makes it disturbingly easy for different agencies to get a wiretap on a private citizen, such wiretaps will happen. If said wiretaps happen, it would be nice if only the FBI were listening to your calls and there were no mistakes in the process.
If going wiretap crazy creates a logistics problem for the telcos, and the results of the telcos' messing up is more likely to be more private information flying around (I would think it more probable than cancelling the wiretap), I'd prefer them to outsource the effort to someone with a higher level of commitment to the task.
The telcos' business is not wiretapping. If they screw up, they don't lose business. It would be Verisign's business, however, not to screw up... plus I expect they would be under constant surveillance by the ACLU and similars.
There's a good possibility that's true. But if the PDA is in a network, suddenly the processing power bottleneck MIGHT be somewhere else...
It all depends on whether the PDA has the power and the bandwidth to send whatever you say in some format to the NEC server, which could have some big iron running these things by the thousands per second.
If the article is well-written and insightful, it could use COBOL for all I care.
What makes you think that slashdotters do not care to read a good programming article just because it uses examples in a language some of them do not use? What makes you think that when they do care, they categorically refuse to use M$ implemented languages?
I have seen more jihads on Slashdot between Java-C than between C++-VisualC++, and remarkably few rants against VB (which was a broken language even by microsofties judgement).
People don't put aside information because it comes packaged in a language used by a company they don't like that much. If you want Slashdot to reject a technical article because your ideological beliefs don't let you read a few lines of code... well sir, that would be idiotic. It's not like the code will virally infect you or anything.
But if it makes you feel better: there are many in Slashdot that are interested in Mono, which would provide ample justification for you to understand C# without working for the "dark side". The same would go for VB.NET, I think, which by the way, seems like a remarkably non-broken language compared with its predecessors.
Just remember that funny as it is, it actually happens. As a college student I annoyed countless lines of customers by consistently paying my 50 dollars in groceries in a chaotic mix of 1-dollar bills, quarters, pennies, lots of dimes, and "yes! I knew it was there!" a 10 or 5 dollar bill. More than once did I pay over 15 dollars in quarters.
Then if the poor cashier lost track of what I was doing, she had the choice of trusting me or counting that mess all over again.
Well, let's see what happened to series that tried to tell a continuing story:
- X-Files tried and very successfully told a good story through its mythology episodes. Guess what: what people complain about the X-Files are the mythology episodes. They demanded more independent episodes, "alien or freak of the week" stories. Their words are typically along the lines of "I can't skip it for a week or two because when I come back, I don't know what's going on".
So the X-Files ended up being a mixture of independent episodes, independent mythologies (so you could pay attention for only a season), and weird malabarisms to tie the mythologies of each season together. This was partly done to keep the audience interested as mentioned above, and partly to keep milking the series after each mythology ended.
A problem with good storytelling is that, in order to tell a good story, you need a beginning, development, and an ending. Unless you're remarkably inspired that's hard to build on-the-spot, but if you tell the networks you plan to finish the series in exactly 3 seasons they are not going to be happy. If the show is bad, they'll cancel it before, but if the show is good, they want to keep it running for as long as possible.
- Millenium tried to do the same as the X-files mythology. It had great character development, a good story to tell, great production values... and no one watched it because they didn't understand what was going on.
- Babylon 5 was the most ambitious series in that sense of storytelling. Continuous story, almost no isolated episodes, pre-planned five seasons... and is considered the geekiest show ever because you either have seen all of it from the beginning, or you don't know what the big deal is about.
Mainstream interest degenerated in a direct correlation with the development of the story, in spite of big compromises to try to bring new viewers to the series.
On the other hand, Star Trek has been successful mostly because it does not depend on real storytelling. Almost every episode is completely independent of each other, and each issue is either completely resolved in an episode, in a series of two-three episodes, or will never be resolved. Watch TNG any time, in any order... you'll notice it just has better execution of the "hit the reset button".
I agree with you with the need for decent storytelling, and that this depends mostly on continuity, as it is really hard to pack good stories and character development in a couple of episodes.
Unfortunately, the general public does not.
They don't have the time or the will to pay attention to a story periodically for that long, and the networks know it (they would probably be reading books if they did). Continuity helps to build a cult out of people who cares, which helps to hype something up to the mainstream media, but the networks are careful not to overdo it, as alienating the mainstream in preference is a bad market move.
They will put up with the storytelling in the movies because, in order to go to the movies, they have planned already to dedicate their attention to that story for as long, and only as long, as the movie takes.
Basicly, they are willing to read a book in one sitting, but if they have to stop at a particular chapter, and then remember what they have seen by the time they watch the next chapter, they get annoyed... or worse.
This is a fundamental problem with television which may or may not be solved with Tivo and similar systems, where the rythm to watch the story is not as imposed.
I also enjoy that about Anime: it tends to have a sense of story, as opposed to the recurring sketch that is a modern sitcom. But that is just more common in Anime, not prevalent. Some of the most popular Anime series have no story development whatsoever, and that happens to be their main appeal (Ranma comes to mind, Slayers), have a background story that is completely irrelevant/accesory (late Dragonball Z), or are just plain crap (too much to mention).
So just don't put all your hopes on Anime, if you haven't been exposed to that much of it you might be really disappointed. It's just a new market where you might find a bit more of what you're looking for. You may be lucky, or not, but you probably still have to search a bit.
Series I recommend for storytelling (in case you haven't seen them yet): Lain, Evangelion, Shojo Kakumei Utena, Noir, Escaflowne, Cowboy Bebop...
I wonder what is the opinion of Stallman with respect to the Bill and the letter?
Will he be as enthusiastic about it as everyone else seems to be? Or will he complain about the use of "open source" terminology and limited freedoms?
Will he praise Villanueva's efforts? Or will he complain that the Bill is not named GNU/1609?
This is the first semi-Insightful comment I have read on Slashdot in the last couple of months.
And it's a signed "Anonymous Coward" comment which no one will probably read because they think "microsoft sucks" comments with +5 represent the smartest people here.
Which, at this rate, they probably do. They talk about the "Great Blackout", but isn't the exodus of insightful commentary to better blogs something that has been happening for a long time, and yet an indication that commentary does not matter to what Slashdot is anymore?
I think according to the MSFT license, they would not have had the right to receive it (the European entity didn't have the right to license it), therefore they would not have had the right to relicense it under the GPL even if they didn't see the MSFT license.
Therefore, their code would be illegal. Charges could not be pressed, but once informed they would have to stop redistributing the code.
As long as you don't go to the US. If you do, you might get arrested for selling your criminal software to Americans or something like that.
It may sound stupid, but I think this would actually be the only way to get people to care about the absurd state of the Patent Office.
Face it: patents, for non-geeks, sound like an incredibly dull subject. They will find it preposterous and silly, but they won't stay tuned long enough to realize the damage it does to the economy. How many typical Joe Americans stay tuned for more than 30 seconds to a political analysis on NPR, C-SPAN or PBS?
Unfortunately, the patents are a "pure real issue". That is, they cannot be reduced to partisanship, a scandal or a psychological "hot button" (like "help the poor", racism, Big Government, abortion, Christian Decency, taxes, gun-control, etc) which seems the only way to gather support for an issue these days.
It takes some real thinking to figure out the role of IP on the economy, and then the role of the Patent Office in there, and then the difference between trademarks, patents, copyrights (because someone will ask about the "patent on Mickey Mouse or Shakespeare").
Even among geeks people care because it has become a psychological hot-button, with most geeks being "for-IP" or "against-IP". If they didn't already advocate one side, they wouldn't probably tune in either.
Now, put ESR or RS on Jerry Springer in a show about "Absurd Patents and the Outrageous Government that Grants Them!" and you'll see more people being aware of the subject than if you throw a rationalistic national campaign. After they already have a position, they might be willing to be convinced.