I do like their approach, but it's still frustrating to have to have the whole CISC/RISC conversion layer in there. How much extra are we paying for those transistors, hmm? If all software were written for that inner RISC processor in the first place, we'd have cheaper, faster CPU's. Unfortunately, even in this day in age where code morphing in hardware is possible, we are still distributing software in primitive machine code formats.
Working with what you already have is good for small changes, but as you add modifications, it becomes less good design and more bloat. Eventually, it's just wasteful.
Unfortunately the old x86 processor architecture is a horrible design. It started out as a cheap 8-bit processor (or was it 4-bit, even?) and has since been extended to 16, 32, and now 64 bit, every time keeping backwards compatibility and sticking with outdated methodologies. The reason why it's faster (if it really is -- these benchmarks are questionable) is not the underlying design, but just the fact that more money has been thrown at it. Personally, I applaud Apple for having the guts to completely get rid of their old processor (the 68k) and move to the PPC, sacrificing backwards compatibility for a better future. Same goes for the switch to OSX. I think moving to x86 would just be a step backwards for them.
(I'm not a Mac junkie. Didn't even like them before OSX, and my main computer is still a PC. I'm just a fan of well-designed systems.)
Hi. I know who NAMBLA is, and I agree that they are dispicable. But, the ACLU was completely right in defending them in this case. NAMBLA did not commit the murder. NAMBLA does not even avocate murder. Just because NAMBLA is sick and twisted doesn't mean that they are automatically wrong in every case. It is not NAMBLA's responsibility to make sure their fans do not commit crimes.
Imagine a country where you are held liable for the consequences of everything you say, and can be sued if someone thinks something you said might have inspired someone else to break the law. How dumb would that be? If I say that the speed limit is too low and that there's no problem with breaking it, and as a result my friend decides to drive faster and gets a speeding ticket, should I get a ticket too? Absolutely not.
The point of free speech is that you should be able to say absolutely anyhting you want, no matter how sick and twisted it is. Words sitting on your web site harm no one. Someone has to actually act on those words before it becomes an issue. Certainly, the guys who murdered this kid should be (and were) put in jail. But it is their own fault, not NAMBLA's. What kind of an excuse would it be for these guys to say "it's not my fault, the web page made me do it"? That's just stupid.
You are implying that it should be illegal to hold certain opinions. Even though I completely agree with you that NAMBLA's opinions are wrong, they have every right to believe whatever they want to believe, and to tell people what they believe. It is not until they actually act on their opinions that it becomes a crime. This is a very important principle, and, believe it or not, our country would be nowhere near as successful as it is without this. Ever notice how just about all of the most successful countries in the world support free speech?
No, there should not be limits on the freedom to express one's opinions. Period.
Summary: Pedophile rapes/kills 10-year-old boy. Turns out he was a fan of NAMBLA. So, family of boy decides to sue NAMBLA.
Personally, while I obviouly agree that NAMBLA is sick and twisted, I think the ACLU was completely right in defending them here. It's not NAMBLA's fault if someone who reads their page goes out and commits murder. NAMBLA may avocate things which are illegal and immoral (note that murder is not among them), but it wasn't NAMBLA that committed the crime. It looks like the parents, being understandably blind with rage, just wanted to sue anyone they could, and figured that NAMBLA was the sort of target that no judge or jury would rule in favor of.
The ACLU wasn't defending NAMBLA's right to have sex with kids. It was defending NAMBLA's right to say whatever it wants on its web page. The whole point of free speech is that people should be allowed to say things even if they are sick and twisted.
Similarily, it's not a video game maker's fault if a fan of their game decides to go on a real-life killing spree. It's not the game's fault that the kid was insane.
Microsoft's security is questionable, surely, but stability? Have you used a Microsoft product in the last three years? Win2k doesn't crash, unless you are running flaky hardware or bad drivers. Used as a desktop machine, it is every bit as stable as Linux. (And, yeah, I have Win2k, OSX, FreeBSD, and even Linux running on various boxes under my desk here.)
Why did I deny that cookie from Google!? Why!? I do all sorts of searches every day, but due to my damned paranoia Google hasn't been able to keep count!
Apparently your posting strategy went something like this:
Quote parent poster.
Ignore good points made by parent poster.
Invent bogus theory for why the moderators modded the guy up.
Declare that this was a stupid reason for him to get modded up.
+5 Funny!
Ironically, your post made for the better demonstration of the problems inherent in the Slashdot moderation system.
A pseudorandom generator is pseudo-random? Give that man a cigar. Still - he did say "pseudo" so another +1 Insightful.
Do you have any idea at all what he was talking about? Lots of cryptographic algorithms depend on random numbers. A common mistake by newbie cryptographers is to use a pseudo-random number generater which gives predictable values, leading to encryption which is easily broken. Real cryptography software must work very hard to find sources of unpredictable randomness in a system (like, say, the timing of a sequence of keypresses, if the computer has a keyboard). He was making a good point.
Ooh! X=0 - why thats an equasion! +1 Insightful!
Do you even know what ones-complement is? Again, he was making a point, but either you intentionally ignored it for the sake of your reply or if flew right over your head.
Brings gaming into it - we all like games - and we like the word "crap" - +1 Insightful!
He made a good point: If a programmer produces a buggy game, it's not a big problem, even if millions of people play it. But if a programmer produces a buggy cryptography library, and millions of people use it, that IS a problem.
Wow - criticizes the established doctrine of Open Source, what a rebel! +1 Insightful!
Wow - criticizes someone else's post without having a clue what it means! +5 Funny!
The problems in the x86 hardware to which you refer would be irrelevant if software were written in a language that didn't allow direct pointer manipulation. Memory protection, IMO, is a big hack to solve a problem that shouldn't exist in the first place. Software written in almost any other language than C or C++ doesn't need it. (Well, doesn't need it for security. It's useful for other things.)
Problem is, 90% or more of programmers are just too lazy to do the work necessary to secure their programs. Now, it would be nice if we could just convince all of them to work harder, but realistically we're probably going to have to deal with programmers being notoriously lazy forever. On the other hand, there are many programming languages out there which make it much, much easier to write secure code. If the computer industry were to move to one of these languages, there would simply be far fewer security holes in most software. Many of these languages also take far less code to write typical programs, and handle a lot of the nitty-gritty of programming (like garbage collection) automatically. Usually they're not as fast as C, but for 99% of applications the difference is irrelevant. So, why not switch?
What does video have to do with sound? The video API and the sound API do not need to interact in any way whatsoever, so there is no reason why you can't use DirectSound and OpenGL at the same time. Or, better yet, use OpenGL and OpenAL. UT2k3 uses OpenAL for audio, ya know. And input? Why would you even want to use the abomination that is DirectInput? Did you know that DirectInput intentionally ignores the user's keyboard layout? Most DirectInput games simply assume that you are using a qwerty keyboard, which screws over people like me (I use Dvorak). Did you know that DirectInput isn't actually any faster than GDI input? Well, maybe it is slightly, but if so it's certainly not noticeable to the user. In a few obscure situations, DirectInput can be marginally useful, but in general it's just a waste of time (ever notice how UT had an "enable DirectInput" option which was off by defult?).
I'm lead programmer for a little gaming company you probably haven't heard of (yet). We're creating a 3D game using OpenGL for video, OpenAL for sound, and the window manager for input. Works great. Although development is taking place on Windows, we plan to port to OSX, FreeBSD, and Linux, as each port will probably take only a day or two to complete. Hell, porting to Linux will probably be no more than a recompile once we have it running on FreeBSD.
Funny... the first thing I thought when I saw the real image was "I should post an ASCII-art version of this with the title 'In case it gets slashdotted'." Then I read the comments, and find this at the top. I wonder how many other people thought the exact same thing.
Real Star Wars fans watch all three... simultaneously! Three screens!
By that criteria, I'm not a real Star Wars fan, but I know someone who has done it, and she says it's really scary how well the scenes line up. Sort of like Wizard of Oz and that one CD (something by Pink Floyd, was it?).
Not many people know it, but one of the problems holding back processor technology today is the way programming languages are designed. Languages like C (or C++, Java, Perl, Python, Fortran, etc.) are inherently serial in nature. That is, they are composed of instructions which must be performed in sequence. However, the best way to improve the speed of processors is to increase parallelization; that is, make them do multiple things at once. And, no, threading isn't the answer -- threading too large-scale, and can only usefully extend to 2-4 parallel processes before most software has trouble taking advantage of it.
Think about this: Why is video graphics hardware so much faster than CPU's? You might say that it is because the video card is specifically designed for one task... however, these days, that isn't really true. Modern video cards allow you to write small -- but arbitrary -- programs which are run on every vertex or every pixel as they are being rendered. They aren't quite as flexible as the CPU, but they are getting close; the newest cards allow for branching and control flow, and they are only getting more flexible. So, why are they so much faster? There are a lot of reasons, but a big one is that they can do lots of things at the same time. The card can easily process many vertices or pixels in parallel.
Now, getting back to C... A program in C is supposed to be executed in order. A good compiler can break that rule in some cases, but it is harder than you would think. Take this simple example:
void increment(int* out, int* in, int count) {
for(int i = 0; i < count; i++)
out[i] = in[i] + 1; }
This is just a piece of C code which takes a list of numbers and produces another list by adding one to each number.
Now, even with current, mostly-serial CPU's, the fastest way to perform this loop is to process several numbers at once, so that the CPU can work on incrementing some of the numbers while it waits for the next ones to load from RAM. For highly-parallel CPU's (such as many currenty in development), you would even more so want to work on several numbers simultaneously.
Unfortunately, because of the way C is designed, the compiler can not apply such optimizations! The problem is, the compiler does not know if the "out" list overlaps with the "in" list. If it does, then the compiler has to do the assignments one-at-a-time to insure proper execution. Imagine the following code that calls the function, for example:
increment(myArray + 1, myArray, count);
Of course, using the function in such a way would not be very useful, but the compiler has to allow for it. This problem is called "aliasing".
ISO C99 provides for a "restrict" keyword which can help prevent this problem, but few people understand it, even fewer use it, and those who do use it usually don't use it everywhere (using it everywhere would be too much work). It's not a very good solution anyway -- more of a "hack" if you ask me.
Anyway, to sum it up, C generally requires the CPU to do things in sequence. As a result, CPU manufacturers are forced to make CPU's that do one thing at a time really, really fast, rather than lots of things at the same time. And, so, since it is so much harder to design a fast CPU, we end up with slower CPU's... and we hit the limits of "Moore's Law" far earlier than we should.
In contrast, functional languages (such as ML, Haskell, Ocaml, and, to a lesser extent, LISP), due to the way they work, have no concept of "aliasing". And, despite what many experienced C programmers would expect, functional languages can be amazingly fast, despite being rather high-level. Functional languages are simply easier to optimize. Unfortunately, experienced C/C++/Java/whatever programmers tend to balk at functional languages at first, as learning them can be like learning to program all over again...
Right... yes, I realize the code I wrote wasn't the best, but it was correct. Besides, as you said, making it cleaner is just going to require more typing, and the whole point is that coders hate more typing.
Using some sort of better string library would certainly help. I'd probably write my own if I ever had to work in C.
I don't use pointers to Strings. I pass them by value. The copy constructor takes care of memory management (including reference counting), and I know that the copy constructor is implemented correctly.
String global;
void function(String str) {
global = str; }
You say that there is a security problem in this code. I do not see one. If someone passes in an invalid String somehow, that's not a problem in THIS code, it's a problem in THEIR code.
I am certainly not saying that C++ is immune to memory problems. I was specifically talking about common string buffering issues in C. This is a common problem in C because C doesn't have very good string management methods. All I was saying is that it is a lot easier to avoid these problems in C++ since you can use something like a String class to manage memory for you. Or, in other languages, there's usually a built-in string type which has the same effect. As a result, buffer overruns when dealing with strings are much less common in these languages, if they are even possible at all.
Some other languages also prevent other forms of memory bugs (like dangling pointers and whatnot), but I am well aware that C++ does not. (Although, I use reference-counted smart pointers a lot in C++, which eliminates most problems.)
Well... that's great that they do that. And, yes, good programmers can usually write pretty secure code in C. But, most programmers are lazy and won't remember to use strlcpy(). Anyway, it's still more difficult than other languages, and it's still only useful if you used statically-sized strings, which are usually a bad idea anyway.
Slashdot Mirror
I do like their approach, but it's still frustrating to have to have the whole CISC/RISC conversion layer in there. How much extra are we paying for those transistors, hmm? If all software were written for that inner RISC processor in the first place, we'd have cheaper, faster CPU's. Unfortunately, even in this day in age where code morphing in hardware is possible, we are still distributing software in primitive machine code formats.
Working with what you already have is good for small changes, but as you add modifications, it becomes less good design and more bloat. Eventually, it's just wasteful.
Unfortunately the old x86 processor architecture is a horrible design. It started out as a cheap 8-bit processor (or was it 4-bit, even?) and has since been extended to 16, 32, and now 64 bit, every time keeping backwards compatibility and sticking with outdated methodologies. The reason why it's faster (if it really is -- these benchmarks are questionable) is not the underlying design, but just the fact that more money has been thrown at it. Personally, I applaud Apple for having the guts to completely get rid of their old processor (the 68k) and move to the PPC, sacrificing backwards compatibility for a better future. Same goes for the switch to OSX. I think moving to x86 would just be a step backwards for them.
(I'm not a Mac junkie. Didn't even like them before OSX, and my main computer is still a PC. I'm just a fan of well-designed systems.)
Hi. I know who NAMBLA is, and I agree that they are dispicable. But, the ACLU was completely right in defending them in this case. NAMBLA did not commit the murder. NAMBLA does not even avocate murder. Just because NAMBLA is sick and twisted doesn't mean that they are automatically wrong in every case. It is not NAMBLA's responsibility to make sure their fans do not commit crimes.
Imagine a country where you are held liable for the consequences of everything you say, and can be sued if someone thinks something you said might have inspired someone else to break the law. How dumb would that be? If I say that the speed limit is too low and that there's no problem with breaking it, and as a result my friend decides to drive faster and gets a speeding ticket, should I get a ticket too? Absolutely not.
The point of free speech is that you should be able to say absolutely anyhting you want, no matter how sick and twisted it is. Words sitting on your web site harm no one. Someone has to actually act on those words before it becomes an issue. Certainly, the guys who murdered this kid should be (and were) put in jail. But it is their own fault, not NAMBLA's. What kind of an excuse would it be for these guys to say "it's not my fault, the web page made me do it"? That's just stupid.
You are implying that it should be illegal to hold certain opinions. Even though I completely agree with you that NAMBLA's opinions are wrong, they have every right to believe whatever they want to believe, and to tell people what they believe. It is not until they actually act on their opinions that it becomes a crime. This is a very important principle, and, believe it or not, our country would be nowhere near as successful as it is without this. Ever notice how just about all of the most successful countries in the world support free speech?
No, there should not be limits on the freedom to express one's opinions. Period.
A quick Google search turned up this.
Summary: Pedophile rapes/kills 10-year-old boy. Turns out he was a fan of NAMBLA. So, family of boy decides to sue NAMBLA.
Personally, while I obviouly agree that NAMBLA is sick and twisted, I think the ACLU was completely right in defending them here. It's not NAMBLA's fault if someone who reads their page goes out and commits murder. NAMBLA may avocate things which are illegal and immoral (note that murder is not among them), but it wasn't NAMBLA that committed the crime. It looks like the parents, being understandably blind with rage, just wanted to sue anyone they could, and figured that NAMBLA was the sort of target that no judge or jury would rule in favor of.
The ACLU wasn't defending NAMBLA's right to have sex with kids. It was defending NAMBLA's right to say whatever it wants on its web page. The whole point of free speech is that people should be allowed to say things even if they are sick and twisted.
Similarily, it's not a video game maker's fault if a fan of their game decides to go on a real-life killing spree. It's not the game's fault that the kid was insane.
Microsoft's security is questionable, surely, but stability? Have you used a Microsoft product in the last three years? Win2k doesn't crash, unless you are running flaky hardware or bad drivers. Used as a desktop machine, it is every bit as stable as Linux. (And, yeah, I have Win2k, OSX, FreeBSD, and even Linux running on various boxes under my desk here.)
Nooooooooooo!
Why did I deny that cookie from Google!? Why!? I do all sorts of searches every day, but due to my damned paranoia Google hasn't been able to keep count!
I blame timothy for this.
The article seems to be missing random chunks of text, including HTML tags. How strange. In any case, it is mostly unreadable. :/
Apparently your posting strategy went something like this:
Ironically, your post made for the better demonstration of the problems inherent in the Slashdot moderation system.
Do you have any idea at all what he was talking about? Lots of cryptographic algorithms depend on random numbers. A common mistake by newbie cryptographers is to use a pseudo-random number generater which gives predictable values, leading to encryption which is easily broken. Real cryptography software must work very hard to find sources of unpredictable randomness in a system (like, say, the timing of a sequence of keypresses, if the computer has a keyboard). He was making a good point.
Do you even know what ones-complement is? Again, he was making a point, but either you intentionally ignored it for the sake of your reply or if flew right over your head.
He made a good point: If a programmer produces a buggy game, it's not a big problem, even if millions of people play it. But if a programmer produces a buggy cryptography library, and millions of people use it, that IS a problem.
Wow - criticizes someone else's post without having a clue what it means! +5 Funny!
Couldn't RTFA, for some unknown reason.
You're new here, aren't you?
As opposed to the... uh... open source jpeg format?
The problems in the x86 hardware to which you refer would be irrelevant if software were written in a language that didn't allow direct pointer manipulation. Memory protection, IMO, is a big hack to solve a problem that shouldn't exist in the first place. Software written in almost any other language than C or C++ doesn't need it. (Well, doesn't need it for security. It's useful for other things.)
Problem is, 90% or more of programmers are just too lazy to do the work necessary to secure their programs. Now, it would be nice if we could just convince all of them to work harder, but realistically we're probably going to have to deal with programmers being notoriously lazy forever. On the other hand, there are many programming languages out there which make it much, much easier to write secure code. If the computer industry were to move to one of these languages, there would simply be far fewer security holes in most software. Many of these languages also take far less code to write typical programs, and handle a lot of the nitty-gritty of programming (like garbage collection) automatically. Usually they're not as fast as C, but for 99% of applications the difference is irrelevant. So, why not switch?
::rolls eyes:: You know what I mean.
What does video have to do with sound? The video API and the sound API do not need to interact in any way whatsoever, so there is no reason why you can't use DirectSound and OpenGL at the same time. Or, better yet, use OpenGL and OpenAL. UT2k3 uses OpenAL for audio, ya know. And input? Why would you even want to use the abomination that is DirectInput? Did you know that DirectInput intentionally ignores the user's keyboard layout? Most DirectInput games simply assume that you are using a qwerty keyboard, which screws over people like me (I use Dvorak). Did you know that DirectInput isn't actually any faster than GDI input? Well, maybe it is slightly, but if so it's certainly not noticeable to the user. In a few obscure situations, DirectInput can be marginally useful, but in general it's just a waste of time (ever notice how UT had an "enable DirectInput" option which was off by defult?).
I'm lead programmer for a little gaming company you probably haven't heard of (yet). We're creating a 3D game using OpenGL for video, OpenAL for sound, and the window manager for input. Works great. Although development is taking place on Windows, we plan to port to OSX, FreeBSD, and Linux, as each port will probably take only a day or two to complete. Hell, porting to Linux will probably be no more than a recompile once we have it running on FreeBSD.
Funny... the first thing I thought when I saw the real image was "I should post an ASCII-art version of this with the title 'In case it gets slashdotted'." Then I read the comments, and find this at the top. I wonder how many other people thought the exact same thing.
"Testing? What's that? If it compiles, it is good, if it boots up it is perfect." -- Linus Torvalds
So now we're guessing the release date based on when it will compile without errors, eh?
No, all three...three times in a row.
Weak.
Real Star Wars fans watch all three... simultaneously! Three screens!
By that criteria, I'm not a real Star Wars fan, but I know someone who has done it, and she says it's really scary how well the scenes line up. Sort of like Wizard of Oz and that one CD (something by Pink Floyd, was it?).
Oh, there will be sex, alright. Just wait until Darl and his friends end up in prison.
You missed the larger point of my post. Aliasing was just one example of something that makes it hard to optimize imperative languages.
(that's a quarter billion $US)
Aww, man, you just ruined all bad the Yen jokes!
Think about this: Why is video graphics hardware so much faster than CPU's? You might say that it is because the video card is specifically designed for one task... however, these days, that isn't really true. Modern video cards allow you to write small -- but arbitrary -- programs which are run on every vertex or every pixel as they are being rendered. They aren't quite as flexible as the CPU, but they are getting close; the newest cards allow for branching and control flow, and they are only getting more flexible. So, why are they so much faster? There are a lot of reasons, but a big one is that they can do lots of things at the same time. The card can easily process many vertices or pixels in parallel.
Now, getting back to C... A program in C is supposed to be executed in order. A good compiler can break that rule in some cases, but it is harder than you would think. Take this simple example:
This is just a piece of C code which takes a list of numbers and produces another list by adding one to each number.
Now, even with current, mostly-serial CPU's, the fastest way to perform this loop is to process several numbers at once, so that the CPU can work on incrementing some of the numbers while it waits for the next ones to load from RAM. For highly-parallel CPU's (such as many currenty in development), you would even more so want to work on several numbers simultaneously.
Unfortunately, because of the way C is designed, the compiler can not apply such optimizations! The problem is, the compiler does not know if the "out" list overlaps with the "in" list. If it does, then the compiler has to do the assignments one-at-a-time to insure proper execution. Imagine the following code that calls the function, for example:
Of course, using the function in such a way would not be very useful, but the compiler has to allow for it. This problem is called "aliasing".
ISO C99 provides for a "restrict" keyword which can help prevent this problem, but few people understand it, even fewer use it, and those who do use it usually don't use it everywhere (using it everywhere would be too much work). It's not a very good solution anyway -- more of a "hack" if you ask me.
Anyway, to sum it up, C generally requires the CPU to do things in sequence. As a result, CPU manufacturers are forced to make CPU's that do one thing at a time really, really fast, rather than lots of things at the same time. And, so, since it is so much harder to design a fast CPU, we end up with slower CPU's... and we hit the limits of "Moore's Law" far earlier than we should.
In contrast, functional languages (such as ML, Haskell, Ocaml, and, to a lesser extent, LISP), due to the way they work, have no concept of "aliasing". And, despite what many experienced C programmers would expect, functional languages can be amazingly fast, despite being rather high-level. Functional languages are simply easier to optimize. Unfortunately, experienced C/C++/Java/whatever programmers tend to balk at functional languages at first, as learning them can be like learning to program all over again...
So, yeah. I recommend you guy
Right... yes, I realize the code I wrote wasn't the best, but it was correct. Besides, as you said, making it cleaner is just going to require more typing, and the whole point is that coders hate more typing.
Using some sort of better string library would certainly help. I'd probably write my own if I ever had to work in C.
I am certainly not saying that C++ is immune to memory problems. I was specifically talking about common string buffering issues in C. This is a common problem in C because C doesn't have very good string management methods. All I was saying is that it is a lot easier to avoid these problems in C++ since you can use something like a String class to manage memory for you. Or, in other languages, there's usually a built-in string type which has the same effect. As a result, buffer overruns when dealing with strings are much less common in these languages, if they are even possible at all.
Some other languages also prevent other forms of memory bugs (like dangling pointers and whatnot), but I am well aware that C++ does not. (Although, I use reference-counted smart pointers a lot in C++, which eliminates most problems.)
Well... that's great that they do that. And, yes, good programmers can usually write pretty secure code in C. But, most programmers are lazy and won't remember to use strlcpy(). Anyway, it's still more difficult than other languages, and it's still only useful if you used statically-sized strings, which are usually a bad idea anyway.
Of course the library could have bugs. We're assuming here that it doesn't. The C stardard library could have bugs, too. What's your point?
Besides, I wrote my own String class, reviewed it, and exensively tested it. I do not believe it has any such vulnerabilities.