"Other examples include Ada and Pascal. Not ALL languages that use bounded arrays have garbage collection.
Another one that comes to mind is Common Lisp. (Probably Scheme, too.)"
Lisp has garbage collection... I'm not sure if you meant to say that it didn't but that's how I parsed your post.:)
There's lots of languages with and without bounded arrays, and with and without garbage collection. Java and Python are just examples that I happen to know.
C has stack protection these days, which OpenBSD and probably others make use of. It's a bit of a hack but there's been a bunch of patches for OpenBSD (again, just the example I happen to know) where an aribtrary code exploit became a DoS. Indeed, some of those those bugs were arbitrary code exploits on NetBSD, as the code was common to both.
"Another good contender (soon) will be D. (Digital Mars D, dmd. http://www.digitalmars.com/d/index.html ) It hasn't hit the 1.0 release yet, but it's a nice looking language. It's main problem appears to be a lack of libraries."
I don't think there's room for another language of that type, even if it's better than the alternatives.
"A good programmer knows that any program he writes needs to be carefully debugged. No program is going to come out of the mind of a programmer without bugs unless it is the "hello world" type. And this is the same no matter the language."
Agreed.
"You should also not forget that sometimes the "managed" solutions are not good enough when it comes to scalability and speed. Sure simple programs can be coded in Java and friends but simple programs are seldom target of attacks. How many successful browsers do you know that are written in Java for example? How many server programs? How many mail clients?
There are some for sure, but do they deserve to win a first prize?"
Well there's no denying that C/C++ are still necessary, particularly in very performance sensitive areas like servers or browsers or (my favorite) OSes, but on the flipside now many dynamic web sites do you know that are written in C?
Now obviously dynamic websites are not without their holes, but I shudder to think what would happen if C/C++ were the dominant language. For dynamic content it's not even in the top 5.
Uhg.
That's not to say I relish the thought of dropouts excreting PHP.
That's not true. Both are compiled to bytecode (Python does this in memory even if it doesn't create.pyc files), and the bytecode is run by a VM.
But anyway...
"Guess what the interpreters are generally written in?"
The VM doesn't touch input directly. The bytecode program does all the work, and the bytecode program can't directly address memory, which makes stack smashing a bit difficult. That's one security advantage of managed languages.
The other advantage is that things like strings and arrays are sized in managed languages. They'll throw exceptions in either language if an attempt is made to go out of bounds. And if you could go out of bounds, it wouldn't help that much because these things live on the heap and not the stack.
"No offense, but give a fool a hammer and he'll crack his skull. C is not inherently insecure. C++ is not inherently insecure. If you don't know how to program, please step aside and let others through. I am not some sort of anti-managed-language zealot, I love Python, but to claim that C *as a language* has a terrible security track record is ridiculous. The applications, not the language, might have a terrible track record due to the ineptness of the programmer."
That's just restating the question.
If managed languages make a certain class of exploits impossible or very unlikely while C doesn't, then C is insecure relative to those languages.
A good C programmer might be able to cut the exploit rate down to some very small value, but they're going to work pretty hard to get to that point while people in managed languages get it for free. And good C programmers still fuck up sometimes.
Of course, there's other ways to screw up. No language is immune from security problems. Using a "managed" language is nothing more than risk management, but it's pretty effective.
C/C++ programs have terrible security track records. They're behind basically every arbitrary code exploit out there. That class of bug just doesn't happen in managed languages. And I don't mean just Java and.NET. An open source example is Python.
I can remember Google being the only search engine worth using by about 2000 or so, but in previous years it flipped between the alternatives quite a bit. I don't think any of them had 5 years of unchallenged dominance.
Also, I don't think anyone can beat Google in quality. Match it yes, but not beat it.
"Just as an offhand observation, I kind of wonder if the 2.6 Linux kernel isn't approaching the level of diminishing returns... it's gotten so complex that it's getting pretty tough to cleanly improve without blowing a lot of stuff up. A microkernel design would probably have made maintenance easier, and *probably* would have given us more stable systems now."
No. That's just the fact that they're doing active development on it. If they'd leave it alone for a few months it would stabalize.
Unfortunately I don't think a USB wigit is sufficient for things like playing DRMed HDTV content. There's no way to get it back into the computer without exposing it to piracy, and having it display directly from the wigit is awkward at best.
Still, I'd rather see a deeply flawed implemenetation get railroaded into place now than have the industry wait till they get it right. Particularly a hardware implementation. With buying cycles being what they are, a flawed hardware implementation could set the cause of DRM back for a good chunk of a decade.
As for the USB cryptography widgit, I think that's a really good idea. You can take it with you when you leave, and it can have a button on it, so even if someone takes over your computer you can just refuse to push the button and nothing will happen.
Remember this as prior art if someone tries to patent the idea!
"You can accomplish all those things in a 100% software implementation of priviledge separation. No special TCPA hardware is needed."
No. Since kernel-mode arbitrary code exploits have been known to occur, you might face a situation where an attacker can read any private keys on the system (for example). TCPA would allow private keys to stay locked away from attack.
Assuming the algorithm is immune to chosen plaintext attacks. And that no other weaknesses are found. After the hardware implementation is set in stone.
In principal it could be good for other things, but I don't trust a committee to design a secure architechture on the first shot.
"OSX is not FreeBSD based. It borrows from FreeBSD and recognizes it as th successor to UCB's BSD. Apple uses FreeBSD as the reference platform for "what constitutes BSD Unix"."
Well, a number of points.
-It's a different kernel but Apple made it system call compatible. Mostly[1]. They have some extra ones I think.
-They took a lot of FreeBSD userland libraries and programs. With a compatible kernel there's simply no point in duplicating this work. A lot of the man pages are even marked FreeBSD.
-I've heard vague talk about FreeBSD kernel code making its way into Darwin (the OS X kernel). It's legal so it seems plausible enough. I have not specifically investigated this.
I don't know what it takes to be considered a BSD. OS X is missing a ports tree (Fink is available but not included by default). It's also not a direct genetic decendant of BSD, at least not in the kernel. It also doesn't feel like a BSD when you're at the command line.
I think the 1.0 release was more of a "technology preview" type thing. I don't have a link handy, but Dillion mentioned that 1.0 was about getting a good chunk of the ideas working if not optimized. I imagine it will be a few years before we start seeing performance results.
But frankly I'm not in the habit of picking OSes for performance. I use OpenBSD instead of a faster OS because of the features (stability, security, very nice firewall (yes all the BSDs have ported PF, but Open is always a few months ahead of on features)).
With DragonFlyBSD, it's apparent that VERY cool features will be possible. I can't be sure they'll deliver, but if they do they can win without necessarily beating FreeBSD or Linux in terms of performance.
Also... if they can provide an efficient and reliable SSI cluster, they're going to be HUGE regardless of their performance on a single machine.
But as you say, it's all in the future. The biggest accomplishment of 1.0 was changing a bunch of behind the scenes stuff without breaking everything. We will see what happens in the future.
"so we tend to be lurkers with less political motivation driving us(there are always exceptions)"
What I find interesting is that so many of the prominant BSD people are former Amiga users. This is true of both Dillon and de Raadt (leaders of the two BSDs with recognizable leaders).
Better than 74xx. I don't think there's any denying that.
I know 86xxx will rock. Impossible to compare one unreleased platform to another, but I imagine 86xxx and Centrino II will be more or less comparable. Then Apple can win on style and features again.
To me, the question is whether 86xxx will be used before the IBM PPC970s or some derivative. No doubt Apple would prefer to use G5s, but that may not be possible given the situation with current PowerBooks.
Funny you should say that. Back in the day, Windows NT ran on Alpha, MIPS, and PowerPC. Natively. They're bringing the PowerPC port back up to speed for XBox2 development (it'll run on PowerMac G5s).
The IA-64 and x86-64 ports of Windows both offer x86 binary compatability, but the kernel and libraries and core of the OS are fully native.
"ARM code size is tighter than that of MIPS or some other RISC architectures because of its conditional execution and register shifting that in effect do three RISC instructions at the same time. For even smaller code size when your inner loop is close to filling the instruction cache, you might want to choose the smaller Thumb encoding that takes the most commonly used instructions and puts them in a 16-bit word, yet still much more orthogonal than Ecch86. The MIPS instruction set has a 16-bit encoding as well."
Huh. I knew ARM could do that but not MIPS. Interesting.
I said that the tendency is for RISC binaries to be bigger than x86. ARM and MIPS have both been heavily optimized for embedded applications, so a) they diverge somewhat from RISC ideals, for example the varying instruction size, and b) they diverge from the tendency with their optimizations.
I will concede that most other architechtures are better suited to embedded applications, including binary size, than x86.
I would point out, though, that MIPS performance is so far behind the leaders that it's hardly worth mentioning unless you're talking about one of those massive SGI machines or embedded applications, and ARM is an exclusively embedded platform, so it can be ignored when talking about server/workstation/desktop issues.
"So in other words, availability of proprietary software determines the platform, right? How should disciples of the Church of Emacs choose a hardware platform? Price?"
Given that the vast majority of people that use exclusively open source software use x86, I'd say they've already chosen by price.
What? They don't emulate the whole OS on other architechtures. They have native ports to x86-64 and IA-64.
Re:Tablespork, you must have been the only one
on
Apple Updates PowerBooks
·
· Score: 3, Interesting
" I was thinking in terms of a notebook. Just like everything else CPUs should not be judged on just one features. Think of cars. Do you always buy the fastest car? What about gas mileage, handling, breaking, or room? In a notebook and now even in PCs other things such as heat/power and cost are factors. For a notebook a G5 maybe a bad trade off. The G4 for most people is a better trade off."
The G5 is a bad tradeoff at the moment, but the G4 is bad as well. I agree G4s may be appropriate for iBooks, but these are PowerBooks, and the slow bus simply precludes their use in many applications. The Centrino platform from Intel has lower power usage and dramatically better performance (particularly with the FSB), and it's only going to get worse with Centrino II.
"Also PowerPC processors are big-endian, so they need more space to store things. Motorola tried to compensate for this by adding L2 cash - a special kind of rebate when you buy the processor. They also introduced out-of-order execution which means that even when the processor is broken it still works."
This is probably a troll, but for the record:
That is absoloutely not the case. Motorola added the large L2 cache primarily because of the slow bus.
Also, big and little-endian architechtures take up the same amount of space for a value of a given size. They just pack the bits in different orders.
Also, everyone has out-of-order execution, and all it does is reorder instructions to run more efficiently.
Slashdot Mirror
Interesting. SO NetBSD runs with only one bit of memory?
"The most common security problem in "managed" languages being that people thing by using them they are safe from security exploits."
Inasmuch as that's the most common security problem anywhere, yes.
"Other examples include Ada and Pascal. Not ALL languages that use bounded arrays have garbage collection.
:)
Another one that comes to mind is Common Lisp. (Probably Scheme, too.)"
Lisp has garbage collection... I'm not sure if you meant to say that it didn't but that's how I parsed your post.
There's lots of languages with and without bounded arrays, and with and without garbage collection. Java and Python are just examples that I happen to know.
C has stack protection these days, which OpenBSD and probably others make use of. It's a bit of a hack but there's been a bunch of patches for OpenBSD (again, just the example I happen to know) where an aribtrary code exploit became a DoS. Indeed, some of those those bugs were arbitrary code exploits on NetBSD, as the code was common to both.
"Another good contender (soon) will be D. (Digital Mars D, dmd. http://www.digitalmars.com/d/index.html ) It hasn't hit the 1.0 release yet, but it's a nice looking language. It's main problem appears to be a lack of libraries."
I don't think there's room for another language of that type, even if it's better than the alternatives.
"A good programmer knows that any program he writes needs to be carefully debugged. No program is going to come out of the mind of a programmer without bugs unless it is the "hello world" type. And this is the same no matter the language."
Agreed.
"You should also not forget that sometimes the "managed" solutions are not good enough when it comes to scalability and speed. Sure simple programs can be coded in Java and friends but simple programs are seldom target of attacks. How many successful browsers do you know that are written in Java for example? How many server programs? How many mail clients?
There are some for sure, but do they deserve to win a first prize?"
Well there's no denying that C/C++ are still necessary, particularly in very performance sensitive areas like servers or browsers or (my favorite) OSes, but on the flipside now many dynamic web sites do you know that are written in C?
Now obviously dynamic websites are not without their holes, but I shudder to think what would happen if C/C++ were the dominant language. For dynamic content it's not even in the top 5.
Uhg.
That's not to say I relish the thought of dropouts excreting PHP.
"Java and python are interpreted."
.pyc files), and the bytecode is run by a VM.
That's not true. Both are compiled to bytecode (Python does this in memory even if it doesn't create
But anyway...
"Guess what the interpreters are generally written in?"
The VM doesn't touch input directly. The bytecode program does all the work, and the bytecode program can't directly address memory, which makes stack smashing a bit difficult. That's one security advantage of managed languages.
The other advantage is that things like strings and arrays are sized in managed languages. They'll throw exceptions in either language if an attempt is made to go out of bounds. And if you could go out of bounds, it wouldn't help that much because these things live on the heap and not the stack.
"No offense, but give a fool a hammer and he'll crack his skull. C is not inherently insecure. C++ is not inherently insecure. If you don't know how to program, please step aside and let others through. I am not some sort of anti-managed-language zealot, I love Python, but to claim that C *as a language* has a terrible security track record is ridiculous. The applications, not the language, might have a terrible track record due to the ineptness of the programmer."
That's just restating the question.
If managed languages make a certain class of exploits impossible or very unlikely while C doesn't, then C is insecure relative to those languages.
A good C programmer might be able to cut the exploit rate down to some very small value, but they're going to work pretty hard to get to that point while people in managed languages get it for free. And good C programmers still fuck up sometimes.
Of course, there's other ways to screw up. No language is immune from security problems. Using a "managed" language is nothing more than risk management, but it's pretty effective.
Fair enough, but how often does the kernel do things like parsing strings?
""Trust the programmer" is the most asinine statement ever put to paper,"
:)
bwhahahahahaha
It's funny because it's true.
"with the possible exception of "security through obscurity.""
No, it's worse than that.
C/C++ programs have terrible security track records. They're behind basically every arbitrary code exploit out there. That class of bug just doesn't happen in managed languages. And I don't mean just Java and .NET. An open source example is Python.
I can remember Google being the only search engine worth using by about 2000 or so, but in previous years it flipped between the alternatives quite a bit. I don't think any of them had 5 years of unchallenged dominance.
Also, I don't think anyone can beat Google in quality. Match it yes, but not beat it.
"Just as an offhand observation, I kind of wonder if the 2.6 Linux kernel isn't approaching the level of diminishing returns... it's gotten so complex that it's getting pretty tough to cleanly improve without blowing a lot of stuff up. A microkernel design would probably have made maintenance easier, and *probably* would have given us more stable systems now."
No. That's just the fact that they're doing active development on it. If they'd leave it alone for a few months it would stabalize.
I mentioned Fink, which does much the same thing. My point was that it's not included by default, which is still true.
Unfortunately I don't think a USB wigit is sufficient for things like playing DRMed HDTV content. There's no way to get it back into the computer without exposing it to piracy, and having it display directly from the wigit is awkward at best.
Still, I'd rather see a deeply flawed implemenetation get railroaded into place now than have the industry wait till they get it right. Particularly a hardware implementation. With buying cycles being what they are, a flawed hardware implementation could set the cause of DRM back for a good chunk of a decade.
As for the USB cryptography widgit, I think that's a really good idea. You can take it with you when you leave, and it can have a button on it, so even if someone takes over your computer you can just refuse to push the button and nothing will happen.
Remember this as prior art if someone tries to patent the idea!
"You can accomplish all those things in a 100% software implementation of priviledge separation. No special TCPA hardware is needed."
No. Since kernel-mode arbitrary code exploits have been known to occur, you might face a situation where an attacker can read any private keys on the system (for example). TCPA would allow private keys to stay locked away from attack.
Assuming the algorithm is immune to chosen plaintext attacks. And that no other weaknesses are found. After the hardware implementation is set in stone.
In principal it could be good for other things, but I don't trust a committee to design a secure architechture on the first shot.
There's one or two things I miss from GNU, but the sh-utils port has them...
"OSX is not FreeBSD based. It borrows from FreeBSD and recognizes it as th successor to UCB's BSD. Apple uses FreeBSD as the reference platform for "what constitutes BSD Unix"."
Well, a number of points.
-It's a different kernel but Apple made it system call compatible. Mostly[1]. They have some extra ones I think.
-They took a lot of FreeBSD userland libraries and programs. With a compatible kernel there's simply no point in duplicating this work. A lot of the man pages are even marked FreeBSD.
-I've heard vague talk about FreeBSD kernel code making its way into Darwin (the OS X kernel). It's legal so it seems plausible enough. I have not specifically investigated this.
I don't know what it takes to be considered a BSD. OS X is missing a ports tree (Fink is available but not included by default). It's also not a direct genetic decendant of BSD, at least not in the kernel. It also doesn't feel like a BSD when you're at the command line.
1 - They don't have jail(). Grr.
I think the 1.0 release was more of a "technology preview" type thing. I don't have a link handy, but Dillion mentioned that 1.0 was about getting a good chunk of the ideas working if not optimized. I imagine it will be a few years before we start seeing performance results.
But frankly I'm not in the habit of picking OSes for performance. I use OpenBSD instead of a faster OS because of the features (stability, security, very nice firewall (yes all the BSDs have ported PF, but Open is always a few months ahead of on features)).
With DragonFlyBSD, it's apparent that VERY cool features will be possible. I can't be sure they'll deliver, but if they do they can win without necessarily beating FreeBSD or Linux in terms of performance.
Also... if they can provide an efficient and reliable SSI cluster, they're going to be HUGE regardless of their performance on a single machine.
But as you say, it's all in the future. The biggest accomplishment of 1.0 was changing a bunch of behind the scenes stuff without breaking everything. We will see what happens in the future.
"so we tend to be lurkers with less political motivation driving us(there are always exceptions)"
What I find interesting is that so many of the prominant BSD people are former Amiga users. This is true of both Dillon and de Raadt (leaders of the two BSDs with recognizable leaders).
"So... How is the Centrino better, again?"
Better than 74xx. I don't think there's any denying that.
I know 86xxx will rock. Impossible to compare one unreleased platform to another, but I imagine 86xxx and Centrino II will be more or less comparable. Then Apple can win on style and features again.
To me, the question is whether 86xxx will be used before the IBM PPC970s or some derivative. No doubt Apple would prefer to use G5s, but that may not be possible given the situation with current PowerBooks.
I think there might have been a SPARC port but don't quote me on that, I don't specifically remember.
I don't think there ever was an ARM port.
Funny you should say that. Back in the day, Windows NT ran on Alpha, MIPS, and PowerPC. Natively. They're bringing the PowerPC port back up to speed for XBox2 development (it'll run on PowerMac G5s).
The IA-64 and x86-64 ports of Windows both offer x86 binary compatability, but the kernel and libraries and core of the OS are fully native.
"ARM code size is tighter than that of MIPS or some other RISC architectures because of its conditional execution and register shifting that in effect do three RISC instructions at the same time. For even smaller code size when your inner loop is close to filling the instruction cache, you might want to choose the smaller Thumb encoding that takes the most commonly used instructions and puts them in a 16-bit word, yet still much more orthogonal than Ecch86. The MIPS instruction set has a 16-bit encoding as well."
Huh. I knew ARM could do that but not MIPS. Interesting.
I said that the tendency is for RISC binaries to be bigger than x86. ARM and MIPS have both been heavily optimized for embedded applications, so a) they diverge somewhat from RISC ideals, for example the varying instruction size, and b) they diverge from the tendency with their optimizations.
I will concede that most other architechtures are better suited to embedded applications, including binary size, than x86.
I would point out, though, that MIPS performance is so far behind the leaders that it's hardly worth mentioning unless you're talking about one of those massive SGI machines or embedded applications, and ARM is an exclusively embedded platform, so it can be ignored when talking about server/workstation/desktop issues.
"So in other words, availability of proprietary software determines the platform, right? How should disciples of the Church of Emacs choose a hardware platform? Price?"
Given that the vast majority of people that use exclusively open source software use x86, I'd say they've already chosen by price.
What? They don't emulate the whole OS on other architechtures. They have native ports to x86-64 and IA-64.
" I was thinking in terms of a notebook. Just like everything else CPUs should not be judged on just one features. Think of cars. Do you always buy the fastest car? What about gas mileage, handling, breaking, or room? In a notebook and now even in PCs other things such as heat/power and cost are factors. For a notebook a G5 maybe a bad trade off. The G4 for most people is a better trade off."
The G5 is a bad tradeoff at the moment, but the G4 is bad as well. I agree G4s may be appropriate for iBooks, but these are PowerBooks, and the slow bus simply precludes their use in many applications. The Centrino platform from Intel has lower power usage and dramatically better performance (particularly with the FSB), and it's only going to get worse with Centrino II.
Apple needs upgraded PowerBooks. Very soon.
"Also PowerPC processors are big-endian, so they need more space to store things. Motorola tried to compensate for this by adding L2 cash - a special kind of rebate when you buy the processor. They also introduced out-of-order execution which means that even when the processor is broken it still works."
This is probably a troll, but for the record:
That is absoloutely not the case. Motorola added the large L2 cache primarily because of the slow bus.
Also, big and little-endian architechtures take up the same amount of space for a value of a given size. They just pack the bits in different orders.
Also, everyone has out-of-order execution, and all it does is reorder instructions to run more efficiently.