Sometimes, it just takes a more approachable book with a shallower ramp to get your boat off the shore and sailing. I found the GoF book thicker than paste and more effective than a bottle of sleeping pills at putting me out for the night. A senior developer at my company then pointed me to some other books, such as Head First Design Patterns. It may've been a little on the goofy side, but it did present (most of) the patterns in a clear and motivated way.
Once I read through that book and largely "got it", I found the GoF book much more approachable and much more useful. I actually read the whole thing. It's not a starter book, though.
As for how I apply patterns, I apply them more like tools in a tool box. I have a problem with a particular shape, and I look for a tool (or tools) that fit that shape. For example, I needed to make a uni-processor program multi-processor while maintaining the fiction of uni-processor to the main program. The various threads' activities were already separate classes. The proxy pattern described an attractive way to replace a class with a stand-in that forwarded interaction to the remote processor, for example. The factory pattern offered a way to build these sets of remote objects from the main event loop on the remote processor. And so on.[*]
It wasn't like one of these competitive cooking shows where they hand you an ostrich egg, some plaintains, purple cabbage and some veal and ask you to whip up a creative dessert...
[*] You're probably thinking "ok, you're reinventing RPC/COM/CORBA/insert technology here, and probably poorly too. Why not use something off-the-shelf?" In case you're wondering, I wrote this to run on the "bare metal" (no OS) on a multiple CPU embedded processing chip. I didn't have the benefit of a more extensive framework, because whatever I write needs to run acceptably in a design simulator that runs veerrrrrrry slowly (on the order of 100 cycles/second), so every cycle counts. A framework with 1ms init time kills 10 hours of sim time to a first order of magnitude. And yet, I can make C++ and design patterns work for me in this environment.
I came here to say "Ok, so they discovered the JTAG port." Seems that blog was already on it.
Now, the researchers claim demonstrate that, via the JTAG port, they can subvert one form of Actel's AES security (but not all--see below) on someone's design to allow reverse-engineering a circuit design loaded into the FPGA. That's fairly interesting. I know that there's a fair bit of business in claiming an FPGA is invulnerable to such snooping, so that vendor A can ship a prototype design to customer B without worrying that customer B might rip off vendor A's design. For example, vendor A might ship an FPGA-based version of a chip they're designing to customer B, so they can design/debug their system while vendor A finishes the design, so both A and B can ramp their products more closely together.
Here's Actel's pitch on design security. The hack claims to expose the AES key for at least one of their encrypted modes, which implies that that particuler security feature is busted, and the guarantees against counterfeiting, reverse engineering and overbuilding it provides are also busted. According to the (occasionally somewhat breathless) claims in this draft paper, that is indeed what they've accomplished. Even then, they didn't break everything:
There are several security protection levels in the PA3 devices according to the manufacturer's datasheet [14]. The Passkey offers the highest level of reversible protection mechanism. Various DPA techniques were attempted to extract the Passkey, however, we were unable to get even a single bit in two weeks time using our off-the-shelf DPA equipment (oscilloscope with differential probe and PC with MatLab). The Passkey hardware security had robust countermeasures that proved to be DPA resistant. In addition to the unstable internal clock and high noise from other parts of the circuit, the Passkey access verification had its side-channel leakage reduced by a factor of 100. Only noise can be observed in the power traces without any characteristic peaks in the frequency domain. This was likely to be achieved through using a well compensated silicon design together with ultra-low-power transistors instead of standard CMOS library components. In addition, the useful leakage signal has a spread spectrum with no characteristic peaks in frequency domain, thus making narrow band filtering useless.
It'll be interesting to see how Actel responds.
As for "ZOMG, the Chinese can infect all our nukes! RUN!" that seems unlikely. To perform this analysis, you need to be able to isolate the FPGA and its bitstream in a circuit where you can observe all the pieces functioning together. This is trivial in the "vendor A / customer B" scenario above. It's not so easy to do without a specimen of the system you're trying to hack, though.
A tangentially related question: Has anyone gotten in trouble with violating their employer's Acceptable Use Policy due to browser preloading / precaching? Often, in search results or even certain news sites there are outbound links to places I'd never visit from work. But if Chrome (or even Firefox) is clicking those links behind my back, my IP address is in a corporate log somewhere as having "visited" that site, isn't it?
How are these preload/precache "hits" distinguished from normal hits? Obviously, if some of the sites are filtering these out, there's some way to tell them apart. At the same time, if the "hits" were noticeably different, there's always the chance the webserver would serve up different pages based on this difference.
Re:Most programs don't need a 64-bit address space
on
Linux 3.4 Released
·
· Score: 2
There are those much more famous than I who would disagree with you. (Scroll down to "A Flame...") Of course, appeal-to-authority is not a great way to argue a point that should be settled by data.
Some workloads are amazingly pointer heavy. Compilers and interpreters are very pointer heavy, for example. At least one SPEC benchmark sped up by over 30% in early testing. Then again, a couple others slowed down, which seems odd. I imagine we'll just have to see what happens as the compilers get tuned and so forth.
If you don't like x32, don't enable it on your system. I don't think it should be written off so easily, though.
Re:Most programs don't need a 64-bit address space
on
Linux 3.4 Released
·
· Score: 4, Interesting
Yes, but so what? A system that supports x32 should also support x86-64. So, if you're relying on ASLR for security purposes, compile those sensitive apps as x86-64.
Granted, the potential attack surface grows as you consider larger and larger threats. For example, a GCC compiled as x32 makes a fair bit of sense. What about Open/Libre Office? Well, that depends on if you open untrusted documents that might try to exploit OOo / LO. (Odds seem pretty low, though.) And what about Firefox? Far less to trust on the web...
So, at some point, you have to make a tradeoff between the marginal benefit of increased performance/better memory footprint in x32 mode vs. increased security against certain overflow attacks that ASLR offers. For most people in most situations, the former likely wins for anything with a decent memory footprint. For people building hardened Internet-facing servers, the latter probably wins.
And it made no sense in the original headline (which appears to have been corrected). It originally read "DreamHammer's Wants To Corner the Drone OS Market."
One fatal flaw in your exposition above: "-gate" wasn't used as a suffix adding onto something else in the case of "Watergate." The "Watergate scandal" was named after the Watergate hotel. It wasn't until sometime later someone decided to split apart Watergate and make "-gate" a suffix.
You realize that my settings have nothing to do with yours. I'm not Jonathan Corbet or anyone else associated with the site. I'm just another LWN subscriber.
But, since LWN added the comment filtering feature (that's what it's called in "My Account", at least -- go check it out), I imagine I'm not the only person who added Florian to the "filtered" list. (And I double checked, Florian is the only person in my filter set.) Enough people add Florian, and *poof*! No more oxygen for the flames.
Filtering doesn't completely hide the person. It just "folds" the threads that start at the filtered user's comment, so that they don't take up all the screen. You can still click to expand, not too much differently than here on Slashdot.
What I don't like about the ribbon is that there are many functions I used to use regularly that were always on screen. Now they're spread out across many different ribbon tabs, and sometimes where they ended up is non-intuitive for me. What used to be a simple click turns into an Easter egg hunt.
Perhaps if I used Office daily, I'd develop the appropriate muscle memory. But, I only use it a few times a month, and it's usually different apps -- this week it's Excel, next week it's PowerPoint.
I don't care if "zoom", "increase font size", "merge and center", and "fill with color" all belong on logically different tabs based on their function. For me, they all belong on the "I use this regularly" page.
I'm pretty sure Florian is the only LWN user I've ever marked as "hidden by default", simply because any branch of a thread that starts with one of his comments almost invariably turns into a trainwreck. It becomes a game of Immovable Object vs. the Irresistible Force.
What amazes me is that the broadcast model ever worked at all for something like Ceefax. Caching apparently made it even more practical, but still, the amount of bandwidth dedicated to the service is barely line noise compared to what's available today. By my calculations, it was managing over 600kbps in its final form (reading a spec from 2003), but it had to send the whole catalog repeatedly, so you had to wait for the useful bits to come by, limiting the total size of what Ceefax could offer.
So, if the modern day equivalent is loading more slowly and providing less, then it's due to a clear lack of caring at all about the service, I'd say than anything about the technology. There's more than enough bandwidth available, and you don't have to constantly replay all the content for everybody on the hopes that anybody would see it, like the broadcast model. You only have to serve it on demand.
I would go further: Thinking about the language of your project can be incredibly useful and clarifying. If you can boil down your problem's concepts into a consistent and fairly precise language, then you stand a better chance of implementing without too many thinkos.
Aligning that language with the business processes is definitely important, if your software is implementing business logic. Not all problems have a business process to align with. But, they have something they interface with, so try to be consistent with that (unless that thing is itself horribly inconsistent).
All that said, the strategy of the GP post of having consistent generic names (i/j/k for loop labels, etc) also has an important role. It makes it easier to identify the details that are not important. Consider array[array_index] vs. a[i]. The former takes a lot longer to read, but doesn't really convey any additional information for the effort. Conventional names for common actions allow you to filter away the noise, leaving you to focus on the actually novel bits.
How many of those programs had comments like this?
i++;/* add 1 to i */
People joke about such bad documentation, but I have actually been subjected to it in a professional environment. If I ever teach a programming class, I will give an automatic zero to such inanity.
It really depends on how many passes over the specs they made, and how separable the sections were. If you have to hold all 2500 pages in your head at the same time in order to spot deep inconsistencies, few (if any) humans will ever succeed. But, if the documentation was well segmented, such that you only needed to hold couple dozen pages of knowledge in your head at one time to understand a section, then you stand a chance, with sufficient reviews, to comb all the nits out.
I imagine there must be large portions of the spec just stating intended interactions with the other 420,000 lines of code. Even just stating the negative (ie. "no interaction with module X") for that much other code would take quite a few pages.
And, consider this quote from the article:
And money is not the critical constraint: the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations.
That's the real reason. Perfection in the software is the primary focus, cost be damned. Most projects live within less generous cost and time constraints. They can't afford a 2.5:1 code to spec ratio.
Also, I wonder about the nature of measuring the defect density. If there's a "deep" error, but the spec and the software agree, does it count as a bug?
For many (but not all) things, I try to write the documentation first, starting at a high level and drilling down. In fact, I've been known to mock up several prototypes of tough problems solely in English. It really does force me to think out the architecture. It doesn't, however, prevent magical thinking about how the low-level implementation will actually work out, and so isn't foolproof. Quite often, though, I'm able to skeleton-out my code in comments first, and then hanging the actual code off the comments is fairly trivial.
For some things, though, it's easier to explain in code than in English. This tends to be true with certain kinds of low-level fiddly stuff. There, it seems best to just state the high level goal in English, and then demonstrate it in code (or at least pseudo-code). English can be horribly imprecise for algorithms, and sometimes you just need a precise algorithm description to capture a set of actions. The ratio of English to code/pseudo-code then necessarily drops.
But all that's just me. Most people I work with code first, and (if they're good) document minimally once it works.
Pretty much. And, while he was going on about subtle concurrency errors, did anyone notice just how awful his sliding window filter actually was?
The code was simple enough, sure, but you could have gone much faster if you kept a running total in the class itself. And, instead of sliding the whole array over by one, just replace the element at array[idx % SIZE]. (You'd have to add a persistent index to the class too.) Those two changes would speed up the code by a factor of N, where N is the length of the window, by eliminating two loops over the arrays.
I love Literate Programming in theory. In practice, I find the source code of a Literate program ugly. I'm not sure a WYSIWYG would help. I believe the concept is a good concept, and what holds it back is the lack of a modern realization of the concept that makes the LP easier to follow and easier on the eyes.
There's no question of Donald Knuth's genius. If there's anyone who has ever threatened to exceed the Shannon limit for information density, it's him. But, aesthetically, the source of a Literate Program and the compiled result lay on direct opposite ends of the "beauty" spectrum. For LP to really catch on, the source needs to be a little more readable, IMHO.
Yeah, I had considered the trojan route also. I'm guessing there's enough people looking over others' programs that trojans won't last too long in the wild. But, I guess it just depends on how subtle the trojan is.
The difference between a backdoor and a coding error might only be found in the programmer's intent and not the code itself. For example, consider a buffer overflow that leads to arbitrary code execution: It's a coding error if the programmer didn't intend for that, but a backdoor if the programmer intended to exploit it later.
Slashdot Mirror
Sometimes, it just takes a more approachable book with a shallower ramp to get your boat off the shore and sailing. I found the GoF book thicker than paste and more effective than a bottle of sleeping pills at putting me out for the night. A senior developer at my company then pointed me to some other books, such as Head First Design Patterns. It may've been a little on the goofy side, but it did present (most of) the patterns in a clear and motivated way.
Once I read through that book and largely "got it", I found the GoF book much more approachable and much more useful. I actually read the whole thing. It's not a starter book, though.
As for how I apply patterns, I apply them more like tools in a tool box. I have a problem with a particular shape, and I look for a tool (or tools) that fit that shape. For example, I needed to make a uni-processor program multi-processor while maintaining the fiction of uni-processor to the main program. The various threads' activities were already separate classes. The proxy pattern described an attractive way to replace a class with a stand-in that forwarded interaction to the remote processor, for example. The factory pattern offered a way to build these sets of remote objects from the main event loop on the remote processor. And so on.[*]
It wasn't like one of these competitive cooking shows where they hand you an ostrich egg, some plaintains, purple cabbage and some veal and ask you to whip up a creative dessert...
[*] You're probably thinking "ok, you're reinventing RPC/COM/CORBA/insert technology here, and probably poorly too. Why not use something off-the-shelf?" In case you're wondering, I wrote this to run on the "bare metal" (no OS) on a multiple CPU embedded processing chip. I didn't have the benefit of a more extensive framework, because whatever I write needs to run acceptably in a design simulator that runs veerrrrrrry slowly (on the order of 100 cycles/second), so every cycle counts. A framework with 1ms init time kills 10 hours of sim time to a first order of magnitude. And yet, I can make C++ and design patterns work for me in this environment.
Lots more information in my post up thread.
I came here to say "Ok, so they discovered the JTAG port." Seems that blog was already on it.
Now, the researchers claim demonstrate that, via the JTAG port, they can subvert one form of Actel's AES security (but not all--see below) on someone's design to allow reverse-engineering a circuit design loaded into the FPGA. That's fairly interesting. I know that there's a fair bit of business in claiming an FPGA is invulnerable to such snooping, so that vendor A can ship a prototype design to customer B without worrying that customer B might rip off vendor A's design. For example, vendor A might ship an FPGA-based version of a chip they're designing to customer B, so they can design/debug their system while vendor A finishes the design, so both A and B can ramp their products more closely together.
Here's Actel's pitch on design security. The hack claims to expose the AES key for at least one of their encrypted modes, which implies that that particuler security feature is busted, and the guarantees against counterfeiting, reverse engineering and overbuilding it provides are also busted. According to the (occasionally somewhat breathless) claims in this draft paper, that is indeed what they've accomplished. Even then, they didn't break everything:
It'll be interesting to see how Actel responds.
As for "ZOMG, the Chinese can infect all our nukes! RUN!" that seems unlikely. To perform this analysis, you need to be able to isolate the FPGA and its bitstream in a circuit where you can observe all the pieces functioning together. This is trivial in the "vendor A / customer B" scenario above. It's not so easy to do without a specimen of the system you're trying to hack, though.
It also raises the ancillary question: If my browser does precache/prerender a page, how does the website detect when I do actually visit it?
A tangentially related question: Has anyone gotten in trouble with violating their employer's Acceptable Use Policy due to browser preloading / precaching? Often, in search results or even certain news sites there are outbound links to places I'd never visit from work. But if Chrome (or even Firefox) is clicking those links behind my back, my IP address is in a corporate log somewhere as having "visited" that site, isn't it?
How are these preload/precache "hits" distinguished from normal hits? Obviously, if some of the sites are filtering these out, there's some way to tell them apart. At the same time, if the "hits" were noticeably different, there's always the chance the webserver would serve up different pages based on this difference.
There are those much more famous than I who would disagree with you. (Scroll down to "A Flame...") Of course, appeal-to-authority is not a great way to argue a point that should be settled by data.
Some workloads are amazingly pointer heavy. Compilers and interpreters are very pointer heavy, for example. At least one SPEC benchmark sped up by over 30% in early testing. Then again, a couple others slowed down, which seems odd. I imagine we'll just have to see what happens as the compilers get tuned and so forth.
If you don't like x32, don't enable it on your system. I don't think it should be written off so easily, though.
Yes, but so what? A system that supports x32 should also support x86-64. So, if you're relying on ASLR for security purposes, compile those sensitive apps as x86-64.
Granted, the potential attack surface grows as you consider larger and larger threats. For example, a GCC compiled as x32 makes a fair bit of sense. What about Open/Libre Office? Well, that depends on if you open untrusted documents that might try to exploit OOo / LO. (Odds seem pretty low, though.) And what about Firefox? Far less to trust on the web...
So, at some point, you have to make a tradeoff between the marginal benefit of increased performance/better memory footprint in x32 mode vs. increased security against certain overflow attacks that ASLR offers. For most people in most situations, the former likely wins for anything with a decent memory footprint. For people building hardened Internet-facing servers, the latter probably wins.
And it made no sense in the original headline (which appears to have been corrected). It originally read "DreamHammer's Wants To Corner the Drone OS Market."
The panda's eats, shoots and leaves.
Dreamhammer's what wants to corner the drone OS market? Don't leave me hanging here...
One fatal flaw in your exposition above: "-gate" wasn't used as a suffix adding onto something else in the case of "Watergate." The "Watergate scandal" was named after the Watergate hotel. It wasn't until sometime later someone decided to split apart Watergate and make "-gate" a suffix.
We should set RidiculouslyCleanPC (2637867) and LookAtThatCleanBooth (2637863) up on a date. Maybe they can spend some quality time cleaning each others... erm... PCs.
Mr. Plow, that's his name, his name again is Mr. Plow.
You realize that my settings have nothing to do with yours. I'm not Jonathan Corbet or anyone else associated with the site. I'm just another LWN subscriber.
But, since LWN added the comment filtering feature (that's what it's called in "My Account", at least -- go check it out), I imagine I'm not the only person who added Florian to the "filtered" list. (And I double checked, Florian is the only person in my filter set.) Enough people add Florian, and *poof*! No more oxygen for the flames.
Filtering doesn't completely hide the person. It just "folds" the threads that start at the filtered user's comment, so that they don't take up all the screen. You can still click to expand, not too much differently than here on Slashdot.
Actually, I have to admit, I'm on the first generation of the ribbon in 2007. I haven't upgraded to 2010 yet.
What I don't like about the ribbon is that there are many functions I used to use regularly that were always on screen. Now they're spread out across many different ribbon tabs, and sometimes where they ended up is non-intuitive for me. What used to be a simple click turns into an Easter egg hunt.
Perhaps if I used Office daily, I'd develop the appropriate muscle memory. But, I only use it a few times a month, and it's usually different apps -- this week it's Excel, next week it's PowerPoint.
I don't care if "zoom", "increase font size", "merge and center", and "fill with color" all belong on logically different tabs based on their function. For me, they all belong on the "I use this regularly" page.
I'm pretty sure Florian is the only LWN user I've ever marked as "hidden by default", simply because any branch of a thread that starts with one of his comments almost invariably turns into a trainwreck. It becomes a game of Immovable Object vs. the Irresistible Force.
What amazes me is that the broadcast model ever worked at all for something like Ceefax. Caching apparently made it even more practical, but still, the amount of bandwidth dedicated to the service is barely line noise compared to what's available today. By my calculations, it was managing over 600kbps in its final form (reading a spec from 2003), but it had to send the whole catalog repeatedly, so you had to wait for the useful bits to come by, limiting the total size of what Ceefax could offer.
So, if the modern day equivalent is loading more slowly and providing less, then it's due to a clear lack of caring at all about the service, I'd say than anything about the technology. There's more than enough bandwidth available, and you don't have to constantly replay all the content for everybody on the hopes that anybody would see it, like the broadcast model. You only have to serve it on demand.
I would go further: Thinking about the language of your project can be incredibly useful and clarifying. If you can boil down your problem's concepts into a consistent and fairly precise language, then you stand a better chance of implementing without too many thinkos.
Aligning that language with the business processes is definitely important, if your software is implementing business logic. Not all problems have a business process to align with. But, they have something they interface with, so try to be consistent with that (unless that thing is itself horribly inconsistent).
All that said, the strategy of the GP post of having consistent generic names (i/j/k for loop labels, etc) also has an important role. It makes it easier to identify the details that are not important. Consider array[array_index] vs. a[i]. The former takes a lot longer to read, but doesn't really convey any additional information for the effort. Conventional names for common actions allow you to filter away the noise, leaving you to focus on the actually novel bits.
How many of those programs had comments like this?
i++; /* add 1 to i */
People joke about such bad documentation, but I have actually been subjected to it in a professional environment. If I ever teach a programming class, I will give an automatic zero to such inanity.
It really depends on how many passes over the specs they made, and how separable the sections were. If you have to hold all 2500 pages in your head at the same time in order to spot deep inconsistencies, few (if any) humans will ever succeed. But, if the documentation was well segmented, such that you only needed to hold couple dozen pages of knowledge in your head at one time to understand a section, then you stand a chance, with sufficient reviews, to comb all the nits out.
I imagine there must be large portions of the spec just stating intended interactions with the other 420,000 lines of code. Even just stating the negative (ie. "no interaction with module X") for that much other code would take quite a few pages.
And, consider this quote from the article:
That's the real reason. Perfection in the software is the primary focus, cost be damned. Most projects live within less generous cost and time constraints. They can't afford a 2.5:1 code to spec ratio.
Also, I wonder about the nature of measuring the defect density. If there's a "deep" error, but the spec and the software agree, does it count as a bug?
For many (but not all) things, I try to write the documentation first, starting at a high level and drilling down. In fact, I've been known to mock up several prototypes of tough problems solely in English. It really does force me to think out the architecture. It doesn't, however, prevent magical thinking about how the low-level implementation will actually work out, and so isn't foolproof. Quite often, though, I'm able to skeleton-out my code in comments first, and then hanging the actual code off the comments is fairly trivial.
For some things, though, it's easier to explain in code than in English. This tends to be true with certain kinds of low-level fiddly stuff. There, it seems best to just state the high level goal in English, and then demonstrate it in code (or at least pseudo-code). English can be horribly imprecise for algorithms, and sometimes you just need a precise algorithm description to capture a set of actions. The ratio of English to code/pseudo-code then necessarily drops.
But all that's just me. Most people I work with code first, and (if they're good) document minimally once it works.
Pretty much. And, while he was going on about subtle concurrency errors, did anyone notice just how awful his sliding window filter actually was?
The code was simple enough, sure, but you could have gone much faster if you kept a running total in the class itself. And, instead of sliding the whole array over by one, just replace the element at array[idx % SIZE]. (You'd have to add a persistent index to the class too.) Those two changes would speed up the code by a factor of N, where N is the length of the window, by eliminating two loops over the arrays.
I love Literate Programming in theory. In practice, I find the source code of a Literate program ugly. I'm not sure a WYSIWYG would help. I believe the concept is a good concept, and what holds it back is the lack of a modern realization of the concept that makes the LP easier to follow and easier on the eyes.
There's no question of Donald Knuth's genius. If there's anyone who has ever threatened to exceed the Shannon limit for information density, it's him. But, aesthetically, the source of a Literate Program and the compiled result lay on direct opposite ends of the "beauty" spectrum. For LP to really catch on, the source needs to be a little more readable, IMHO.
Yeah, I had considered the trojan route also. I'm guessing there's enough people looking over others' programs that trojans won't last too long in the wild. But, I guess it just depends on how subtle the trojan is.
The difference between a backdoor and a coding error might only be found in the programmer's intent and not the code itself. For example, consider a buffer overflow that leads to arbitrary code execution: It's a coding error if the programmer didn't intend for that, but a backdoor if the programmer intended to exploit it later.