If I were to take all the claims in the
article literally, then these guys would have
to be magicians - since we know that some of
the things they claim to be able to do are not
compatible with the protocols in use today (i.e. impossible).
Add in random "gee whiz" quotes such as that it is possible to extract the data off an "erased" hard disk (which is entirely irrelevant to a discussion of Internet content) and steganography ("gee whiz, people can hide messages within inocuous text!) and we have the recipe for froth and bubble,
self-promoting but of no actual value.
C is a language which is extremely good for creating hard to trace bugs - memory leaks, data corruption and so on - and extremely poor for
programmer productivity.
Quite true. I've written quite a lot of C, C++
and Perl (and other languages irrelevant to
this discussion). I have found perl to be much
faster to write, its object model far cleaner
than C++, its modules actually usable, and its
execution time has never been a problem. Perl
has several dodgy language features and
I don't use those. Effortless polymorphism,
no anal requirement for full declaration, strings and hashes as part of the language core, inbuilt substitution and comparison operators and runtime garbage collection all give perl the edge over C++.
If I was writing a 50,000 line single-process application with a GUI, I'd probably do it in Java. But for anything smaller, and without
any strong speed constraints, it's really going to be much faster to write, and probably less buggy, when written in perl.
Rather than rebuilding the vacuum-tube behemoth
they should just write an emulator and release
it under the GPL. Then we can all have our
own colossus in an Xterm:-)
The analogy is unsound, because anybody can
make an infinite number of copies of some
Metallica MP3,
however your credit card
number is simply a reference to your money, which
is very definitely limited.
Now if only there was some way to replenish or duplicate the money in my bank account...:-)
I've found something which fails repeatedly after 2000-01-01 on Linux - but not on all of my boxes. Try this:
/sbin/clock -u -w
On most of my boxes there is no error. But on 3 boxes the error mktime() failed unexpectedly (rc -1). Aborting. is output.
Two of the boxes are running RedHat 5.2. One of the boxes is running the equivalent of RedHat 4.2. Other boxes running RedHat 5.2 are not affected.
Checking the library which is used by/sbin/clock, the 4.2 box is using libc 5.4.44, the 5.2 boxes are both using glibc 2.0.7. Other boxes with that same libc do not exhibit this error.
The linux kernel version is 2.0.36. It doesn't seem to be a hardware error... strace shows the process trying to open/dev/rtc and failing, but this also happens on another box which doesn't exhibit the error. Weird - no common denominator found yet.
Slashdot Mirror
Add in random "gee whiz" quotes such as that it is possible to extract the data off an "erased" hard disk (which is entirely irrelevant to a discussion of Internet content) and steganography ("gee whiz, people can hide messages within inocuous text!) and we have the recipe for froth and bubble, self-promoting but of no actual value.
If I was writing a 50,000 line single-process application with a GUI, I'd probably do it in Java. But for anything smaller, and without any strong speed constraints, it's really going to be much faster to write, and probably less buggy, when written in perl.
Rather than rebuilding the vacuum-tube behemoth they should just write an emulator and release it under the GPL. Then we can all have our own colossus in an Xterm :-)
The analogy is unsound, because anybody can make an infinite number of copies of some Metallica MP3, however your credit card number is simply a reference to your money, which is very definitely limited.
Now if only there was some way to replenish or duplicate the money in my bank account ... :-)
On most of my boxes there is no error. But on 3 boxes the error mktime() failed unexpectedly (rc -1). Aborting. is output.
Two of the boxes are running RedHat 5.2. One of the boxes is running the equivalent of RedHat 4.2. Other boxes running RedHat 5.2 are not affected.
Checking the library which is used by /sbin/clock, the 4.2 box is using libc 5.4.44, the 5.2 boxes are both using glibc 2.0.7. Other boxes with that same libc do not exhibit this error.
The linux kernel version is 2.0.36. It doesn't seem to be a hardware error... strace shows the process trying to open /dev/rtc and failing, but this also happens on another box which doesn't exhibit the error. Weird - no common denominator found yet.