I think that story (using Nintendo chips as missile guidance?) was totally debunked in the end and it was suggested it may have been dreamed up along with the majority of the illegal weapons, to justify a war that was already desired
Particularly when it is well known that you can defeat missiles using that kind of control system with something as simples as a track ball and three buttons. Here's a picture of the operator console for such a system: http://cdn.chud.com/a/a2/a23bbcb6_11011101.jpeg
Claims that old private telephone calls have been leaking onto people's Timelines have been dismissed by AT&T. Apparently, as many concluded early on, the "leaked" messages were just old calls recorded in room 614A - http://en.wikipedia.org/wiki/Room_641A, that users had mistakenly believed were private. Given the lack of user understanding, now is a good time for AT&T to revamp its privacy help pages. Let's hope users pay attention, and AT&T genuinely resists exploiting their naivety.
The problem isn't "The Scarlet FELON", it's that the jobs just aren't there for anyone, unless they have in-demand skill sets. Convicted felons and half of all recent college graduates typically don't have them.
On the flip side, half of recent college graduates do have full time jobs, and convicted felons can get jobs; in both cases, they have to have in-demand skill sets.
The difficulty with the site is that the owner offered to delete the comments upon payment of £299 (around $500). If the purpose of the site was genuine (to allow complaints to be 'heard') why was it possible to take comments down? And what is to stop fake comments from being posted to attract further payment?
Fortunately for the solicitors in England and Wales, action was taken by the Law Society and the owner of the site was forced to take the site down and suffer the consequences of poorly defended legal action.
That action was taken by the Law Society as the only option available to the libeled solicitors was to launch an individual libel claim. The owner of the site had to respond to such claims and didn't fair particularly well in these either, particularly when it was clear that he had offered to take the comments down for a payment (see paragraph 23).
The correct way to legally extort money is to call it an investigation and processing fee, rather than an offer to take the review down. The investigation will inevitably turn up the fact that the review was not submitted in good faith and/or by a nut job, and it will be taken down, which is what the lawyer wanted, but the investigation and processing fee in that case would be legitimate, even if the whole thing was automated or partially automated - there's no reason you wouldn't pay some broke college student 1-2% of the processing fee to actually perform an investigation process on a contract rather than a permanent employment basis, as piecework, in order to avoid actually becoming an employer, and as long as you paid your taxes, there's pretty much nothing to be done about it.
To avoid any appearance of impropriety whatsoever, you could also post positive reviews, and justify listing all negative reviews before positive ones on the basis that people in need of a lawyer would be best served by the review site by knowing as quickly as possible if the lawyer failed in a case similar to theirs -- so a lawyer with 100 reviews and a 96% positive rating would still have the 4 bad reviews listed before everything else that said good things, and that is what people would see first.
Taking this approach, $5 worth of investigation might not be enough, and even if it were, factually bad reviews would stick to a lawyer on the review site, which is maybe not a bad thing... it pretty much puts them in the same boat as trademark registration, where you have to zealously defend your trademark by spending money, only in this case, you pay the review site, rather than paying lawyers (perhaps adding some much needed symmetry to the universe in the process, but I digress...).
Note that I'm not recommending this as an honorable business model, but it's one that works pretty well for a couple of "review sites" here in the US, and in that case, even a libel case would have to name the original reviewer, rather than the site, as long as the site doesn't have employees posting the negative reviews in the first place (libel laws differ in the US, and astroturfing bad reviews in order to get people to pay for advertising is one of the techniques used by one of the putative review sites).
The attacker just needs to have something running on your machine that they can use from their machine to provide the answers to your bank.
This is not technically an interposition attack, it's a referral attack, similar to the captcha breaking systems which proxy a captcha to a human wanting to look at porn, the human solves the captcha, gets the porn, and is happy, while the system proxying the captcha has used the solution to attack an unrelated system normally requiring detecting an actual human to avoid attack.
I have to agree with dkf here. I don't think you understand CI or how it is valuable. You don't need test first or any of that. Your code should always build. CI is a guarantee that the codebase will always build. A guarantee that developers are not committing broken code. From that vantage you can add lots of good stuff: Unit Testing, Style Reviews, Automated Bug Checks, Automated Dependency Updates... But, you have to start with a codebase that compiles and CI does that.
CI doesn't actually keep broken, or worse, flakey code out of your tree, it keeps it buildable, and it keeps new code moving into your TOT. Buildable isn't the same as working/not flakey.
The Mozilla project nearly died under the weight of "buildable, but not working", and it's one of the reasons so many SourceForge projects fail: the elves don't materialize out of the woodwork to fix the bugs for you because they don't have a "mostly working" base from which to make improvements.
It's very possible to get into a state where you commit code that is in fact broken/flakey but buildable, and not have a clear way backwards to working. This happened with the FreeBSD 5.0 schedule slippage for literally years because of stair-steps introduced by resource-based autoscaling of system parameters. Matt Dillon, who initially introduced the problem, and later realized his mistake after the fact, was unable to get the changes reverted, and eventually left and founded DragonflyBSD in partial reaction to the introduced instability. It boiled down to "if you had a machine with the same amount of RAM as the most active developers, things worked, otherwise if you ran up against a resource starvation on a scaled value, like number of open sockets, the OS becomes extremely unstable".
Code has to be tinkerable for people to want to work on it, and if it's currently broken/unstable, it's no longer tinkerable, no matter how many times you successfully recompile it. At that point the barrier to entry curve rises exponentially.
First provide some unit tests and regression tests that run under continuous integration. Then some real documentation (not Java Docs).
FTFY.
Continuous integration assumes a waterfall development methodology, which is a great idea if you are building a prototype, and a terrible idea if you are building a product.
The reason this is true is that the continuous integration and waterfall models do not lend themselves to productization, which requires a feature cutoff and a feature focus. If you are doing either, you aren't feature-focused, since the development is scattered over product feature areas. What this means is that you don't get work on incomplete features prioritized. You can do a release cycle cut with your current top of tree, but you can't omit work intended for the next release cycle, and you can't omit partial implementation.
Unit tests and regression tests are a great idea, particularly if you are writing the tests first from a design specification, and only assigning significance to the test results after the design point is feature complete. If you are doing anything else with them, however, you are doing it wrong: you will end up with spotty test coverage, spurious tree closures on false/erroneous test failures, and worst of all, you will assign inflated significance to the tests you have in hand, vs. the ones you should have had in hand before you started your feature work.
There are some projects that get away with this model; Android is one of them. But they only get away with it because the cell phone vendors take a tree snapshot, and refuse to take additional waterfall work into their product after it has been declared feature complete, and then only do bug fixes. This process is called variously "integration" or "productization", and it's done by companies like Motorola, Nokia, Samsun, Ericsson, and so on, and it typically not part of the Android process proper(*).
(*) This, incidentally, is a partial explanation of why cell phone vendors tend to stick on antique versions of Android once the product has shipped, and do not issue updates. The rest of the explanation is the carrier business model doesn't actually want the updates, even if it were not effectively the same cost as developing an entirely new phone, as far as the handset vendors are concerned. To the carriers, changing this means that someone can get the new OS features and applications written for the new OS, and "ride out" the remainder of their carrier contract and switch carriers, rather than re-upping with the same carrier 6 months before contract expiration in order to get the new OS with the new handset.
Below a certain population density, mass transit doesn't really scale. Take a look at these maps, and you'll be able to tell the places where it makes sense, and where it doesn't: http://en.wikipedia.org/wiki/Population_density
Most of Europe is pretty dense, and large swaths of Asia, but unless you live in an urban megaples in the U.S., it generally doesn't work so well.
Oh, and the original poster should just buy some soundproof windows; a rating of 45 will yield a 95% reduction in the sound comin through the windows, so long as they are kept closed.
And they've failed to pursue a suit against the AJ All Clocks screen saver:
hhttp://beeks.eu/Screensaver.htm
So I'm going to guess they have lost their trademark status on a technicality already, only no one's called them on it, and now they are going after the company with the deep pockets in hopes of a payday.
If I were Apple, I'd claim to have copied the screen saver. And if that doesn't work, claim to have copied the Dutch railway clock rather than the Swiss, and let the Swiss go after the Netherlands first before they can go after Apple, and see how far they get trying to go down that road, when it would mean ripping out all the clocks in the Netherlands. Alternately, they could agree to FRAND license the clock design to Apple after they get a settlement with the Netherlands.
Either way, it's a pretty spectacularly stupid way to try and make money, rather than, for example, efficiently operating the railroads for which the clock was built.
The robotic automated control systems are typically shit, but that doesn't mean it's not doable, it just means that mechanical and electrical engineers should not write robotic control systems, they should leave it to software engineers. In other words, it's the same problem that the Diamond Viper video cards had back in the day when they let EE's write the video BIOS, instead of hiring a software engineer to do it.
I recently spent some quality time programming a Toshiba CA10-M00 controller interfaced robot for the purposes of doing testing on capacitive touch devices, such as trackpads, and the programming interface at the lowest level was, to put it bluntly, incredibly badly designed. The one saving grace was "palletizing" mode, and all that let you do was do things like fill columns in a biological sample tray while moving the pallet on which it was situated over one row at a time, and then repeating the previous instruction.
In any case, the controller was pretty terrible, very limited in capability, and only capable of controlling 4 degrees of freedom without being ganged to another controller for the next 4 degrees of freedom; even then; you'd want to install optional interface modules to use for step-signalling between the controllers, rather than ganging them, based on the limited number of steps available under the control of a single controller, and the inability to do anything remotely useful in only 1000 steps (with 4 degrees of freedom, 1000 steps was pushing rationality as it was).
As delivered, the hardware didn't actually function (had to send it back once to have a servo replaced), and when driven from other than the EEPROM, the command language is insufficiently rich to perform motion on more than a single axis at a time (which basically meant writing a program to write a program, rather than controlling it directly). Additionally, the plat was oriented incorrectly, and there were no registration marks on any of the manual adjustments, and the robot was not set up to be capable of non-2-d self interference (read: if incorrectly programmed, it could beat itself to death).
To top all this joy off, they very much expected you to use a "teaching pendant" to do a single static program, and I had to reverse engineer how to talk to the thing with a documented list of serial functions, with no documentation of order or the requirements for baseline settings.
All in all, to get a suite of repeatable test motions that could be applied to multiple devices with different form-factors required some fairly clever hackery. What I ended up with was a library of code that could be used to write a program that could program the robot. The most interesting of those are not in the public repository, but the rest of the code is here: http://git.chromium.org/gitweb/?p=chromiumos/platform/touchbot.git;a=tree
The bottom line is that by using meta-programming, instead of using the default crap interface you get by applying teaching-pendant programming, it'd be pretty trivial to change over the location of a screw, or even radically alter the layout.
And just practically speaking, fetching a screw is a subroutine, putting in a screw is a subroutine, and where to put the screw in is a point in the X,Y,Z,R point table, if you wrote your code correctly in the first place, which you'd be unlikely to do if using the teaching pendant, but which was still technically possible using one. Which'd mean just rewriting the point table after issuing a region erase command to the robot controller over an RS232C link, after jamming the robot into a receptive mode with 5 other command would move the screw.
But doing the metaprogramming approach, it'd also be possible to radically alter the robot behaviour pretty trivially and be up and running on the real assembly line once you got your test line working correctly to the new model.
Which is to say, the argument that you can't as trivially recon
First, nowhere on that page does Microsoft pledge not to track you. Second, Microsoft has a vested interest in shooting everyone who honors DNT in the head so that they can't get any more revenue by being better at analytics than Microsoft. Third, Microsoft sites fail to honor DNT, even if you are dumb and use IE9. Fourth, the DNT standard was written such that DNT was opt-in, not opt-out, and Microsoft is failing to implement the standard with IE9.
So the business model is:
(1) Ruin every honest web sites analytics by DNT-by-default in IE9 (2) Ignore the DNT sent by IE9 and other browsers when doing their own analytics (3) Become the sole source of qualified targeted advertising as a result (4) Profit!
Would you demand all your employees learn graphic design and have them all create graphics to be used in production?
If I were selling graphic design product, I might.
"Production" in this context means "demonstrating what the tools can do on a customer premises in order to close the sale". I'd hope to hell that if I were selling Photoshop or Final Cut Pro or Shake that I'd be able to demo it to the customer and connect with them on at least a semi-professional level so that they'd have confidence that what I'm selling them will do what I'm telling them it will do.
Listening to music is a right brain activity, and making intuitive cognitive leaps, such as concluding closure of an algorithm or detailed debugging operations is also a right brain activity.
The two sources I have are:
The Origin of Consciousness in the Breakdown of the Bicameral Mind Jaynes, Julian Houghton Mifflin, 1976 Mariner Books, 2000 ISBN-10: 0618057072 Pages 367-368
Peopleware : productive projects and teams Tom DeMarco & Timothy Lister Dorsett House, 1999 ISBN-10: 0932633439 Online PDF: Search for PeopleWare_2ed.pdf Pages 78, 230, 231 anecdotally document a Cornell experiment, and claim personal involvement
Both books are still in print in hard copy from Amazon.
Not all change is bad. Slashdot has been somewhat limping for a while now due to dips in readership. Anything that could improve traffic would be a good thing for Slashdot:
DHCP6 is if you are anal and want to explicitly exclude giving routable addresses to random devices.
The thing that's frequently missed is that you don't have the necessary CERT to do an update to the local DNS server, if you want your machine to update DNS automatically, then you need to have a CERT for a DNS server where you do have update rights.
Practically, this comes down to my laptop always being named "mylaptop.mygroup.mycompany.com" because I put the IPv6 stateless autoconfiguration address into the DNS server for "mygroup.mycompany.com" mapping it to that name with the CERT, and then the local DNS allows this as an inaddr.arpa. update because the forward check was allowed by my DNS server.
It doesn't matter if I use this address to send random SPAM, since it comes back to my domain via gethostbyaddr(). This assumes you deploy DomainKeys. If not, then the reverse name doesn't happen, and no one will be willing to relay your SPAM for you anyway.
If you care about routable addresses, then you probably need to set up a DMZ with a WiFi certificate for the non-DMZ network. This is how GoogleGuest allows people on the Google campus onto the Internet.
If you can listen to music and code at the same time, then you tend to do better in an open plan cube farm, but due to continuous partial attention, perhaps not so well as if you had some place quiet to cogitate.
If you can't listen to music because that's the part of your brain that also processes code, you tend to be at a disadvantage because there's no refuge in wearing headphones. I do OK in an open plan environment, but I do better in an office, since when I get into a deep problem, I tend to react to expected distraction. On the plus side, I can generally go fairly deeper than someone who is listening to music, or at least that's my personal anecdotal experience.
Generally speaking, in open plan cube farm companies, you can typically find a small conference room, or you can find a quiet corner of a lab, or you can grab a phone room, or you can work from home (which they tend to tolerate better than office-based companies) in these situations, so it's not impossible to make progress on deep problems.
It's a "third shift" knock-off of the Ainol Novo with less RAM and cheaper parts. Ainol failed to control their supply chain (third shift is why Apple buys up all the possible parts suppliers for three or four of the components in any of their products: it makes a third shift non-viable for the factory). It's also using a cheaper screen, which is why the capacitive sensor is so bad - it's not tuned for the dielectric it's got. Finally it's actually got a reduced size battery, which is one of the big cost items for any tablet.
We should pick someone we hate, and wind them up and point them in that direction.
Seriously, those idiots are not storming a US embassy because they are upset about a Youtube video, they are storming it because it's a US embassy, and 9/11 was a convenient excuse to celebrate by storming an embassy.
I think that story (using Nintendo chips as missile guidance?) was totally debunked in the end and it was suggested it may have been dreamed up along with the majority of the illegal weapons, to justify a war that was already desired
Particularly when it is well known that you can defeat missiles using that kind of control system with something as simples as a track ball and three buttons. Here's a picture of the operator console for such a system: http://cdn.chud.com/a/a2/a23bbcb6_11011101.jpeg
But the US can still nuke anyone from the orbit, so the money was not well-spent in the first place.
People keep saying this, but it never happens; the US keep sending conventional troops places to get shot up instead.
I say put up or shut up.
...they will complain that she ganked the election.
Claims that old private telephone calls have been leaking onto people's Timelines have been dismissed by AT&T. Apparently, as many concluded early on, the "leaked" messages were just old calls recorded in room 614A - http://en.wikipedia.org/wiki/Room_641A, that users had mistakenly believed were private. Given the lack of user understanding, now is a good time for AT&T to revamp its privacy help pages. Let's hope users pay attention, and AT&T genuinely resists exploiting their naivety.
Exactly - the problem with prison time isn't just the prison time, it's wearing the scarlet letter of "FELON" for the rest of your life.
Is this the life to which you aspire?
As opposed to half of recent college grads being unable to find full time work, according to a Rutgers University study? http://www.heldrichpodcasts.com/Chasing_American_Dream_Report.pdf
The problem isn't "The Scarlet FELON", it's that the jobs just aren't there for anyone, unless they have in-demand skill sets. Convicted felons and half of all recent college graduates typically don't have them.
On the flip side, half of recent college graduates do have full time jobs, and convicted felons can get jobs; in both cases, they have to have in-demand skill sets.
The difficulty with the site is that the owner offered to delete the comments upon payment of £299 (around $500). If the purpose of the site was genuine (to allow complaints to be 'heard') why was it possible to take comments down? And what is to stop fake comments from being posted to attract further payment?
Fortunately for the solicitors in England and Wales, action was taken by the Law Society and the owner of the site was forced to take the site down and suffer the consequences of poorly defended legal action.
That action was taken by the Law Society as the only option available to the libeled solicitors was to launch an individual libel claim. The owner of the site had to respond to such claims and didn't fair particularly well in these either, particularly when it was clear that he had offered to take the comments down for a payment (see paragraph 23).
The correct way to legally extort money is to call it an investigation and processing fee, rather than an offer to take the review down. The investigation will inevitably turn up the fact that the review was not submitted in good faith and/or by a nut job, and it will be taken down, which is what the lawyer wanted, but the investigation and processing fee in that case would be legitimate, even if the whole thing was automated or partially automated - there's no reason you wouldn't pay some broke college student 1-2% of the processing fee to actually perform an investigation process on a contract rather than a permanent employment basis, as piecework, in order to avoid actually becoming an employer, and as long as you paid your taxes, there's pretty much nothing to be done about it.
To avoid any appearance of impropriety whatsoever, you could also post positive reviews, and justify listing all negative reviews before positive ones on the basis that people in need of a lawyer would be best served by the review site by knowing as quickly as possible if the lawyer failed in a case similar to theirs -- so a lawyer with 100 reviews and a 96% positive rating would still have the 4 bad reviews listed before everything else that said good things, and that is what people would see first.
Taking this approach, $5 worth of investigation might not be enough, and even if it were, factually bad reviews would stick to a lawyer on the review site, which is maybe not a bad thing... it pretty much puts them in the same boat as trademark registration, where you have to zealously defend your trademark by spending money, only in this case, you pay the review site, rather than paying lawyers (perhaps adding some much needed symmetry to the universe in the process, but I digress...).
Note that I'm not recommending this as an honorable business model, but it's one that works pretty well for a couple of "review sites" here in the US, and in that case, even a libel case would have to name the original reviewer, rather than the site, as long as the site doesn't have employees posting the negative reviews in the first place (libel laws differ in the US, and astroturfing bad reviews in order to get people to pay for advertising is one of the techniques used by one of the putative review sites).
It can be a man-on-the-side attack, too.
The attacker just needs to have something running on your machine that they can use from their machine to provide the answers to your bank.
This is not technically an interposition attack, it's a referral attack, similar to the captcha breaking systems which proxy a captcha to a human wanting to look at porn, the human solves the captcha, gets the porn, and is happy, while the system proxying the captcha has used the solution to attack an unrelated system normally requiring detecting an actual human to avoid attack.
I have to agree with dkf here. I don't think you understand CI or how it is valuable. You don't need test first or any of that. Your code should always build. CI is a guarantee that the codebase will always build. A guarantee that developers are not committing broken code. From that vantage you can add lots of good stuff: Unit Testing, Style Reviews, Automated Bug Checks, Automated Dependency Updates... But, you have to start with a codebase that compiles and CI does that.
CI doesn't actually keep broken, or worse, flakey code out of your tree, it keeps it buildable, and it keeps new code moving into your TOT. Buildable isn't the same as working/not flakey.
The Mozilla project nearly died under the weight of "buildable, but not working", and it's one of the reasons so many SourceForge projects fail: the elves don't materialize out of the woodwork to fix the bugs for you because they don't have a "mostly working" base from which to make improvements.
It's very possible to get into a state where you commit code that is in fact broken/flakey but buildable, and not have a clear way backwards to working. This happened with the FreeBSD 5.0 schedule slippage for literally years because of stair-steps introduced by resource-based autoscaling of system parameters. Matt Dillon, who initially introduced the problem, and later realized his mistake after the fact, was unable to get the changes reverted, and eventually left and founded DragonflyBSD in partial reaction to the introduced instability. It boiled down to "if you had a machine with the same amount of RAM as the most active developers, things worked, otherwise if you ran up against a resource starvation on a scaled value, like number of open sockets, the OS becomes extremely unstable".
Code has to be tinkerable for people to want to work on it, and if it's currently broken/unstable, it's no longer tinkerable, no matter how many times you successfully recompile it. At that point the barrier to entry curve rises exponentially.
First provide some unit tests and regression tests that run under continuous integration. Then some real documentation (not Java Docs).
FTFY.
Continuous integration assumes a waterfall development methodology, which is a great idea if you are building a prototype, and a terrible idea if you are building a product.
The reason this is true is that the continuous integration and waterfall models do not lend themselves to productization, which requires a feature cutoff and a feature focus. If you are doing either, you aren't feature-focused, since the development is scattered over product feature areas. What this means is that you don't get work on incomplete features prioritized. You can do a release cycle cut with your current top of tree, but you can't omit work intended for the next release cycle, and you can't omit partial implementation.
Unit tests and regression tests are a great idea, particularly if you are writing the tests first from a design specification, and only assigning significance to the test results after the design point is feature complete. If you are doing anything else with them, however, you are doing it wrong: you will end up with spotty test coverage, spurious tree closures on false/erroneous test failures, and worst of all, you will assign inflated significance to the tests you have in hand, vs. the ones you should have had in hand before you started your feature work.
There are some projects that get away with this model; Android is one of them. But they only get away with it because the cell phone vendors take a tree snapshot, and refuse to take additional waterfall work into their product after it has been declared feature complete, and then only do bug fixes. This process is called variously "integration" or "productization", and it's done by companies like Motorola, Nokia, Samsun, Ericsson, and so on, and it typically not part of the Android process proper(*).
(*) This, incidentally, is a partial explanation of why cell phone vendors tend to stick on antique versions of Android once the product has shipped, and do not issue updates. The rest of the explanation is the carrier business model doesn't actually want the updates, even if it were not effectively the same cost as developing an entirely new phone, as far as the handset vendors are concerned. To the carriers, changing this means that someone can get the new OS features and applications written for the new OS, and "ride out" the remainder of their carrier contract and switch carriers, rather than re-upping with the same carrier 6 months before contract expiration in order to get the new OS with the new handset.
Below a certain population density, mass transit doesn't really scale. Take a look at these maps, and you'll be able to tell the places where it makes sense, and where it doesn't: http://en.wikipedia.org/wiki/Population_density
Most of Europe is pretty dense, and large swaths of Asia, but unless you live in an urban megaples in the U.S., it generally doesn't work so well.
Oh, and the original poster should just buy some soundproof windows; a rating of 45 will yield a 95% reduction in the sound comin through the windows, so long as they are kept closed.
And we are done with spreading mercury everywhere.
I think the subject says it all, but if I missed something, feel free to comment?
And they've failed to pursue a suit against the AJ All Clocks screen saver:
hhttp://beeks.eu/Screensaver.htm
So I'm going to guess they have lost their trademark status on a technicality already, only no one's called them on it, and now they are going after the company with the deep pockets in hopes of a payday.
If I were Apple, I'd claim to have copied the screen saver. And if that doesn't work, claim to have copied the Dutch railway clock rather than the Swiss, and let the Swiss go after the Netherlands first before they can go after Apple, and see how far they get trying to go down that road, when it would mean ripping out all the clocks in the Netherlands. Alternately, they could agree to FRAND license the clock design to Apple after they get a settlement with the Netherlands.
Either way, it's a pretty spectacularly stupid way to try and make money, rather than, for example, efficiently operating the railroads for which the clock was built.
The robotic automated control systems are typically shit, but that doesn't mean it's not doable, it just means that mechanical and electrical engineers should not write robotic control systems, they should leave it to software engineers. In other words, it's the same problem that the Diamond Viper video cards had back in the day when they let EE's write the video BIOS, instead of hiring a software engineer to do it.
I recently spent some quality time programming a Toshiba CA10-M00 controller interfaced robot for the purposes of doing testing on capacitive touch devices, such as trackpads, and the programming interface at the lowest level was, to put it bluntly, incredibly badly designed. The one saving grace was "palletizing" mode, and all that let you do was do things like fill columns in a biological sample tray while moving the pallet on which it was situated over one row at a time, and then repeating the previous instruction.
In any case, the controller was pretty terrible, very limited in capability, and only capable of controlling 4 degrees of freedom without being ganged to another controller for the next 4 degrees of freedom; even then; you'd want to install optional interface modules to use for step-signalling between the controllers, rather than ganging them, based on the limited number of steps available under the control of a single controller, and the inability to do anything remotely useful in only 1000 steps (with 4 degrees of freedom, 1000 steps was pushing rationality as it was).
As delivered, the hardware didn't actually function (had to send it back once to have a servo replaced), and when driven from other than the EEPROM, the command language is insufficiently rich to perform motion on more than a single axis at a time (which basically meant writing a program to write a program, rather than controlling it directly). Additionally, the plat was oriented incorrectly, and there were no registration marks on any of the manual adjustments, and the robot was not set up to be capable of non-2-d self interference (read: if incorrectly programmed, it could beat itself to death).
To top all this joy off, they very much expected you to use a "teaching pendant" to do a single static program, and I had to reverse engineer how to talk to the thing with a documented list of serial functions, with no documentation of order or the requirements for baseline settings.
All in all, to get a suite of repeatable test motions that could be applied to multiple devices with different form-factors required some fairly clever hackery. What I ended up with was a library of code that could be used to write a program that could program the robot. The most interesting of those are not in the public repository, but the rest of the code is here: http://git.chromium.org/gitweb/?p=chromiumos/platform/touchbot.git;a=tree
The bottom line is that by using meta-programming, instead of using the default crap interface you get by applying teaching-pendant programming, it'd be pretty trivial to change over the location of a screw, or even radically alter the layout.
And just practically speaking, fetching a screw is a subroutine, putting in a screw is a subroutine, and where to put the screw in is a point in the X,Y,Z,R point table, if you wrote your code correctly in the first place, which you'd be unlikely to do if using the teaching pendant, but which was still technically possible using one. Which'd mean just rewriting the point table after issuing a region erase command to the robot controller over an RS232C link, after jamming the robot into a receptive mode with 5 other command would move the screw.
But doing the metaprogramming approach, it'd also be possible to radically alter the robot behaviour pretty trivially and be up and running on the real assembly line once you got your test line working correctly to the new model.
Which is to say, the argument that you can't as trivially recon
First, nowhere on that page does Microsoft pledge not to track you. Second, Microsoft has a vested interest in shooting everyone who honors DNT in the head so that they can't get any more revenue by being better at analytics than Microsoft. Third, Microsoft sites fail to honor DNT, even if you are dumb and use IE9. Fourth, the DNT standard was written such that DNT was opt-in, not opt-out, and Microsoft is failing to implement the standard with IE9.
So the business model is:
(1) Ruin every honest web sites analytics by DNT-by-default in IE9
(2) Ignore the DNT sent by IE9 and other browsers when doing their own analytics
(3) Become the sole source of qualified targeted advertising as a result
(4) Profit!
There isn't even a "???" step in there.
Would you demand all your employees learn graphic design and have them all create graphics to be used in production?
If I were selling graphic design product, I might.
"Production" in this context means "demonstrating what the tools can do on a customer premises in order to close the sale". I'd hope to hell that if I were selling Photoshop or Final Cut Pro or Shake that I'd be able to demo it to the customer and connect with them on at least a semi-professional level so that they'd have confidence that what I'm selling them will do what I'm telling them it will do.
http://www.imm.org/
http://www.foresight.org/
http://www.khanacademy.org/
Listening to music is a right brain activity, and making intuitive cognitive leaps, such as concluding closure of an algorithm or detailed debugging operations is also a right brain activity.
The two sources I have are:
The Origin of Consciousness in the Breakdown of the Bicameral Mind
Jaynes, Julian
Houghton Mifflin, 1976
Mariner Books, 2000 ISBN-10: 0618057072
Pages 367-368
Peopleware : productive projects and teams
Tom DeMarco & Timothy Lister
Dorsett House, 1999 ISBN-10: 0932633439
Online PDF: Search for PeopleWare_2ed.pdf
Pages 78, 230, 231 anecdotally document a Cornell experiment, and claim personal involvement
Both books are still in print in hard copy from Amazon.
George Wallace, is that you?
http://en.wikipedia.org/wiki/Stand_in_the_Schoolhouse_Door
Not all change is bad. Slashdot has been somewhat limping for a while now due to dips in readership. Anything that could improve traffic would be a good thing for Slashdot:
http://en.wikipedia.org/wiki/Slashdot#Traffic_and_publicity
DHCP6 is if you are anal and want to explicitly exclude giving routable addresses to random devices.
The thing that's frequently missed is that you don't have the necessary CERT to do an update to the local DNS server, if you want your machine to update DNS automatically, then you need to have a CERT for a DNS server where you do have update rights.
Practically, this comes down to my laptop always being named "mylaptop.mygroup.mycompany.com" because I put the IPv6 stateless autoconfiguration address into the DNS server for "mygroup.mycompany.com" mapping it to that name with the CERT, and then the local DNS allows this as an inaddr.arpa. update because the forward check was allowed by my DNS server.
It doesn't matter if I use this address to send random SPAM, since it comes back to my domain via gethostbyaddr(). This assumes you deploy DomainKeys. If not, then the reverse name doesn't happen, and no one will be willing to relay your SPAM for you anyway.
If you care about routable addresses, then you probably need to set up a DMZ with a WiFi certificate for the non-DMZ network. This is how GoogleGuest allows people on the Google campus onto the Internet.
If you can listen to music and code at the same time, then you tend to do better in an open plan cube farm, but due to continuous partial attention, perhaps not so well as if you had some place quiet to cogitate.
If you can't listen to music because that's the part of your brain that also processes code, you tend to be at a disadvantage because there's no refuge in wearing headphones. I do OK in an open plan environment, but I do better in an office, since when I get into a deep problem, I tend to react to expected distraction. On the plus side, I can generally go fairly deeper than someone who is listening to music, or at least that's my personal anecdotal experience.
Generally speaking, in open plan cube farm companies, you can typically find a small conference room, or you can find a quiet corner of a lab, or you can grab a phone room, or you can work from home (which they tend to tolerate better than office-based companies) in these situations, so it's not impossible to make progress on deep problems.
It's a "third shift" knock-off of the Ainol Novo with less RAM and cheaper parts. Ainol failed to control their supply chain (third shift is why Apple buys up all the possible parts suppliers for three or four of the components in any of their products: it makes a third shift non-viable for the factory). It's also using a cheaper screen, which is why the capacitive sensor is so bad - it's not tuned for the dielectric it's got. Finally it's actually got a reduced size battery, which is one of the big cost items for any tablet.
See the inset here: http://www.rmmagazine.com/Magazine/PrintTemplate.cfm?AID=3376 for how the "third shift" works to produce cheaper product at the expense of quality.
It's called stateless address autoconfiguration.
http://www.ietf.org/rfc/rfc2462.txt
We should pick someone we hate, and wind them up and point them in that direction.
Seriously, those idiots are not storming a US embassy because they are upset about a Youtube video, they are storming it because it's a US embassy, and 9/11 was a convenient excuse to celebrate by storming an embassy.
According to Reuters http://www.reuters.com/article/2012/09/13/us-usa-libya-attack-idUSBRE88B1C620120913 and the Wall Street Journal http://online.wsj.com/article/SB10000872396390444517304577653680320732176.html?mod=googlenews_wsj, the Libya attack was planned in advance.
Considering all the Apollo moon landings happened under the Nixon presidency.