If it used IRC, which channel would it go to and how would it know which messages were code? Surely a particular IRC channel or particular IRC server can be taken down just like a web page. And who is going to put the code there in the first place?
Freenet makes more sense perhaps, provided that most Freenet users will be too lazy to reconfigure their software to stop distributing copies of the worm's code. (Perhaps the Freenet software deliberately lacks any option to be selective about what resources are forwarded to others - anyone knowledgeable about this stuff care to explain?)
It would have been smarter for the worm to verify a signature on the code it downloads (a la Xbox) so it couldn't be disabled in this way. Trusting a particular Geocities URL is just silly.
Yes I think I was thinking of the 'quack' debacle, you know more about it than I do. Still it is _possible_ that some video card could do lower-quality rendering (perhaps due to a bug) in a particular benchmark and so get an unfairly high score.
Hmm, I thought that checking the rendering was very difficult because graphics cards (at least the consumer ones) always do have some latitude, they are never pixel perfect. You could render the scene in software and then do a pixel-by-pixel comparison I imagine, but I'd worry that things like textures would be consistenly 1.5 pixels out or something, and so you'd get a very big pixel-value diff for a similar image.
So - given two images, one rendered in hardware and one (presumably pixel-perfect and correct) rendered in software, what is the quantitative measure for finding how different they are?
It's like the main argument for developing lossless compression algorithms rather than lossy ones: you have an objective basis on which to compare them, rather than worrying about which changes in the data are allowed.
Yes, the output is correct for that particular scene and camera angle, and the answer in this case is to benchmark many different camera angles (they'd be unlikely to hardcode clipping for every one) and preferably many different scenes.
I don't see why voting has to involve a slip of paper. Why not have a line of buckets, one for each candidate, and you drop a small token into one of the buckets (or more than one, depending on your electoral system). To preserve confidentiality there would need to be a slot through which you drop the token, to stop you reaching in and removing some or looking to see who's had the most votes so far. Then counting votes is just weighing the buckets (and checking for invalid tokens).
What I meant to say was, nobody would test based *only* on taking the square root of seven.
You make a good point about the difficulty of checking that the scene was rendered correctly. The graphics card could 'optimize' the benchmark by showing a blank screen, and the software would not be any the wiser. However, if the drawing requests the benchmark sends to the graphics card are wide-ranging, the card could not give any special treatment to the benchmark (whether accidentally or deliberately).
Secondly, even with a benchmark that draws a single scene or fixed animation there is no way to test the picture quality produced. It has happened in the past that video cards downgraded Quake 3 quality to do better in benchmarks. Of course the benchmark program did not notice.
There are two different issues here: firstly, how to make sure that the benchmark gives a varied range of tasks and not a fixed sequence that can be special-case optimized; and secondly, how to check that the rendered image for a given set of commands is 'correct'. You can deal with the two separately, at least for video cards.
(BTW, can you suggest a benchmark and a validation suite for floating-point performance? I tried running 'paranoia' on my Linux/i386 box but it found lots of errors.)
Why is it that people are assessing the performance of cards based on running the same narrow set of benchmarks each time? Of _course_ if you do that then performance optimization will be narrowly focused towards those benchmarks. Not just on the level of blatant cheating (recording a particular hardcoded text string or clipping plane) but more subtle things like only optimizing one particular code path because that's the only one the benchmark exercises.
More importantly why is any benchmark rendering the exact same scene each time? Nobody would test an FPU based on how many times per second it could take the square root of seven. You need to generate thousands, millions of different scenes and render them all. Optionally, the benchmark could generate the scenes at random, saving the random seed so the results are reproducible and results can be compared.
I wonder, with the increase in CPU speeds since 2.9x was current, whether a $500 machine now can compile faster or slower than a $500 machine a few years back.
Of course it would be still nice for gcc not to get slower, or maybe even to get faster:-(.
Most often called Santa Cruz, Calderuman was one of the first of the UNIX vendors to arrive in Intel-earth, after the arrival of the System V. He was said to be the eldest of the order. For a dozen years, and maybe more, he journeyed in the barren East, and was little heard of at Berkeley.
It was at about this time that Calderuman began to study the Rings of Power, their history and the means of their making.
In year 31 of the Epoch, he was given the keys of OpenLinux, and took up his abode there. He continued his researches into Ring-Zero-lore, and the making of device drivers, and was accustomed to watch the stars from the pinnacle of the Tower. When the Council debated the Rings of Power, Calderuman claimed that his researches showed that the One Ring had been lost forever. It was later shown that he did not believe this, however, and was searching for it himself, having secretly rebelled against the Council.
He built an army of Lawyers and Orcs of his own within the ring of Isengard to challenge both the Wise and the forces of Mondred. In May of the 24th year, when he was ready to reveal himself, Calderuman set a trap for Gandalf, luring him to Orthanc. When Gandalf came, Calderuman revealed that he had made a Ring of his own, and that he intended to gain control of Linux , or at least prevent Gandalf from using it freely himself.
To be continued...
(Plagiarized of course - Google to find the source.)
Re:SCO has Dirty Hands. Will not be able to collec
on
SCO To Show Copied Code
·
· Score: 2, Informative
LZH (Lempel-Ziv-Huffman; find repeated strings in a sliding window and then use Huffman coding on the resulting backreferences and raw characters) is freely implementable in all countries - it was developed for pkzip-2.0, and later adopted for gzip. You're thinking of LZW (Lempel-Ziv-Welch). Although the US patent on that will expire in a couple of years IIRC.
In the past, when a kernel has not compiled with a new gcc version it has been more often a bug in the kernel than one with gcc. The same goes for most apps. Looking at the list archives, the main problem seems to be with __inline__ which was a gcc extension to start with, so the problem is presumably that the meaning of that keyword has been deliverately changed.
Yes, if it can be determined at compile time that the return of Month fits into the range Months, then no run-time check is necessary.
I've hacked up an equivalent in about 30 lines of C++, it lets you declare variables as
bounded_int<5, 10> i; bounded_int<6, 7> j;
Then 'i = j;' will compile happily, since the range of j is within the range of i. And of course another bounded_int<5, 10> could be assigned to i. However, if you want to assign the other way round, you have to use an explicit cast:
j = range_cast<6, 7>(i);
and this will throw an exception at run time if the value is outside the allowed range.
However, my prototype code is still ugly, in particular I haven't worked out a clean way to say:
bounded_int<5, 10> i = 7;
which ought to compile without complaints because 7 can be statically determined to be within the limits. There are other rough edges such as having to pass the new range explicitly to range_cast, you can't just say 'j = range_cast(i);'. Maybe this can be done with cunning template code, maybe not. In a way it is cleaner to have the support directly in the language. OTOH, some would say it's better to have an expressive but minimal base language and implement this stuff in the standard library.
In any case, from a practical point of view, Ada has bounded integers while C++'s standard library does not (yet), so Ada wins.
As for indexing arrays from not-zero, this is trivial to do with a wrapper class, either for native arrays or for classes like the STL's vector. But again, there is no current provision for it in the standard library and no clean integration with classes like the bounded_int I wrote.
C++'s STL is notorious for not having any bounds checking on many of its containers, particularly vector. This means that you have little excuse not to use vector (which does at least auto-resize if you ask it to grow) rather than built-in arrays, but it also makes it harder to write and debug safe code. I'd prefer to have the safe behaviour of throwing exceptions on bounds errors by default, and the option of turning it off in really performance-critical code (or when the compiler can figure out statically that no check is needed, as when using bounded integer types). Failing that, at least the option of turning it *on* would be welcome. Again this is something you can easily provide yourself, but it's not in the standard library.
Your comment reminds me of MS-DOS where COM and EXE files really were different executable types (COM being limited to small memory model and a hangover from CP/M, or something), but when running the executable DOS ignored the extension and looked at the content. Which makes you wonder why they didn't use the.exe extension for both.
For web browsing there is a third way of identifying files: the MIME-type, which browsers are supposed to use. But last I heard, Internet Explorer tended to ignore the MIME-type and use the filename extension. So there are three different ways of determining a file type, all conflicting.
You're right that buggy application can contain buffer overflow bugs. But that doesn't mean you can just ignore the problem of running untrusted executables, which is a far easier exploit and much more common. Really there are three stages:
- Don't run untrusted executables and don't disguise them as 'documents'. This is so basic it shouldn't even need mentioning.
- Fix the applications which are insecure by design, that is, those which execute scripts embedded in documents with the user's full privelege and without his or her say-so.
- Fix bugs such as buffer overruns in other applications that might allow a document to execute a program even though this was not intended by the application's author.
They all need doing, but the first two are by far a commoner source of exploits and are more urgent.
On second thoughts perhaps the article title is a deliberate allusion to the Two Ronnies sketch 'Nuts Milord' in which they also got the distinction wrong. Conflating Python and the Two Ronnies in a single headline is neat.
Distinguish between 'milord' and 'my lord'. The former is (I think) used only for continental nobles, France in particular. Same with 'milady'. Did nobody here watch that Three Muskethounds cartoon?
The executable bit is not the answer, at least not in a multiuser system. Other people can turn on executable bits on their files, a tarball could unpack with some files already a+x, and so on. You could make some more sophisticated system of 'I trust this particular file', where you have in effect a personalized executable bit under your control and not under the control of the file's owner. But that is best done in userland I think.
Associating a script file with Notepad is not 'defeating the GUI' unless you start with the assumption that the purpose of the GUI is to run any programs found, whether they are trustworthy or not. The action 'open a file' should do just that, _open_ the file, not run it. If some environments have blurred the distinction so that double-click now means 'maybe open the file, or maybe run it, depending on some obscure file association that isn't clear', well that is their problem to fix.
So yes, I am arguing for a right-click and explicitly choose 'run'. Running programs is a dangerous operation, at least in cases where those programs came from the outside world and they have your full privilege level, and it needs to be made a bit more explicit. Of course there could be some mechanism for remembering certain files so you can run them more easily; the double-click operation might be bound to 'run' instead of 'open' for just those few files. But the default must be safe. The default must be opening not running.
(I wasn't seriously advocating Notepad; it was just an example to contrast with the current setup of executing the program without prompting. More user-friendly would be a dialogue box saying 'there is no way to open this as a document, but if you're sure you want to execute it as a program, here's how...'.)
I don't think you can trust the executable flag on a file to say 'this document is privileged and can execute scripts'. Imagine a wordprocessor that doesn't execute macros in the document normally but does so when the document has execute permission. This would not be a very sane user interface because it would be too unpredictable and would do weird things when loading documents from DOS filesystems or other places that don't have an executable bit. More importantly, it provides no extra security because a file owned by someone else could of course have execute permissions for all.
There needs to be some other check, and the best way IMHO is to have it safe by default and turn on 'unsafe' scripting (in Ghostscript's case, file access) only with explicit user approval.
Speaking of which, when you view a Postscript document with gsview or gv or ggv or just plain old Ghostscript, does it allow local filesystem access? Last time I looked this was on by default and you had to pass the -DSAFER switch, which seems broken to me.
I think you misunderstand. The equivalent of 'please jump off a cliff' in computer terms is a malicious executable or script. Just as with the imaginary letter, it is a sequence of instructions. As humans we can easily distinguish between *reading* some instructions and *performing* those instructions. However, a broken mail client may decide to execute scripts contained in the message rather than just looking at them.
FWIW, I don't think the executable bit is that strongly linked to this: you can imagine a stupid Unix mail client or file browser that seeing a file with '.sh' extension runs it with/bin/sh. Indeed I think elm or some other mail client had just this security hole a while ago (it thought the file would be a shell archive). And '.vbs' is in a similar position on Windows to '.sh' on Unix. What Windows needs to do is assocate _opening_ a.vbs file with loading it in Notepad or the Visual Basic editor or something equally harmless, and for there to be a separate operation of _running_ files which has to be invoked explicitly (and not just by double-clicking).
Minitel terminals work just fine outside France... you just have to change the number dialled and pay for an international phone call. Or you can use your PC's modem and a terminal emulator to dial up the Minitel system directly.
Slashdot Mirror
If it used IRC, which channel would it go to and how would it know which messages were code? Surely a particular IRC channel or particular IRC server can be taken down just like a web page. And who is going to put the code there in the first place?
Freenet makes more sense perhaps, provided that most Freenet users will be too lazy to reconfigure their software to stop distributing copies of the worm's code. (Perhaps the Freenet software deliberately lacks any option to be selective about what resources are forwarded to others - anyone knowledgeable about this stuff care to explain?)
It would have been smarter for the worm to verify a signature on the code it downloads (a la Xbox) so it couldn't be disabled in this way. Trusting a particular Geocities URL is just silly.
Yes I think I was thinking of the 'quack' debacle, you know more about it than I do. Still it is _possible_ that some video card could do lower-quality rendering (perhaps due to a bug) in a particular benchmark and so get an unfairly high score.
Hmm, I thought that checking the rendering was very difficult because graphics cards (at least the consumer ones) always do have some latitude, they are never pixel perfect. You could render the scene in software and then do a pixel-by-pixel comparison I imagine, but I'd worry that things like textures would be consistenly 1.5 pixels out or something, and so you'd get a very big pixel-value diff for a similar image.
So - given two images, one rendered in hardware and one (presumably pixel-perfect and correct) rendered in software, what is the quantitative measure for finding how different they are?
It's like the main argument for developing lossless compression algorithms rather than lossy ones: you have an objective basis on which to compare them, rather than worrying about which changes in the data are allowed.
Yes, the output is correct for that particular scene and camera angle, and the answer in this case is to benchmark many different camera angles (they'd be unlikely to hardcode clipping for every one) and preferably many different scenes.
I don't see why voting has to involve a slip of paper. Why not have a line of buckets, one for each candidate, and you drop a small token into one of the buckets (or more than one, depending on your electoral system). To preserve confidentiality there would need to be a slot through which you drop the token, to stop you reaching in and removing some or looking to see who's had the most votes so far. Then counting votes is just weighing the buckets (and checking for invalid tokens).
What I meant to say was, nobody would test based *only* on taking the square root of seven.
You make a good point about the difficulty of checking that the scene was rendered correctly. The graphics card could 'optimize' the benchmark by showing a blank screen, and the software would not be any the wiser. However, if the drawing requests the benchmark sends to the graphics card are wide-ranging, the card could not give any special treatment to the benchmark (whether accidentally or deliberately).
Secondly, even with a benchmark that draws a single scene or fixed animation there is no way to test the picture quality produced. It has happened in the past that video cards downgraded Quake 3 quality to do better in benchmarks. Of course the benchmark program did not notice.
There are two different issues here: firstly, how to make sure that the benchmark gives a varied range of tasks and not a fixed sequence that can be special-case optimized; and secondly, how to check that the rendered image for a given set of commands is 'correct'. You can deal with the two separately, at least for video cards.
(BTW, can you suggest a benchmark and a validation suite for floating-point performance? I tried running 'paranoia' on my Linux/i386 box but it found lots of errors.)
But if your C++ code today obeys the standard, and the code you wrote three years ago did not...
I agree though, standards compliance is more important than compilation speed.
Why is it that people are assessing the performance of cards based on running the same narrow set of benchmarks each time? Of _course_ if you do that then performance optimization will be narrowly focused towards those benchmarks. Not just on the level of blatant cheating (recording a particular hardcoded text string or clipping plane) but more subtle things like only optimizing one particular code path because that's the only one the benchmark exercises.
More importantly why is any benchmark rendering the exact same scene each time? Nobody would test an FPU based on how many times per second it could take the square root of seven. You need to generate thousands, millions of different scenes and render them all. Optionally, the benchmark could generate the scenes at random, saving the random seed so the results are reproducible and results can be compared.
Please run your posts through a mixed-metaphor checker before pressing 'Submit' :-P.
I wonder, with the increase in CPU speeds since 2.9x was current, whether a $500 machine now can compile faster or slower than a $500 machine a few years back.
:-(.
Of course it would be still nice for gcc not to get slower, or maybe even to get faster
Most often called Santa Cruz, Calderuman was one of the first of the UNIX vendors to arrive in Intel-earth, after the arrival of the System V. He was said to be the eldest of the order. For a dozen years, and maybe more, he journeyed in the barren East, and was little heard of at Berkeley.
It was at about this time that Calderuman began to study the Rings of Power, their history and the means of their making.
In year 31 of the Epoch, he was given the keys of OpenLinux, and took up his abode there. He continued his researches into Ring-Zero-lore, and the making of device drivers, and was accustomed to watch the stars from the pinnacle of the Tower. When the Council debated the Rings of Power, Calderuman claimed that his researches showed that the One Ring had been lost forever. It was later shown that he did not believe this, however, and was searching for it himself, having secretly rebelled against the Council.
He built an army of Lawyers and Orcs of his own within the ring of Isengard to challenge both the Wise and the forces of Mondred. In May of the 24th year, when he was ready to reveal himself, Calderuman set a trap for Gandalf, luring him to Orthanc. When Gandalf came, Calderuman revealed that he had made a Ring of his own, and that he intended to gain control of Linux , or at least prevent Gandalf from using it freely himself.
To be continued...
(Plagiarized of course - Google to find the source.)
LZH (Lempel-Ziv-Huffman; find repeated strings in a sliding window and then use Huffman coding on the resulting backreferences and raw characters) is freely implementable in all countries - it was developed for pkzip-2.0, and later adopted for gzip. You're thinking of LZW (Lempel-Ziv-Welch). Although the US patent on that will expire in a couple of years IIRC.
In the past, when a kernel has not compiled with a new gcc version it has been more often a bug in the kernel than one with gcc. The same goes for most apps. Looking at the list archives, the main problem seems to be with __inline__ which was a gcc extension to start with, so the problem is presumably that the meaning of that keyword has been deliverately changed.
Yes, if it can be determined at compile time that the return of Month fits into the range Months, then no run-time check is necessary.
I've hacked up an equivalent in about 30 lines of C++, it lets you declare variables as
bounded_int<5, 10> i;
bounded_int<6, 7> j;
Then 'i = j;' will compile happily, since the range of j is within the range of i. And of course another bounded_int<5, 10> could be assigned to i. However, if you want to assign the other way round, you have to use an explicit cast:
j = range_cast<6, 7>(i);
and this will throw an exception at run time if the value is outside the allowed range.
However, my prototype code is still ugly, in particular I haven't worked out a clean way to say:
bounded_int<5, 10> i = 7;
which ought to compile without complaints because 7 can be statically determined to be within the limits. There are other rough edges such as having to pass the new range explicitly to range_cast, you can't just say 'j = range_cast(i);'. Maybe this can be done with cunning template code, maybe not. In a way it is cleaner to have the support directly in the language. OTOH, some would say it's better to have an expressive but minimal base language and implement this stuff in the standard library.
In any case, from a practical point of view, Ada has bounded integers while C++'s standard library does not (yet), so Ada wins.
As for indexing arrays from not-zero, this is trivial to do with a wrapper class, either for native arrays or for classes like the STL's vector. But again, there is no current provision for it in the standard library and no clean integration with classes like the bounded_int I wrote.
C++'s STL is notorious for not having any bounds checking on many of its containers, particularly vector. This means that you have little excuse not to use vector (which does at least auto-resize if you ask it to grow) rather than built-in arrays, but it also makes it harder to write and debug safe code. I'd prefer to have the safe behaviour of throwing exceptions on bounds errors by default, and the option of turning it off in really performance-critical code (or when the compiler can figure out statically that no check is needed, as when using bounded integer types). Failing that, at least the option of turning it *on* would be welcome. Again this is something you can easily provide yourself, but it's not in the standard library.
Your comment reminds me of MS-DOS where COM and EXE files really were different executable types (COM being limited to small memory model and a hangover from CP/M, or something), but when running the executable DOS ignored the extension and looked at the content. Which makes you wonder why they didn't use the .exe extension for both.
For web browsing there is a third way of identifying files: the MIME-type, which browsers are supposed to use. But last I heard, Internet Explorer tended to ignore the MIME-type and use the filename extension. So there are three different ways of determining a file type, all conflicting.
You're right that buggy application can contain buffer overflow bugs. But that doesn't mean you can just ignore the problem of running untrusted executables, which is a far easier exploit and much more common. Really there are three stages:
- Don't run untrusted executables and don't disguise them as 'documents'. This is so basic it shouldn't even need mentioning.
- Fix the applications which are insecure by design, that is, those which execute scripts embedded in documents with the user's full privelege and without his or her say-so.
- Fix bugs such as buffer overruns in other applications that might allow a document to execute a program even though this was not intended by the application's author.
They all need doing, but the first two are by far a commoner source of exploits and are more urgent.
Yeah I think there is a difference between m'lord and milord.
On second thoughts perhaps the article title is a deliberate allusion to the Two Ronnies sketch 'Nuts Milord' in which they also got the distinction wrong. Conflating Python and the Two Ronnies in a single headline is neat.
Distinguish between 'milord' and 'my lord'. The former is (I think) used only for continental nobles, France in particular. Same with 'milady'. Did nobody here watch that Three Muskethounds cartoon?
The executable bit is not the answer, at least not in a multiuser system. Other people can turn on executable bits on their files, a tarball could unpack with some files already a+x, and so on. You could make some more sophisticated system of 'I trust this particular file', where you have in effect a personalized executable bit under your control and not under the control of the file's owner. But that is best done in userland I think.
Associating a script file with Notepad is not 'defeating the GUI' unless you start with the assumption that the purpose of the GUI is to run any programs found, whether they are trustworthy or not. The action 'open a file' should do just that, _open_ the file, not run it. If some environments have blurred the distinction so that double-click now means 'maybe open the file, or maybe run it, depending on some obscure file association that isn't clear', well that is their problem to fix.
So yes, I am arguing for a right-click and explicitly choose 'run'. Running programs is a dangerous operation, at least in cases where those programs came from the outside world and they have your full privilege level, and it needs to be made a bit more explicit. Of course there could be some mechanism for remembering certain files so you can run them more easily; the double-click operation might be bound to 'run' instead of 'open' for just those few files. But the default must be safe. The default must be opening not running.
(I wasn't seriously advocating Notepad; it was just an example to contrast with the current setup of executing the program without prompting. More user-friendly would be a dialogue box saying 'there is no way to open this as a document, but if you're sure you want to execute it as a program, here's how...'.)
I don't think you can trust the executable flag on a file to say 'this document is privileged and can execute scripts'. Imagine a wordprocessor that doesn't execute macros in the document normally but does so when the document has execute permission. This would not be a very sane user interface because it would be too unpredictable and would do weird things when loading documents from DOS filesystems or other places that don't have an executable bit. More importantly, it provides no extra security because a file owned by someone else could of course have execute permissions for all.
There needs to be some other check, and the best way IMHO is to have it safe by default and turn on 'unsafe' scripting (in Ghostscript's case, file access) only with explicit user approval.
Speaking of which, when you view a Postscript document with gsview or gv or ggv or just plain old Ghostscript, does it allow local filesystem access? Last time I looked this was on by default and you had to pass the -DSAFER switch, which seems broken to me.
I think you misunderstand. The equivalent of 'please jump off a cliff' in computer terms is a malicious executable or script. Just as with the imaginary letter, it is a sequence of instructions. As humans we can easily distinguish between *reading* some instructions and *performing* those instructions. However, a broken mail client may decide to execute scripts contained in the message rather than just looking at them.
/bin/sh. Indeed I think elm or some other mail client had just this security hole a while ago (it thought the file would be a shell archive). And '.vbs' is in a similar position on Windows to '.sh' on Unix. What Windows needs to do is assocate _opening_ a .vbs file with loading it in Notepad or the Visual Basic editor or something equally harmless, and for there to be a separate operation of _running_ files which has to be invoked explicitly (and not just by double-clicking).
FWIW, I don't think the executable bit is that strongly linked to this: you can imagine a stupid Unix mail client or file browser that seeing a file with '.sh' extension runs it with
Minitel terminals work just fine outside France... you just have to change the number dialled and pay for an international phone call. Or you can use your PC's modem and a terminal emulator to dial up the Minitel system directly.