I'd say relying on a particular endianness is a bug even if you only run the program on one platform. Likewise assuming that an int and a pointer are the same size is always a bug. In both cases you are relying on something that's undocumented.
I guess this illustrates the difference between a bug and a defect. Assuming sizeof(int) == sizeof(void *) is a bug in code, but it may not be a defect in the final executable if you compile for a platform where they do happen to be the same size.
Yes, but if you fix a crash-causing bug (such as a buffer overrun) on one architecture, it's likely that the same bug was present on others. Or rather, would also cause a crash on other platforms - since a bug is a property of the source code, the meaning of the program, and the fact that a program happens to work on Tuesday doesn't mean the bug is not there.
Consider: projects such as openssh and Apache do not issue separate vulnerability warnings for different platforms. If a memory-corruption bug exists, it is probably exploitable on most platforms given the right conditions.
Still, it's very likely that some particular bug cause crashes often on PPC, but is less likely to be tickled on x86. Then it might not get fixed, because it's less likely to be reported. But if a PPC user does report it, the x86 users benefit from the fix too, even if for them it was a fairly obscure and not-often-noticed bug.
I don't see why programmers should be bad at user interface design. The most important rules of UI design are the same as those for programming:
- Keep it simple.
- Don't reinvent the wheel; reuse what has already been done (eg standard dialogue boxes and conventions).
- Don't create many slightly-different ways to accomplish the same thing; provide a few simple and obvious primitives that are easy to use together.
Where this may fall down is in not understanding how users think, although many programmers have some idea of how another programmer will think and can take that into account when writing code.
Er - exception handling is the number one reason why C++ libraries are not binary compatible with other libraries. Exceptions are in fact the only C++ feature that requires a change to the ABI compared to C. Adding exception handling to C would require a similar change.
So the best you can hope for is to use C++ (hey - you can just use the C89 subset plus exceptions, if you wish) and avoid exceptions for externally visible functions in a library. Of course C++ code can call C libraries without problems.
My mouse has only two buttons, so middle-clicking is awkward. And it broke almost completely when I upgraded my box to Linux 2.6.0-test4 (no idea why the kernel should break XFree86's emulate3buttons option, but it did).
Plus I still can't quite grok the idea of having two different clipboards (SELECTION and CLIPBOARD, or whatever they're called) and how they interact. And if you select text to copy it into the selection, what does it mean to have some text selected in two different windows?
I don't see why a spammer, even a big one, should make an effort to take out anti-spam sites. Spammers, so common opinion holds, are just there to make money - not to engage in any sort of crusade against anti-UCE groups. So what does one individual spammer have to gain? If, after a great deal of effort, a spam blacklist is taken down, all spammers share in the benefits. It doesn't seem that one individual would make enough extra profit - possible profit at some time in the future - to justify getting into such games now.
More likely that crackers want to target Spamhaus and the like because it's a big target, just as Slashdot attracts trolls.
What is the motivation for one individual spammer to start launching attacks? Or is there some spammers' guild where they band together?
One of the principles behind OpenBSD (and therefore OpenSSH) is full disclosure of security vulnerability. They don't want to lie about how secure the software is or try to conceal things from you. Therefore the vulnerability reports (and fixes) are published as soon as possible. In practice, I think they do wait to have a patched version before announcing the bug.
I was thinking of a PC which had Oracle installed with Oracle Forms and had at least three java.exe in the Oracle installation alone. I know because we did 'dir/s java.exe' to track down a problem where one of those executables was doing a kind of fork-bomb at startup. The PC has since been reinstalled so I can't give the dir/s output now.
As for why they distribute different ones: who knows. Perhaps it is Oracle that has the problem, not Java, and it would all work fine if they just shipped.class files. But you have to wonder.
Oracle ships three JVMs on the *same platform*. As in, Oracle on Windows includes three different ones and they are all installed in different places. If Java were portable, you'd expect that one JVM would suffice. To the other poster who asked for hard facts: I'll have a look at the files installed when I go to work tomorrow.
The management of the company, both before and after philg got booted out, had a lot of faults. But it's not in doubt that from a technical point of view the switch to Java was a mistake.
A user can see the SQL structure anyway by looking at the database and by logging what queries are executed. If you're paranoid about that you can use sqlite.
I think we gave different interpretations to 'hardcoding SQL statements'. I don't have any objection to keeping the SQL separated out and making it easy to switch from one dialect to another - although usually it is better just to code to the ANSI SQL standard, with some allowance for common deviations like Oracle's ''-as-null. What I have a problem with is deciding that any form of SQL is evil, and treating the database like a glorified (and rather slow) one-row-at-a-time object store, in order to avoid 'hardcoding' such heinously non-portable constructs as 'select name where age > 50'. And yes, this is based on experience.
One point - the 'nonportable SQL verbs' you mention can in some cases be the only way to tweak the best performance out of an RDBMS. Using a nonstandard extension to SQL is not a decision to be taken lightly, but it's good to at least have the option.
It might be helpful (for those who don't know) to learn a bit about the ArsDigita experience with Java. aD was philg's old company and developed a toolkit (the ACS) based on Tcl and Oracle. The software was a bit kludgy in many ways but had the advantage of being fairly scalable and written close to the database, so you could tune the queries and generally figure out what was going on. The lack of typechecking in Tcl didn't matter too much because SQL queries and stored procedure calls are checked at compilation - and besides, if you keep the edit-test cycle down to under a second you can quickly find bugs.
The rewrite of the system in Java, based on using database abstractions and (would you believe) HTML abstractions was a complete crock and ended up being not only slower than the Tcl/SQL version, but less maintainable and much more buggy. I think they got something out of it in the end, after dropping 90% of the extra complexity and object-oriented-itis, but there's no way Java plus an object-relational mapping layer was the right implementation language.
OpenACS and Java makes a similar argument to philg's, but more coherently and less trollishly. I agree with his essential points however. And what he writes is based on experience, both with managing a web development company and with teaching students.
What the OpenACS project do to separate out SQL is to have separate code and query files. This keeps the code tidy, lets you have separate queries for Postgres and Oracle if that should prove necessary, and lets a database programmer go and optimize the queries while an application programmer rewrites the code, without them stepping on each others' footsteps. OpenACS, BTW, is the descendent of the ACS toolkit developed by Philip Greenspun's company ArsDigita.
Pray tell what is the problem with hardcoded SQL statements? Why are they any worse than hardcoded C statements or hardcoded Java statements or hardcoded shell scripts?
SQL is a much higher-level language than C or Java or even Perl. This is why people who talk about 'database abstraction' are usually missing the point. SQL is an abstraction, and a much more expressive one than some object-based mapping full of get_x() and set_x(). But unlike many high-level languages, the extra abstraction of SQL gives you _better_ performance by letting the database optimize your queries for you.
Portability? Oracle ships with three different JVMs because they are all incompatible with each other. That's all you need to know about Java portability.
Hmm, but wouldn't it be better to have the delete operator do something? I know you don't _need_ it to do anything, because the garbage collector will eventually free the memory, but performance might be better if you can insert explicit 'delete' at certain places in your program where you know that an object is no longer referenced. operator delete() would inform the GC that the memory had been freed manually.
Re:Linux should work on it, actually....
on
New Treo Reviewed
·
· Score: 1
The CPU is supported (few aren't) but it's more a question of having drivers for the display, stylus, networking and so on.
Slashdot Mirror
I'd say relying on a particular endianness is a bug even if you only run the program on one platform. Likewise assuming that an int and a pointer are the same size is always a bug. In both cases you are relying on something that's undocumented.
I guess this illustrates the difference between a bug and a defect. Assuming sizeof(int) == sizeof(void *) is a bug in code, but it may not be a defect in the final executable if you compile for a platform where they do happen to be the same size.
Yes, but if you fix a crash-causing bug (such as a buffer overrun) on one architecture, it's likely that the same bug was present on others. Or rather, would also cause a crash on other platforms - since a bug is a property of the source code, the meaning of the program, and the fact that a program happens to work on Tuesday doesn't mean the bug is not there.
Consider: projects such as openssh and Apache do not issue separate vulnerability warnings for different platforms. If a memory-corruption bug exists, it is probably exploitable on most platforms given the right conditions.
Still, it's very likely that some particular bug cause crashes often on PPC, but is less likely to be tickled on x86. Then it might not get fixed, because it's less likely to be reported. But if a PPC user does report it, the x86 users benefit from the fix too, even if for them it was a fairly obscure and not-often-noticed bug.
I predict a return of the Office Assistant... but in a new version with 30% more 'attitude'.
Hey kids, always reboot. TO THE EXTREME!
I don't see why programmers should be bad at user interface design. The most important rules of UI design are the same as those for programming:
- Keep it simple.
- Don't reinvent the wheel; reuse what has already been done (eg standard dialogue boxes and conventions).
- Don't create many slightly-different ways to accomplish the same thing; provide a few simple and obvious primitives that are easy to use together.
Where this may fall down is in not understanding how users think, although many programmers have some idea of how another programmer will think and can take that into account when writing code.
Er - exception handling is the number one reason why C++ libraries are not binary compatible with other libraries. Exceptions are in fact the only C++ feature that requires a change to the ABI compared to C. Adding exception handling to C would require a similar change.
So the best you can hope for is to use C++ (hey - you can just use the C89 subset plus exceptions, if you wish) and avoid exceptions for externally visible functions in a library. Of course C++ code can call C libraries without problems.
My mouse has only two buttons, so middle-clicking is awkward. And it broke almost completely when I upgraded my box to Linux 2.6.0-test4 (no idea why the kernel should break XFree86's emulate3buttons option, but it did).
Plus I still can't quite grok the idea of having two different clipboards (SELECTION and CLIPBOARD, or whatever they're called) and how they interact. And if you select text to copy it into the selection, what does it mean to have some text selected in two different windows?
Unfortunately, the name Y Window System has already been taken by the Hungry Programmers. Still, Z is probably free :-P.
I don't see why a spammer, even a big one, should make an effort to take out anti-spam sites. Spammers, so common opinion holds, are just there to make money - not to engage in any sort of crusade against anti-UCE groups. So what does one individual spammer have to gain? If, after a great deal of effort, a spam blacklist is taken down, all spammers share in the benefits. It doesn't seem that one individual would make enough extra profit - possible profit at some time in the future - to justify getting into such games now.
More likely that crackers want to target Spamhaus and the like because it's a big target, just as Slashdot attracts trolls.
What is the motivation for one individual spammer to start launching attacks? Or is there some spammers' guild where they band together?
Reading that article I can't help but be reminded of Victor Lewis-Smith's Gay Daleks.
One of the principles behind OpenBSD (and therefore OpenSSH) is full disclosure of security vulnerability. They don't want to lie about how secure the software is or try to conceal things from you. Therefore the vulnerability reports (and fixes) are published as soon as possible. In practice, I think they do wait to have a patched version before announcing the bug.
I was thinking of a PC which had Oracle installed with Oracle Forms and had at least three java.exe in the Oracle installation alone. I know because we did 'dir /s java.exe' to track down a problem where one of those executables was doing a kind of fork-bomb at startup. The PC has since been reinstalled so I can't give the dir /s output now.
.class files. But you have to wonder.
As for why they distribute different ones: who knows. Perhaps it is Oracle that has the problem, not Java, and it would all work fine if they just shipped
I for one welcome our new immortal mouse overlords!
Oracle ships three JVMs on the *same platform*. As in, Oracle on Windows includes three different ones and they are all installed in different places. If Java were portable, you'd expect that one JVM would suffice. To the other poster who asked for hard facts: I'll have a look at the files installed when I go to work tomorrow.
The management of the company, both before and after philg got booted out, had a lot of faults. But it's not in doubt that from a technical point of view the switch to Java was a mistake.
A user can see the SQL structure anyway by looking at the database and by logging what queries are executed. If you're paranoid about that you can use sqlite.
I think we gave different interpretations to 'hardcoding SQL statements'. I don't have any objection to keeping the SQL separated out and making it easy to switch from one dialect to another - although usually it is better just to code to the ANSI SQL standard, with some allowance for common deviations like Oracle's ''-as-null. What I have a problem with is deciding that any form of SQL is evil, and treating the database like a glorified (and rather slow) one-row-at-a-time object store, in order to avoid 'hardcoding' such heinously non-portable constructs as 'select name where age > 50'. And yes, this is based on experience.
One point - the 'nonportable SQL verbs' you mention can in some cases be the only way to tweak the best performance out of an RDBMS. Using a nonstandard extension to SQL is not a decision to be taken lightly, but it's good to at least have the option.
It might be helpful (for those who don't know) to learn a bit about the ArsDigita experience with Java. aD was philg's old company and developed a toolkit (the ACS) based on Tcl and Oracle. The software was a bit kludgy in many ways but had the advantage of being fairly scalable and written close to the database, so you could tune the queries and generally figure out what was going on. The lack of typechecking in Tcl didn't matter too much because SQL queries and stored procedure calls are checked at compilation - and besides, if you keep the edit-test cycle down to under a second you can quickly find bugs.
The rewrite of the system in Java, based on using database abstractions and (would you believe) HTML abstractions was a complete crock and ended up being not only slower than the Tcl/SQL version, but less maintainable and much more buggy. I think they got something out of it in the end, after dropping 90% of the extra complexity and object-oriented-itis, but there's no way Java plus an object-relational mapping layer was the right implementation language.
OpenACS and Java makes a similar argument to philg's, but more coherently and less trollishly. I agree with his essential points however. And what he writes is based on experience, both with managing a web development company and with teaching students.
What the OpenACS project do to separate out SQL is to have separate code and query files. This keeps the code tidy, lets you have separate queries for Postgres and Oracle if that should prove necessary, and lets a database programmer go and optimize the queries while an application programmer rewrites the code, without them stepping on each others' footsteps. OpenACS, BTW, is the descendent of the ACS toolkit developed by Philip Greenspun's company ArsDigita.
Pray tell what is the problem with hardcoded SQL statements? Why are they any worse than hardcoded C statements or hardcoded Java statements or hardcoded shell scripts?
SQL is a much higher-level language than C or Java or even Perl. This is why people who talk about 'database abstraction' are usually missing the point. SQL is an abstraction, and a much more expressive one than some object-based mapping full of get_x() and set_x(). But unlike many high-level languages, the extra abstraction of SQL gives you _better_ performance by letting the database optimize your queries for you.
Portability? Oracle ships with three different JVMs because they are all incompatible with each other. That's all you need to know about Java portability.
What's the 'copyright problem' you refer to with LOC? From the sound of things it couldn't be any worse than Dewey.
Hmm, but wouldn't it be better to have the delete operator do something? I know you don't _need_ it to do anything, because the garbage collector will eventually free the memory, but performance might be better if you can insert explicit 'delete' at certain places in your program where you know that an object is no longer referenced. operator delete() would inform the GC that the memory had been freed manually.
The CPU is supported (few aren't) but it's more a question of having drivers for the display, stylus, networking and so on.
Does it run Linux?
Pretty soon people will be modding their computers to _remove_ all the silly lights and windows.