Because the screen real estate and keystrokes consumed by an item should somehow be related to how much information content it has?
Compare and contrast:
MoveImmediately #1, R1
MoveImmediately #3, R2
MVI #1, R1
MVI #3, R2
R1 = 1;
R2 = 3;
Of the two mnemonic-assembly examples, which most closely resembles what you might write in any other context (i.e. the third example?) Hmmm. Maybe the same reason you write "a + b" rather than "perform_addition(a, b)" and most people use
i, j, k for index variables instead of "array_index". (Though there are exceptions to the latter, and those people quite frankly are nutty.):-)
Err... I think you mean 8, with four threads per core. To the OS it looks like a 32-way machine on one chip. It's Intel that has been in the news again recently about its 80-core research chip. And then there's those GPUs with 128 cores on them that you can program in C.
Oh, believe me, on more capable assemblers for larger architectures, I do that sort of thing. I use symbolic names when possible. Here's a dot product kernel more along the lines of what I write when I'm writing for a "big" machine.
For this tiny, ancient machine, the assembler is a hold-over from 16-bit DOS. You could almost call it a toy assembler. There are only 6 general purpose registers, and they're not *quite* general purpose. Shift instructions only work with R0-R3, indirect addressing only works on R1 - R5, with R4 and R5 auto-incrementing. JSR return addresses can only go in R4, R5 or R6. (I don't count R6 as a general purpose register as it is the stack pointer, though most instructions can operate on it.)
My point is, for a tiny machine, it only works against you to name your registers symbolically. Imagine doing this for the 6502, which has one accumulator, A, and two index registers, X and Y. In fact, the register name is built into the opcode.
Oh, and I do use labels. I don't hard-code offsets unless it's called for.:-P
And it's saved me and others countless time, I'm certain. When it comes to C code I comment similarly to how the article suggests. It's fairly obvious. For example, consider this code. There's some tricky stuff involved in correctly emulating the controller inputs for the Intellivision, and the bulk of the comments revolve around explaining the trickiness.
That said, when I code assembly language, I tend to comment nearly every line. Why? Unlike C code, most assembly statements aren't very descriptive. For instance, "MVI@ R4, R0" means "read whatever R4 points to into R0." Ok, but what might R4 be pointing to? What kind of thing are you reading? What are you trying to accomplish? Imagine if you wrote your C code so that all pointers were named p and q, and all other variables were named i, j, k, a, b, and c. That's what assembly's often like. So, I use short per-line comments (or sometimes per group-of-lines comments) to add that missing information. Here's an example from Space Patrol. (In this particular example I also was counting cycles, due to the performance critical nature of the code. That's an entirely different story.)
All I can say is that comments like these have saved my ass more than once.
I actually have two 48GB databases full of minimal instruction sequences for generating boolean functions. Do I win the obscure use of disk space prize?
The motivation for security should be with each of the people who handle the data. This includes the end merchant. If the merchant can't deal w/ CC#s securely, then they shouldn't. If enough vendors throw their hands up and say "This can't be workable," then VISA, MC and friends will figure something out. It's that simple.
Fraudulent chargebacks are like fraudulent charges. They need to be dealt with. I don't disagree on this point. Someone is going to try to abuse the system.
This is why I like per-transaction ID #s. If you need to authenticate yourself to VISA, MC or whomever to get a per-transaction ID, then the responsibility clearly lies w/ the party granting the ID. At that point, they can take whatever precautions they feel are necessary to prove, beyond a reasonable doubt, that the person spending the money is authorized to do so by the cardholder.
Until we get to that point, though, every link in the chain carrying card numbers needs to be "sufficiently strong." It makes sense to penalize the weakest links. Heck, if a particular card holder seems to be an unusually high target of fraud, penalize them because either they're the fraudster, or they have really bad habits.
Consumer protection laws have some effect here. Already we make credit card companies liable for everything beyond the first $50 of fraud. In the end they pass that back onto the customer as increased rates/fees, or to vendors through chargebacks. To some extent, chargebacks are a good thing: They put motivation on vendors to not accept fraudulent transactions. The downside is that they provide little motivation to the CC companies to assist in stamping out identity theft.
Still, I think part of the problem is lack of foresight on the part of the card companies. If a CC company can offer lower rates and higher profits by proactively weeding out fraud, it's in their best interest to do so. Right now, I wouldn't be surprised if there isn't some push-back within the CC companies' own fraud units to avoid another level of automation that might make them irrelevant, or at least less relevant.
I suspect if interest rates start going up, we might see some more pressure for card companies to cut costs to keep their rates manageable. Right now, with all the liquidity out there, money's cheap, so it's easier to waste it.
Personally, I'd love to simply have disposable credit card numbers. Give me a per-transaction or even per-vendor card #. (Per-vendor isn't *quite* as good, but better than a raw # because it can only be used with that vendor.) We should be able to do this by now.
The credit card companies are big enough, why can't they instead work out a special program with each of the search engine vendors? That is, whenever the search engine crawler detects a page that appears to have credit card numbers, why not have it push this information to the credit card companies? It could even sort by number range, so that AMEX only get AMEX numbers, Master Card only gets MC numbers, Visa only gets Visa, and so on. Each CC company would get the list of potential card #s along with the URLs where they were spotted. The URL information could be used for prosecution purposes, as well as identifying what merchants etc. are leaking card data.
Obviously, the CC vendors would have to pay a fee, but isn't that cheaper than the rampant credit card fraud they have to deal with? Its price could be comparable to the cost of the proposed scanning hack, but the results would be higher quality and would put less of a load on the search engines.
Granted, this is a mitigation strategy, not a solution. But to me it's like eating well and exercising in addition to having doctors and hospitals. You need both proactive and reactive strategies.
I'm dissatisfied with Windows, because I work more like UNIX / Linux does. I could do without quite a bit of this desktop-oriented stuff. It just gets in my way, and it assumes I want a machine that works more like a Windows or Mac machine. No thanks. (And damn it, STOP STEALING MY KEYBOARD FOCUS! Sorry. Ahem.)
I see only a couple main benefits to me coming from Linux's recent desktop focus:
Getting a critical mass of users so that vendors produce hardware and software we can use.
Simplifying installation and package management. After all, I care more about the software I'm running than how it gets installed. (Sit on your hands for this one, Gentoo.)
More users == more testing == hopefully fewer bugs.
I'm not a big fan of many of the "usability" changes GNOME has made in the name of "desktop users." It seems that "desktop user" means "someone who just gets by in Windows." For instance, it always annoyed me that pop-ups stole keyboard focus in MS Windows. I finally found a way to disable them there. Why did GNOME (a) copy that crappy behavior, and (b) not give me a way to disable it? It'd be less annoying if GAIM and various package managers didn't pop up all these silly keyboard-focus-stealing dialog boxes whenever they're doing stuff automagically in the background. (Ok, as antidote to those who might say "Oh, that's fixed in x.yy!" Well, I'm on Ubuntu 6.06 LTS. LTS == Long Term Support. I am actually happy to upgrade less than once every 6 months. I guess I lean more towards UNIX than Linux on that point?)
I don't think they're talking about dropping 32-bit app support. That would be suicide. They're just dropping the ability to boot the OS on 32-bit machines. x86-64 machines can run 32-bit binaries while in 64-bit mode. They just can't run 16-bit binaries.
By the time Vista's successor comes out, 64-bit x86 processors will have been on the market about 10 years, I'm guessing. That's about the same length of time as we saw between the introduction of the 386 (1985) and Windows 95.
The problem is that any coordinated effort will also likely have a single point of failure.
--Joe
Re:Here's how it works from another perspective
on
How Image Spam Works
·
· Score: 4, Insightful
I once made a calculation that if every person on the Internet responded positively to precisely one spam, that would be enough to make spam wildly profitable. Granted, that was a few years ago, but bandwidth (and therefore spam) has only gotten cheaper and bot nets more prevalent (making spam cheaper still).
You don't have to go too far down the left tail of the bell curve to make up for the folks on the right half. After all, in terms of positive response, the best the folks in the right half can do is respond positively to zero spams. The further you go into the left tail, the more likely you are to run into people who respond positively to spam on a somewhat regular basis. The cut-over line for "responds to spam" vs "does not respond to spam" can be pretty far into the left tail and still have spam be profitable.
Making matters worse, negative responses to spam rarely do anything to the spammer. Instead, they just annoy IT departments into implementing ever heavier spam filters. Every so often somebody gets sued, but it's hardly enough to make a real dent in things.
Ok, this article inspired me to go find a copy of "Macho, Macho Duck". I couldn't find an MP3 to download (but if someone has a link, please share). BUT, what I found along the way is not only relevant, but hilarious! The Torture Tape Experiment. Basically, the goal is to make a mix tape so awful, it drives your opponent mad. You and your opponent prepare tapes for each other, trade, listen and weep.
Now, if this isn't something that digs at the "angry face" response, I don't know what is. Imagine going all day, listening to these tracks, going insane, bolstered only by the comforting—nay, rewarding—thought of what you're doing to your opponent? Yeah.
Oh, and I should add, as you add more processes, you spend more time context switching and you pollute the caches more, so it's a tradeoff. That's why performance falls as you go to higher and higher parallelism. At very high parallelism, you can go off a cliff if you exceed the available system RAM. That's why kernel devs like to do "make -j" on the kernel as a VM stress test.
Happy to. At various points, one or more of the processes will be blocked in I/O. With N+1 tasks running, there's a higher likelihood that all N CPUs will be busy, despite the occasional I/O waits in individual processes. With only N tasks running, an I/O wait directly translates into an idle CPU during that period.
Prevailing wisdom and personal experience suggest using "-j N+1" for N CPUs. I have a 4 CPU setup at home (dual dual-core Opterons). Here's are approximate compile times for jzIntv + SDK-1600, which altogether comprise about 80,000 lines of source:
-j4: 6.72 seconds
-j5: 6.55 seconds
-j6: 6.58 seconds
-j7: 6.59 seconds
-j8: 6.69 seconds
Now keep in mind, everything was in cache, so disk activity didn't factor in much at all. But, for a typical disk, I imagine the difference between N+1 and N+2 to be largely a wash. N+1 seems to be the sweet spot if the build isn't competing with anything else. Larger increments might make sense if the build is competing with other tasks (large background batch jobs) or highly latent disks (NFS, etc). But for a local build on a personal workstation? N+1.
Well, it's not prime in the sense usually understood by people who've just taken a traditional algebra/calculus sequence. CRCs operate within a finite field, and if you've never taken a course that touched on field arithmetic, you won't have a clue as to what a "generator polynomial" is and so on. I never encountered any of these things in any math course I've taken, and basically had to teach myself this stuff.
I just read through the article, and maybe someone here from/. cleaned it up. It seemed mostly fine to me, although more could have been moved out of this article and into the mathematics of CRCs article. (Not going to bother to look at the edit log.)
Before I start, I pretty much agree with you, and would like to throw my 2 cents into the ring.
Science and math are hard, which is precisely why you shouldn't throw unnecessary roadblocks up on the path to understanding.
For instance, I sometimes have to look up some mathematical construct for whatever reason. If I find it on Wikipedia, many times the entire article is fairly short and laden with a bunch of mathematical symbology. While all that may be obvious to a mathmetician, it's entirely a foreign language to me. I came to the English language Wikipedia. Would it hurt to describe topics in English rather than compress whole paragraphs down to 3 symbols I haven't seen in 10 years?
This is quite different than writing brain-candy documentaries such as the ones you complain about. Those are just sensationalistic pablum using science as a backdrop.
As for your comment:
Think about it: in an article on modern file systems or database design, do you *really* want to delve into the finer aspects of sorting algorithms?
That's what factorization is for. None of that information should be in-line in a filesystem article, but if you really wanted to cover the topic competently, you ought to link to articles on relevant classes of data structures and algorithms. For instance, it makes no sense to define and describe B* trees (such as HFS uses) in the article, but it makes complete sense to mention that on-disk directory structures include various tree structures. It might also make sense to include a survey table of popular filesystems and structures they use. Or, even save that for filesystem-specific articles.
As Wikipedia is more a reference than a textbook, it doesn't make sense for it to try to teach algorithm design, but it does make sense for it to compare the merits of various sorting algorithms at a high level, and perhaps compare the cost of various actions on a sorted data structure (key insert, key removal, etc.).
As an engineer, I often have to explain complex topics to people who are highly technical, but not experts in the specific area I'm operating in. For example, many people are competent programmers, but not experts on the specific nomenclature and behavior of a cache hierarchy. A competent programmer in most cases only needs to know to keep their working set "small enough for the cache," and not, for example, the difference between an inclusive vs. exclusive cache hierarchy or the difference between an LRU and Pseudo-LRU replacement policy. But, if I'm writing a comprehensive reference (or worse, writing a useful errata description), I sometimes need to convey these concepts to interested non-experts. Is it better for me to explain it with a terse equation, or with a couple paragraphs of standard English that goes light on the jargon? The complaint is that Wikipedia often tends towards the former.
This particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.
I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)
Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)
Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.
Presumably, the act of submitting an article is a tacit vote for the article. Then again, mental illness seems slightly over represented in the Slashdot community at times...
Slashdot Mirror
Because the screen real estate and keystrokes consumed by an item should somehow be related to how much information content it has? Compare and contrast:
MoveImmediately #1, R1
MoveImmediately #3, R2
MVI #1, R1
MVI #3, R2
R1 = 1;
R2 = 3;
Of the two mnemonic-assembly examples, which most closely resembles what you might write in any other context (i.e. the third example?) Hmmm. Maybe the same reason you write "a + b" rather than "perform_addition(a, b)" and most people use i, j, k for index variables instead of "array_index". (Though there are exceptions to the latter, and those people quite frankly are nutty.) :-)
You forgot the fraction of a human hair's width it'll fit in...
Err... I think you mean 8, with four threads per core. To the OS it looks like a 32-way machine on one chip. It's Intel that has been in the news again recently about its 80-core research chip. And then there's those GPUs with 128 cores on them that you can program in C.
Oh, believe me, on more capable assemblers for larger architectures, I do that sort of thing. I use symbolic names when possible. Here's a dot product kernel more along the lines of what I write when I'm writing for a "big" machine.
For this tiny, ancient machine, the assembler is a hold-over from 16-bit DOS. You could almost call it a toy assembler. There are only 6 general purpose registers, and they're not *quite* general purpose. Shift instructions only work with R0-R3, indirect addressing only works on R1 - R5, with R4 and R5 auto-incrementing. JSR return addresses can only go in R4, R5 or R6. (I don't count R6 as a general purpose register as it is the stack pointer, though most instructions can operate on it.)
My point is, for a tiny machine, it only works against you to name your registers symbolically. Imagine doing this for the 6502, which has one accumulator, A, and two index registers, X and Y. In fact, the register name is built into the opcode.
Oh, and I do use labels. I don't hard-code offsets unless it's called for. :-P
--JoeAnd it's saved me and others countless time, I'm certain. When it comes to C code I comment similarly to how the article suggests. It's fairly obvious. For example, consider this code. There's some tricky stuff involved in correctly emulating the controller inputs for the Intellivision, and the bulk of the comments revolve around explaining the trickiness.
That said, when I code assembly language, I tend to comment nearly every line. Why? Unlike C code, most assembly statements aren't very descriptive. For instance, "MVI@ R4, R0" means "read whatever R4 points to into R0." Ok, but what might R4 be pointing to? What kind of thing are you reading? What are you trying to accomplish? Imagine if you wrote your C code so that all pointers were named p and q, and all other variables were named i, j, k, a, b, and c. That's what assembly's often like. So, I use short per-line comments (or sometimes per group-of-lines comments) to add that missing information. Here's an example from Space Patrol. (In this particular example I also was counting cycles, due to the performance critical nature of the code. That's an entirely different story.)
All I can say is that comments like these have saved my ass more than once.
--JoeI actually have two 48GB databases full of minimal instruction sequences for generating boolean functions. Do I win the obscure use of disk space prize?
The motivation for security should be with each of the people who handle the data. This includes the end merchant. If the merchant can't deal w/ CC#s securely, then they shouldn't. If enough vendors throw their hands up and say "This can't be workable," then VISA, MC and friends will figure something out. It's that simple.
Fraudulent chargebacks are like fraudulent charges. They need to be dealt with. I don't disagree on this point. Someone is going to try to abuse the system.
This is why I like per-transaction ID #s. If you need to authenticate yourself to VISA, MC or whomever to get a per-transaction ID, then the responsibility clearly lies w/ the party granting the ID. At that point, they can take whatever precautions they feel are necessary to prove, beyond a reasonable doubt, that the person spending the money is authorized to do so by the cardholder.
Until we get to that point, though, every link in the chain carrying card numbers needs to be "sufficiently strong." It makes sense to penalize the weakest links. Heck, if a particular card holder seems to be an unusually high target of fraud, penalize them because either they're the fraudster, or they have really bad habits.
--JoeConsumer protection laws have some effect here. Already we make credit card companies liable for everything beyond the first $50 of fraud. In the end they pass that back onto the customer as increased rates/fees, or to vendors through chargebacks. To some extent, chargebacks are a good thing: They put motivation on vendors to not accept fraudulent transactions. The downside is that they provide little motivation to the CC companies to assist in stamping out identity theft.
Still, I think part of the problem is lack of foresight on the part of the card companies. If a CC company can offer lower rates and higher profits by proactively weeding out fraud, it's in their best interest to do so. Right now, I wouldn't be surprised if there isn't some push-back within the CC companies' own fraud units to avoid another level of automation that might make them irrelevant, or at least less relevant.
I suspect if interest rates start going up, we might see some more pressure for card companies to cut costs to keep their rates manageable. Right now, with all the liquidity out there, money's cheap, so it's easier to waste it.
Personally, I'd love to simply have disposable credit card numbers. Give me a per-transaction or even per-vendor card #. (Per-vendor isn't *quite* as good, but better than a raw # because it can only be used with that vendor.) We should be able to do this by now.
--JoeThe credit card companies are big enough, why can't they instead work out a special program with each of the search engine vendors? That is, whenever the search engine crawler detects a page that appears to have credit card numbers, why not have it push this information to the credit card companies? It could even sort by number range, so that AMEX only get AMEX numbers, Master Card only gets MC numbers, Visa only gets Visa, and so on. Each CC company would get the list of potential card #s along with the URLs where they were spotted. The URL information could be used for prosecution purposes, as well as identifying what merchants etc. are leaking card data.
Obviously, the CC vendors would have to pay a fee, but isn't that cheaper than the rampant credit card fraud they have to deal with? Its price could be comparable to the cost of the proposed scanning hack, but the results would be higher quality and would put less of a load on the search engines.
Granted, this is a mitigation strategy, not a solution. But to me it's like eating well and exercising in addition to having doctors and hospitals. You need both proactive and reactive strategies.
--JoeI'm dissatisfied with Windows, because I work more like UNIX / Linux does. I could do without quite a bit of this desktop-oriented stuff. It just gets in my way, and it assumes I want a machine that works more like a Windows or Mac machine. No thanks. (And damn it, STOP STEALING MY KEYBOARD FOCUS! Sorry. Ahem.)
I see only a couple main benefits to me coming from Linux's recent desktop focus:
I'm not a big fan of many of the "usability" changes GNOME has made in the name of "desktop users." It seems that "desktop user" means "someone who just gets by in Windows." For instance, it always annoyed me that pop-ups stole keyboard focus in MS Windows. I finally found a way to disable them there. Why did GNOME (a) copy that crappy behavior, and (b) not give me a way to disable it? It'd be less annoying if GAIM and various package managers didn't pop up all these silly keyboard-focus-stealing dialog boxes whenever they're doing stuff automagically in the background. (Ok, as antidote to those who might say "Oh, that's fixed in x.yy!" Well, I'm on Ubuntu 6.06 LTS. LTS == Long Term Support. I am actually happy to upgrade less than once every 6 months. I guess I lean more towards UNIX than Linux on that point?)
--JoeI don't think they're talking about dropping 32-bit app support. That would be suicide. They're just dropping the ability to boot the OS on 32-bit machines. x86-64 machines can run 32-bit binaries while in 64-bit mode. They just can't run 16-bit binaries.
By the time Vista's successor comes out, 64-bit x86 processors will have been on the market about 10 years, I'm guessing. That's about the same length of time as we saw between the introduction of the 386 (1985) and Windows 95.
--JoeHmmm... I wonder how it'd do against Intellivision Chess? :-)
Sounds like a familiar idea. Too bad it didn't work.
The problem is that any coordinated effort will also likely have a single point of failure.
--JoeI once made a calculation that if every person on the Internet responded positively to precisely one spam, that would be enough to make spam wildly profitable. Granted, that was a few years ago, but bandwidth (and therefore spam) has only gotten cheaper and bot nets more prevalent (making spam cheaper still).
You don't have to go too far down the left tail of the bell curve to make up for the folks on the right half. After all, in terms of positive response, the best the folks in the right half can do is respond positively to zero spams. The further you go into the left tail, the more likely you are to run into people who respond positively to spam on a somewhat regular basis. The cut-over line for "responds to spam" vs "does not respond to spam" can be pretty far into the left tail and still have spam be profitable.
Making matters worse, negative responses to spam rarely do anything to the spammer. Instead, they just annoy IT departments into implementing ever heavier spam filters. Every so often somebody gets sued, but it's hardly enough to make a real dent in things.
Hmmm... I found a copy of the DDR version of the track. That's enough for me for now.
Ok, this article inspired me to go find a copy of "Macho, Macho Duck". I couldn't find an MP3 to download (but if someone has a link, please share). BUT, what I found along the way is not only relevant, but hilarious! The Torture Tape Experiment. Basically, the goal is to make a mix tape so awful, it drives your opponent mad. You and your opponent prepare tapes for each other, trade, listen and weep.
Now, if this isn't something that digs at the "angry face" response, I don't know what is. Imagine going all day, listening to these tracks, going insane, bolstered only by the comforting—nay, rewarding—thought of what you're doing to your opponent? Yeah.
--JoeJust when I start to feel old, folks like you make me feel young again. ;-)
Oh, and I should add, as you add more processes, you spend more time context switching and you pollute the caches more, so it's a tradeoff. That's why performance falls as you go to higher and higher parallelism. At very high parallelism, you can go off a cliff if you exceed the available system RAM. That's why kernel devs like to do "make -j" on the kernel as a VM stress test.
--JoeHappy to. At various points, one or more of the processes will be blocked in I/O. With N+1 tasks running, there's a higher likelihood that all N CPUs will be busy, despite the occasional I/O waits in individual processes. With only N tasks running, an I/O wait directly translates into an idle CPU during that period.
--JoePrevailing wisdom and personal experience suggest using "-j N+1" for N CPUs. I have a 4 CPU setup at home (dual dual-core Opterons). Here's are approximate compile times for jzIntv + SDK-1600, which altogether comprise about 80,000 lines of source:
Now keep in mind, everything was in cache, so disk activity didn't factor in much at all. But, for a typical disk, I imagine the difference between N+1 and N+2 to be largely a wash. N+1 seems to be the sweet spot if the build isn't competing with anything else. Larger increments might make sense if the build is competing with other tasks (large background batch jobs) or highly latent disks (NFS, etc). But for a local build on a personal workstation? N+1.
--JoeWell, it's not prime in the sense usually understood by people who've just taken a traditional algebra/calculus sequence. CRCs operate within a finite field, and if you've never taken a course that touched on field arithmetic, you won't have a clue as to what a "generator polynomial" is and so on. I never encountered any of these things in any math course I've taken, and basically had to teach myself this stuff.
I just read through the article, and maybe someone here from /. cleaned it up. It seemed mostly fine to me, although more could have been moved out of this article and into the mathematics of CRCs article. (Not going to bother to look at the edit log.)
--JoeBefore I start, I pretty much agree with you, and would like to throw my 2 cents into the ring.
Science and math are hard, which is precisely why you shouldn't throw unnecessary roadblocks up on the path to understanding.
For instance, I sometimes have to look up some mathematical construct for whatever reason. If I find it on Wikipedia, many times the entire article is fairly short and laden with a bunch of mathematical symbology. While all that may be obvious to a mathmetician, it's entirely a foreign language to me. I came to the English language Wikipedia. Would it hurt to describe topics in English rather than compress whole paragraphs down to 3 symbols I haven't seen in 10 years?
This is quite different than writing brain-candy documentaries such as the ones you complain about. Those are just sensationalistic pablum using science as a backdrop.
As for your comment:
That's what factorization is for. None of that information should be in-line in a filesystem article, but if you really wanted to cover the topic competently, you ought to link to articles on relevant classes of data structures and algorithms. For instance, it makes no sense to define and describe B* trees (such as HFS uses) in the article, but it makes complete sense to mention that on-disk directory structures include various tree structures. It might also make sense to include a survey table of popular filesystems and structures they use. Or, even save that for filesystem-specific articles.
As Wikipedia is more a reference than a textbook, it doesn't make sense for it to try to teach algorithm design, but it does make sense for it to compare the merits of various sorting algorithms at a high level, and perhaps compare the cost of various actions on a sorted data structure (key insert, key removal, etc.).
As an engineer, I often have to explain complex topics to people who are highly technical, but not experts in the specific area I'm operating in. For example, many people are competent programmers, but not experts on the specific nomenclature and behavior of a cache hierarchy. A competent programmer in most cases only needs to know to keep their working set "small enough for the cache," and not, for example, the difference between an inclusive vs. exclusive cache hierarchy or the difference between an LRU and Pseudo-LRU replacement policy. But, if I'm writing a comprehensive reference (or worse, writing a useful errata description), I sometimes need to convey these concepts to interested non-experts. Is it better for me to explain it with a terse equation, or with a couple paragraphs of standard English that goes light on the jargon? The complaint is that Wikipedia often tends towards the former.
--JoeThis particular patent looks to be a rather unusual and somewhat odd way to implement breakpoints. You put the breakpoints in at compile-time as function calls to an empty function, and then the debugger (if it's running) puts a trap in that empty function. The technique isn't too far, though, from some ancient and well known techniques.
I once implemented a debug monitor in a similar manner: Call a magic location. If the monitor's present, see if the host wants anything. If the monitor's not present, it's a NOP. Similar concept. In my case, though, I was implementing remote watch windows over a special parallel-cable link. The monitor request poll just lived in the idle loop. The test was cheap enough I actually left it in my production code. (Look for EC_POLL and friends.) The monitor itselfis pretty simple and kinda cool. (Source: INTV-side ASM and PC-side C code)
Prior to that, I had implemented a monitor for an 8052 board that used the "call-instruction-as-breakpoint" technique. If you wanted a breakpoint in a loop, you were advised to assemble NOPs or a call to the breakpoint function into your app, because the normal breakpoint clearing technique (replace the call with the original code) meant you couldn't hit the breakpoint more than once. The breakpoint design wasn't mine. I'm pretty sure every CPU board we had in the lab for the particular modular computer system we had used the same technique. (It was a custom system designed by our professors and implemented incrementally over the years by students.)
Methinks there's lots of prior art in this space. Even if EPSON's exact way of doing it wasn't previously widely known, it's close enough to other techniques that it brings the novelty and obviousness into question.
--JoePresumably, the act of submitting an article is a tacit vote for the article. Then again, mental illness seems slightly over represented in the Slashdot community at times...
--JoeAnd don't forget Open Source Resistance!
--Joe