the entire site looks to me like someone desperate to sell a book.
and people say mitnick is full of himself? they've obviously never seen that site -- all the chest-thumping by the website author gets rather tiresome.
the website is also hideously ugly, almost as if the author doesn't want you to read it.
SpaceShipOne didn't even come close to what Shepard did.
SpaceShipOne went straight up and down, 367k feet. It peaked at mach 3 and reentry topped at around 5g's. Maximum reentry temperature was around 200F.
Shepard's flight was 612k feet, and 302 miles downrange. It peaked at mach 7.7, and on reentry he experienced nearly 12g's. Maximum reentry temperature was around 2000F.
And if they aren't rare, how would you know? That was my point. A leaky application that allocates 3MB on startup, leaks 1KB an hour, but never gets run for more than 5 days at a time, will probably never get fixed, because it's likely nobody will ever notice there is a problem.
Developers use things like dmalloc and mpatrol to tell, if they don't wrap allocations themselves (which is trivial to do). It's not like these are unsolvable C/C++ problems that can only be solved by porting to java.
That's great, but gcc4 is not the same thing as C++.
Sure it is.
$ cat test.cpp int main( void ) {
int xyz[30];
xyz[31] = 0; } $ g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with:../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=x86_64-redhat-linux Thread model: posix gcc version 4.0.1 20050727 (Red Hat 4.0.1-5) $ g++ -fmudflap -lmudflap -o test test.cpp $ ldd test
libmudflap.so.0 =>/usr/lib64/libmudflap.so.0 (0x00002aaaaaadc000)
libstdc++.so.6 =>/usr/lib64/libstdc++.so.6 (0x0000003d87d00000)
libm.so.6 =>/lib64/libm.so.6 (0x0000003d85900000)
libgcc_s.so.1 =>/lib64/libgcc_s.so.1 (0x0000003d87b00000)
libc.so.6 =>/lib64/libc.so.6 (0x0000003d85600000)
libdl.so.2 =>/lib64/libdl.so.2 (0x0000003d85b00000) /lib64/ld-linux-x86-64.so.2 (0x0000003d85400000) $./test ******* mudflap violation 1 (check/write): time=1128968399.682800 ptr=0x7ffffff384f0 size=128 pc=0x2aaaaaae4add location=`test.c:4 (main)' /usr/lib64/libmudflap.so.0(__mf_check+0x18) [0x2aaaaaae4add] ./test(main+0xbd) [0x400a65] /lib64/libc.so.6(__libc_start_main+0xef) [0x3d8561c3cf] Nearby object 1: checked region begins 0B into and ends 8B after mudflap object 0x602ae0: name=`test.c:2 (main) int xyz [30]' bounds=[0x7ffffff384f0,0x7ffffff38567] size=120 area=stack check=0r/3w liveness=3 alloc time=1128968399.682787 pc=0x2aaaaaae541e number of nearby objects: 1
microsoft and intel's compilers have similar features.
these tools exist, these are easily solvable problems. it's not like this is the exclusive domain of java.
now if they'll solve the java problem of eclipse and azureus wanting 100's of mb's of ram just to start up...:-/
telemarketers have got wise to this, that's why they're moving "offshore" and forging CID now.
demand to be added to the DNC list and they laugh in your face, "oh, we're in canada, HAW HAW HAW FUCK YUO STUPID AMERICAN WE WILL CALL YUO ANY TIME WE FEEL LIKE IT". real nice to get these criminals calling you at 5am.
memory *leaks* are rare because applications very rarely malloc. most data is temporary local variables off the stack, automatically destroyed when the function is exited.
gcc4 has -fbounds-checking and -fmudflap which work very well to catch bounds errors. while they might have been harder to find and fix years ago, they are now trivial and java no longer has the upper hand.
azureus (idle, no torrents running) takes 500mb of virtual memory and 100mb of real memory. when running, azureus is very sluggish. just like eclipse, by the way.
openoffice takes 100mb of virtual and 30mb of real memory.
java might "not" be "slower" but every java application i have ever used, old or brand spanking new recent, are all very sluggish and massive resource hogs.
people's current experience with java applications influences them far more than several year old microbenchmarks.
i have a desktop opteron with 1gb ram and azureus is still extremely sluggish compared to any other application including openoffice. azureus, with no torrents running, also takes many times MORE memory than openoffice! that's pretty amazing to me.
thing is, people waited and waited and waited and waited and waited for a java that didn't suck. java's poor reputation became pretty much cast in stone after nearly a decade of waiting. if java has only recently managed to fix the legions of major performance issues, it's rather late now.
"modern" applications like eclipse and azureus are so piggish and slow that it really doesn't feel like anything has changed since 1999.
so basically we're over a decade into java, and they're still having to fix major performance issues with java.
not to mention java has now fragmented into j2me/j2ee. wonder how much more it will fragment/diverge. j2we (web edition) anyone? maybe j2ge (gui edition)?
too bad jvms are still resource-hungry monsters. i'm quite tired of java apps taking >100mb of real memory and >500mb of virtual.
it's notable that these days, good java gui applications are the exception, not the rule, when it comes to java. applications like eclipse are highly unusual -- not the norm. most of java's penetration is behind the scene these days with web server backends, where interactive performance doesn't matter that much.
actually I have looked at the bugzillas and changelogs of hundreds of projects, and memory leaks are the single least common bug ever. far more common (by orders of magnitude) are off-by-one errors. java won't save you there. other far more common bugs than memory leaks are logical bugs and high level design flaws, which would have occured regardless if the project was written in c, c++, java, or any other language.
web applications are generally not time-critical, thus stuff like a couple hundred ms of GC won't necessarily hurt you. you hardly notice GC among the noise of network i/o etc.
when you get into GUI applications that's when it becomes really noticeable. the low performance and lag becomes annoying.
and when you get into the realm of realtime applications, games, etc. it's catastrophic.
i think the issue is that with C, you have control over exactly when and how the GC is done, so you can schedule it in ways it doesn't hurt your application.
actually, yahoo rewrote their merchant system in C++ and Perl, and of Jan 2003 yahoo is no longer using lisp.
so no, yahoo doesn't count anymore.
orbitz uses lisp indirectly. they didn't write the software, they licensed it from ITA. to claim orbitz "uses" lisp is kinda like claiming someone "uses" C because the linux kernel is written in it.
Because C++ compilers can ("implementation-defined") modify your main() to call static constructors. If this happens, your globals get stomped. You are also disallowed in C++ to compute the address of main(), lest you try to call main via a pointer.
because it's the latest fad, fashionable hip and trendy to bash mysql for (whatever perceived shortcomings). like bsd'ers bashing linux, it makes you leet. and it's a badge of honor. it doesn't actually matter if mysql is or isn't guilty of the things you accuse it of, as long as you make the accusations. you will be applauded anyway, because bashing mysql is so clever.
While it is probably the first time the copy technique had been expressed in C, it's certainly not the first time the actual technique had been expressed in code.
I recall seeing the same trick implemented in assembler somewhat earlier, I think the technique was called towers?
Slashdot Mirror
it's an excellent article which puts mitnick, markoff and shimomura in their proper light.
Hi shimomura. Or is it markoff?
Nice to see you're back.
the entire site looks to me like someone desperate to sell a book.
and people say mitnick is full of himself? they've obviously never seen that site -- all the chest-thumping by the website author gets rather tiresome.
the website is also hideously ugly, almost as if the author doesn't want you to read it.
SpaceShipOne didn't even come close to what Shepard did.
SpaceShipOne went straight up and down, 367k feet. It peaked at mach 3 and reentry topped at around 5g's. Maximum reentry temperature was around 200F.
Shepard's flight was 612k feet, and 302 miles downrange. It peaked at mach 7.7, and on reentry he experienced nearly 12g's. Maximum reentry temperature was around 2000F.
Developers use things like dmalloc and mpatrol to tell, if they don't wrap allocations themselves (which is trivial to do). It's not like these are unsolvable C/C++ problems that can only be solved by porting to java.
That's great, but gcc4 is not the same thing as C++.
Sure it is.microsoft and intel's compilers have similar features.
these tools exist, these are easily solvable problems. it's not like this is the exclusive domain of java.
now if they'll solve the java problem of eclipse and azureus wanting 100's of mb's of ram just to start up...
the government is allowed to ignore patents.
telemarketers have got wise to this, that's why they're moving "offshore" and forging CID now.
demand to be added to the DNC list and they laugh in your face, "oh, we're in canada, HAW HAW HAW FUCK YUO STUPID AMERICAN WE WILL CALL YUO ANY TIME WE FEEL LIKE IT". real nice to get these criminals calling you at 5am.
memory *leaks* are rare because applications very rarely malloc. most data is temporary local variables off the stack, automatically destroyed when the function is exited.
gcc4 has -fbounds-checking and -fmudflap which work very well to catch bounds errors. while they might have been harder to find and fix years ago, they are now trivial and java no longer has the upper hand.
azureus (idle, no torrents running) takes 500mb of virtual memory and 100mb of real memory. when running, azureus is very sluggish. just like eclipse, by the way.
openoffice takes 100mb of virtual and 30mb of real memory.
what.the.fuck ?
java might "not" be "slower" but every java application i have ever used, old or brand spanking new recent, are all very sluggish and massive resource hogs.
people's current experience with java applications influences them far more than several year old microbenchmarks.
i have a desktop opteron with 1gb ram and azureus is still extremely sluggish compared to any other application including openoffice. azureus, with no torrents running, also takes many times MORE memory than openoffice! that's pretty amazing to me.
so basically you had to write your code in a special way to get around the shortcomings of java's performance. this is not reassuring.
thing is, people waited and waited and waited and waited and waited for a java that didn't suck. java's poor reputation became pretty much cast in stone after nearly a decade of waiting. if java has only recently managed to fix the legions of major performance issues, it's rather late now.
"modern" applications like eclipse and azureus are so piggish and slow that it really doesn't feel like anything has changed since 1999.
so basically we're over a decade into java, and they're still having to fix major performance issues with java.
not to mention java has now fragmented into j2me/j2ee. wonder how much more it will fragment/diverge. j2we (web edition) anyone? maybe j2ge (gui edition)?
azureus is dog slow, and takes >500mb of virtual memory and >100mb of real memory. yeah, great example there.
and uh, comparing azureus/netbeans to openoffice ? can I have some of whatever you're smoking?
too bad jvms are still resource-hungry monsters. i'm quite tired of java apps taking >100mb of real memory and >500mb of virtual.
it's notable that these days, good java gui applications are the exception, not the rule, when it comes to java. applications like eclipse are highly unusual -- not the norm. most of java's penetration is behind the scene these days with web server backends, where interactive performance doesn't matter that much.
actually I have looked at the bugzillas and changelogs of hundreds of projects, and memory leaks are the single least common bug ever. far more common (by orders of magnitude) are off-by-one errors. java won't save you there. other far more common bugs than memory leaks are logical bugs and high level design flaws, which would have occured regardless if the project was written in c, c++, java, or any other language.
web applications are generally not time-critical, thus stuff like a couple hundred ms of GC won't necessarily hurt you. you hardly notice GC among the noise of network i/o etc.
when you get into GUI applications that's when it becomes really noticeable. the low performance and lag becomes annoying.
and when you get into the realm of realtime applications, games, etc. it's catastrophic.
i think the issue is that with C, you have control over exactly when and how the GC is done, so you can schedule it in ways it doesn't hurt your application.
actually, yahoo rewrote their merchant system in C++ and Perl, and of Jan 2003 yahoo is no longer using lisp.
so no, yahoo doesn't count anymore.
orbitz uses lisp indirectly. they didn't write the software, they licensed it from ITA. to claim orbitz "uses" lisp is kinda like claiming someone "uses" C because the linux kernel is written in it.
Because C++ compilers can ("implementation-defined") modify your main() to call static constructors. If this happens, your globals get stomped. You are also disallowed in C++ to compute the address of main(), lest you try to call main via a pointer.
See Section 3.6.1 paragraph 3 of IEC 14882.
because it's the latest fad, fashionable hip and trendy to bash mysql for (whatever perceived shortcomings). like bsd'ers bashing linux, it makes you leet. and it's a badge of honor. it doesn't actually matter if mysql is or isn't guilty of the things you accuse it of, as long as you make the accusations. you will be applauded anyway, because bashing mysql is so clever.
calling main in C is perfectly legal in both c89 and c99. in C++ it's forbidden.
read: useful for constrained (eg, embedded) systems.
While it is probably the first time the copy technique had been expressed in C, it's certainly not the first time the actual technique had been expressed in code.
I recall seeing the same trick implemented in assembler somewhat earlier, I think the technique was called towers?
provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
it's not obnoxious like the original bsd advertising clause, but you're still required by the license to toot your horn about ucb.