Folks, in the interest of injecting some FACTS in the discussion, here's my analysis of what the hack does. It merely generates a URL of the following form, where all of the non-italicised text can remain constant:
In other words, the view/edit mailbox functionality appears to not check the password field, plain and simple. It's just plain bad CGI programming, not an OS or webserver issue.
Look at table 4, and you'll see he's getting the extra combinations from the subnet bits. He's seems to be operating under the delusional assumption that the subnet mask somehow floats alongside the IP address. Combine that with his delusional ramblings about decimal vs. binary vs. hexadecimal. (Dude, those are just representations, just like 90 degrees is PI/2 radians is a right angle! I could write the numbers in octal if I wanted to and it wouldn't change their values.)
The reality, of course, is that we can get at most 2**32 (~4.3 billion) globally unique addresses if we completely remove any artificial partitioning and special encodings that would use up encoding space. This guys "mathematical proof" reads like some of those "random data compression" patents that Jean-loup Gailly (of Info-Zip/ZLib fame) likes to discredit on his homepage.
Of course, having partitions and special values does simplify things alot, which is why we don't get all ~4.3Billion addresses. Just look at RISC computers which use a 32-bit opcode. They sure as heck don't implement 4 billion different instructions.
Three words come to mind: HIT, NAIL, and HEAD. :-)
To give an example from a paper I'm a coauthor on (being presented at ICSPAT'99), consider a JPEG decoder. Here's a quick overview of the bulk of a JPEG decoder:
for each 8x8 block
decode the Huffman code for the block
Perform inverse-quantization on the block
Perform the IDCT on the block
Write the block to the correct plane in the image
On a deeply pipelined / highly parallel processor, this is horribly inefficient, because each task is very small when applied to only one block, whereas switching between tasks is quite expensive. But, that's exactly what alot of JPEG decoders do (including the Independent JPEG Group's decoder). The decoder is alot easier to write that way, but is not nearly as efficient as it could be.
Instead, you want to batch things up as much as possible:
For all chunks of the encoded JPEG, do
Read a chunk of encoded JPEG
Decode the Huffman code for as many 8x8 blocks as possible
Inverse-quantize all of these blocks.
Perform IDCT on all of these blocks.
Write all of these blocks out to the image.
Now, you can make massive gains in efficiency due to better instruction cache locality, better parallelism across loop iterations due to the fact you're actually looping quite a bit now, and so on. (The wins are rather dramatic on a DSP which relies on programmed DMAs to move data on and off chip.)
What's nice about a system with parallel processing units (whether multiprocessor or multithreaded) is that each stage in the pipeline can become another parallel-executing thread. Indeed, that was one common way to program the TMS320C80 family DSPs, which had 2 or 4 DSPs on one chip, alongside a fairly strong RISC CPU... all on one die! The DSPs would be organized as a pipeline, communicating through a "crossbar" to shared on-chip SRAM. The RISC CPU would coordinate tasks and issue commands to the DSPs. It was really quite cool.
For an even number of samples, the median is the arithmetic average of the middle two samples in a sorted list. For an odd number of samples, the median is the middle value in the sorted list.
So, in this case, the median is 50.
The mode is the most commonly occuring value in the list. Again, this is 50.
Yes, there are geek girls. This particular one carries quite an impressive resume: I started Carnegie Mellon University in Electrical and Computer Engineering with a double major in Cognitive Science. My final degree, though, is in Mathematics, with a concentration in Biomedical Engineering. In December 1995, I received a Ph.D. in the field of Neuroscience from Northwestern University. My thesis is entilted ``The Role of the Plant Properties in Point-to-Point Arm Movements: A Neural Network Approach''
I'm pretty fortunate myself. My fiancee is into computers (and likes to sysadmin, too), although she's a Geology major. (I'm an EE myself, but honestly, I'm really just a software jock. The last hardware I built used 7400-series TTL.) You can look outside your major and outside your career, you know. Just remember, if you're not looking, you won't find anything, and if you're looking but not finding, you need to change your search space or your search criterion!
Heh... of course it's different, as long as you're coding for yourself!
When I'm not busy programming for work, or *ahem* socializing *ahem* with my fiancee, I'm usually writing my own software. Right now, I'm developing an Intellivision emulator for Linux. :-)
(That is, as soon as I unpack the computer. We just moved into a bigger place so that we can move the computers out of the bedroom and have more room for both computer and bedroom fun....;-) )
*sigh* Yet another person who regrets his childhood rather than revelling in it. Bad memories, eh? I bet coworkers don't bother passing around the joke sheets to you, fearing you'll grumble something about "having work to do, don't have time for such nonesense." Remember that when you have a major coronary due to cumulative stress at the age of 45.
I'm quite happy to proudly proclaim my allegiance to Weird Al. While songs such as Albuquerque are little more than a (fun) stage for really bizarre jokes, songs such as Germs have more subtle messages interleaved in the obvious humor. Even his polkas and their arrangements make a message, at least about the songs being paranoid. (For instance, how about Intergalactic and Ray of Light in Polka Power?)
I have to admit, I personally treat Dare To Be Stupid as a personal anthem of sorts, for two reasons: For one, it savagely pokes fun at the commercialism and common sensibility of our day (eg. "Buy some sensible shoes and a Chevrolet", or perhaps "It's like they say you gotta buy one if you wanna get one free."). For another thing, the title says it all -- you don't always have to be smart, at least not in the conventional sense. You should dare to be stupid, which I interpret to mean (according to the subtle sarcasm of the song) challenge the norms. Dare To Be Stupid presents a very deep, right-brain-centric message that also permeates his work. Anyone who deeply appreciates Dave Barry's or Michael Abrash's works should be able to see this nearly immediately.
And on a separate note...
I have way to much class to let this thread linger. Come over here and pull on my finger...
--Joe
(With apologies to Weird Al on the paraphrased lyrics.)
I suggest you take the cotton out of your ears and listen a little closer... After all, what's so formulaic about dental hygentists with spatulas tatooed on their arms, alongside a BIG BOWL OF SOUR KRAUT?
While the "Eddie Vedder" song isn't exactly as masterful as, say, Dare To Be Stupid, you've gotta admit that Albuquerque is one of Al's greatest accomplishments on Running With Scissors.
There will always be bugs. There's no avoiding that.
For now, Alan Cox is maintaining 2.0.xx, and it appears (from what I saw on Kernel Traffic) that he is/will be responsible for future 2.2.xx releases as well. Progress continues to be made on cleaning up the remaining nasties in 2.2, and 2.2.11 should be available sometime soon. (I'm guessing by the end of August.) Alan stated (and I'm paraphrasing heavily here) at the introduction of 2.2 that people who are happy with 2.0.3x shouldn't feel any overwhelming need to upgrade right away, and that they wouldn't be left out in the cold. I'm sure a similar sentiment holds for 2.2.
IMHO, Linux 2.2.0 was far from perfect, but I must say that 2.2.10 seems to be far closer to "stable" than 2.0.10 was. In many ways, the stability and progress of 2.2 remind me of Linux 1.2 much more than it does of 2.0, which I believe is a very good thing. 2.0 took almost 30 revisions before it was truly stable, and it may even make it to 2.0.40 (although that's unlikely now).
I think we can expect to see a number of bug fixes for awhile to come, perhaps with some well after 2.4.0 debuts. After all, 1.0.9 came out partway into the 1.2 series, and you have a similar story for 1.2.15 vs. 2.0.x and 2.0.37 vs. 2.2.x....
Don't forget, the last day of fall is Dec 20th. I'm guessing that this is mainly a call to get people serious about closing on 2.4, and it's easier to be serious if you're at least somewhat serious about a deadline. In this case, Linus is trying to give us 2.4 as an early Christmas present, it would appear (even though he hasn't come out and said so).
I'm sure that the kernel will go out when it's ready, and no sooner. Nonetheless, it's good to state some goals up-front, and a "limited development cycle" goal for 2.4 is probably a good idea. Saying "feature freeze" and "2.4 in the fall" at least gets people starting to think in that manner, rather than leaving it open-ended and sprawling, as it happened with Linux 2.2.
(Personally, I feel 2.0 should've been 1.4, and 2.2 should've been 2.0, in retrospect. At least the numbering, relative amounts of features and release dates are more consistent that way. Ahhh well....)
I could make a lewd comment about rock-solid releases here, but I won't....
--Joe
--
CPU heat is function of non-HLT'd cycles.
on
LinModems?
·
· Score: 1
When the CPU is halted (HLT instruction), it burns very little power while it waits for an interrupt to wake it back up again. When the CPU is not halted, it burns a fair amount of juice.
Linux (and I hear NT) execute a HLT whenever the ready queue is empty. Win9X sits in a busy loop.
Ergo, CPU power consumption (and therefore temperature) is a function of system loading in OSes which halt the CPU (Linux, NT), and not on OSes which don't halt the CPU (Win9x).
Rather, in order to correctly interprete the wave signals from the modem in software required that the driver execute at specific times.
For a perfect software modem, yes, this is true. But for a simple software modem, there are many things you can do to be "good enough", including the following:
Buffer up alot of samples to increase your tolerance for latency. The buffering could occur via DMA to system memory, I imagine.
Run as a real-time task or interrupt driven device driver to place your priority over the rest of the tasks on the system.
Treat dropped samples as line noise and just request a retransmit if you can't error-correct the glitch.
If you miss getting samples out to the board in time, no worries -- replay your previous samples and pray the link was idle so it just looks like the idle-time carrier. If it wasn't, the remote modem will behave as if it were line noise and all will still be well.
After all, Win9x has the same problems as Linux does in this regards (eg. no guaranteed hard-real-time scheduling), yet software modems seem to function passibly in such an environment. If anything, Linux would probably do better than Win9x at this same task. In any case, missing a real-time deadline with a soft-modem would look like lag to the end user and little else. Annoying, but not fatal.
Now, I'm not running out and signing up to buy a soft modem (particularly since I'm about to get DSL service, obviating the need for a POTS modem almost entirely), but there are some interesting ideas that could make LinModems popular, depending on how open PC-Tel is.
Software modem lights that actually work. (The ones I've seen in the past were worthless for actually diagnosing modem troubles. Eye candy at best.)
Real-time modem connection quality statistics, such as number of retrains, current symbol rate, etc... perhaps via an entry in/proc. The more detail, the better.
General on-the-fly control of modem parameters, such as explicitly requesting fallback/fallforward. For instance, lower symbol rates tend to work alot better for interactive sessions since latency is lower, but higher symbol rates tend to be better for downloading. You could actually request the modem to fall forward or fall backwards by signalling the driver directly. You can't really do that with an external modem.
At least one person to filter the chaos and make it into something cohesive.
Very good point. Let's not forget it.
Basically, for each of the M versions of P that might exist, there needs to be some amount of leadership leading the development of that version of P. Where open source wins is that there's no corporate structure dictating who the leaders are. Rather, much like ducks do when flying in formation, whoever has the most energy leads the wedge, and as one tires, another from the pack leads. And if one duck is particularly eager, he's welcome to start his own formation, but there's always the existing bias not to which keeps things at least somewhat clustered.
The address, data, and command lines can all be multiplexed on a single 64-bit wide bus. Recall that most transfers onto and off of the chip are going to be cache-line fills. Folks, these addresses are adjacent. You only need to know the starting address to know where the entire burst of data goes.
What this means is that you can put out a single "Address With Command" on the bus, followed by a burst of N data items. You've lengthened the transfer by 1 cycle for N items. Suddenly, you've cut your number of lines per CPU port from 128 to 64, and your performance is (N + k) / (N + k + 1), where N is the number of items, and k is the overhead occurred just by initiating a bus access. All in all, the "+ 1" looks pretty tiny, doesn't it?
Besides, ever hear of "pipeline burst cache" for L2?
Suppose Processor A is a producer and Processor B is a consumer. The only way they can communicate is via shared memory, unless, like a transputer, you have some other explicit CPU-to-CPU communication mechanism.
What happens is that Processor A ends up caching up a whole bunch of data that Processor B needs. The way Processor B ends up getting it is by accessing external memory, triggering Processor A to do its cache writebacks, and in the meantime stalling both Processor A and B.
Ick.
So, while the whole process is transparent to the programmer (at least insofar as the entire memory map is coherent, regardless of what CPU you're on), the whole cache-snooping business can kill performance.
For decent SMP performance in this scenario, Processor A really needs to manually flush the portions of its cache that Processor B needs (or instead use write-through, rather than write-back, in which case cache invalidation is all that is necessary). Since you're explicitly manipulating the cache, you're no longer transparent.
(Or, if you're a DSP or some other device with onchip SRAM instead-of/in-addition-to cache, you just DMA all the data where it needs to be in the background, and keep processing without missing a beat... :-) ) --Joe
But, the real issue is whether copying bits ever constitutes theft. When I buy a hard-disk, I physically own all of the bits on that drive. Is it theft if I change their states such that they correspond to the music of a given song?
Besides, see the other posts on here by actual musicians who welcome the arrival of cheap redistribution outside of the shadow of the recording industry. If it were stealing, who would you be stealing from if the artists themselves are happy to let you have it?
Hmmm... if they change processor platforms, Intel... If they change desktops, KDE... and then if they change back to their original processor platform, Motorola...
Not quite. In AR-style static libraries (the good old.a files) the linking granularity is object file level. (eg. the.o file level) with traditional linkers.
There are linkers which work at much finer granularity these days. Some work by dealing with code in a not-fully-compiled intermediate format. The intermediate code is linked, inlined, and generally mucked about. Then, after linking, a final code generation step produces the final output code from the linked intermediate code. Such an approach is a huge win for languages like C++, because you can inline methods from a library into your program and other nice things.
Ooops... I did it again. The TCP stream was repackaged into IP packets.
Oh bother. My IP packets were repackaged into ATM frames on the backbone.
*sigh*
Time to start wiring up the direct serial link from my dumb-terminal to their database. Oh wait, that won't work. The serial port will repackage the bytes by inserting parity and stop bits.
Slashdot Mirror
Folks, in the interest of injecting some FACTS in the discussion, here's my analysis of what the hack does. It merely generates a URL of the following form, where all of the non-italicised text can remain constant:
http://207.82.250.251/cgi-bin/start?curmbox=ACTIVIn other words, the view/edit mailbox functionality appears to not check the password field, plain and simple. It's just plain bad CGI programming, not an OS or webserver issue.
--Joe--
Look at table 4, and you'll see he's getting the extra combinations from the subnet bits. He's seems to be operating under the delusional assumption that the subnet mask somehow floats alongside the IP address. Combine that with his delusional ramblings about decimal vs. binary vs. hexadecimal. (Dude, those are just representations, just like 90 degrees is PI/2 radians is a right angle! I could write the numbers in octal if I wanted to and it wouldn't change their values.)
The reality, of course, is that we can get at most 2**32 (~4.3 billion) globally unique addresses if we completely remove any artificial partitioning and special encodings that would use up encoding space. This guys "mathematical proof" reads like some of those "random data compression" patents that Jean-loup Gailly (of Info-Zip/ZLib fame) likes to discredit on his homepage.
Of course, having partitions and special values does simplify things alot, which is why we don't get all ~4.3Billion addresses. Just look at RISC computers which use a 32-bit opcode. They sure as heck don't implement 4 billion different instructions.
--Joe--
Three words come to mind: HIT, NAIL, and HEAD. :-)
To give an example from a paper I'm a coauthor on (being presented at ICSPAT'99), consider a JPEG decoder. Here's a quick overview of the bulk of a JPEG decoder:
On a deeply pipelined / highly parallel processor, this is horribly inefficient, because each task is very small when applied to only one block, whereas switching between tasks is quite expensive. But, that's exactly what alot of JPEG decoders do (including the Independent JPEG Group's decoder). The decoder is alot easier to write that way, but is not nearly as efficient as it could be.
Instead, you want to batch things up as much as possible:
Now, you can make massive gains in efficiency due to better instruction cache locality, better parallelism across loop iterations due to the fact you're actually looping quite a bit now, and so on. (The wins are rather dramatic on a DSP which relies on programmed DMAs to move data on and off chip.)
What's nice about a system with parallel processing units (whether multiprocessor or multithreaded) is that each stage in the pipeline can become another parallel-executing thread. Indeed, that was one common way to program the TMS320C80 family DSPs, which had 2 or 4 DSPs on one chip, alongside a fairly strong RISC CPU ... all on one die! The DSPs would be organized as a pipeline, communicating through a "crossbar" to shared on-chip SRAM. The RISC CPU would coordinate tasks and issue commands to the DSPs. It was really quite cool.
--Joe--
Not flaming, just explaining:
For an even number of samples, the median is the arithmetic average of the middle two samples in a sorted list. For an odd number of samples, the median is the middle value in the sorted list.
So, in this case, the median is 50.
The mode is the most commonly occuring value in the list. Again, this is 50.
--Joe--
Yes, there are geek girls. This particular one carries quite an impressive resume: I started Carnegie Mellon University in Electrical and Computer Engineering with a double major in Cognitive Science. My final degree, though, is in Mathematics, with a concentration in Biomedical Engineering. In December 1995, I received a Ph.D. in the field of Neuroscience from Northwestern University. My thesis is entilted ``The Role of the Plant Properties in Point-to-Point Arm Movements: A Neural Network Approach''
I'm pretty fortunate myself. My fiancee is into computers (and likes to sysadmin, too), although she's a Geology major. (I'm an EE myself, but honestly, I'm really just a software jock. The last hardware I built used 7400-series TTL.) You can look outside your major and outside your career, you know. Just remember, if you're not looking, you won't find anything, and if you're looking but not finding, you need to change your search space or your search criterion!
--Joe--
Heh... of course it's different, as long as you're coding for yourself!
When I'm not busy programming for work, or *ahem* socializing *ahem* with my fiancee, I'm usually writing my own software. Right now, I'm developing an Intellivision emulator for Linux. :-)
(That is, as soon as I unpack the computer. We just moved into a bigger place so that we can move the computers out of the bedroom and have more room for both computer and bedroom fun.... ;-) )
--Joe--
Please pardon my bout of mental flatulence.
LATEST-IS-1.2.13
--Joe
--
I said:
*sigh* Yet another person who regrets his childhood rather than revelling in it. Bad memories, eh? I bet coworkers don't bother passing around the joke sheets to you, fearing you'll grumble something about "having work to do, don't have time for such nonesense." Remember that when you have a major coronary due to cumulative stress at the age of 45.
I'm quite happy to proudly proclaim my allegiance to Weird Al. While songs such as Albuquerque are little more than a (fun) stage for really bizarre jokes, songs such as Germs have more subtle messages interleaved in the obvious humor. Even his polkas and their arrangements make a message, at least about the songs being paranoid. (For instance, how about Intergalactic and Ray of Light in Polka Power?)
I have to admit, I personally treat Dare To Be Stupid as a personal anthem of sorts, for two reasons: For one, it savagely pokes fun at the commercialism and common sensibility of our day (eg. "Buy some sensible shoes and a Chevrolet", or perhaps "It's like they say you gotta buy one if you wanna get one free."). For another thing, the title says it all -- you don't always have to be smart, at least not in the conventional sense. You should dare to be stupid, which I interpret to mean (according to the subtle sarcasm of the song) challenge the norms. Dare To Be Stupid presents a very deep, right-brain-centric message that also permeates his work. Anyone who deeply appreciates Dave Barry's or Michael Abrash's works should be able to see this nearly immediately.
And on a separate note...
--JoeI have way to much class to let this thread linger.
Come over here and pull on my finger...
(With apologies to Weird Al on the paraphrased lyrics.)
--
I suggest you take the cotton out of your ears and listen a little closer... After all, what's so formulaic about dental hygentists with spatulas tatooed on their arms, alongside a BIG BOWL OF SOUR KRAUT?
--Joe--
While the "Eddie Vedder" song isn't exactly as masterful as, say, Dare To Be Stupid, you've gotta admit that Albuquerque is one of Al's greatest accomplishments on Running With Scissors .
--JoePS. There's a data track too...
--
There will always be bugs. There's no avoiding that.
For now, Alan Cox is maintaining 2.0.xx, and it appears (from what I saw on Kernel Traffic) that he is/will be responsible for future 2.2.xx releases as well. Progress continues to be made on cleaning up the remaining nasties in 2.2, and 2.2.11 should be available sometime soon. (I'm guessing by the end of August.) Alan stated (and I'm paraphrasing heavily here) at the introduction of 2.2 that people who are happy with 2.0.3x shouldn't feel any overwhelming need to upgrade right away, and that they wouldn't be left out in the cold. I'm sure a similar sentiment holds for 2.2.
IMHO, Linux 2.2.0 was far from perfect, but I must say that 2.2.10 seems to be far closer to "stable" than 2.0.10 was. In many ways, the stability and progress of 2.2 remind me of Linux 1.2 much more than it does of 2.0, which I believe is a very good thing. 2.0 took almost 30 revisions before it was truly stable, and it may even make it to 2.0.40 (although that's unlikely now).
I think we can expect to see a number of bug fixes for awhile to come, perhaps with some well after 2.4.0 debuts. After all, 1.0.9 came out partway into the 1.2 series, and you have a similar story for 1.2.15 vs. 2.0.x and 2.0.37 vs. 2.2.x....
--Joe--
Don't forget, the last day of fall is Dec 20th. I'm guessing that this is mainly a call to get people serious about closing on 2.4, and it's easier to be serious if you're at least somewhat serious about a deadline. In this case, Linus is trying to give us 2.4 as an early Christmas present, it would appear (even though he hasn't come out and said so).
I'm sure that the kernel will go out when it's ready, and no sooner. Nonetheless, it's good to state some goals up-front, and a "limited development cycle" goal for 2.4 is probably a good idea. Saying "feature freeze" and "2.4 in the fall" at least gets people starting to think in that manner, rather than leaving it open-ended and sprawling, as it happened with Linux 2.2.
(Personally, I feel 2.0 should've been 1.4, and 2.2 should've been 2.0, in retrospect. At least the numbering, relative amounts of features and release dates are more consistent that way. Ahhh well....)
--Joe--
I could make a lewd comment about rock-solid releases here, but I won't....
--Joe--
When the CPU is halted (HLT instruction), it burns very little power while it waits for an interrupt to wake it back up again. When the CPU is not halted, it burns a fair amount of juice.
Linux (and I hear NT) execute a HLT whenever the ready queue is empty. Win9X sits in a busy loop.
Ergo, CPU power consumption (and therefore temperature) is a function of system loading in OSes which halt the CPU (Linux, NT), and not on OSes which don't halt the CPU (Win9x).
--Joe--
You mentioned the following:
For a perfect software modem, yes, this is true. But for a simple software modem, there are many things you can do to be "good enough", including the following:
After all, Win9x has the same problems as Linux does in this regards (eg. no guaranteed hard-real-time scheduling), yet software modems seem to function passibly in such an environment. If anything, Linux would probably do better than Win9x at this same task. In any case, missing a real-time deadline with a soft-modem would look like lag to the end user and little else. Annoying, but not fatal.
Now, I'm not running out and signing up to buy a soft modem (particularly since I'm about to get DSL service, obviating the need for a POTS modem almost entirely), but there are some interesting ideas that could make LinModems popular, depending on how open PC-Tel is.
- Software modem lights that actually work. (The ones I've seen in the past were worthless for actually diagnosing modem troubles. Eye candy at best.)
- Real-time modem connection quality statistics, such as number of retrains, current symbol rate, etc... perhaps via an entry in
/proc. The more detail, the better. - General on-the-fly control of modem parameters, such as explicitly requesting fallback/fallforward. For instance, lower symbol rates tend to work alot better for interactive sessions since latency is lower, but higher symbol rates tend to be better for downloading. You could actually request the modem to fall forward or fall backwards by signalling the driver directly. You can't really do that with an external modem.
--Joe--
Very good point. Let's not forget it.
Basically, for each of the M versions of P that might exist, there needs to be some amount of leadership leading the development of that version of P. Where open source wins is that there's no corporate structure dictating who the leaders are. Rather, much like ducks do when flying in formation, whoever has the most energy leads the wedge, and as one tires, another from the pack leads. And if one duck is particularly eager, he's welcome to start his own formation, but there's always the existing bias not to which keeps things at least somewhat clustered.
--Joe--
The address, data, and command lines can all be multiplexed on a single 64-bit wide bus. Recall that most transfers onto and off of the chip are going to be cache-line fills. Folks, these addresses are adjacent. You only need to know the starting address to know where the entire burst of data goes.
What this means is that you can put out a single "Address With Command" on the bus, followed by a burst of N data items. You've lengthened the transfer by 1 cycle for N items. Suddenly, you've cut your number of lines per CPU port from 128 to 64, and your performance is (N + k) / (N + k + 1), where N is the number of items, and k is the overhead occurred just by initiating a bus access. All in all, the "+ 1" looks pretty tiny, doesn't it?
Besides, ever hear of "pipeline burst cache" for L2?
--Joe--
Suppose Processor A is a producer and Processor B is a consumer. The only way they can communicate is via shared memory, unless, like a transputer, you have some other explicit CPU-to-CPU communication mechanism.
What happens is that Processor A ends up caching up a whole bunch of data that Processor B needs. The way Processor B ends up getting it is by accessing external memory, triggering Processor A to do its cache writebacks, and in the meantime stalling both Processor A and B.
Ick.
So, while the whole process is transparent to the programmer (at least insofar as the entire memory map is coherent, regardless of what CPU you're on), the whole cache-snooping business can kill performance.
For decent SMP performance in this scenario, Processor A really needs to manually flush the portions of its cache that Processor B needs (or instead use write-through, rather than write-back, in which case cache invalidation is all that is necessary). Since you're explicitly manipulating the cache, you're no longer transparent.
(Or, if you're a DSP or some other device with onchip SRAM instead-of/in-addition-to cache, you just DMA all the data where it needs to be in the background, and keep processing without missing a beat... :-) ) --Joe
--
You're talking past each other here.
Of course.
But, the real issue is whether copying bits ever constitutes theft. When I buy a hard-disk, I physically own all of the bits on that drive. Is it theft if I change their states such that they correspond to the music of a given song?
Besides, see the other posts on here by actual musicians who welcome the arrival of cheap redistribution outside of the shadow of the recording industry. If it were stealing, who would you be stealing from if the artists themselves are happy to let you have it?
--Joe--
For most volume CD's, the cost of producing the contents of the CD is fairly small per CD, I'd imagine.
--Joe--
Hmmm... if they change processor platforms, Intel... If they change desktops, KDE... and then if they change back to their original processor platform, Motorola...
--
You mean there's a multiuser mode?
--Joe--
Not quite. In AR-style static libraries (the good old .a files) the linking granularity is object file level. (eg. the .o file level) with traditional linkers.
There are linkers which work at much finer granularity these days. Some work by dealing with code in a not-fully-compiled intermediate format. The intermediate code is linked, inlined, and generally mucked about. Then, after linking, a final code generation step produces the final output code from the linked intermediate code. Such an approach is a huge win for languages like C++, because you can inline methods from a library into your program and other nice things.
Not that I'm switching to C++ anytime soon.
--Joe--
Ooops... I repackaged the query in a TCP stream.
Ooops... I did it again. The TCP stream was repackaged into IP packets.
Oh bother. My IP packets were repackaged into ATM frames on the backbone.
*sigh*
Time to start wiring up the direct serial link from my dumb-terminal to their database. Oh wait, that won't work. The serial port will repackage the bytes by inserting parity and stop bits.
Aw, hell, I'll go grab the yellow pages instead.
--Joe--