It bums me out when the first time I hear about something cool is when it's getting shut down.
I sounds like this Google project/subsidiary was doing great work, but Google didn't bother to give them a marketing department.
Then they say it isn't viable.
Catch 22 - QED.
Eval has been part of the Lisp programming language since the dawn of computing, but few experienced Lisp programmers ever used it outside of read-eval-print loops and software development tools (where its existence is a totally awesome gift). Eval is widely considered a beginner's trap. It is rarely "the right thing," typically because it is super inefficient. But my biggest concern is that it is a huge security hole, especially when the expression to be evaluated comes from the user. Think SQL injection attack. It is wise to require some sort of security credentials and/or filters to make sure the expression is within a "safe subset" of the language... at which point you might as well write the mini-interpreter you really need, instead of making the entire, underlying language and the application's entire data environment available for anyone to use or misuse.
This might be a new idea in the U.S., but at one of Canada's premier colleges, this is already old hat. Go look at McGill University's "menu" of tuition fees. You'll see that they charge radically lower rates to the art student, English major, or nursing student compared to the computer scientist or pre-med. I hadn't thought of the costs of running these programs, but up in Montreal they almost certainly did. What seemed striking to me is how compassionate this policy is for the student. Is it coincidental that these Canadian tuition rates happen to be scaled to the earning potential of the graduate? So no more crazy high debt for your "B.A. in Barista." But for super in-demand and high-paid software engineers? Sure, they think you can afford to pay off those big loans. Oh, but wait... if you are a Quebec resident, your tuition will be so low that you won't need any big loans! 20/20 hindsight: if only we had moved to Canada, my wife and teenagers would have been way less stressed.
The 4004 was used in the first electronic taximeter, the Argo Kiensle 1140, and these were in service for many decades, but have since been largely replaced. I'd speculate that there are still some traffic lights that have an Intel 4004 inside. The chip went out of production in 1986.
I can't remember encountering such obvious political mud-slinging here on Slashdot before. I guess I was under the mistaken impression that this was a zone safe from non-tech-related, political cow patties.
I first learned to code by being a guinea pig at a Stanford University educational research lab and a volunteer at a Silicon Valley community computer center, then self-taught on "luggable" computers and programmable pocket calculators lent to me on weekends by a generous Hewlett Packard employee, and ultimately on my high school's PDP-8. I learned about computer science, again self-taught, while working as a "research specialist" (read: peon) at the MIT AI Lab.
Notice I didn't talk about my undergraduate education, which mostly involved placing out of CS classes, so not exactly a formal education. I learned more from independent projects than anything else. Professional programming I learned on the job--you almost have to, where else are you going to collaborate with other programmers and make things bulletproof? Absolutely, there's GitHub and open source projects. For me, that came about well after I earned my "sea legs."
But enough about us old farts (and there seem to be a lot of us on Slashdot). How did you millennials learn to program? Where did you find and figure out how to use programming tools/environments? What were your first projects about: The Web, Robotics, Games, something else?
It just goes to show that the bad guys don't do their homework. Bill and Melinda Gates are the biggest philanthropists of all time, their generosity extends the world over, and they have a Middle East Team specifically to benefit Arab countries.
You can all rest assured that this discussion is safe from the prying eyes of optometrists, otherwise one of them would have piped up that...
...there are a number of progressive lenses designed specifically for computer work. These have a larger center sweet spot focused at "monitor distance." My optometrist also taught me an additional trick: If you limit the focal range so infinity is not included, progressive lenses work even better for computer work. These are designed specifically for indoor "office" work. You'd wear another, less expensive, single prescription "distance" glasses for driving, etc. (keep them in your glove compartment).
There has never been a better time in history to dive into robotics from where you are coming from. There are a solid handful of really high quality, on-line vendors that sell individual parts and complete robot kits. For many items there is extensive documentation and a community of hobbyists who help each other get over the growing pains.
My three favorite "robot stores" are
Pololu Robotics and Electronics
SparkFun Electronics
RobotShop (based in Canada)
I don't work for any of these companies, but in the spirit of full disclosure, I did go to school with one of Pololu's founding partners.
When you are pitching to venture capitalists, it will be the rare exception where you can expect any sort of confidentiality. VCs will act in their own interests, and if they think that leaking/sharing something you told them will help make them money, they will do it.
They don't care about the details of your algorithms. They probably won't understand what you say anyway. They only care about what your technology will do for them (i.e. make them piles money).
More important than any technical details is the assurance that you can protect yourself from copycats.
And of course they also want some assurance that you can be trusted to make money with their money, should they give it to you.
Use your PowerPoint deck to tell them about your past successes, your credentials, your well researched business plan, how you are uniquely qualified to make their investors money, and how much interest you've been getting from competing sources of funding.
Back when I worked on digital camera firmware in 2004, our Taiwanese manufacturing partner asked us to make sure our USB interface worked with Windows 95, claiming that a significant number of their mainland customers were still using this ancient OS. Maybe they're still buying floppies too.
Flash is a serious battery waster on laptops too
on
Apple iPad Reviewed
·
· Score: 2, Informative
I'm not surprised Apple doesn't support Flash on the iPhone and iPad. I can personally testify that Flash is a serious battery-life waster on laptops too. One morning I was using a web site that had an animated banner ad at the top of each and every page, and I got only 2.5 hours out of my unibody 13" MacBook Pro's "9 hour battery." Without Flash running I can get at least six hours. Then I found the BashFlash app, and realized how often Flash takes 30+% of the CPU. Now I regularly use it to kill the Flash plug-in. Too bad Adobe doesn't give you tools to manage irresponsible Flash adds. A second or two of animation would be fine, after that Flash should "dial it down," but no... continuous attention-grabbing is what the advertisers seem to want, at the expense of my hard-earned battery life!
The 4004 family was fabbed using a 10um pMOS process. Single metal, single poly, self-aligned gate. No depletion. Buried contacts were only used in the 4004 due to density requirements. Pretty sure the rest (4001, 4002, and 4003) used the same process as Intel's SRAMs of the day (e.g. the 1101). Not sure how the diff layer was made. I can ask. Bootstrap loads were used for high-side of push-pull inverters needed to drive big loads. Much to my surprise, diff was used instead of poly for interconnect that couldn't be done in metal.
If you want lots of current and future tech professionals to hate you, keep hassling small businesses like SparkFun. Your trademark case against them borders on frivolous. It is a battle that you are unlikely to win in court, and that you will certainly lose in the court of public opinion. Stick with your bread and butter mission: championing the SPARC architecture. Leave popular "Davids" alone, unless the goal is to smear your own brand name.
In grad school I studied and developed methods to make programming accessible to young children. At the time, the general consensus in the field was that before the ages of 11-14, children don't typically have the cognitive ability to write programs, even simple ones. Even though I am a professional programmer now, when I was introduced to BASIC at age 9, I definitely didn't "get it." When I got to 7th grade I did.
Radia Perlman did some groundbreaking work in the 1970's to develop technology in the hope that 6-years-old could learn programming skills. Years later, Ken Kahn developed a game/programming environment called ToonTalk. From my personal experience and research, I don't think you can expect kids younger than 9 to build and program robots, but they can start playing with the physical and conceptual "building blocks."
I see from LEGO's literature that WeDo is aimed at children 7-11 years old. Their approach is very sensible: Keep things very, very simple: One motor, one motion sensor, and one tilt sensor. RoboSoccer can wait until they are older.
Back in the late-60's and early-70's, when the Busicom 141-PF calculator software was written, United States copyright law was very different, you needed to explicitly mark a work with a copyright symbol, and register it with the U.S. Copyright Office. Nowadays everything is automatically protected by copyright law. Back then it was not. There was no copyright on the Busicom binaries, so this code is free-and-clear. The re-created "source code" was written without access to the original Busicom source code. In this sense it was done using techniques similar to a traditional "clean room".
Barry and Brian Silverman wrote a disassembler, and we all stared at the disassembled code a bunch, then they started running the calculator code in their homebrew simulation of the 4004 and the rest of the calculator hardware. They fiddled with it until they got the printer and keyboard interfaces modeled correctly. The printer serves as the calculator's "heartbeat" in a fundamentally important way. If it "spins" too fast, the calculator stops working. At this point we had a pretty good idea, "from a 10,000 foot level" how the calculator worked, it's overall design, etc.
What Lajos did was "take it down to sea level." He put tons of time into understanding how the byte code worked, what every single opcode did, what every single 4004 subroutine did, and what algorithms were used to do the computations (e.g. square root). He extensively studied the behavior of the calculator to discover anomalous behavior that made us wonder if there were transcription errors when we read the original ROMs. To see if read the ROMs correctly, we hope one day to compare our results with a working Busicom 141-PF. There are only a couple working ones in existence. We are pretty sure Lajos found one single-bit error, but it doesn't seem to affect the calculator operation in an important way, so we left it. There are other anomalies that, if not intentional, fall into the category of "emergent behavior" like the divide-by-zero you get when you press "=" on a completely cleared calculator. Our simulation is "bug for bug compatible" with the original calculator in this respect. Another example of the analysis Lajos did was to figure out that one of the byte code opcodes was a "branch always." This means there are a few extra arrows on the flowchart diagram that we will want to remove when we get a chance.
By "authentic" I mean the original Busicom 141-PF calculator firmware running on an Intel 4004 instruction-level simulator with printer and keyboard hardware simulated in software. This is all described in the documentation available at http://www.4004.com/
Intel only patented the time-multiplexed bus and memory architecture of the 4004 family (US patent 3,821,715), and its reset circuitry (US patent 3,753,011). The schematics were a trade secret until relatively recently.
Slashdot Mirror
It bums me out when the first time I hear about something cool is when it's getting shut down. I sounds like this Google project/subsidiary was doing great work, but Google didn't bother to give them a marketing department. Then they say it isn't viable. Catch 22 - QED.
Eval has been part of the Lisp programming language since the dawn of computing, but few experienced Lisp programmers ever used it outside of read-eval-print loops and software development tools (where its existence is a totally awesome gift). Eval is widely considered a beginner's trap. It is rarely "the right thing," typically because it is super inefficient. But my biggest concern is that it is a huge security hole, especially when the expression to be evaluated comes from the user. Think SQL injection attack. It is wise to require some sort of security credentials and/or filters to make sure the expression is within a "safe subset" of the language... at which point you might as well write the mini-interpreter you really need, instead of making the entire, underlying language and the application's entire data environment available for anyone to use or misuse.
This might be a new idea in the U.S., but at one of Canada's premier colleges, this is already old hat. Go look at McGill University's "menu" of tuition fees. You'll see that they charge radically lower rates to the art student, English major, or nursing student compared to the computer scientist or pre-med. I hadn't thought of the costs of running these programs, but up in Montreal they almost certainly did. What seemed striking to me is how compassionate this policy is for the student. Is it coincidental that these Canadian tuition rates happen to be scaled to the earning potential of the graduate? So no more crazy high debt for your "B.A. in Barista." But for super in-demand and high-paid software engineers? Sure, they think you can afford to pay off those big loans. Oh, but wait... if you are a Quebec resident, your tuition will be so low that you won't need any big loans! 20/20 hindsight: if only we had moved to Canada, my wife and teenagers would have been way less stressed.
This is a myth. Viking and Voyager used custom processors.
The 4004 was used in the first electronic taximeter, the Argo Kiensle 1140, and these were in service for many decades, but have since been largely replaced. I'd speculate that there are still some traffic lights that have an Intel 4004 inside. The chip went out of production in 1986.
This is the best suggestion I've read so far!
I can't remember encountering such obvious political mud-slinging here on Slashdot before. I guess I was under the mistaken impression that this was a zone safe from non-tech-related, political cow patties.
I first learned to code by being a guinea pig at a Stanford University educational research lab and a volunteer at a Silicon Valley community computer center, then self-taught on "luggable" computers and programmable pocket calculators lent to me on weekends by a generous Hewlett Packard employee, and ultimately on my high school's PDP-8. I learned about computer science, again self-taught, while working as a "research specialist" (read: peon) at the MIT AI Lab.
Notice I didn't talk about my undergraduate education, which mostly involved placing out of CS classes, so not exactly a formal education. I learned more from independent projects than anything else. Professional programming I learned on the job--you almost have to, where else are you going to collaborate with other programmers and make things bulletproof? Absolutely, there's GitHub and open source projects. For me, that came about well after I earned my "sea legs."
But enough about us old farts (and there seem to be a lot of us on Slashdot). How did you millennials learn to program? Where did you find and figure out how to use programming tools/environments? What were your first projects about: The Web, Robotics, Games, something else?
It just goes to show that the bad guys don't do their homework. Bill and Melinda Gates are the biggest philanthropists of all time, their generosity extends the world over, and they have a Middle East Team specifically to benefit Arab countries.
...there are a number of progressive lenses designed specifically for computer work. These have a larger center sweet spot focused at "monitor distance." My optometrist also taught me an additional trick: If you limit the focal range so infinity is not included, progressive lenses work even better for computer work. These are designed specifically for indoor "office" work. You'd wear another, less expensive, single prescription "distance" glasses for driving, etc. (keep them in your glove compartment).
My three favorite "robot stores" are
I don't work for any of these companies, but in the spirit of full disclosure, I did go to school with one of Pololu's founding partners.
When you are pitching to venture capitalists, it will be the rare exception where you can expect any sort of confidentiality. VCs will act in their own interests, and if they think that leaking/sharing something you told them will help make them money, they will do it. They don't care about the details of your algorithms. They probably won't understand what you say anyway. They only care about what your technology will do for them (i.e. make them piles money). More important than any technical details is the assurance that you can protect yourself from copycats. And of course they also want some assurance that you can be trusted to make money with their money, should they give it to you. Use your PowerPoint deck to tell them about your past successes, your credentials, your well researched business plan, how you are uniquely qualified to make their investors money, and how much interest you've been getting from competing sources of funding.
In case you are finding that securityblog.verizonbusiness.com is refusing your connections, here is a cached version of the source article: http://webcache.googleusercontent.com/search?q=cache:http://securityblog.verizonbusiness.com/2013/01/14/case-study-pro-active-log-review-might-be-a-good-idea/
Back when I worked on digital camera firmware in 2004, our Taiwanese manufacturing partner asked us to make sure our USB interface worked with Windows 95, claiming that a significant number of their mainland customers were still using this ancient OS. Maybe they're still buying floppies too.
I'm not surprised Apple doesn't support Flash on the iPhone and iPad. I can personally testify that Flash is a serious battery-life waster on laptops too. One morning I was using a web site that had an animated banner ad at the top of each and every page, and I got only 2.5 hours out of my unibody 13" MacBook Pro's "9 hour battery." Without Flash running I can get at least six hours. Then I found the BashFlash app, and realized how often Flash takes 30+% of the CPU. Now I regularly use it to kill the Flash plug-in. Too bad Adobe doesn't give you tools to manage irresponsible Flash adds. A second or two of animation would be fine, after that Flash should "dial it down," but no... continuous attention-grabbing is what the advertisers seem to want, at the expense of my hard-earned battery life!
The 4004 family was fabbed using a 10um pMOS process. Single metal, single poly, self-aligned gate. No depletion. Buried contacts were only used in the 4004 due to density requirements. Pretty sure the rest (4001, 4002, and 4003) used the same process as Intel's SRAMs of the day (e.g. the 1101). Not sure how the diff layer was made. I can ask. Bootstrap loads were used for high-side of push-pull inverters needed to drive big loads. Much to my surprise, diff was used instead of poly for interconnect that couldn't be done in metal.
If you want lots of current and future tech professionals to hate you, keep hassling small businesses like SparkFun. Your trademark case against them borders on frivolous. It is a battle that you are unlikely to win in court, and that you will certainly lose in the court of public opinion. Stick with your bread and butter mission: championing the SPARC architecture. Leave popular "Davids" alone, unless the goal is to smear your own brand name.
http://blogofbile.com/wp-content/uploads/2009/04/30/a_scary_thing_happened.pdf
In grad school I studied and developed methods to make programming accessible to young children. At the time, the general consensus in the field was that before the ages of 11-14, children don't typically have the cognitive ability to write programs, even simple ones. Even though I am a professional programmer now, when I was introduced to BASIC at age 9, I definitely didn't "get it." When I got to 7th grade I did.
Radia Perlman did some groundbreaking work in the 1970's to develop technology in the hope that 6-years-old could learn programming skills. Years later, Ken Kahn developed a game/programming environment called ToonTalk. From my personal experience and research, I don't think you can expect kids younger than 9 to build and program robots, but they can start playing with the physical and conceptual "building blocks."
I see from LEGO's literature that WeDo is aimed at children 7-11 years old. Their approach is very sensible: Keep things very, very simple: One motor, one motion sensor, and one tilt sensor. RoboSoccer can wait until they are older.
For further information
The link in the article is to David Merrill's talk at TED2009. Here is a link to David's Siftables project page at the MIT Media Lab
Back in the late-60's and early-70's, when the Busicom 141-PF calculator software was written, United States copyright law was very different, you needed to explicitly mark a work with a copyright symbol, and register it with the U.S. Copyright Office. Nowadays everything is automatically protected by copyright law. Back then it was not. There was no copyright on the Busicom binaries, so this code is free-and-clear. The re-created "source code" was written without access to the original Busicom source code. In this sense it was done using techniques similar to a traditional "clean room".
Barry and Brian Silverman wrote a disassembler, and we all stared at the disassembled code a bunch, then they started running the calculator code in their homebrew simulation of the 4004 and the rest of the calculator hardware. They fiddled with it until they got the printer and keyboard interfaces modeled correctly. The printer serves as the calculator's "heartbeat" in a fundamentally important way. If it "spins" too fast, the calculator stops working. At this point we had a pretty good idea, "from a 10,000 foot level" how the calculator worked, it's overall design, etc.
What Lajos did was "take it down to sea level." He put tons of time into understanding how the byte code worked, what every single opcode did, what every single 4004 subroutine did, and what algorithms were used to do the computations (e.g. square root). He extensively studied the behavior of the calculator to discover anomalous behavior that made us wonder if there were transcription errors when we read the original ROMs. To see if read the ROMs correctly, we hope one day to compare our results with a working Busicom 141-PF. There are only a couple working ones in existence. We are pretty sure Lajos found one single-bit error, but it doesn't seem to affect the calculator operation in an important way, so we left it. There are other anomalies that, if not intentional, fall into the category of "emergent behavior" like the divide-by-zero you get when you press "=" on a completely cleared calculator. Our simulation is "bug for bug compatible" with the original calculator in this respect. Another example of the analysis Lajos did was to figure out that one of the byte code opcodes was a "branch always." This means there are a few extra arrows on the flowchart diagram that we will want to remove when we get a chance.
The CNN article has a much more informative article than the New York Times article cited in the Slashdot article.
By "authentic" I mean the original Busicom 141-PF calculator firmware running on an Intel 4004 instruction-level simulator with printer and keyboard hardware simulated in software. This is all described in the documentation available at http://www.4004.com/
Intel only patented the time-multiplexed bus and memory architecture of the 4004 family (US patent 3,821,715), and its reset circuitry (US patent 3,753,011). The schematics were a trade secret until relatively recently.