One fundamental misunderstanding you seem to have is that O("something") is a function. It's not. It's a set of functions.
Therefore you cannot say stuff like O(n)=f(n). I know that this notation is sometimes used (inaccurately) in the litterature, but it should be f(n) \in O(n) where \in is the set membership symbol.
Firstly, he still used letters. That's a restriction.
Secondly, it would be quite easy (almost trivial, in fact) to write a programming language that could interpret any string of characters as a syntactically legal program. (IIRC Malbolge comes close). The fact that the program wouldn't make any sense semantically shouldn't matter, since the "random letters with weird shape" poem presumably doesn't make much sense either.
I thought the whole idea of including Andy Serkis in the live-action flashback scene to Smeagol vs. Deagol was to make him eligible for the Best Supporting Actor oscar
I think the idea of that shot might have been to, oh I don't know... give you a better feeling of how the ring corrupted Smeagol? I hardly think PJ was pandering to the Oscar voters when making LoTR. There have to be easier ways to get Oscars than making a trilogy of this magnitude.:)
I think you're misunderstanding something. The Free Software community is not some huge blob of people with one singular consciousness. It's just a bunch of very different people which all share one common trait; they give away their software (with some restrictions yes, but that's beside the point).
If you're one of those who pushes for schools to use your (or someone else's!) software, then yes, maybe it is your responsibility to make it better. But if someone takes something I give away and wants you to use it, then it's not my responsibility to make it any better.
Btw, good sig! Very trollish (and an actual quote as well).
copyright holder of that software said "take this, make as many copies as you want, and make derivitive works with this source code."
You must be smoking something really good, dude. The copyright holder said "take this,..., BUT ONLY IF YOU AGREE TO GIVE YOUR CHANGES AWAY TOO UNDER THE SAME LICENSE" (I am aware that the source/binary code actually has to be redestributed by an entity before this last bit is relevant). That is the spirit of the license and any competent judge will see that.
Maybe it has something to do with the way you point out those flaws...?
If you're a programmer working on something which scratches your itch, there a good chance that you already know how your own program works. Having someone come and say "Nonono, this interface is crap!" without actually providing suggestions for how to make it better is annoying at best.
Annoying as it may be, the "program your own version" may also be a valid argument from the programmer's perspective. If changing a UI is a lot of work, then the programmer may not actually have the time (or motivation; remember they've already scratched their own itch) to implement your set of changes. But you can still do it or get someone else to do it if you feel strongly enough about it. Remember, what you're getting is free (probably as in beer and freedom), so the programmer has no moral obligation to do anything for you.
But I've usually found that if you are polite and above all humble when you suggest fixes (be it UI fixes or regular bug fixes), then people will usually do it out of the goodness of their hearts. Btw, you might check this link:
Yeah, that's it! Let's get a huge organization which is utterly stifled by bureaucracy(*) to run the infrastructure of the Internet. That's the ticket!
Seriously, the UN is like the Borg, with one difference: They don't actually ever get anything done.
There is another reason. You can't reverse map one IP to several domains -- so no sending mail from multiple domains from one box. That's why using reverse lookups is a bad idea. Note that SPF (and similar schemes) does not have this problem because the authorization is in the actual domain you're (claiming to be) sending from, not the reverse domain.
Would knowing anything about their actual project, I'd wager that they're using something like NumPy for the actual calculations, and just using Python as "glue" between high-level operations.
No it isn't. Can't be bothered to find a link (Google can probably help), but since somewhere around 1.3 it has in fact become cheaper to let the JVM handle reuse of short-lived objects than it is to do it yourself.
Btw, in C this is actually a problem, because malloc() is (usually) extremely expensive for allocating lots of small objects.
And I was referring to if all MS software was vaporized.
Yeah, but that couldn't actually happen, could it? Kind of silly to base your whole argument on something which could actually never(*) happen, isn't it?
Governments have little place in how millions of consumers make their individual decisions in the market.
There are reasons for laws against various business practises when used by monopolies (which may not apply when the business in question is not a monopoly). I suggest you try reading up on it before spouting such nonsense.
(*) Well, barring some sort of Windows-deleting virus. But even that's kind of far fetched and would only influence actually installed copies. I'm sure there are quite a lot of CDROMs lying about which are pretty much impervious to malicious software.
Unfortunately, the GIMP people can't afford to fend off patent-related lawsuits.
Even if the GIMP people develop CMYK processes (and whatever that entails) completely independently of Adobe, Pantone, etc., but just happen to stumble on algorithms similar to any of the already patented methods, they could be dragged to court. Any you know what? Adobe, Pantone, etc. would win. That's because patents don't take into consideration whether or not you actually developed something from scratch. If the end result of your development (or "borrowing" ideas) is too similar to a patented algorithm or method, it's infringing.
Since almost anything related to CMYK is patented by these companies, it's just too dangerous to even try to develop some of this stuff... It's basically a minefield of patents.
I can see why someone might blame Adobe for not allowing their patented techniques to be used by OSS/Free software, but there is no point. Businesses exist for the purpose of making money, and you don't make money by giving away your R&D to your competitors (whether the competitors' products are Free or non-free is irrelevant). Businesses have no morals.
Instead of blaming Adobe, blame the patent system.
I don't think SMTP allows for a "reject" after getting to the DATA portion of the SMTP transaction. That prevents most (effective) spam filters from working at SMTP time. If it were possible, wouldn't everybody be doing this?
Hmm... maybe it's time to update SMTP to allow for this? (Sure, bandwidth is still being consumed, but at least legitimate senders would know that their message didn't get through because of "spamminess")
Umm... without giving further information, it's impossible to tell whether that code is safe or not. If we know that host->h_name is always limited to a '\0'-terminated string of at most 20 chars (including the terminating '\0'), then that code is perfectly safe. (I'm not saying that rewriting it to use strncpy is necessarily a bad idea, just pointing out that you left some information out).
This is simply not true. Both Unix and Windows operate on the assumption that a user completely trusts any program that he or she runs.
This is technically true, but it ignores that fact that it's much easier for a user to (unsafely) run anything they get in their mail. No UNIX mail client I have ever seen has allowed one to run attachments like Outlook does -- this seems to be because UNIX programmers actually realize that it's bad to trade a little convenience for security (esp. with the ever-increasing hostility of the Internet). I am aware that a warning dialog box is displayed when one tries to do this, but who reads those? Seriously. Any real user I've ever seen just immediately clicks "OK" on anything they are presented with without reading what it says.
But, as you say, that's an Outlook problem, not a Windows problem.
No. C++ is an abomination. Although it technically has all the features of other languages, its syntax (esp. templates) and semantics (esp. for anyone doing optimization) are just horrendous.
Note that templates != generics. Templates are more powerful than the generics in java. In fact C++ templates are Turing complete; I seem to remember someone even implementing the Towers of Hanoi in C++ templates (it would generate print statements which would print the correct sequence of moves. Truly evil stuff!).
Correctness checking the code generated by templates is impossble, but that's just because (in general) correctness checking programs in any Turing Complete language is. So correctness checking an arbitrary C program is also impossible. However, note that type checking C++ templates is very possible; my compiler does it all the time.
The type checking is much weaker thus introducing new potential holes for error to slip through.
No. Type checking is stronger because you can avoid type casts. (Note, I'm talking about generics in general, not the Java implementation which is slightly broken because of VM compatibility problems).
You must make some assumptions about the used classes however verifying the correctness of these assumptions in nearly impossible.
What the hell are you talking about? Be more specific.
The reusabilty "argument" is rubbish: that's what we have already OOP for. And when you now claim performance problems due to heavy stack/virtual methods use: that's an issue of the processor design not of the programming language. When you think that running serious software on system compatible to 30 year old rubbish is cool, then you must accept the performance of 30 year old waste in the same turn.
The lack of speed of virtual methods has NOTHING to do with processor technology. It is there because you MUST do a lookup at runtime (which there is absolutely no way to avoid). This will ALWAYS add overhead, regardless of processor technology. The only way to avoid this overhead while still having "reusability" is to have "compile-time virtual methods" (i.e. templates).
The above mentioned problems create new security holes. That's why the use of generics/templates in strictly forbidden in e.g. the banking sector.
Now you're talking pure nonsense. What security holes? Generics AVOID security holes because they avoid typecasts (invalid typecasts are one typical reason for security holes).
Due to turing completeness of most template/generics systems the compiler is slowed down to 30 percent performance. More evil is that templates push the grammars into the Chomsky-0 type making secure (=100%) correctness checking impossible.
Nonsense. Compilers are not slowed noticably down by generics in general. All functional programming languages support "generics" (type-variables is a more correct term), but the compiler for e.g. O'Caml is still as fast (or faster) than gcc is for C code. Compilers for C++ may be slower because of templates, but that's because the C++ templates are nothing more than macros with a little added type-checking (so the compilers usually have to compile lots and lots of extra code).
In old languages like Lisps the use of generics is usually strongly discouraged to users unless they are ultra-gurus due to the bad experiences. It's not clear why this should be different for Java or C++.
There is no such concept as "generics" in LISP -- since everything is dynamically typed generics are the default. If you're talking about macros, then some people may discourage them, but those people are idiots. Macros are the precise reason that the LISPs are so powerful.
Not really. It might also just mean that, in Canada, fewer (more responsible) people own more guns between them. It might also prove that proper screening is more prevalent in Canada. It could mean any number of things.
You're either lying or insane (or rather, any person who wants to use Linux in such a system is insane).
and having something that does the bare minimum--fast-- is optimal.
Linux does not do the bare minimum! It does FAR FAR more than a fly-by-wire system would ever need. So,you say, we just disable that when we do "make config". Ah, but what if there are interactions with code which you've just disabled? (It happens. It shouldn't but it does happen).
And don't give me any shit about Linux being tested by millions of people. Yes, it's tested by millions of people, but they are almost all testing different configurations, different code bases (think distribution patches here). Furthermore, Linux contains millions of lines of code. Don't tell me that millions of people testing millions of lines of code = no bugs. The fact is that there are still lots of bugs in Linux.
I would have thought a fly-by-wire system would REQUIRE a hard realtime OS -- we don't want an interrupt stalling (pardon the pun) processing while the system is taking corrective actions to compensate for weather conditions (winds, etc.), do we? Linux is NOT EVEN CLOSE to being hard real time. (Neither is RTLinux).
You mentioned somewhere that Linux is FREE as some great property of Linux. Yes, it's free. However, QNX (which would seem much more appropriate for the application) is a pittance compared to the cost of the hardware it's running on. A plane costs, what, millions of dollars? Who the hell cares if the OS costs $1,000 or even $10,000? It's nothing compared to the total cost of the plane.
Re:What do you mean 99% useless to others?
on
KDE 3.2.0 Released
·
· Score: 0
It's kind of hard to kiss your own ass if your head is between your knees. (Unless you're seriously deformed, that is).
(Oh, and the possessive pronoun is "its", not "it's".)
Not without potentially losing information. Convertion to/from null-terminated strings is lossy, because the original string may contain null characters in the middle of the string. I haven't checked, but they probably have a "copy-into-regular-array-of-chars-of-specified-siz e" function which is lossless.
Modern scripting languages such as Perl and Python -- and for that matter, the later Microsoft BASICs -- keep much more state information, almost performing a full compilation.
That's a bit of an overstatement, at least for Python (and probably Perl as well). Python is nowhere near to being compiled when the interpreter loads a Python program. It is simply parsed into its basic syntactical elements -- no compilation takes place. This is mainly because of Python's highly dynamic nature which actually makes it impossible to "compile" Python code into anything other than an executable containing a Python interpreter (which would have to be there anyway for the eval() function to work properly) and a copy of the program.
All of which can quite easily be faked by making select changes in the IP stack of the kernel you're running. (I seem to remember a story about this some time ago, but can't be bothered to look it up).
Slashdot Mirror
One fundamental misunderstanding you seem to have is that O("something") is a function. It's not. It's a set of functions.
Therefore you cannot say stuff like O(n)=f(n). I know that this notation is sometimes used (inaccurately) in the litterature, but it should be f(n) \in O(n) where \in is the set membership symbol.
Firstly, he still used letters. That's a restriction.
Secondly, it would be quite easy (almost trivial, in fact) to write a programming language that could interpret any string of characters as a syntactically legal program. (IIRC Malbolge comes close). The fact that the program wouldn't make any sense semantically shouldn't matter, since the "random letters with weird shape" poem presumably doesn't make much sense either.
I think that invalidates your conclusion.
I think the idea of that shot might have been to, oh I don't know... give you a better feeling of how the ring corrupted Smeagol? I hardly think PJ was pandering to the Oscar voters when making LoTR. There have to be easier ways to get Oscars than making a trilogy of this magnitude.
I think you're misunderstanding something. The Free Software community is not some huge blob of people with one singular consciousness. It's just a bunch of very different people which all share one common trait; they give away their software (with some restrictions yes, but that's beside the point).
If you're one of those who pushes for schools to use your (or someone else's!) software, then yes, maybe it is your responsibility to make it better. But if someone takes something I give away and wants you to use it, then it's not my responsibility to make it any better.
Btw, good sig! Very trollish (and an actual quote as well).
You must be smoking something really good, dude. The copyright holder said "take this,
That's a huge difference, and you know it!
Maybe it has something to do with the way you point out those flaws...?
If you're a programmer working on something which scratches your itch, there a good chance that you already know how your own program works. Having someone come and say "Nonono, this interface is crap!" without actually providing suggestions for how to make it better is annoying at best.
Annoying as it may be, the "program your own version" may also be a valid argument from the programmer's perspective. If changing a UI is a lot of work, then the programmer may not actually have the time (or motivation; remember they've already scratched their own itch) to implement your set of changes. But you can still do it or get someone else to do it if you feel strongly enough about it. Remember, what you're getting is free (probably as in beer and freedom), so the programmer has no moral obligation to do anything for you.
But I've usually found that if you are polite and above all humble when you suggest fixes (be it UI fixes or regular bug fixes), then people will usually do it out of the goodness of their hearts. Btw, you might check this link:
How To Report Bugs Effectively
Most of it also applies to UI bugs.
Yeah, that's it! Let's get a huge organization which is utterly stifled by bureaucracy(*) to run the infrastructure of the Internet. That's the ticket!
Seriously, the UN is like the Borg, with one difference: They don't actually ever get anything done.
There is another reason. You can't reverse map one IP to several domains -- so no sending mail from multiple domains from one box. That's why using reverse lookups is a bad idea. Note that SPF (and similar schemes) does not have this problem because the authorization is in the actual domain you're (claiming to be) sending from, not the reverse domain.
Would knowing anything about their actual project, I'd wager that they're using something like NumPy for the actual calculations, and just using Python as "glue" between high-level operations.
No it isn't. Can't be bothered to find a link (Google can probably help), but since somewhere around 1.3 it has in fact become cheaper to let the JVM handle reuse of short-lived objects than it is to do it yourself.
Btw, in C this is actually a problem, because malloc() is (usually) extremely expensive for allocating lots of small objects.
Yeah, but that couldn't actually happen, could it? Kind of silly to base your whole argument on something which could actually never(*) happen, isn't it?
There are reasons for laws against various business practises when used by monopolies (which may not apply when the business in question is not a monopoly). I suggest you try reading up on it before spouting such nonsense.
(*) Well, barring some sort of Windows-deleting virus. But even that's kind of far fetched and would only influence actually installed copies. I'm sure there are quite a lot of CDROMs lying about which are pretty much impervious to malicious software.
Unfortunately, the GIMP people can't afford to fend off patent-related lawsuits.
Even if the GIMP people develop CMYK processes (and whatever that entails) completely independently of Adobe, Pantone, etc., but just happen to stumble on algorithms similar to any of the already patented methods, they could be dragged to court. Any you know what? Adobe, Pantone, etc. would win. That's because patents don't take into consideration whether or not you actually developed something from scratch. If the end result of your development (or "borrowing" ideas) is too similar to a patented algorithm or method, it's infringing.
Since almost anything related to CMYK is patented by these companies, it's just too dangerous to even try to develop some of this stuff... It's basically a minefield of patents.
I can see why someone might blame Adobe for not allowing their patented techniques to be used by OSS/Free software, but there is no point. Businesses exist for the purpose of making money, and you don't make money by giving away your R&D to your competitors (whether the competitors' products are Free or non-free is irrelevant). Businesses have no morals.
Instead of blaming Adobe, blame the patent system.
I don't think SMTP allows for a "reject" after getting to the DATA portion of the SMTP transaction. That prevents most (effective) spam filters from working at SMTP time. If it were possible, wouldn't everybody be doing this?
Hmm... maybe it's time to update SMTP to allow for this? (Sure, bandwidth is still being consumed, but at least legitimate senders would know that their message didn't get through because of "spamminess")
What would you rather they called it? A minority hole?
Umm... without giving further information, it's impossible to tell whether that code is safe or not. If we know that host->h_name is always limited to a '\0'-terminated string of at most 20 chars (including the terminating '\0'), then that code is perfectly safe. (I'm not saying that rewriting it to use strncpy is necessarily a bad idea, just pointing out that you left some information out).
This is technically true, but it ignores that fact that it's much easier for a user to (unsafely) run anything they get in their mail. No UNIX mail client I have ever seen has allowed one to run attachments like Outlook does -- this seems to be because UNIX programmers actually realize that it's bad to trade a little convenience for security (esp. with the ever-increasing hostility of the Internet). I am aware that a warning dialog box is displayed when one tries to do this, but who reads those? Seriously. Any real user I've ever seen just immediately clicks "OK" on anything they are presented with without reading what it says.
But, as you say, that's an Outlook problem, not a Windows problem.
No. C++ is an abomination. Although it technically has all the features of other languages, its syntax (esp. templates) and semantics (esp. for anyone doing optimization) are just horrendous.
Note that templates != generics. Templates are more powerful than the generics in java. In fact C++ templates are Turing complete; I seem to remember someone even implementing the Towers of Hanoi in C++ templates (it would generate print statements which would print the correct sequence of moves. Truly evil stuff!).
Correctness checking the code generated by templates is impossble, but that's just because (in general) correctness checking programs in any Turing Complete language is. So correctness checking an arbitrary C program is also impossible. However, note that type checking C++ templates is very possible; my compiler does it all the time.
No. Type checking is stronger because you can avoid type casts. (Note, I'm talking about generics in general, not the Java implementation which is slightly broken because of VM compatibility problems).
What the hell are you talking about? Be more specific.
The lack of speed of virtual methods has NOTHING to do with processor technology. It is there because you MUST do a lookup at runtime (which there is absolutely no way to avoid). This will ALWAYS add overhead, regardless of processor technology. The only way to avoid this overhead while still having "reusability" is to have "compile-time virtual methods" (i.e. templates).
Now you're talking pure nonsense. What security holes? Generics AVOID security holes because they avoid typecasts (invalid typecasts are one typical reason for security holes).
Nonsense. Compilers are not slowed noticably down by generics in general. All functional programming languages support "generics" (type-variables is a more correct term), but the compiler for e.g. O'Caml is still as fast (or faster) than gcc is for C code. Compilers for C++ may be slower because of templates, but that's because the C++ templates are nothing more than macros with a little added type-checking (so the compilers usually have to compile lots and lots of extra code).
There is no such concept as "generics" in LISP -- since everything is dynamically typed generics are the default. If you're talking about macros, then some people may discourage them, but those people are idiots. Macros are the precise reason that the LISPs are so powerful.
Not really. It might also just mean that, in Canada, fewer (more responsible) people own more guns between them. It might also prove that proper screening is more prevalent in Canada. It could mean any number of things.
Linux does not do the bare minimum! It does FAR FAR more than a fly-by-wire system would ever need. So,you say, we just disable that when we do "make config". Ah, but what if there are interactions with code which you've just disabled? (It happens. It shouldn't but it does happen).
And don't give me any shit about Linux being tested by millions of people. Yes, it's tested by millions of people, but they are almost all testing different configurations, different code bases (think distribution patches here). Furthermore, Linux contains millions of lines of code. Don't tell me that millions of people testing millions of lines of code = no bugs. The fact is that there are still lots of bugs in Linux.
I would have thought a fly-by-wire system would REQUIRE a hard realtime OS -- we don't want an interrupt stalling (pardon the pun) processing while the system is taking corrective actions to compensate for weather conditions (winds, etc.), do we? Linux is NOT EVEN CLOSE to being hard real time. (Neither is RTLinux).
You mentioned somewhere that Linux is FREE as some great property of Linux. Yes, it's free. However, QNX (which would seem much more appropriate for the application) is a pittance compared to the cost of the hardware it's running on. A plane costs, what, millions of dollars? Who the hell cares if the OS costs $1,000 or even $10,000? It's nothing compared to the total cost of the plane.
It's kind of hard to kiss your own ass if your head is between your knees. (Unless you're seriously deformed, that is).
(Oh, and the possessive pronoun is "its", not "it's".)
Or maybe ask Terry Pratchett, seeing as Mr. Adams is (unfortunately) dead. Pratchett has the perfect name (can't remember the book): "Surprise".
Not without potentially losing information. Convertion to/from null-terminated strings is lossy, because the original string may contain null characters in the middle of the string. I haven't checked, but they probably have a "copy-into-regular-array-of-chars-of-specified-siz e" function which is lossless.
That's a bit of an overstatement, at least for Python (and probably Perl as well). Python is nowhere near to being compiled when the interpreter loads a Python program. It is simply parsed into its basic syntactical elements -- no compilation takes place. This is mainly because of Python's highly dynamic nature which actually makes it impossible to "compile" Python code into anything other than an executable containing a Python interpreter (which would have to be there anyway for the eval() function to work properly) and a copy of the program.
All of which can quite easily be faked by making select changes in the IP stack of the kernel you're running. (I seem to remember a story about this some time ago, but can't be bothered to look it up).