Sure you can decompile an optimized and symbol-stripped C++ program, but you'd never have it the original compact form of the source as you do with the Java class file decompilers due to the heavy use of inline functions and templates used in C++. A C program, sure, but decompiling C++ is not terribly useful.
I have a buddy who still uses an old WP Java beta and swears it runs wonderfully now that PCs are fast enough to run it properly.
Slashdot tip #53: When annoying 'facts' get in the way - invent a buddy! Watch in awe as Java zealots mod up a baseless pro-java post based on second-hand hearsay!
Hearsay Any evidence that is offered by a witness of which they do not have direct knowledge but, rather, their testimony is based on what others have said to them. For example, if Bob heard from Susan about an accident that Susan witnessed but that Bob had not, and Bob attempted to repeat Susan's story in court, it could be objected to as "hearsay." The basic rule, when testifying in court, is that you can only provide information of which you have direct knowledge. In other words, hearsay evidence is not allowed. Hearsay evidence is also referred to as "second-hand evidence" or as "rumor." You are able to tell a court what you heard, to repeat the rumor, and testify that, in fact, the story you heard was told to you, but under the hearsay rule, your testimony would not be evidence of the actual facts of the story but only that you heard those words spoken.
The article's author states: For users accessing mail via IMAP or POP, network speed and congestion have a greater influence over performance than anything done on the client side; even for users with local mailboxes, I doubt that we're looking at a huge performance hit.
I beg to differ. I use email a lot - as do most people. I need it to be lightning quick in handling multi-megabyte local mailboxes. Basically, he could not have thought of a worse example of where performance supposedly does not matter since modern email repositories resemble databases these days. I am not willing to give up performance for perceived security in this area. Yes, that's right - performance and ease of use are every bit as important as security. Security for security's sake is simply not good enough. Users expect more - they expect both security and performance. You cannot give them less than what they already have. If the C or C++ code has a flaw - you fix it - it's that simple. OpenBSD has been doing this for years. Yes, it takes extra work - but the results are well worth it. Just don't give me this crap that my critical applications have to written in some interpreted or sandboxed computer language which takes up 4 times the memory and runs at less than half the speed all just for supposed security's sake. Show me this magical machine that can make all interpretted code run lighting fast and I will show you a machine that can run twice as many compiled applications over three times faster.
I was referring to the data stored within the STL vector or map being very space efficient. As for template code bloat - it's getting less so with modern C++ compilers. Furthermore, only the template functions actually used by the program are actually linked into the executable. Because STL does not use virtual functions programs using these templates can be highly optimized. Some compilers even share template methods between types if the type does not affect the generated code. However, I will concede that all this intense optimization does take a lot of compile time and memory. Some scarier template-heavy source files I've encountered using Boost have used 500 megs of RAM to compile under high optimization; but the final.o file size was very respectable.
Spirit has to be seen to be believed. Basically you contruct a parser which looks like normal extended Backus-Normal Form (EBNF) but the source you write is 100% C++ source code - not run through a preprocessor:
This is truly a testimony to the power and expressiveness of C++ operator overloading and templates.
As an aside, Perl6 is slated to have lexer/yaccer rule syntax built into the language itself. It's really an exciting time for users of computer languages.
Templates only seem to be a necessary evil in OO languages that don't ultimately inherit all objects from one object.
This is a naive view that circa 1992 C++ collection class designers used to share. The OO-container strategy was proven to be slow and not type-safe. The designer of the C++ Standard Template Library (STL) Stepanov does not even believe in OO programming - he calls OO a hoax. I personally would not go that far, but I appreciate that OO and generics are completely independent concepts. Furthermore, an STL map or vector working on types directly is much more space efficient than any OO container-based approach because each object contained does not require OO overhead. Indeed, native types (ints, doubles, etc) in vectors can be nearly as efficiently stored and accessed under STL as would C style arrays. No need for awkward casting or unnecessary and slow boxing/unboxing. To sumamrize, C++ templates and the STL fit in perfectly with the C++'s "zero overhead" principle.
If CDs could not be perfectly copied then Intuit and other firms would not have to resort to this nonsense. They could just insist on using the program with the CD in the drive (like most other consumer software sold). But cheap CD copying - 50 cents or less - makes this scheme useless. I know this may not be politically correct in the Slashdot crowd, but how do you prevent software piracy without resorting to such draconian measures? Must you accept that for every copy of software sold that two will be pirated?
I see you're a proponent of efficient market theory where the market somehow "knows" the intrinsic value of goods. Well, the dot com bubble disproved that theory. Lawsuits are a complete crapshoot. No one is willing to place a big bet on one side or another until the judge has ruled. Anyway, the current market cap of SCOX is irrelevant compared to the billion dollars they are asking for in damages. Notice that insiders hold the majority of stock. They cannot be bought out without their approval. The insiders are probably holding out for $500 million. Remember - Caldera successfully got money from Microsoft over DR DOS. Anything is possible.
You've got to love these arm-chair economists. Who is this "we" the article talks about? We should do this, we should do that. These vague generalities may make for an interesting article, but they're not good for much else. When a company is losing money certain actions must be taken for the survival of the company. Costs must be cut. Do you borrow money and invest in research and development and continue losing money in a down market? Of course not. The company would go out of business in no time. American companies are not stupid. When times are bad you scale back and when times are good you expand. R&D still goes on throughout this entire process, albeit at a slower rate.
It's a shame that RMS fails to see the advantage of opening up GCC's data structures. Sure there would be some cheaters who'd use it for personal gain (writing proprietary front-ends for the GCC backend) - but there would be ten times as many people creating useful free languages and other free tools with it. It would also greatly aid in the learning of GCC itself (no simple task). It's a calculated risk, but in my opinion, one with more upside than downside potential. But who are we to say what RMS should do with his work? The FSF is the copyright holder, afterall.
who the their right mind would not want to be part of a "do not call" registry? Lonely or insane people? People with too much money to burn? The government would save a lot of money creating a "please call" registry. That way the drug companies would know exactly who to target their anti-depressant drugs to.
Keep in mind that NPTL paved the way for the kernel changes that NGPT also makes use of. I'm sure that the NPTL team won't simply give up. Anyway - it looks like Linux will finally have a good SMP threading library.
I stand corrected based on your clarification of platform support. Is there a simple way to build a stripped down minimalistic Pike without modules/threads/shmem/java etc? Also may I ask what compiler is this "rntcl"? (from "Windows_NT 4.0 x86 CC=rntcl) I can't find anything about this compiler on Google except for Pike references. Is "rntcl" a commercial compiler?
Thanks for the info. The Pike platform build success grid does not look very encouraging for platforms other than IA32 Linux. Too bad - Pike is an excellent language - much better and faster than any interpreted C-like language I have used. Pike also appears to be roughly 2 to 4 times faster than Perl 5.x and all free ECMAScript implementations. I'm a Pike convert. I'll hack on Pike under Cygwin disabling stuff until it works. I suspect that disabling native code generation might do the trick.
I can build and run Pike okay on Linux, but building on Cygwin complains about unresolved externals (shmget and other shm* functions). I then #undef'd the appropriate code in memory.c to disable shared memory support, and re-make. Pike.exe appears to link without errors or warnings but the final pike.exe is not functional. All pike scripts appear to run, but do nothing and print no error but the shell returns "10" when queried via echo "$?". Any ideas? Is Pike supported on Cygwin?
That's a great language features decision article you wrote. They were exactly the issues I faced when designing an interpreted language. I came to the conclusion that there was little point in creating one (except for interest's sake) because thousands had trod down that road before me making the same mistakes, and probably better designs in the end. In the end it is just a matter of syntactic preference. PHP is interesting because it has the syntax of javascript and the $variable syntax of perl/shell scripts. When you live inside quotes as often as you do in PHP the $variable style is often preferable and results in less typing. I had not considered a hybrid approach as you offered in your article: use the dollar variable prefix inside of quotes and drop the dollar variable prefix outside of quotes. Great idea.
One of the slides talked about migrating processes with threads and their plans to have distributed memory support in by summer 2003, but to my surprise there was no talk about migrating processes with open sockets (without dropping the connections of course). Is this a low priority for OpenMOSIX?
Re:The market frowns on Sun's 'monopoly potential'
on
Sun vs. OpenBSD?
·
· Score: 4, Informative
It exists only in a non-open form - via an NDA. This is why it can not be used by OpenBSD.
Re:The market frowns on Sun's 'monopoly potential'
on
Sun vs. OpenBSD?
·
· Score: 5, Insightful
Nice troll yourself. Where's the document in question describing the new SPARC memory protection feature that OpenBSD requires? It does not exist, hence the problem. Quoting some useless FAQ doesn't make it any more real or "open".
Yeah, it has to make you wonder - how would Sun be hurt financially by releasing Sparc software specifications? They own Sparc, afterall. You'd think it could only result in more hardware sales for them.
This is even more bizarre in light of Sun's recent open standards/Linux push. Sun does not appear to have a coherent strategy.
The only possible reason I can think of why Sun would not want OpenBSD to be easily ported to the newer Sparc chips is because OpenBSD could offer people an easy migration strategy away from Sparc to other less expensive platforms.
Slashdot Mirror
Sure you can decompile an optimized and symbol-stripped C++ program, but you'd never have it the original compact form of the source as you do with the Java class file decompilers due to the heavy use of inline functions and templates used in C++. A C program, sure, but decompiling C++ is not terribly useful.
First they discover that fish can feel pain - and now this! Damn science! What am I supposed to eat?
The Speedy Java VM Mantra
(aka "Tomorrow" Lyrics © Martin) Charnin
The sun'll come out
Tomorrow
Bet your bottom dollar
That tomorrow
There'll be sun!
Just thinkin' about
Tomorrow
Clears away the cobwebs,
And the sorrow
'Til there's none!
When I'm stuck with a day
That's gray,
And lonely,
I just stick out my chin
And Grin,
And Say,
Oh
The sun'll come out
Tomorrow
So ya gotta hang on
'til tomorrow
Come what may
Tomorrow!
Tomorrow!
I love ya
Tomorrow!
You're always
A day
A way!
I have a buddy who still uses an old WP Java beta and swears it runs wonderfully now that PCs are fast enough to run it properly.
Slashdot tip #53: When annoying 'facts' get in the way - invent a buddy!
Watch in awe as Java zealots mod up a baseless pro-java post based on second-hand hearsay!
Hearsay
Any evidence that is offered by a witness of which they do not have direct knowledge but, rather, their testimony is based on what others have said to them. For example, if Bob heard from Susan about an accident that Susan witnessed but that Bob had not, and Bob attempted to repeat Susan's story in court, it could be objected to as "hearsay." The basic rule, when testifying in court, is that you can only provide information of which you have direct knowledge. In other words, hearsay evidence is not allowed. Hearsay evidence is also referred to as "second-hand evidence" or as "rumor." You are able to tell a court what you heard, to repeat the rumor, and testify that, in fact, the story you heard was told to you, but under the hearsay rule, your testimony would not be evidence of the actual facts of the story but only that you heard those words spoken.
The article's author states:
For users accessing mail via IMAP or POP, network speed and congestion have a greater influence over performance than anything done on the client side; even for users with local mailboxes, I doubt that we're looking at a huge performance hit.
I beg to differ. I use email a lot - as do most people. I need it to be lightning quick in handling multi-megabyte local mailboxes. Basically, he could not have thought of a worse example of where performance supposedly does not matter since modern email repositories resemble databases these days. I am not willing to give up performance for perceived security in this area. Yes, that's right - performance and ease of use are every bit as important as security. Security for security's sake is simply not good enough. Users expect more - they expect both security and performance. You cannot give them less than what they already have. If the C or C++ code has a flaw - you fix it - it's that simple. OpenBSD has been doing this for years. Yes, it takes extra work - but the results are well worth it. Just don't give me this crap that my critical applications have to written in some interpreted or sandboxed computer language which takes up 4 times the memory and runs at less than half the speed all just for supposed security's sake. Show me this magical machine that can make all interpretted code run lighting fast and I will show you a machine that can run twice as many compiled applications over three times faster.
I was referring to the data stored within the STL vector or map being very space efficient. As for template code bloat - it's getting less so with modern C++ compilers. Furthermore, only the template functions actually used by the program are actually linked into the executable. Because STL does not use virtual functions programs using these templates can be highly optimized. Some compilers even share template methods between types if the type does not affect the generated code. However, I will concede that all this intense optimization does take a lot of compile time and memory. Some scarier template-heavy source files I've encountered using Boost have used 500 megs of RAM to compile under high optimization; but the final .o file size was very respectable.
Spirit has to be seen to be believed. Basically you contruct a parser which looks like normal extended Backus-Normal Form (EBNF) but the source you write is 100% C++ source code - not run through a preprocessor:
struct calculator : public grammar<calculator> {
template <typename ScannerT>
struct definition {
definition(calculator const& self) {
expression = term
>> *( ('+' >> term)[&do_add]
| ('-' >> term)[&do_subt]
);
term = factor
>> *( ('*' >> factor)[&do_mult]
| ('/' >> factor)[&do_div]
);
factor = lexeme_d[(+digit_p)[&do_int]]
| '(' >> expression >> ')'
| ('-' >> factor)[&do_neg]
| ('+' >> factor);
}
rule<ScannerT> expression, term, factor;
rule<ScannerT> const& start() const { return expression; }
};
};
This is truly a testimony to the power and expressiveness of C++ operator overloading and templates.
As an aside, Perl6 is slated to have lexer/yaccer rule syntax built into the language itself. It's really an exciting time for users of computer languages.
Templates only seem to be a necessary evil in OO languages that don't ultimately inherit all objects from one object.
This is a naive view that circa 1992 C++ collection class designers used to share. The OO-container strategy was proven to be slow and not type-safe. The designer of the C++ Standard Template Library (STL) Stepanov does not even believe in OO programming - he calls OO a hoax. I personally would not go that far, but I appreciate that OO and generics are completely independent concepts. Furthermore, an STL map or vector working on types directly is much more space efficient than any OO container-based approach because each object contained does not require OO overhead. Indeed, native types (ints, doubles, etc) in vectors can be nearly as efficiently stored and accessed under STL as would C style arrays. No need for awkward casting or unnecessary and slow boxing/unboxing. To sumamrize, C++ templates and the STL fit in perfectly with the C++'s "zero overhead" principle.
If CDs could not be perfectly copied then Intuit and other firms would not have to resort to this nonsense. They could just insist on using the program with the CD in the drive (like most other consumer software sold). But cheap CD copying - 50 cents or less - makes this scheme useless. I know this may not be politically correct in the Slashdot crowd, but how do you prevent software piracy without resorting to such draconian measures? Must you accept that for every copy of software sold that two will be pirated?
Or is this just a baseless rumour? I haven't found any concrete proof supporting this claim.
SCOX
Market Capitalization $25.0M
Shares Outstanding 11.4M
Float 3.70M
I see you're a proponent of efficient market theory where the market somehow "knows" the intrinsic value of goods. Well, the dot com bubble disproved that theory. Lawsuits are a complete crapshoot. No one is willing to place a big bet on one side or another until the judge has ruled. Anyway, the current market cap of SCOX is irrelevant compared to the billion dollars they are asking for in damages. Notice that insiders hold the majority of stock. They cannot be bought out without their approval. The insiders are probably holding out for $500 million. Remember - Caldera successfully got money from Microsoft over DR DOS. Anything is possible.
You've got to love these arm-chair economists. Who is this "we" the article talks about? We should do this, we should do that. These vague generalities may make for an interesting article, but they're not good for much else. When a company is losing money certain actions must be taken for the survival of the company. Costs must be cut. Do you borrow money and invest in research and development and continue losing money in a down market? Of course not. The company would go out of business in no time. American companies are not stupid. When times are bad you scale back and when times are good you expand. R&D still goes on throughout this entire process, albeit at a slower rate.
It's a shame that RMS fails to see the advantage of opening up GCC's data structures. Sure there would be some cheaters who'd use it for personal gain (writing proprietary front-ends for the GCC backend) - but there would be ten times as many people creating useful free languages and other free tools with it. It would also greatly aid in the learning of GCC itself (no simple task). It's a calculated risk, but in my opinion, one with more upside than downside potential. But who are we to say what RMS should do with his work? The FSF is the copyright holder, afterall.
must be dark in there
who the their right mind would not want to be part of a "do not call" registry? Lonely or insane people? People with too much money to burn? The government would save a lot of money creating a "please call" registry. That way the drug companies would know exactly who to target their anti-depressant drugs to.
NGPT 2.2.0 tops both Linuxthreads and NPTL
Keep in mind that NPTL paved the way for the kernel changes that NGPT also makes use of.
I'm sure that the NPTL team won't simply give up.
Anyway - it looks like Linux will finally have a good SMP threading library.
I stand corrected based on your clarification of platform support.
Is there a simple way to build a stripped down minimalistic Pike without modules/threads/shmem/java etc?
Also may I ask what compiler is this "rntcl"? (from "Windows_NT 4.0 x86 CC=rntcl)
I can't find anything about this compiler on Google except for Pike references.
Is "rntcl" a commercial compiler?
Thanks for the info. The Pike platform build success grid does not look very encouraging for platforms other than IA32 Linux. Too bad - Pike is an excellent language - much better and faster than any interpreted C-like language I have used. Pike also appears to be roughly 2 to 4 times faster than Perl 5.x and all free ECMAScript implementations. I'm a Pike convert. I'll hack on Pike under Cygwin disabling stuff until it works. I suspect that disabling native code generation might do the trick.
I can build and run Pike okay on Linux, but building on Cygwin complains about unresolved externals (shmget and other shm* functions). I then #undef'd the appropriate code in memory.c to disable shared memory support, and re-make. Pike.exe appears to link without errors or warnings but the final pike.exe is not functional. All pike scripts appear to run, but do nothing and print no error but the shell returns "10" when queried via echo "$?".
Any ideas?
Is Pike supported on Cygwin?
That's a great language features decision article you wrote. They were exactly the issues I faced when designing an interpreted language. I came to the conclusion that there was little point in creating one (except for interest's sake) because thousands had trod down that road before me making the same mistakes, and probably better designs in the end. In the end it is just a matter of syntactic preference.
PHP is interesting because it has the syntax of javascript and the $variable syntax of perl/shell scripts. When you live inside quotes as often as you do in PHP the $variable style is often preferable and results in less typing. I had not considered a hybrid approach as you offered in your article: use the dollar variable prefix inside of quotes and drop the dollar variable prefix outside of quotes. Great idea.
One of the slides talked about migrating processes with threads and their plans to have distributed memory support in by summer 2003, but to my surprise there was no talk about migrating processes with open sockets (without dropping the connections of course). Is this a low priority for OpenMOSIX?
GNUCash can import OFX/QFX files.
It exists only in a non-open form - via an NDA.
This is why it can not be used by OpenBSD.
Nice troll yourself. Where's the document in question describing the new SPARC memory protection feature that OpenBSD requires? It does not exist, hence the problem. Quoting some useless FAQ doesn't make it any more real or "open".
Yeah, it has to make you wonder - how would Sun be hurt financially by releasing Sparc software specifications? They own Sparc, afterall. You'd think it could only result in more hardware sales for them.
This is even more bizarre in light of Sun's recent open standards/Linux push.
Sun does not appear to have a coherent strategy.
The only possible reason I can think of why Sun would not want OpenBSD to be easily ported to the newer Sparc chips is because OpenBSD could offer people an easy migration strategy away from Sparc to other less expensive platforms.