Slashdot Mirror

In this particular case, how does the book, Vista Annoyances, not just duplicate the full contents of the equivalent title in the publisher's equally popular The Missing Manual series (also reviewed by Slashdot) which according to its official webpage "offers complete and comprehensive coverage of all five versions of Vista."

Oh, Really?

...are you sure?

I mean, seriously - you're sure about that?

Idiot.

/P

Do you mean like Oreilly's Safari service?

this article with a few graphs and stuff that sheds interesting light on the whole "How many vista installs..." question.

They compare Vista and MacOS, and no Linux numbers, but still, interesting read...

Excellent point. Although other debates have questioned Microsoft's numbers, if there are really 20 million installs (plus further installs since then) in use out there, hackers might begin to take a look.

But to paraphrase the Drake equation, of the total Vista installs, how many have been hit by crackers? How many of those were honeypots, caught by virus scanners, or otherwise detected? How many exploits found by crackers have been used in highly targeted attacks and kept secret?

All I can think of is the remote TCP/IP exploit. As some of you may recall, that exploit existed in all versions of Windows. And Vista supposedly has a "completely rewritten TCP/IP stack" (source).

"I have a bad feeling about this."

As I understand it, even with this so-called pharming technique, the bad guys still cannot correctly spoof an "https:" page... at least not without compromising the private key used to secure the SSL connection, or compromising the private key of the certificate signing authority.

When I explain to people how to use the Web, I always tell them to look for the security indicators before doing anything involving money.

P.S. I wouldn't be surprised if the bad guys here added Javascript code to their fake bank site, to rewrite the address bar of the web browser to show the "https:". This is why I prefer to do all my online banking with Javascript disabled; thank you, NoScript.

steveha

Here's a link explaining the parent for all you c|net "reporters" and NYT technology stringers who read slashdot. You know who you are.

Many, many years ago Michael Tiemann wrote a brilliant article on this very topic.
He and a couple of friends started Cygnus software, investing $6,000 to get
started. They added features (well, in the end pretty much built) the
GNU development tool chain. Their customers were embedded developers.

Here's the article:

http://www.oreilly.com/catalog/opensources/book/tiemans.html

I'm really sad to have come in late on this discussion because this
article is a must read for anyone wanting to make money writing free software.
Tiemann, et all became very rich doing it this way (Cygnus was sold
to RedHat for $600 million -- although a venture capital company
walked away with some of that money).

My quick take on it: Get money up front. Get paid for development,
not software. Realize that marketing is probably at least as
important was programming.

I really believe there is still a huge niche for custom software
development built on free software. Over 90% of software development
is in house development (OK, it's a number I pulled out of my
ass, but I think it's accurate). Your job as a free software
developer that wants to get paid is to convince companies that
you can deliver software to them cheaper than their in house
teams.

So what you need to do is to get a track record in the niche
that you want to work in. Then you need to hit the streets
and knock on doors. If you build it, they may or may not
come. You need to market your work. You need to show these
companies the potential for using your services rather than
building it themselves, or buying it off the shelf.

As Tiemann showed, if you do it right you will have more than
enough work to keep you fed.

a huge difference of opinion between someone who actually produces something, and those who spend all day theorizin

You are so right! RMS is just a lazy bastard who has never contributed anything to the community. Linus did his early work completely from scratch. Whatever you do don't read this book, it is full of lies: Open Sources

Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.

Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.

I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.

"Any particular one of the four books that people might know to be most useful for me, or a suggested reading order anyone might have?"

They're all good books but you may have trouble going from theory to practice. A book I'd recommend A website I'd also recommend Here's some more. A nice tool for those doing 3d flash and it's open source. Have fun!

Yeah, I think the article is a little off base about RTF. It's not IP-encumbered. As you pointed out, you can download the spec from MS. There's a ton of OSS implementations. There are perl modules that read and write it. There's an O'Reilly book on it (free short version of it here).

Okay, so RTF changes when a new version of Word comes out. That means that, e.g., it shouldn't be used for archiving government documents, and it's not suitable as a universal format for people to collaborate on extremely complex documents using different software. It doesn't mean RTF is useless or evil. I write fiction, and RTF turns out to be a very useful lingua franca for magazines that accept electronic submissions. For a fiction manuscript, you don't need anything very fancy --- basically just the ability to underline, and put a header on each page. RTF works just fine for that, and I'm really, really glad that RTF is the de facto standard for this purpose, and not doc.

It's unfortunate that OOo's RTF support is so horrible. E.g., if you save a document from OOo in RTF format, open it, edit it again, and save it again, you lose the whole document. Yeesh!

Users in a lot of places use their email as a document management system. This is somewhat effective on an individual basis, but in large organizations shared documents get duplicated dozens or even hundreds of times

For instance, suppose someone leaves the company, either permanently or in a vacation, and somebody else takes over a job. How do you transfer the relevant information to the substitute? Forward several dozens of emails and hope it makes sense? What if Alice forwards an email to Bob but not to Charlie, how do you make sure everybody in the project has access to all the relevant information?

Email and http are widely used because they are widely available, but neither of them is a very good solution for information handling.

Probably the best example of this is the GCC tool set as it was developed by Cygnus software (google around for Michael Tiemann's description of how to make this work -- it's brilliant.)

The eBook reader format that Oreilly adopts is likely to be my next favorite device, however. How would you like to search every instance of a function across their entire library, at once, on the plane?

I have also never submitted a kernel patch, but I want to try to answer your excuse. Start at kernel.org. Read through the Bugzilla Open Issues. I have read this book and it does an excellent job introducing the tools and techniques needed to work with the kernel.

To attack the meat of the article (Open Source Sun CPU), it is valuable because it gives the specialized community a rallying point to get behind. There might be less than 100,000 people qualified to do anything meaningful with this... but I assume you that the majority are not within the Sun umbrella and thus the release serves to benefit the majority of those who are qualified. And I would guess that a handful of the people who would care are old enough to be retired and would take an interest purely as a hobby that they wouldn't be able to do otherwise.

The other value is that as a student of computer science and engineering who graduated in '01... I haven't dealt with ANY of this type of work and that is a damned shame. A single university probably can't afford the $1B price tag, but I would bet a consortium of schools (MIT, CalTech, Stanford, CMU, Northeastern, RPI, UChicago, UPenn, et cetera) would jump on this. Could 20 schools inject $50M each? I think so. Add the value of educating 50 students per year at each of those schools (1,000 per year) would overvalue the $1B initial cost. After five years, the average cost per student would be as low as $50,000 because economies of scale would kick in (and I think you would agree that I have used extremely modest estimates).

So yeah, this is a VERY GOOD THING (TM).

The 2nd edition of this book already covered CSS2 and CSS2.1. It says so right on the cover. How about a pocket reference that covers CSS3 -- and a widely-used browser that supports it well.

I was looking at the O'Reilly page for this book. Under the review section, there are two reviews: 3/5 and 5/5. The page claims the average is 5/5. Let's see, (3/5 + 5/5)/2 = ((3+5)/5)/2 = (8/5)/2 = 8/10 = 5/5. Oh, their math is right. Never mind.

Please check thy facts, kind sir. Javascript was conceived of as a Java-like script language. A poor man's Java for those that found object oriented concepts a little too brain intensive. Thrown in the first netscape browser to allow a little customisation of the DOM on the fly, for things that then then HTML 3 couldn't do properly.

You may be surprised to know that I am well in possession of the facts. I used to believe that Javascript (formerly Livescript, formerly Mocha) got its name in simply a cross-branding deal. In fact, it was far more complex than that. Javascript was created to script Java as well as the DOM. The original concept would have blown today's AJAX out of the water in usability. Alas, it was not to be.

Here's more history for you: http://safari.oreilly.com/0768666775/ch01lev1sec1

Also, here's a bit of Javascript for you, demonstrating how powerful it was intended to be:

<script>
var myobj = Packages.javax.swing.JOptionPane;
var Frame = java.awt.Frame;

var frame = new Frame();

frame.show();

myobj.showConfirmDialog(frame, "Hello from Java! See Ma? No applet!");

frame.hide();
</script>

(That will work in FireFox with a recent Java plugin. I guarantee that it will not work on Internet Explorer.)

You have to remember, Java already existed in the browser when Javascript was created. Netscape internally discussed just using Java itself for scripting, but decided that a new, more dynamic scripting language would be more useful. (Source) Thus the birth of Javascript. Eich described the first revision as "having gotten out of the lab a bit earlier than intended". Javascript 1.1 was much closer to his vision, and what we think of today when we talk about Javascript.

You also need to understand that the Javascript language went beyond just the browser. Much of its development was driven by its use as a server-side CGI language. So it became a "real" language very quickly, despite its slow start.

And if you think that's cool, remind me sometime to tell you about how multipart/x-mixed-replace could have been server-side push long before AJAX, Comet, or <event-source> ever existed. ;)

Javascript is not an object oriented language.

Incorrect. Prototype-based languages are very much OO languages. They're different from class-based, languages, but that doesn't make them any less powerful.

There is no polymorphesm

I think you misunderstand the very meaning of polymorphism if you believe that.

Here's the "Runnable" interface implemented in Javascript:

var MyObject1() {}
MyObject1.prototype.run = function() { alert("Running 1!"); }

var MyObject2() {}
MyObject2.prototype.run = function() { alert("Running 2!"); }

var objarray = [new MyObject1(), new MyObject2()];

for(var i=0; i<objarray.length; i++) objarray.run();

The polymorphism appears to work fine?

or inheritance

Funny, Netscape's Client Guide has an entire chapter on that.

strong type checking

Strong typing is not a OOP requirement. It is a feature of some languages. Nothing more, nothing less. In any case, Javascript actually has quite a few typing fe

ESP Game:
http://www.espgame.org/

More info:
http://radar.oreilly.com/archives/2006/09/more_on_google_image_labeler.html

Very interesting video:
http://video.google.com/videoplay?docid=-8246463980976635143

Yeah both "AOL, Cordance, JanRain, Microsoft, NetMesh, Six Apart, Sxip, Sun Microsystems, Symantec, Verisign, Yahoo! [and] Google." http://radar.oreilly.com/archives/2007/12/openid_20_final.html Not to mention plugins already available for open source publishing tools such as WordPress.

Another potential solution is to create different ePaper books for different purposes, instead of saying "What people REALLY want is...". That's what you want, which is cool, but not necessarily salable.

Personally, I'd love 4 or so low-cost, safari-enabled, 7"x9" ePaper solutions myself (the website, not the web browser). Couple it with a tabletop computer (ala Microsoft Surface), and I'd be in heaven. Unfortuntely that's not necessarily salable either.

For tech books, I've already switched to that model. I give Safari $40 a month for their whole library. Since I used to buy more than one book of this type a month, and a typical title costs more than that, I'm way ahead. It's easy enough to print the occasional chapter when I need to, and the big bonus is that I have access to whole library anywhere I have Internet access at, instead of hauling the books around.

Their "DRM" as it were is that all the chapter downloads and printouts have my personal information watermarked in them. Doesn't restrict me one bit, but I'm sure not going to upload them to a warez site or something.

They are doing this, you mean, with books, but without the EVDO-based electronic reader; personally, I think Kindle support would be a great feature. See Safari.

Just write a memo, "We need a license for this code". It probably won't be very expensive.

Here's the policy on use of code snippets in O'Reilly books. They generally allow it, but require acknowledgement in the documentation.

I'd stick with O'reilly or some publisher that focuses on computers personally.

The Head First series is published by O'Reilly. I think it's a great series of books - even for advanced users.

Cricket Liu is a real authority. He's one of the authors of DNS and Bind which is the must read for anyone administrating a domain server. Just following the first couple of chapters and you'll have a robust server.

What I also like about Cricket Liu (and Paul Albitz) is that they explain the domain name system really well in an understandable way.

If you're server is handing out zones to anyone and everyone, you might want to check you're not offering recursion to everyone as well (see allow-recursion {}; ). http://www.oreilly.com/catalog/dns4/chapter/ch11.html.

Unfortunately, many people have been ridiculed when asking about these sorts of cables at their local electronics store: "But cables don't really have a direction. My expert friend at work laughed at me when I asked about this!" Yes, your friend is right. Cables don't have a direction, but these little arrows indicate that this cable will prevent or solve your ground loop problem.

Yeah, they are aiming at the wrong music. Instead of selling to the casual reader, who buys paperbacks, they should sell to people who buy technical references, who 1) are used to shelling out $30-40 for a book and 2) who often want to be able to access many books at once. A single fiction paperback is fine for the train and costs little. On the other hand, I'd kill for a device that would let me carry 10-15 O'Reilly references in my backpack. Unfortunately, the current devices don't render safari PDFs well because the screen is too small.

Woops, meant to Mod you funny, hit "Overrated" instead. I do miss the old style mod where I would get a chance to review/change the mod before clicking submit.

This comments erases it, all good now, keep bashing the statistics in the story. While you are at it pickup a copy of Oreilly: Statistics Hacks.

Oh, and here's the entire commend history summarized in five words: "Lies, damned lies, and statistics"

- except it was an application included on a CD in David Pogue's Palm PDA book:

http://www.oreilly.com/catalog/palmpilot/

- my client's simple license clearly stated 'no distribution on media without permission,' but it was included...

- i never busted o'reilly's chops about it, 'cause i met him one time at a Perl conference in Monterey and he was very nice to me...

If I understand correctly you must build from source if you want to use stable branch.
Binary set for 4.2 are just relase binaries, no errata patches are applied.

http://www.openbsd.org/stable.html

http://safari.oreilly.com/9780596510152/switching_to_the_openbsd_stable_branch

Pax isn't an OS X tool tool any more than tar is - just an FYI. Also, learn to love rsync. It would've done what you described in a breeze (at least when compared with other command-line tools).

Eben was right about o'reilly

OpenMoko and the 1973 will fail just as the Greenphone did. There is no leadership behind the project, no vision, just a bunch of well-intentioned geeks who want to make something cool. With no cohesive plan, though, the Neo1973 will never succeed.

1. If OpenMoko doesn't succeed, it will be largely because of posts like the above. Enough negative sentiment will doom any project, however cool.
2. OpenMoko isn't a product, it's a platform. Sure, the Neo1973 isn't the all-time ultimate mobile phone - it's a development platform. That's why in addition to the pre-built phone you get a development board you can house in your own enclosure with your own battery, screen, and other hardware bits. If you don't like Neo1973, build your own phone round the platform.
3. When I first started using Linux in 1993, doomsayers were saying it was obsolete and would never fly. Guess what? They were wrong.

I'm not saying OpenMoko is the world's ultimate phone project. Of course it isn't. But it's a good, big start, and it deserves support. If you don't support it, don't complain if, in ten years time, all you can get are closed, proprietary phones you can't even load your own software on.

You know, I'm getting old. I belong to a generation which, when someone gave us cool hardware, we grabbed and built cool software on top of it. Now, if it isn't all pretty and polished right out of the box, it gets condemned as rubbish. Guess what? Linus Torvalds was just a college kid when he wrote the first kernel. His professors didn't even rate him as very good. Certainly no-one thought he had leadership potential. And as for a cohesive plan, his cohesive plan was to build a scheduler which could schedule two tasks.

Stuff happens. It will surprise you. OpenMoko may, indeed, not be a great success. But if it's a bit of a success, other people will be able to come along and build on it - it is open source. In fact, that's already happening - that's what this story is about. The GreenPhone is not 'dead', it has mutated. Instead of building their own hardware platform, the Trolls are developing the 'green suite' on the OpenMoko platform. So you can still have your greenphone - the only thing is, it will be black and silver, or white and orange.

• Quality of underlying map data. Google only provides the lower quality Teleatlas data through their API (even though they use both Teledata and Navteq for their maps.google.com service). This has been well-discussed on O'Reilly's blog
• . Microsoft appears to provide high quality Navteq data through their API (based on the license marks shown on sites using Microsoft's APIs).
• Currency of map data. All of the providers receive quarterly updates from Navteq and Teleatlas. I looked at the currency of their data a year ago and found that Google and Microsoft were equally current, but they both were behind Yahoo (faster updates). It is probably worth doing a similar analysis and determining if one or the other is keeping their data more current.
• Advertising. I'm more familiar with Google's license than Microsoft's, however the Google license does have a few points that people should be aware of. Most notably they may include advertising in your maps.
• You cannot charge consumers
• You may not use the API if you charge consumers for content displayed on the maps. (Think you might want to create a premium section? You can't use Google maps). I don't know MSFTs terms.

> Even GPL 2 was written by lawyers. And as it so happens, your
> argument would be valid in the USA if the GPL was a contract
> according to US law, but it isn't.

http://www.oreilly.com/openbook/freedom/ch09.html
(The GNU General Public License)

------
Mark Fischer, a Boston attorney specializing in intellectual-property
law, recalls discussing the license with Stallman during this period.
"Richard had very strong views about how it should work," Fischer says,
"He had two principles. The first was to make the software absolutely
as open as possible. The second was to encourage others to adopt the
same licensing practices."

Encouraging others to adopt the same licensing practices meant closing
off the escape hatch that had allowed privately owned versions of
Emacs to emerge. To close that escape hatch, Stallman and his free
software colleagues came up with a solution: users would be free to
modify GNU Emacs just so long as they published their modifications. In
addition, the resulting "derivative" works would also have carry the
same GNU Emacs License.

The revolutionary nature of this final condition would take a while to
sink in. At the time, Fischer says, he simply viewed the GNU Emacs
License as a simple contract. It put a price tag on GNU Emacs' use.
Instead of money, Stallman was charging users access to their own
later modifications. That said, Fischer does remember the contract
terms as unique.
------

But we all know that the GPL is not a contract according to FSF and SFLC. :-)

------
One of biggest myths concerning the GPL was founded by the Free Software
Foundation's insistence that the "GPL is a license not a contract" or
it's a "conditional license". Perhaps they are confused concerning the
difference between a copyright license' "permitted scope of use
restriction" and a contractual covenant but all copyright license are
drafted as contracts.

The Supreme Court in referring to patents, opined in 1927:
"No formal granting of a license is necessary in order to give it
effect. Any language used by the owner of the patent or any conduct on
his part exhibited to another, from which that other may properly infer
that the owner consents to his use of the patent in making or using it,
or selling it, upon which the other acts, constitutes a license, and a
defense to an action for a tort. Whether this constitutes a gratuitous
license, or one for a reasonable compensation, must, of course, depend
upon the circumstances; but the relation between the parties thereafter
in respect of any suit brought must be held to be contractual, and not
an unlawful invasion of the rights of the owner."; DE FOREST RADIO TEL.
& TEL. CO. v. UNITED STATES, 273 U.S. 236 (1927)

This principle was held to apply to a copyright license by the Ninth
Circuit in 1996 (quoting the Second Circuit):
"Generally, a 'copyright owner who grants a nonexclusive license to use
his copyrighted material waives his right to sue the licensee for
copyright infringement' and can sue only for breach of contract." Id. at
1121 (quoting Graham v. James, 144 F.3d 229, 236 (2d Cir. 1998) (citing
Peer Int'l Corp. v. Pausa Records, Inc., 909 F.2d 1332, 1338-39 (9th
Cir. 1990))."; Sun Microsystems, Inc. v. Microsoft Corp.,. 188 F.3d 1115
(9th Cir. 1996)

The Eleventh Circuit is in accord with this principle:
"Implicit in that permission was a promise not to sue for copyright
infringement-a promise that at least one court has found to be the
essence of a nonexclusive license. See In re CFLC, Inc., 89 F.3d 673,
677 (9th Cir.1996) ("[A]nonexclusive patent license is, in essence, "a
mere waiver of the right to sue' the licensee for infringement.")
(quoting De Forest Radio Telephone & Telegraph Co. v. United States, 273
U.S. 236, 242, 47 S.Ct. 366, 368, 71 L.Ed.

http://en.wikipedia.org/wiki/Tim_O'Reilly

http://www.oreilly.com/

Hopefully those of us at Yahoo! working on Hadoop (and its related project Pig) can help change this perception.

It absolutely doesn't. According to this open letter http://www.oreilly.com/news/amazon_patents.html it's more of a stepping stone towards a larger crusade of reforming software and business model patents. I agree with some of the points he is making in the open letter. I for one would love to see a patent law that eliminates trolling. Patents should be limited to those making the real investment to bring an invention to market.

Please take a look at Linux Device Drivers, Third Edition. It's available for free but you of course will be purchasing it (you only mentioned it had to be free - not that you would be using the free version if there were multiple versions available).

I'll be expecting to see your name popping up on the Linux Kernel Mailing List in a few months announcing fixes and new features for my Intel, AMD/ATI, Via and NVIDIA graphics cards (some of which you will be reverse engineering). No need to thank me (you may also need to find a good book on X).

The project's new name, Emacs, came courtesy of Stallman. Short for "editing macros," it signified the evolutionary transcendence that had taken place during the macros explosion two years before. It also took advantage of a gap in the software programming lexicon. Noting a lack of programs on ITS starting with the letter "E," Stallman chose Emacs, making it possible to reference the program with a single letter. Once again, the hacker lust for efficiency had left its mark.6

In the course of developing a standard system of macro commands, Stallman and Steele had to traverse a political tightrope. In creating a standard program, Stallman was in clear violation of the fundamental hacker tenet-"promote decentralization." He was also threatening to hobble the very flexibility that had fueled TECO's explosive innovation in the first place.

"On the one hand, we were trying to make a uniform command set again; on the other hand, we wanted to keep it open ended, because the programmability was important," recalls Steele.

To solve the problem, Stallman, Steele, and fellow hackers David Moon and Dan Weinreib limited their standardization effort to the WYSIWYG commands that controlled how text appeared on-screen. The rest of the Emacs effort would be devoted to retaining the program's Tinker Toy-style extensibility.

Stallman now faced another conundrum: if users made changes but didn't communicate those changes back to the rest of the community, the Tower of Babel effect would simply emerge in other places. Falling back on the hacker doctrine of sharing innovation, Stallman embedded a statement within the source code that set the terms of use. Users were free to modify and redistribute the code on the condition that they gave back all the extensions they made. Stallman dubbed it the " Emacs Commune." Just as TECO had become more than a simple editor, Emacs had become more than a simple software program. To Stallman, it was a social contract. In an early memo documenting the project, Stallman spelled out the contract terms. "EMACS," he wrote, "was distributed on a basis of communal sharing, which means that all improvements must be given back to me to be incorporated and distributed."

Not everybody accepted the contract. The explosive innovation continued throughout the decade, resulting in a host of Emacs-like programs with varying degrees of cross-compatibility. A few cited their relation to Stallman's original Emacs with humorously recursive names: Sine (Sine is not Emacs), Eine (Eine is not Emacs), and Zwei (Zwei was Eine initially). As a devoted exponent of the hacker ethic, Stallman saw no reason to halt this innovation through legal harassment. Still, the fact that some people would so eagerly take software from the community chest, alter it, and slap a new name on the resulting software displayed a stunning lack of courtesy.

Such rude behavior was reflected against other, unsettling developments in the hacker community. Brian Reid's 1979 decision to embed "time bombs" in Scribe, making it possible for Unilogic to limit unpaid user access to the software, was a dark omen to Stallman. "He considered it the most Nazi thing he ever saw in his life," recalls Reid. Despite going on to later Internet fame as the cocreator of the Usenet alt heirarchy, Reid says he still has yet to live down that 1979 decision, at least in Stallman's eyes. "He said that all software should be free and the prospect of charging money for software was a crime against humanity."

http://www.oreilly.com/news/differences_nt.html

The ten connection limit was IIRC introduced into the NT codebase during NT 3.x days to stop people using NT Workstation as a very capable file server.

I also recommend the book Building Scalable Web Sites, also from O'Reilly. Loads of good ideas on clustering, performance monitoring, even some ideas on scaling the development process itself. Scalability and high availability are not the same thing, but much of the material covered in this book is relevant to both. /t

I'm a musician, have played in bands, have done recording of various types (multitrack, reel2reel mastering, digital) and have known a number of audiophiles (and enjoyed their systems) over the years.

This argument is similar to the debate years ago surrounding speaker cables. I wanted to get to the bottom of it, so I set up a test. I could not detect a difference between using expensive 'monster' cable and cheap lamp cable for the same set of speakers (although it is true that the potential for induction/crosstalk increases in the non-shielded cable - a smart deployment of the wire, seperated from power and crossing at right angles when needed, decreases the likelyhood of interference - and doesn't cost an arm and a leg).

Similarly, with a high quality headset (high and low frequencies beyond 'standard' headsets) - I can't tell the difference between a CD and a MP3 of the same song played through my system. Taking a step farther still, the sound is certainly better for that particular music than was possible via Cassette Tape or over the FM radio back in the day.

Short of hearing a live performance of the song - MP3 is as good as it gets - and certainly audio equivalent to CD when uncompressed. The argument from the article is a fallacy as far as I am concerned. Now it may be possible that someone with extraordinary hearing could detect details between CD and MP3 formats - maybe. But I am not one of those people.

I get the feeling from my own experience that these folks may be manipulating the outcome inside their mind. The human mind is capable of filling in the blesks - jhst as yiu rahd tneje wouhs tkat are sjwlhed incorrectly - by filling in the corrections in your mind. This is no different that what could be happening in your mind with the so-called differences allegedly heard between the different formats. This is certainly as valid a theory as that put forward in the article (that MP3 compression is heard differently than CD quality by the brain - and thus could effect our emotional experience of the music). Both signals are translated to an analog signal that powers the speakers in any case - and going back to my tried and true old recordings - I can't hear a difference. (Read this to learn more about mp3 compression and psychoacoustics)

I will say this - the quality of recordings has gone down - and not because of MP3s. I know this because my old albums and remasters of old albums are better on average than the new stuff that is coming out today - on CD or not doesn't matter. I hear a lot of rookie mistakes - particularly clipping/overdriving of recording levels - that are not present in the older recordings. That is not to say there aren't any good recordings today - they just seem to be few and far between.

This is much to do about nothing IMHO.

OK, so you believe that by posting as anonymous, that there is no way it could be tracked back to me? And you believe this in context to a story on a people tracking system?
Dude, spend less time jerking off, your brain needs more exercise.
Every ISP tracks and maintain logs of IPs, and dial in times for dial up customers. Many countries are introducing or have passed laws making it a legal requirement. Many (most?) ISPs are already doing it out of courtesy to law enforcement (wouldn't want to piss off the cia or interpol now would you?).
Some quick unfiltered results from a google search for those who are challenged in using a tool like google;
http://www.sage.org/lists/sage-members-archive/200 2/msg01352.html
http://news.com.com/2100-1028_3-6156948.html
http://tools.ietf.org/html/rfc3871
http://safari.oreilly.com/0130454966
http://news.zdnet.com/2100-1009_22-5748649.html

A quote from the last article;
A 1996 federal law called the Electronic Communication Transactional Records Act regulates data preservation. It requires Internet providers to retain any "record" in their possession for 90 days "upon the request of a governmental entity."
So brave man go ahead, post any classified secrets you know of as AC on slashdot and see if anybody is listening - that is IF you know of anything classified, somehow I doubt that you do.

Nope, you're wrong. There's lots of special behavior that you get with the empty <> that you don't get with <STDIN>. The special behaviors are particularly useful for writing filters (programs that read from and write to other programs via pipes) but they can be useful for standalone programs too. In fact, <STDIN> is particularly bad for writing filters.

See perlop - I/O Operators, scrolling down a bit to "The null filehandle <> is special...", and Perl Best Practices #135, Avoid using *STDIN unless you really mean it.