"SCO has learned that the ESA's Beagle mission resulted in unlawful dissemination of SCO UNIX code to our Martian competitors", McBride said in a press conference. "This morning we filed for a preliminary injunction to stop the ESA and NASA from distributing SCO code across the surface of Mars."
If granted, the motion would compel the ESA to recall the estimated 647,000 Beagle components distributed so far, or face stiff fines until the Martian distribution channel was brought into legal compliance.
Kylix didn't sell because...
on
Kylix in Limbo
·
· Score: 1
Client GUI development is increasingly web-centric, and in the web server-side arena Delphi can't compete with the best languages out there (Lisp, Ruby, Python, Perl, Java).
Plus, Kylix was expensive.
Finally, Borland is Microsoft's whore these days--for Borland, it's.NET all the way (Delphi 8 only produces code for the.NET virtual machine). The last thing Microsoft wants on Linux is an IDE that brings Visual Basic-like simplicity to thick client development.
There aren't any buffer overflows inherent in the c++ language, it's crappy programming that causes buffer overflows.
That's a cute sentiment, but the reality is that in a large project that takes months to complete, every programmer--no matter how prodigious his skills--will produce at least some crappy code. In a language that allows buffer overflows, some of this crappy code will cause buffer overflows.
So you're only correct in theory, not in practice.
If Mozilla had a clear advantage over IE, there would certainly be a jump as there was from IE to netscape in times gone by.
Very little "jump"ing happened. The real reason IE rose to dominance is that MS bundled it with Win98 and later, and consumers were too lazy or ignorant to investigate alternatives.
I personally think IE 4 and IE 5 were far better than Navigator 4, but superiority is not why IE surpassed Navigator's popularity. Consumers who don't even know how to organize their Start->Programs menus (I see this all the time) aren't capable of switching browsers.
There was another story about this same book on Slashdot a few weeks ago. I made a snide remark about the risk amplificiation inherent in writing "secure" code in C/C++ rather than a language that disallows illegal memory operations.
John Viega took me to task, wielding the old "you can write insecure code in any language" argument. That's true, but it's beside the point. C and C++ inherently increase the risk of security problems because they don't check buffer bounds, so the program ends up with all of the security problems that would've existed in a buffer-safe langauge, plus buffer overflow vulnerabilities. Viega was dismissive of this assertion.
I felt vindicated a couple of weeks later when Valve's Half-Life 2 source code was stolen by a cracker who initially penetrated their network via a buffer overflow.
The bottom line is that trying to write "secure" code in C/C++ is a bad idea. Eminent programmers with massive QA support try it, and fail almost routinely.
Even though you may indeed deserve far more than the $0 you've been paid so far, you can't expect this one company to foot the entire development bill.
Don't try to charge this single company full price for your work, or the use of your program is likely to become more expensive to this particular company than a competing (and probably more feature-complete) commercial package. If your software's good enough to have attracted hundreds of users and a corporate sponsor, it'll probably become good enough to attract even more sponsors.
What you don't want is for the one corporate sponsor you've attracted so far to come away feeling as though you're trying to saddle them with a development bill that should have been more broadly distributed.
In summary: you're on the right track, but have patience.
probably rushed out as fast as possible, I can't believe that Intel had plans for the EE all along given that there were 0 leaks
A lot of the reviewers' P4 EEs appeared to be labelled with a magic marker, so I think your suspicion is correct.
by the time the EE will actually be available to customers I'm sure the MP support will disappear
Yes. Otherwise, potential customers wouldn't buy any Xeon MPs. A 2.0 GHz Xeon MP with 512KB L2 cache and 3MB L3 cache (like the P4 EE) costs about $3,200.00. And that's at 2.0 GHz.
The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.
Seriously!
Re:Java is finished for most open source work
on
Java vs .NET
·
· Score: 1
Java... provides a nice, strongly typed, compiled, object oriented language (a niche none of those scripting languages fill) that's available almost anywhere...
Python is "nice", strongly typed, object oriented, and available on many platforms.
You're confusing "strong" typing with "static" typing.
Transaction? No. But a LOCK can be handy (if implemented correctly, of course) to do a query of data from a fixed point in time. Perhaps that's what the OP meant. I sincerely hope so.
Yes, a transaction. I suggest you read up on MVCC, which is supported by PostgreSQL, Firebird, and Oracle.
By forcing myself to deal with those consequences manually by doing my own locking and my own data-integrety management, I find that I can rely on my data far more than most people can, and the likelihood that one of my programs is going to "go bad" and rip out whole transactional units just because an non-essential field was initialized oddly is much, much lower.
And since your ad hoc locking and transaction management code never contains bugs (unlike the piddly implementation in the RDBMS that's only been tested by millions of users), everyone lives happily ever after.
Playing Quake for ten hours at a time with headphones that lacked a hardware volume control sure didn't improve my hearing;) This was on Windows 95, in the days before Alt-Tab functioned properly in most games. My hearing has never recovered.
Besides.... we all know (whether we'll admit or not) that even the most modest computers in use spend most of thier time simply waiting around for the user to make them do something.
I'm tired of hearing this. It's beside the point.
Firefighters spend "most of their time simply waiting around for a fire", but does that mean they don't need to extinguish it as quickly as possible when it does occur? No. Similarly, when a PC finally receives user input, it needs to complete the resulting action very, very quickly in order to ensure a responsive user experience. The fact that a desktop processor might spend 97% of its time twiddling its thumbs is irrelevant.
And when it comes to servers, the situation is entirely different because they're often serving hundreds of users simultaneously.
What an utter load of manure. Jumbo cluebat for you. C/C++ is used for application development by both commercial and non-commercial software. It has for decades.
No shit. Did you notice that:
the article explicitly stated that the GNUCash project can't attract developers because of the "high barrier to entry"?
there are no compelling reasons to write a program like this in a language that tends to scare away potential contributors, and waste the time of those who're already involved with memory handling bugs.
computers are a lot faster now than they were "decades ago"?
most open source projects (obviously including this one) can't afford the same pre-release QA rigor that commercial ones can?
Don't let your inadequateces in dealing with C/C++ make you think others are having as rough a time.
Nice troll, but I write C on a regular basis, and love it. It's a very nice high-level assembler that will undoubtedly survive for many decades to come--and rightly so. But I use it only where it's warranted, because I value my time (this response to a troll notwithstanding).
Furthermore, it was the article's explicit statement that made me "think others are having... [a] rough a time" dealing with C; my own "fear" of C/C++ is immaterial because it's non-existent.
Seriously the "Everyone else isn't programming in the language I want them to, therefore they're wrong" attitude needs to die, NOW!
We're having this discussion because the GNUCash project is dying, in no small part because of its language choice. So I happen to think that discussions of language choice are highly germane.
Slashdot Mirror
"SCO has learned that the ESA's Beagle mission resulted in unlawful dissemination of SCO UNIX code to our Martian competitors", McBride said in a press conference. "This morning we filed for a preliminary injunction to stop the ESA and NASA from distributing SCO code across the surface of Mars."
If granted, the motion would compel the ESA to recall the estimated 647,000 Beagle components distributed so far, or face stiff fines until the Martian distribution channel was brought into legal compliance.
Client GUI development is increasingly web-centric, and in the web server-side arena Delphi can't compete with the best languages out there (Lisp, Ruby, Python, Perl, Java).
Plus, Kylix was expensive.
Finally, Borland is Microsoft's whore these days--for Borland, it's .NET all the way (Delphi 8 only produces code for the .NET virtual machine). The last thing Microsoft wants on Linux is an IDE that brings Visual Basic-like simplicity to thick client development.
Isn't it among the most innovative open source applications of recent times?
MS sees God as competition.
Nah, they don't reaaally. They just said that during the antitrust trial to minimize public perception of the true extent of their monopoly.
Why not simply name a product for what it is instead of spending all those dollars to come up with lame names?
Because somehow I don't think "Shitteon" or "Also-ron" would move many chips.
There aren't any buffer overflows inherent in the c++ language, it's crappy programming that causes buffer overflows.
That's a cute sentiment, but the reality is that in a large project that takes months to complete, every programmer--no matter how prodigious his skills--will produce at least some crappy code. In a language that allows buffer overflows, some of this crappy code will cause buffer overflows.
So you're only correct in theory, not in practice.
Very little "jump"ing happened. The real reason IE rose to dominance is that MS bundled it with Win98 and later, and consumers were too lazy or ignorant to investigate alternatives.
I personally think IE 4 and IE 5 were far better than Navigator 4, but superiority is not why IE surpassed Navigator's popularity. Consumers who don't even know how to organize their Start->Programs menus (I see this all the time) aren't capable of switching browsers.
There was another story about this same book on Slashdot a few weeks ago. I made a snide remark about the risk amplificiation inherent in writing "secure" code in C/C++ rather than a language that disallows illegal memory operations.
John Viega took me to task, wielding the old "you can write insecure code in any language" argument. That's true, but it's beside the point. C and C++ inherently increase the risk of security problems because they don't check buffer bounds, so the program ends up with all of the security problems that would've existed in a buffer-safe langauge, plus buffer overflow vulnerabilities. Viega was dismissive of this assertion.
I felt vindicated a couple of weeks later when Valve's Half-Life 2 source code was stolen by a cracker who initially penetrated their network via a buffer overflow.
The bottom line is that trying to write "secure" code in C/C++ is a bad idea. Eminent programmers with massive QA support try it, and fail almost routinely.
Even though you may indeed deserve far more than the $0 you've been paid so far, you can't expect this one company to foot the entire development bill.
Don't try to charge this single company full price for your work, or the use of your program is likely to become more expensive to this particular company than a competing (and probably more feature-complete) commercial package. If your software's good enough to have attracted hundreds of users and a corporate sponsor, it'll probably become good enough to attract even more sponsors.
What you don't want is for the one corporate sponsor you've attracted so far to come away feeling as though you're trying to saddle them with a development bill that should have been more broadly distributed.
In summary: you're on the right track, but have patience.
Hell, Microsoft is even kind enough to send the "Latest Internet Patch" right to my inbox. Sometimes 36 times a day, when necessary!!
Now that's what I call service!
probably rushed out as fast as possible, I can't believe that Intel had plans for the EE all along given that there were 0 leaks
A lot of the reviewers' P4 EEs appeared to be labelled with a magic marker, so I think your suspicion is correct.
by the time the EE will actually be available to customers I'm sure the MP support will disappear
Yes. Otherwise, potential customers wouldn't buy any Xeon MPs. A 2.0 GHz Xeon MP with 512KB L2 cache and 3MB L3 cache (like the P4 EE) costs about $3,200.00. And that's at 2.0 GHz.
You'd be surprised how much hardware is supported by BeOS, Athlon XP CPUS, P4s, ...
Wow! An x86-oriented operating system supports x86-compatible CPUs? This is revolutionary!
Well, the guy indeed was a founder of a (profitable) enterprise. Please adjust your buzzwords.
Not a profitable enterprise, but a well capitalized enterprise (during the bubble). Now it's bankrupt.
The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.
Seriously!
Java... provides a nice, strongly typed, compiled, object oriented language (a niche none of those scripting languages fill) that's available almost anywhere...
Python is "nice", strongly typed, object oriented, and available on many platforms.
You're confusing "strong" typing with "static" typing.
Transaction? No. But a LOCK can be handy (if implemented correctly, of course) to do a query of data from a fixed point in time. Perhaps that's what the OP meant. I sincerely hope so.
Yes, a transaction. I suggest you read up on MVCC, which is supported by PostgreSQL, Firebird, and Oracle.
By forcing myself to deal with those consequences manually by doing my own locking and my own data-integrety management, I find that I can rely on my data far more than most people can, and the likelihood that one of my programs is going to "go bad" and rip out whole transactional units just because an non-essential field was initialized oddly is much, much lower.
And since your ad hoc locking and transaction management code never contains bugs (unlike the piddly implementation in the RDBMS that's only been tested by millions of users), everyone lives happily ever after.
Playing Quake for ten hours at a time with headphones that lacked a hardware volume control sure didn't improve my hearing ;) This was on Windows 95, in the days before Alt-Tab functioned properly in most games. My hearing has never recovered.
I guess you didn't hear about the Apple PowerMac G5 when it was announced months ago and began shipping last week
You mean the G5 that can't even outperform a two-year-old Athlon XP 2000+? That G5?
Besides.... we all know (whether we'll admit or not) that even the most modest computers in use spend most of thier time simply waiting around for the user to make them do something.
I'm tired of hearing this. It's beside the point.
Firefighters spend "most of their time simply waiting around for a fire", but does that mean they don't need to extinguish it as quickly as possible when it does occur? No. Similarly, when a PC finally receives user input, it needs to complete the resulting action very, very quickly in order to ensure a responsive user experience. The fact that a desktop processor might spend 97% of its time twiddling its thumbs is irrelevant.
And when it comes to servers, the situation is entirely different because they're often serving hundreds of users simultaneously.
When will we see a government -- a people -- that will stand up to large corporate interests...
We won't, because modern governments are, in essence, large corporations.
Who said anything about C#? What about Java, Python, Perl, or Ruby?
What an utter load of manure. Jumbo cluebat for you. C/C++ is used for application development by both commercial and non-commercial software. It has for decades.
No shit. Did you notice that:
Don't let your inadequateces in dealing with C/C++ make you think others are having as rough a time.
Nice troll, but I write C on a regular basis, and love it. It's a very nice high-level assembler that will undoubtedly survive for many decades to come--and rightly so. But I use it only where it's warranted, because I value my time (this response to a troll notwithstanding).
Furthermore, it was the article's explicit statement that made me "think others are having... [a] rough a time" dealing with C; my own "fear" of C/C++ is immaterial because it's non-existent.
Seriously the "Everyone else isn't programming in the language I want them to, therefore they're wrong" attitude needs to die, NOW!
We're having this discussion because the GNUCash project is dying, in no small part because of its language choice. So I happen to think that discussions of language choice are highly germane.
But come on, whitespace? Are you serious? ;-)
Yes.
If you don't indent your code, you're a fucking idiot. If you already do, you'll barely notice Python's use of whitespace to denote block structure.
Analysis brought to you by the eminently unbiased Eben Moglen.