Look, there's nothing wrong with the encryption algorithm used on DVD's. And DeCSS wasn't created by "breaking" the encryption, but rather by extracting the keys from a software DVD player.
The problem with CSS is a protocol problem. If the secret keys have to reside in the player, they're susceptible to getting stolen. Anyone who can come up with a better solution that doesn't require processing power on the discs themselves would have to be be a genius.
The difference I suppose, is one of basic skills. If I needed to write a program in Python or PHP (to name two languages I've never used), while my first effort might not exactly be beautiful, it'd at least be organized sensibly, and commented.
On the other hand, somebody with no training and no pre-gold-rush experience will probably cobble something together by cutting and pasting from someone else's scripts that they don't understand, and end up with a mess that "kinda" works...
C tends to reward that kind of "programming" by not compiling your program, or having it crash immediately. Perl, on the other hand, will happily accept almost anything, and unless you turn on diagnostics (which nobody but me ever does, apparently), you won't even get a warning about you egregiously broken code.
Yeah, there's some real bad C code out there. But at least everybody who writes a C program has read at least one book prior.
Hey, if all those art majors and wanna-be fashion designers hadn't decided to become "web developers", maybe someone who can write an actual program in Perl might get some respect.
Seriously, scripting languages have been "tainted" by the Web. "If it's a script, it can't possibly be worth anything" is a pretty common mind-set these days.
While I've seen some pretty awful C and C++ code out there, it's nothing compared to the horror of amateur Perl or (shudder) Shell scripts.
It's interesting to consider that scripting languages have been able to ride Moore's Law to the extent that you can reasonably implement things in a scripting language hat would have really needed to be compiled a short time ago.
I would argue that a JIT compiler isn't a "Normal Unix process", the way that Theo's using the term. A debugger wouldn't be either, among other things.
But your http server, and your inetd, don't need to write code into their own address space...
Well, most C compilers allocate temporary variables on the stack, which is the same place that they use to keep track of where the currently-executing function was called from, so they can return to the previous function.
If your program overflows the end of a temporary string or array (due to a bug in the error-checking, most likely), it can overwrite other things on the stack, including the return address of the current function call.
So, the attacker sends in an enormous string, which "just happens" to contain some executable code that does something nasty, followed by the address of that same code.
The new return address overwrites the one on the stack, so that when the function returns, it actually jumps into the previously-loaded data on the stack, which then does something nasty.
Making the stack non-executable causes the program to crash when you try to exploit it this way.
You can still overwrite data on the stack, which might still allow you to get a program to misbehave, but at least you're limited to running code that's already in the application.
Some of the other changes mentioned in the paper try to make it harder to exploit overwriting data on the stack, too.
I never did understand why this particular set of problems was allowed to exist on most x86 UNIX-like operating systems.
It's too bad that they weren't able to completely seperate executable and readable memory, but it's good to see somebody finally taking these problems seriously.
And as a bonus to making the system more secure, these changes will make it easier to debug stack-smashing bugs.
Just so you know: There is one "classic" Firewire port and one Firewire 800 port on the 17" Powerbook. So no need for an adapter.
I remember hearing somewhere that the Powerbook comes with an adapter so you can plug old Firewire cables into the Firewire 800 port, but I couldn't find any confirmation of that on the Apple site.
You can implement reversibility on a per-thread basis (though that's harder than it sounds, in my experience). For multiple threads, it's basically impossible.
It's much easier to implement back-stepping in a processor simulator or virtual machine than it is in a native-code debugger. Unless you single-step through all the instructions, keeping snapshots of all the relevant state along the way, you can't go back.
And if you do single-step, the performance will likely be so poor that you might as well use a simulator.
If you wanted to be safe, you probably could have just read the code, then re-implemented it in a line or two of your own code, rather than doing an actual cut-and-paste operation.
If the code you independently developed to have the same function ended up being naturally very similar to the code in VNC, well then, that's just because that's the easiest or most obvious way to do that.
You can't copyright an idea, just the expression of the idea.
I don't think you'll be able to test EVERY combination of options, simply because there are so many.
On the version of GCC I normally use, there are 25 -f options for controlling optimization. There are also a couple of other options that will effect code efficiency as a side-effect.
To test every combination of 25 options, you'd have to recompile and re-execute your tests 33,554,432 (2 to the 25th power) times, which will probably exceed your patience.
With a little clever winnowing of options, you might be able to cut that down to a reasonable set of options. Presumably, some options will always be a win, in nearly every situation. If you take those as fixed, that'll cut down the set of permutations significantly.
The main barrier to providing a service like this for the Mac, or for Linux, Solaris, BeOS, or whatever, isn't the cost to develop the software, it's the cost of supporting users on another platform.
Every time someone calls with a question, it costs the company money. The quicker you can answer their question and get them off the phone, the better. This means minimizing the number of different systems your support folks have to be trained for.
> I'm also missing large silicon devices to > actually discharge the thing. SCRs that can > handle 10 or 20kA are not common and seem to > cost many hundred of dollars. If anyone's got > a spare one, please tell me!
High-current SCR's are expensive, that's for sure. Do you really need a fast cycle time, though?
I know somebody already suggested a mechanical switch. Given the energy levels you want, it's probably not very realistic to use a knife switch.
A liquid-metal contact switch at least wouldn't weld itself together every time you closed it. Good luck finding one of those that's a) in your price range, and b) not full of Mercury, though.
Have you considered a spark gap? Since your working voltage is (relatively) low, you could use a triggered gap as a switch. Sort of like the flash tube, but built a lot more rugged.
Take a look at some of the web pages out there devoted to voltage cascades, Marx generators, and Tesla coils. Maybe someone has a solution figured out already.
Or, how about a vacuum tube? Peak current might be an issue there, too, but the voltage range seems about right, anyway. I'm no vacuum tube expert though.
I think that I made more typos myself in that post than in all the rest of my Slashdot comments *combined*. I suppose it could be this wicked cold I'm currently trying to get over.
Ive noticed over the last 10 years or so, that the number of obvious typographical errors in the novels I read has been on the increase.
Mostly, the problem is the use of the wrong word, or the omission of part of a sentence, rather than misspelling words
Is there something about the process that's changed, or is this the result of over-dependence on computers to "spell check" manuscripts? Does anybody actually read the final MS before printing the books, or is that just not done.
This is something that's been bothering me for a while, and I figured that since you're in the publishing business, you might have some insight.
IRC OpenStep had protected memory for it drivers, but Darwin ( the MacOS X kernel ) did away with this to increase response times.
That's not correct, drivers have always run at the highest privilege level in that family of operating systems.
The only PC operating system that I know of that ran drivers at a lower privilege level than the kernel was Novell Netware.
Actually, Netware allowed you to set the privilege level for individual drivers, so you could run "trusted" drivers at a higher privilege level for better performance.
Unfortunately, running hardware drivers at a lower privilege level doesn't solve everything. You need to engineer the whole OS such that it can respond appropriately to driver failures.
In many cases, there isn't enough information kept outside the driver to completely reconstruct the state before the crash (and no guarantee that retrying the operation won't cause another crash).
..is that in the cases you cited, the new technology had significant advantages *for the consumer*, which is what really drives adoption:
-- CD's - with widespread adoption of tapes, what is the motivation for taping companies to provide widespread support for another format, with CD readers costing about $2000?
Random access, along with much-improved quality and durability.
-- tapes - with widespread adoption of vinyl disks, what is the motivation for sound companies to provide widespread support for another format, with tape recorders costing about $2000?
Cassette tapes made it possible to carry your music with you anywhere. LP's, 45's and reel-to-reel would never have been practical in a car or a portable music player.
-- vinyl disks -...
Compared to what? That was really the first consumer-friendly music format (well, plastic disks, anyway. I don't think the kind of plastic matters much). Edison cylinders weren't really something the kids could use.
-- Internet Explorer/Word/Windows -.... widespread adoption of Netscape/WordPerfect/MacOS... who needs another...?
A little less obvious, but: 1. Explorer came with Windows, which is what killed Netscape, really. How the heck would you even manage to download Netscape in order to install it in the first place, if you weren't an uber-Geek? 2. I have no explanation for the success of Word - I never really used word processors during the time that Word replaced Wordperfect/Wordstar. I suspect that the rise of Windows did in Wordperfect, though. Which leads to: 3. Windows didn't replace MacOS, it just enabled people who had bought the wrong system in the first place to use a cheap knock-off.
-- WWW - with widespread... news... e-mail... who needs another format?
Ease of use, pure and simple. I could (and did) use Gopher, news, ftp, and all the rest, but my mother never could.
Slashdot Mirror
On the other hand, they're slow, loud, and the drivers don't work for crap on Mac OS X.
And nobody carries the supplies, except online.
- former ALPS MD-5000 user
Look, there's nothing wrong with the encryption algorithm used on DVD's. And DeCSS wasn't created by "breaking" the encryption, but rather by extracting the keys from a software DVD player.
The problem with CSS is a protocol problem. If the secret keys have to reside in the player, they're susceptible to getting stolen. Anyone who can come up with a better solution that doesn't require processing power on the discs themselves would have to be be a genius.
-Mark
The difference I suppose, is one of basic skills. If I needed to write a program in Python or PHP (to name two languages I've never used), while my first effort might not exactly be beautiful, it'd at least be organized sensibly, and commented.
On the other hand, somebody with no training and no pre-gold-rush experience will probably cobble something together by cutting and pasting from someone else's scripts that they don't understand, and end up with a mess that "kinda" works...
C tends to reward that kind of "programming" by not compiling your program, or having it crash immediately. Perl, on the other hand, will happily accept almost anything, and unless you turn on diagnostics (which nobody but me ever does, apparently), you won't even get a warning about you egregiously broken code.
Yeah, there's some real bad C code out there. But at least everybody who writes a C program has read at least one book prior.
-Mark
Hey, if all those art majors and wanna-be fashion designers hadn't decided to become "web developers", maybe someone who can write an actual program in Perl might get some respect.
Seriously, scripting languages have been "tainted" by the Web. "If it's a script, it can't possibly be worth anything" is a pretty common mind-set these days.
While I've seen some pretty awful C and C++ code out there, it's nothing compared to the horror of amateur Perl or (shudder) Shell scripts.
It's interesting to consider that scripting languages have been able to ride Moore's Law to the extent that you can reasonably implement things in a scripting language hat would have really needed to be compiled a short time ago.
-Mark
I would argue that a JIT compiler isn't a "Normal Unix process", the way that Theo's using the term. A debugger wouldn't be either, among other things.
But your http server, and your inetd, don't need to write code into their own address space...
-Mark
Well, most C compilers allocate temporary variables on the stack, which is the same place that they use to keep track of where the currently-executing function was called from, so they can return to the previous function.
If your program overflows the end of a temporary string or array (due to a bug in the error-checking, most likely), it can overwrite other things on the stack, including the return address of the current function call.
So, the attacker sends in an enormous string, which "just happens" to contain some executable code that does something nasty, followed by the address of that same code.
The new return address overwrites the one on the stack, so that when the function returns, it actually jumps into the previously-loaded data on the stack, which then does something nasty.
Making the stack non-executable causes the program to crash when you try to exploit it this way.
You can still overwrite data on the stack, which might still allow you to get a program to misbehave, but at least you're limited to running code that's already in the application.
Some of the other changes mentioned in the paper try to make it harder to exploit overwriting data on the stack, too.
Hope this was helpful,
-Mark
I never did understand why this particular set of problems was allowed to exist on most x86 UNIX-like operating systems.
It's too bad that they weren't able to completely seperate executable and readable memory, but it's good to see somebody finally taking these problems seriously.
And as a bonus to making the system more secure, these changes will make it easier to debug stack-smashing bugs.
-Mark
I just tried to get to mutantwatch, and I got re-directed to some damned pro-mutant website.
Somebody has got to DO something about the mutant threat.
Yep. Interesting when a typo ends up looking like the same letter...
(I had to re-read my original post multiple times to see the error)
Made out of clay, lives to carry out instructions, etc. Are there any other Jewish mythology references in the book?
-Mark
Just so you know:
There is one "classic" Firewire port and one Firewire 800 port on the 17" Powerbook. So no need for an adapter.
I remember hearing somewhere that the Powerbook comes with an adapter so you can plug old Firewire cables into the Firewire 800 port, but I couldn't find any confirmation of that on the Apple site.
-Mark
You can implement reversibility on a per-thread basis (though that's harder than it sounds, in my experience). For multiple threads, it's basically impossible.
It's much easier to implement back-stepping in a processor simulator or virtual machine than it is in a native-code debugger. Unless you single-step through all the instructions, keeping snapshots of all the relevant state along the way, you can't go back.
And if you do single-step, the performance will likely be so poor that you might as well use a simulator.
-Mark
There's an article in the latest issue of Embedded Systems Programming about using visualization tools for debugging. Well worth reading.
-Mark
If you wanted to be safe, you probably could have just read the code, then re-implemented it in a line or two of your own code, rather than doing an actual cut-and-paste operation.
If the code you independently developed to have the same function ended up being naturally very similar to the code in VNC, well then, that's just because that's the easiest or most obvious way to do that.
You can't copyright an idea, just the expression of the idea.
-Mark
I don't think you'll be able to test EVERY combination of options, simply because there are so many.
On the version of GCC I normally use, there are 25 -f options for controlling optimization. There are also a couple of other options that will effect code efficiency as a side-effect.
To test every combination of 25 options, you'd have to recompile and re-execute your tests 33,554,432 (2 to the 25th power) times, which will probably exceed your patience.
With a little clever winnowing of options, you might be able to cut that down to a reasonable set of options. Presumably, some options will always be a win, in nearly every situation. If you take those as fixed, that'll cut down the set of permutations significantly.
-Mark
The main barrier to providing a service like this for the Mac, or for Linux, Solaris, BeOS, or whatever, isn't the cost to develop the software, it's the cost of supporting users on another platform.
Every time someone calls with a question, it costs the company money. The quicker you can answer their question and get them off the phone, the better. This means minimizing the number of different systems your support folks have to be trained for.
-Mark
We're only talking about 6 billion bits or so. You'd need about 2 CD's, if you didn't compress it at all.
-Mark
Let's see. Three billion base pairs, at approximately two bits of information per base pair = 6 billion bits, or about 750 Megabytes of raw data.
It'll probably compress very well, since most of the sequences correspond with either Amino Acids or control codes of one sort or another.
Probably smaller than the source code to your favorite Linux distribution, overall...
-Mark
Here's something close -Mark
> I'm also missing large silicon devices to
> actually discharge the thing. SCRs that can
> handle 10 or 20kA are not common and seem to
> cost many hundred of dollars. If anyone's got
> a spare one, please tell me!
High-current SCR's are expensive, that's for sure. Do you really need a fast cycle time, though?
I know somebody already suggested a mechanical switch. Given the energy levels you want, it's probably not very realistic to use a knife switch.
A liquid-metal contact switch at least wouldn't weld itself together every time you closed it. Good luck finding one of those that's a) in your price range, and b) not full of Mercury, though.
Have you considered a spark gap? Since your working voltage is (relatively) low, you could use a triggered gap as a switch. Sort of like the flash tube, but built a lot more rugged.
Take a look at some of the web pages out there devoted to voltage cascades, Marx generators, and Tesla coils. Maybe someone has a solution figured out already.
Or, how about a vacuum tube? Peak current might be an issue there, too, but the voltage range seems about right, anyway. I'm no vacuum tube expert though.
-Mark
I think that I made more typos myself in that post than in all the rest of my Slashdot comments *combined*. I suppose it could be this wicked cold I'm currently trying to get over.
-Mark
Ive noticed over the last 10 years or so, that the number of obvious typographical errors in the novels I read has been on the increase.
Mostly, the problem is the use of the wrong word, or the omission of part of a sentence, rather than misspelling words
Is there something about the process that's changed, or is this the result of over-dependence on computers to "spell check" manuscripts? Does anybody actually read the final MS before printing the books, or is that just not done.
This is something that's been bothering me for a while, and I figured that since you're in the publishing business, you might have some insight.
-Mark
FYI, reprogramming your ECU also violates CARB's regulations.
-Mark
IRC OpenStep had protected memory for it drivers, but Darwin ( the MacOS X kernel ) did away with this to increase response times.
That's not correct, drivers have always run at the highest privilege level in that family of operating systems.
The only PC operating system that I know of that ran drivers at a lower privilege level than the kernel was Novell Netware.
Actually, Netware allowed you to set the privilege level for individual drivers, so you could run "trusted" drivers at a higher privilege level for better performance.
Unfortunately, running hardware drivers at a lower privilege level doesn't solve everything. You need to engineer the whole OS such that it can respond appropriately to driver failures.
In many cases, there isn't enough information kept outside the driver to completely reconstruct the state before the crash (and no guarantee that retrying the operation won't cause another crash).
-Mark
..is that in the cases you cited, the new technology had significant advantages *for the consumer*, which is what really drives adoption:
...
.... widespread adoption of Netscape/WordPerfect/MacOS ... who needs another ...?
... news ... e-mail ... who needs another format?
-- CD's - with widespread adoption of tapes, what is the motivation for taping companies to provide widespread support for another format, with CD readers costing about $2000?
Random access, along with much-improved quality and durability.
-- tapes - with widespread adoption of vinyl disks, what is the motivation for sound companies to provide widespread support for another format, with tape recorders costing about $2000?
Cassette tapes made it possible to carry your music with you anywhere. LP's, 45's and reel-to-reel would never have been practical in a car or a portable music player.
-- vinyl disks -
Compared to what? That was really the first consumer-friendly music format (well, plastic disks, anyway. I don't think the kind of plastic matters much). Edison cylinders weren't really something the kids could use.
-- Internet Explorer/Word/Windows -
A little less obvious, but:
1. Explorer came with Windows, which is what killed Netscape, really. How the heck would you even manage to download Netscape in order to install it in the first place, if you weren't an uber-Geek?
2. I have no explanation for the success of Word - I never really used word processors during the time that Word replaced Wordperfect/Wordstar. I suspect that the rise of Windows did in Wordperfect, though. Which leads to:
3. Windows didn't replace MacOS, it just enabled people who had bought the wrong system in the first place to use a cheap knock-off.
-- WWW - with widespread
Ease of use, pure and simple. I could (and did) use Gopher, news, ftp, and all the rest, but my mother never could.
-Mark