Slashdot Mirror

Pilot here. Can say the same. But remember that natural-born pilots fly with the guts, literally. You feel the flight in your stomach. You begin flying with glider planes.

This lack of gut-flying, and excessive reliance on simulators for everything, caused the crash of Air France 447: the pilot didn't feel the plane's attitude [falling while leveled] with his guts.

Centripital acceleration is equal to velocity squared over the radius of the turn.

The slow speeds of a glider or private plane require a large change in yaw or pitch to generate substantial g-forces (centripetal acceleration). On an airliner like AF447 flying close to the speed of sound, a small change in yaw or pitch generates large g-forces, which can easily overwhelm your gut feel for what the plane is doing and your sense of the pull of gravity (it's much easier to enter a 1-g turn even when inverted). You're much more reliant on the instruments to determine the attitude of the plane, and the instruments failed in AF447.

Every time relativity has been put to the test, it's been shown to be correct. As for Newton, most everyone knew there were problems with his gravitational theory in the 1890's... try to keep up. http://theory.uwinnipeg.ca/use... Newton gravity doesn't even account for the time differences from the ground to a GPS satellite. Newton didn't have satellites to contend with, so he never saw that particular problem... so he never knew it was a problem to fix. But, that's what science does... as technology progresses, we have to revisit earlier ideas to account for new observations. Hence, yes, Relativity replaced Newton's gravity.

Gravitational lensing has been a mathematical thing longer than General Relativity has been published. http://www.einstein-online.inf... In 1979 the first one was found, just as had been predicted. We understand them fairly well (the mechanism). So, just like EVERY OTHER prediction Relativity makes that has undergone experimental testing, Relativity was shown to be correct.

Electric universe bullshit, on the other hand, has no math behind it, has no observational data, and can't even find what few things it predicted we'd find. It's complete and utter bullshit trying to legitimize itself as science via really stupid people continuing to bring it up every chance they get. Additionally, Relativity has to be wrong for the electric universe cult of stupidity to be right. Yet experiments keep showing Relativity is correct.

Electric universe wise, even Alfvén can't find his radio transmissions that are REQUIRED. EU is complete and utter bullshit. It's not a new idea, it's an older idea that was disproven a couple decades ago.... it's just really stupid people keep bringing it up. It's not science, it's a quasi-religious pseudoscience cult of stupidity driven by their need to con people out of money for their t-shirts.

If you put forth a scientific hypothesis, and the only predictions it makes are shown to be wrong, your hypothesis is wrong. In the case of electric universe, that doesn't dissuade the fucking idiots from trying to make a buck off it conning people... or posting anon to try to defend complete rubbish. EU is the very definition of your cargo cult science, while people suggesting relativity, which has been verified EVERY SINGLE TIME it's been tested for 99 years now is... those people are complete fucking idiots.

'Not like anybody would've expected that ...no way ...'

Especially given Nikon's less than stellar record with encrypting stuff previously. Remember the fuss about Nikon's white balance encryption a few years ago?:

http://it.slashdot.org/story/05/04/25/0511241/Adobe-Blasts-Nikons-Closed-File-Format

Adobe cut a deal with Nikon over this to avoid potential DMCA violations (Adobe Camera Raw uses some Nikon code to decrypt white balance), but everyone else just reverse-engineered Nikon's 'secret' key, which turned out not to be much of a challenge - it's now the 'xlat' table in the dcraw and ExifTool source:

http://cpan.uwinnipeg.ca/htdocs/Image-ExifTool/Image/ExifTool/Nikon.pm.html

(Nikon obfuscates things somewhat by also using the camera serial number and shutter count as keys).

From the Elcomsoft article on the latest crack:

'Two 1024-bit (128-byte) signatures are stored in EXIF MakerNote tag 0Ã--0097 (Color Balance).'

This is the same tag that Nikon still uses to store white balance values encrypted with their broken xlat key (which dcraw, ExifTool and others routinely decrypt). Of course the difference here is that image authentication was a feature designed for the benefit of the (forensic) user, whereas white balance encryption was intended to benefit only Nikon by denying third party software access to important metadata. But both are now equally broken.

Quite a bit is localized to the cortex, such as motor control. It's also used for higher thought, but that's too random to really do much with. Humans have the most advanced cortex of any animal, although that also means it's thicker (1.5 - 4.5 mm), which may present the problem you propose.

I have never understood the "rubber sheet" model of gravity either, for that reason - it seems like circular reasoning. If somebody could explain that, I will have learned something today.

Wow you've haven't used DOS for very long have you? Try doing any sort of job control in DOS.

Hmmm.... The Scientific Method may be more accurately summarized as follows:

1. Observe
2. Develop Hypothesis
3. Make predictions based on hypothesis
4. Test predictions by experimentation

Remember: a Hypothesis is not the same as Theory

... we wrote it.

http://cpan.uwinnipeg.ca/dist/PHP

I think he meant an emulation mode in terms of vi emulating emacs.

However, there are easier ways to emulate vi in emacs, namely viper.

Perhaps you are thinking that "there are some memories that I have that I will never forget. I remember them as if they just happened. Sure, some of my memories may be become altered or even distorted, but surely these special memories are not subject to such changes." What you are thinking of are called flashblub memories, which are memories formed when some personally significant event occurs, and the whole scene is encoded into memory. Examples of flashbulb memories may include the first time someone asked you, or you asked someone, out on a date, the first time you heard that a special person died, when you first heard you won a prize or contest...

Neisser and Harsch (1992) had subjects describe what was going on when they first heard about the Challenger shuttle explosion. Two and half years later, Neisser and Harsch found their subjects, and again asked them to describe what they had been doing when they first heard about the Challenger explosion. They compared the descriptions and scored them for similarity. The mean score was 2.95 out of 7. Three subjects of 44 got a perfect 7, and over half were less than 2.[emphasis added]

Heh. By the way, galaxies don't move away from us faster than the speed of light. That would mean that in our frame of reference, galaxies move faster than light; that is false.

Tangent:
One can't just add velocities linearly in special relativity. One has to use a separate formula for that, known as the addition of velocities formula (see http://theory.uwinnipeg.ca/mod_tech/node137.html). Supposing I fire a man in a catapult going 0.9c (my catapult is awesome), and he throws a ball going 0.5c in his frame of reference (he is a major-league pitcher), the total velocity is not 1.4c: it is (0.5c + 0.9c) / (1 + (0.5c * 0.9c) / c^2) = .97c.

Looking at the source code to XML-RPC library in question, to me it's raises some disturbing questions.

From a design perspective, it's really bizarre the way they've chosen to use eval() in the first place.

For a given XML-RPC request or response, they parse the XML then generate PHP code on the fly, which later get's eval'ed. Aside from the fact that using eval() should trigger all sorts of security alerts in a developers head, especially when you're building a library for hooking up remote systems, there's no need to use eval() in the first place.

You can convert data types directly from XML into a PHP data structure then make use of things like call_user_func_array() to execute a callback function as needed. This approach is taken by The Incutio XML-RPC Library for PHP, for example, and there are others to chose from.

Two further things that are disturbing about this exploit.

First looking at the diff which patched the exploit here, all that's basically changed is replacing a single quote with a double quote. That may prevent this specific exploit but the use of eval() is still there and I'm not see any further stringent checks that the incoming input is valid / safe etc. Would not be surprised if there are other ways to "inject" code here.

Second and perhaps most disturbing is the source for this library has a long history going back to Usefulinc and Edd Dumbill. Believe this and the Perl Frontier-RPC libraries were the first two Open Source XML-RPC projects released and in many ways reference implementations in a manner that parallels Apache being a reference implementation for HTTP.

This exploint has taken a very long time to spot. Looking at the main projects CVS here, with the very first revision 1.1, back in "Mon Aug 27 19:21:25 2001 UTC" (and the code is older than that going back to 1999 I believe), it looks like this specific exploit was possible then.

These days Usefulinc are doing things Gnome related - i.e. you'd assume they are real developers not PHP script kiddies. The original developer, Edd Dumbill, is no fool. In Edd's defence, believe he began development before PHP 4.0.4, somewhere with PHP 3.x, which means things like call_user_func_array() was not available and perhaps eval() was required but that should have been revised by the current maintainers of the project as PHP matured.

What's more alot of people have used this code and (hopefully) it's also had alot of experienced eyes looking at it. Those who ported it to PEAR, for example, are not beginners.

But only now, six year laters, was the exploit found. Seems like not a proud moment for Open Source.

If only the fans of sci-fi would learn about special relativity, they would quickly learn that their dreams of intergalactic travel would quickly shrivel up. Consider the so-called "twin paradox" that would have a space traveler age quite differently than the people left behind. Here is a link http://theory.uwinnipeg.ca/mod_tech/node141.html with a brief explanation. Better ones can probably be found.

ABSOLUTELY SECOND THE MOTION FOR GD.

In combination with Perl, which has a neato module for using this, you can create very nice, functional graphs with minimal fuss.

I automated the creation of a set of graphs for a project I was working on. The hardest part was rebuilding Perl to include the GDI interface. But, that's much better documented than it was, and there's several subclass / extension modules to simplify life even further (check at CPAN.org for more info on GD, but a first link is: http://cpan.uwinnipeg.ca/dist/GD)

You can do almost anything you want. GD-graph, GD-chart3d, etc. Very easy to use once I got it installed.

The Friedmann equations which form the basis for standard cosmology in general relativity, treat the universe as a perfect fluid, a non-interacting medium characterized by only its density and (isotropic) pressure (the Weyl postulate). Basically, it treats whole galaxies as "particles" in a "cosmological fluid".

How come copiers aren't taxed?

Actually, there is a tariff on photocopiers and toner in Canada, with the proceeds going to rightsholders. And libraries have to keep complete logs send in part of their copy machine income to CanCopy as well.

I don't think the tariffs are high enough. There's no "punishment", and you don't help your argument by using such loaded language.

I would quote my physics books but it is harder to provide a link to a hardback book ;-)

but here are a few more links:

http://theory.uwinnipeg.ca/mod_tech/node78.html
http://www.christiananswers.net/q-eden/edn-thermod ynamics.html
http://www.cartage.org.lb/en/themes/Sciences/Chemi stry/Miscellenous/Helpfile/spontaneityentropy/2ndl aw.htm

Google has 15,897 more if you like. Every one I reviewed said entropy can ONLY increase.

As per your statement, I beleive I DID refute your claim.

You put forth a tea cup as a model for your claim that entropy remains constant.

I provided two counter examples that directly refute your claim. One immediate and one very long term. Tea evaporating and wood rotting. Both of these will increase the entropy of your system unless energy is used to counter act it.

I also provided an atomic view of the world that directly refutes your claim vis-avis nanotech.

This principle is represented in the "activation energy" of chemical reactions. You can graph it by drawing a line followed by a hump with another line following the hump at a different height than the first.

In a chemical reaction you must put enough energy into the molecules to get them over the hump. The hump represents how dificult it is to get the atoms where they need to be. The height of the lines represents the energy level of the products based on bond energy and entropy level.

Now, please remember that atoms are not all at the same energy level. Temperature only represents the AVERAGE energy level. Now if the hump is close to the line on one side, the chance of a random higher energy molecule hitting your fancy nanite and giving it enough energy to break apart goes up dramatically.

As per YOUR physics knowledge, I will admit there is the possibility of a system which does not spontaneously increase entropy. However this system absolutly requiers a closed system and pre-existing uniform entropy. Your example has neither of these. Now systems like this has ever been observed or created and no one anticipates finding them.

I suggest that you review your physics books and sample problems before you try and design an entropy static system.

would be to use Net::SFTP. At this point you are scripting in Perl, which might be a good thing ;)

'Black holes' and 'worm holes' are two very different things.

http://theory.uwinnipeg.ca/users/gabor/black_holes /slide9.html

"The Earth's mass does affect it's orbit around the Sun. See Kepler's laws of planetary motion."

That's not correct.

• Kepler's 1st Law: "The orbits of the planets are ellipses, with the Sun at one focus of the ellipse."
• Kepler's 2nd Law: "The line joining the planet to the Sun sweeps out equal areas in equal times as the planet travels around the ellipse."
• Kepler's 3rd Law: "The ratio of the squares of the revolutionary periods for two planets is equal to the ratio of the cubes of their semimajor axes."

You can prove it algebraically: Taking the simple case of a circular orbit, let r = orbital radius, M = mass of sun, m = mass of earth, G = gravitational constant, F = attractive force between sun and earth due to gravity, v = instantaneous linear velocity of earth

From Newton's law of gravitation, F = GMm/r^2

Since the orbit describes a circular path and no other forces act on the Earth, the centripetal force acting on it must be F. (Any object moving in a circle requires a centripetal force acting towards the center of the circle)

Centripetal force F = mv^2 / r

Since the forces are the same, equate them:

mv^2/r = GMm/r^2

Multiply both sides by r:

mv^2 = GMm/r

Divide both sides by m

v^2 = GM/r

As you can see, the orbital radius depends only on the Sun's mass (M) and the instantaneous velocity (v) since G is a universal constant. It is unaffected by the mass of the Earth.

The maths is a bit trickier for an elliptical orbit but the 'm's still cancel.

It is worth noting that in practice the Sun experiences the same force and is therefore displaced, but only by a tiny amount because it has a much greater mass than the Earth. I'm not sure if this is measurable but it has very little to do with the Earth's orbit.

This is a common misconception but it's simply not true. The theoretical limit of efficiency is for an internal combustion engine like the one we use in our power plants is 35%. Internal combustion fossil fuel power plants operate at very near that theoretical limit but you have to factor in transmission loss, about 9%, which basically makes them equal to best-case car engine use (about 30%). The problem with today's cars is they often operate far from best-case (idling, downhill slopes, breaking, etc) bringing their efficiency down to 18-23%. This is why hybrid vehicles do so much better. They operate the engines much more intelligently and bring the efficiency up to about 30%. That means that an electric car powered by an fossil fuel power plant uses just about as much fuel as a hybrid car running on gasoline. This says nothing about pollution emissions which will be better from the power plant, but fuel use and CO2 emissions will be roughly the same.

The only way electric/fuel cell based cars are actually a benefit to the environment is if they are powered by nuclear power plants or some other non-poluting technology. Fuel cells in cars won't solve anything by themselves.

Good stats on fuel efficiency

Second law of thermodynamics wrt. internal combustion

"If I hadn't switched to gmail I'd plan on participating."

Mail::Webmail::Gmail

For anyone seriously needing to migrate from a webmail provider, there are various Perl tools such as yahoo mail downloader.

If your favourite web-based data source doesn't already have a tool to access it using Perl, there are also web-scraper modules (and LWP) which make it easy to build your own. Remember to put it on CPAN if you create something new.

Dark energy apparently exhibits a repulsive force similar to gravity but opposite to it in direction... what direction does Gravity work in? I mean, it "pulls towards" something, correct? So this "Dark Energy" repels away from something?

I wrote my own little Perl scripts using MP3::Info and MP3::ID3v1Tag. While you're at it, you may want to check out Apache::MP3 and my own pet project, TVDinner Streaming MP3 Server.

I wrote my own little Perl scripts using MP3::Info and MP3::ID3v1Tag. While you're at it, you may want to check out Apache::MP3 and my own pet project, TVDinner Streaming MP3 Server.

I wrote my own little Perl scripts using MP3::Info and MP3::ID3v1Tag. While you're at it, you may want to check out Apache::MP3 and my own pet project, TVDinner Streaming MP3 Server.

Nothing that can't already done with any number of form automation/templatting systems already out there. And where's the docs?

I'll stick to mod_perl, CGI::Application, HTML::Template and CGI.pm. But that's my opinion. Everything I could possibly need for dynamic forms with flexible presentation.

Nothing that can't already done with any number of form automation/templatting systems already out there. And where's the docs?

I'll stick to mod_perl, CGI::Application, HTML::Template and CGI.pm. But that's my opinion. Everything I could possibly need for dynamic forms with flexible presentation.

You use PERL? As in PERL?

Netscape 2.0 enabled framesets and was introduced March 1996.
It was added to HTML 4 at least as early as Dec. 1997.
A note on frames with CSS dated 08-Jun-1996 exists also.
The article mentions having an invention date at least as early as May 1996
Even the patent is completely silly, but the dates are wrong, March happend before May in the year 1996, didn't it ?

For the record, you're wrong.

Please look at wxPython and Perl's entire user interface section of CPAN.

Please do the tiniest bit of research before you post. It would have been enough.

* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.

That's a nebulous statement. I think Perl is not a hard language to learn. Furthermore, I don't see anything in this post that leads me to believe eggtroll has ever used either language, so this isn't even good anecdotal evidence.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

Perl's OO support does need work. But it does support introspection. (Reflection is another term for introspection.)

Real problems with Perl's OO: it does not statically check anything. It does not enforce encapsulation. It feels like a kludge in general to me. From what I've been reading of Perl 6, I think it will be much better. I'm looking forward to it.

Self-replication? Ontological data-points? These are not OO terms.

I do not use PHP, but I would be shocked if its OO support rivalled SmallTalk's. You'd need to provide a lot of evidence for me to accept that.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later.

I regularly use Perl with Oracle. There are many different database drivers.

* Speed. [...] Its [sic] definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point.

I assert otherwise. Prove it. In fact, I think PHP uses the PCRE - Perl-compatible regex library, intended to be like Perl's but somewhat less complete.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl!

I do regularly, with success.

* Graphics. [...] Perl lacks a graphics library of any kind.

Wrong. It has image libraries and windowing libraries.

* Data Structures. [...] Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used.

Perl has references. As in Java, they are essentially safe pointers with automatic memory management (though the GC is less sophisticated). And it does have OO support, at least to the extent required to make a Node class. There is no limit to the data structures possible in Perl.

Perl has its flaws, but these are not they.

* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.

That's a nebulous statement. I think Perl is not a hard language to learn. Furthermore, I don't see anything in this post that leads me to believe eggtroll has ever used either language, so this isn't even good anecdotal evidence.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

Perl's OO support does need work. But it does support introspection. (Reflection is another term for introspection.)

Real problems with Perl's OO: it does not statically check anything. It does not enforce encapsulation. It feels like a kludge in general to me. From what I've been reading of Perl 6, I think it will be much better. I'm looking forward to it.

Self-replication? Ontological data-points? These are not OO terms.

I do not use PHP, but I would be shocked if its OO support rivalled SmallTalk's. You'd need to provide a lot of evidence for me to accept that.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later.

I regularly use Perl with Oracle. There are many different database drivers.

* Speed. [...] Its [sic] definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point.

I assert otherwise. Prove it. In fact, I think PHP uses the PCRE - Perl-compatible regex library, intended to be like Perl's but somewhat less complete.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl!

I do regularly, with success.

* Graphics. [...] Perl lacks a graphics library of any kind.

Wrong. It has image libraries and windowing libraries.

* Data Structures. [...] Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used.

Perl has references. As in Java, they are essentially safe pointers with automatic memory management (though the GC is less sophisticated). And it does have OO support, at least to the extent required to make a Node class. There is no limit to the data structures possible in Perl.

Perl has its flaws, but these are not they.

* Ease of use. After about a day I had an excellent understanding of both PHP and SQL. I was able to get a stable, useable and presentable website up within 24 hours of reading the basics of PHP. Learning Perl took me weeks and I'm still not even as good with it as I am with PHP. I would definitely not recommend anyone new to programming begin with Perl.

That's a nebulous statement. I think Perl is not a hard language to learn. Furthermore, I don't see anything in this post that leads me to believe eggtroll has ever used either language, so this isn't even good anecdotal evidence.

* The OO of PHP is excellent. In my experience, it rivals Smalltalk. We all know that Perl's OO still needs work (whether or not OO is all that great is another discussion.) Hopefully Perl will be patched up so it supports such must-have OO features like introspection, reflection, self-replication and ontological data-points.

Perl's OO support does need work. But it does support introspection. (Reflection is another term for introspection.)

Real problems with Perl's OO: it does not statically check anything. It does not enforce encapsulation. It feels like a kludge in general to me. From what I've been reading of Perl 6, I think it will be much better. I'm looking forward to it.

Self-replication? Ontological data-points? These are not OO terms.

I do not use PHP, but I would be shocked if its OO support rivalled SmallTalk's. You'd need to provide a lot of evidence for me to accept that.

* Outstanding database support. PHP supports virtually every DB under the sun (although Berkeley DB is missing, oddly enough.) Perl seems limited to MySQL and PostgreSQL, and its really a kludge for the later.

I regularly use Perl with Oracle. There are many different database drivers.

* Speed. [...] Its [sic] definitely faster than Perl in almost every case, particularly in regex which has long been Perl's strongest point.

I assert otherwise. Prove it. In fact, I think PHP uses the PCRE - Perl-compatible regex library, intended to be like Perl's but somewhat less complete.

* Portability. I can take PHP code off my Linux box and plop it onto an IIS server, or even one of those new Macintosh servers and have it run without having to change a single line of code. Try doing this with Perl!

I do regularly, with success.

* Graphics. [...] Perl lacks a graphics library of any kind.

Wrong. It has image libraries and windowing libraries.

* Data Structures. [...] Under Perl you're extremely limited in what you can do. This is because Perl isn't OO (so you can't create Node classes, for example, usefull in a linked list) and because it lacks pointers. Some of you may notice that PHP lacks pointers, but look deeper! Behind the scenes, hidden from the user pointers are used.

Perl has references. As in Java, they are essentially safe pointers with automatic memory management (though the GC is less sophisticated). And it does have OO support, at least to the extent required to make a Node class. There is no limit to the data structures possible in Perl.

Perl has its flaws, but these are not they.

...I'm definitely going to take advantage of F !=ma. I'm going to give my car a good shove tomorrow morning and ride it all the way to work.

I just hope that we don't spin out of orbit while F != G(m1m2)/d2. I guess, though, that if we start to spin out of orbit, somebody on the far side of the planet can just give it a shove and we'll be back in place.

Unfortunately, I've already noticed my CPU getting hotter. And I stood on this really tall guy's shoulders but I couldn't see very far...

Check out WWW::Automate if you need to code a web application test in perl.

There used to be a theory of gravity, it is now the law of gravity. It has been proven. It has been observed many times. Gee even the folks in east Tennessee call it Newton's 2nd law. And in Oregon. And in Winnepeg. Or do a Google search.

So you are saying that you have proof of the three items you mentioned? Would you please post them for our education? But number 2 is not evolution, it is adaptation and that is totally different and can't be used to prove number 1 (see my previous post concerning the wallabys, they are still wallabys). I am not sure that number 3 can be used to prove number 1 either. There are very good arguements against DNA proving evolution. The fossil record could be misintrepreted, just as the length of time in the earth's creation is being misintrepreted. And morphology is simply studying change which is another way of saying adaptation (using big words to hide the truth).

No, I haven't seen a species or a universe being created. But I also don't refer to it as a theory (nor as a law). It is simply fact and has been declared since the beginning. The "theory of creationism" was created by scientist attempting to drag creation down to the same level as evolution.

I don't hear voices in my head, and I have never heard voices in my head. And you called me a very poor troll.

I guess you just have a bizarre and rarefied sense of humour.

actually if you install the cpan perl modules it has a wonderful installer.

for example to install the icecast perl module

you run
$cpan
cpan> install Net::Icecast

it will get the module in question and any dependencies you might have. then it will compile and install them. it has similar facilities for searching and quering package information. what more does the pear installer do?

it's nice that php finally has such a beast. like i said things might have changed in the last year or so. a quick browse through the available packages at pear shows that they still have a long ways to go though.

What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.

Perl is really good about this. The Test::Harness and Test::More modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.

PostgreSQL has regression tests.

There's a really nice test environment for Java code called JUnit. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways. I'm using a C++ workalike called CppUnit in one of my projects.

The Boost code has automated testing.

There's a project called qmtest.

The Wine people have recently started using regression tests.

What's shocking to me is that almost no open source authors or advocates give a hoot about automated testing of any kind. The only free software I've found with a test suite is gcc. As much as I hate to say it, there's a good chance that the relative inexperience of most open source authors is a factor here.

Perl is really good about this. The Test::Harness and Test::More modules make it very easy to write test suites, so CPAN modules have lots of automated tests. It might even be a requirement to get a module into CPAN; I'm not sure.

PostgreSQL has regression tests.

There's a really nice test environment for Java code called JUnit. Lots of stuff is using it. Lots of articles about how to write effective tests. There's a project to develop mock versions of common objects (servlet requests, SQL queries) that fail in interesting, predefined ways. I'm using a C++ workalike called CppUnit in one of my projects.

The Boost code has automated testing.

There's a project called qmtest.

The Wine people have recently started using regression tests.

Semi off-topic, but you just can't compare CPAN to PEAR

CPAN and PEAR have nothing in common. CPAN stands for Comprehensice Perl Archive Network. This highly active site is maintained by the Perl community. From CPAN you can find hunderds (thousands?) of Free Perl libraries and corresponding on-line documentation.

PEAR web page says "PEAR is a framework and distribution system for reusable PHP components". So among other things, it acts as an abstraction layer to various RDBM's.

I don't think there's full equivalent to PEAR in Perl world but what the original poster probably meant is DBI - The Perl Database Interface.

Ever tried adding metadata to an MP3 file? ID3v1.1 is trivial but ID3v2 has a 95,000 line reference implementation. Uh? UH?

Perl's MP3::Info Module makes ID3v1.1 updates pretty easy but as you said, ID3v2 isn't quite as easy. It has some support for ID3v2 tagging (read, delete but no update).

Hopefully write support will be available soon. The author doens't want to use MPEG::ID3v2Tag because it requires >= Perl 5.05. The MPEG::ID3v2Tag module doesn't look too rough.

Ever tried adding metadata to an MP3 file? ID3v1.1 is trivial but ID3v2 has a 95,000 line reference implementation. Uh? UH?

Perl's MP3::Info Module makes ID3v1.1 updates pretty easy but as you said, ID3v2 isn't quite as easy. It has some support for ID3v2 tagging (read, delete but no update).

Hopefully write support will be available soon. The author doens't want to use MPEG::ID3v2Tag because it requires >= Perl 5.05. The MPEG::ID3v2Tag module doesn't look too rough.

Here and Here

This is a really great Perl module that can help to combat the CodeRed virus and could possible even be used on Nimda:

Apache::CodeRed

Sorry - I have to disagree.

SOAP is a messaging protocol based on XML, and can be parsed in any language for which there are decent XML parsing tools: hence, the already extensive SOAP tools for Perl. It's already on the standards track with the W3C. There's already a good deal of support for SOAP in Perl.

Committing to CORBA means using a CORBA-compliant development environment, which doesn't even take into account the differences between CORBA implementations. Committing to RMI basically means you're using Java, period. Support for SOAP in a programming language, on the other hand, is only a couple of steps past a decent XML library.

There is a Perl module that does the same sort of thing written by Lincoln Stein on CPAN: Apache::MP3.

--

Damian Conway threw together a brilliant application for this new breed of computers. QSP

Imagine not having to wait Log N for anything!

Dancin Santa