...what other obvious things we didn't really bother to check?
Well, let's see here:
Economics:
1) Sovereign debt is not like ordinary debt, so it's OK for the US to have a large deficit 2) A little inflation is good (but we can't tell you what the best value actually is)
Medicine:
1) Depression is a disease, and not a consequence of another disorder (as "fever" is) 2) Depression meds actually work 3) Obesity can be fixed by a) diet, b) exercise, or c) eating less 4) Every medical study that hasn't been replicated at least once
Psychology:
1) Seeing a psychiatrist has more benefit than not seeing one 2) Every study which hasn't been replicated at least once (More info)
Social sciences:
1) Every study which hasn't been replicated at least once
Physics, Chemistry, other "hard" sciences:
Nothing, really. Most everything of note has been replicated and confirmed by independent experimenters.
If you have a better idea, please elaborate. For some reason completely oblivious to you, preparation against catastrophic events costs money.
Well, then. Let's see what we have here:
1) Reduce the number of aircraft carriers from 10 (+3 under construction) to 5 2) Spend less on military than the rest of the world combined. Reduce the amount by half. 3) Stop waging war in Afghanistan. Pull out of Afghanistan entirely and bring our people home. 4) Stop the war on drugs. Release everyone jailed for non-violent drug-related crime. 5) Stop the war on immigrants. Allow an easy and expensive path to citizenship. (Note: Our population is declining and we need more taxpayers.) 6) Stop the war on tourism. Disband homeland security, allow unencumbered and easy travel within the US. Redirect the TSA money away from worthless scanners and put it towards intelligence.
That's just off the top of my head. Search for "ways the federal government can save money" and get a zillion hits. Google is your friend.
(Ending Saturday delivery of mail would save an est. $1.7 - $3.1 billion alone. How much did you say those satellites cost?)
Someone care to do a cultural translation for an european why its okay for kids to play with tanks and guns(both seen in TFA video) yet them seeing naked people is like your kids life is ruined?
Because the universe was created by an all-powerful all-knowing being who came down to us in the form of a cosmic Jewish Zombie who was his own father who can make you live forever if you symbolically eat his flesh and telepathically tell him you accept him as your master.
He can remove an evil force from your soul that is present in humanity because a rib-woman was convinced by a talking snake to eat from a magical tree.
He has defined a category of behaviours which are biologically imperative but which we should not do, lest he judge us unworthy in his eyes and stick us in his personal torture chamber for all eternity.
Showing naked people to children encourages them to have sex in ways which are not permitted, which will get them sent to the eternal torture chamber.
If you have difficulty expressing yourself in front of others for whatever reason (stage fright, for instance) consider joining Toastmasters.
It's a club for people who want to learn to speak in front of an audience. It's got branch clubs all over the world, so there's probably one near you. They meet twice a month (more or less - depending on the club) and have a nominal yearly dues.
After about two years of going you start to "get the hang of it" and become more relaxed and fluent when talking to groups.
If you think you might get a Skype interview and if you have trouble with presentations, you should check them out.
I read a more in-depth report of the incident. Mr. Weir phoned the police, who suggested all of the things one would expect: turning off the engine, shifting to neutral, &c.
Mr. Weir was unable to stop the car using the foot brake alone, and only "just barely" managed to stop the car using both the handbrake *and* the foot brake *while* hopped up on adrenaline.
Anyone in worse physical shape than Mr. Weir (a 22-year old male) would have considerable difficulty stopping a vehicle under those circumstances.
Oh, and read the report: he was speeding for 30 minutes and had time to call the police. He didn't inadvertently have his foot on the gas.
This might indeed be bull, but I've got good evidence in support of my statements.
The actual error was more nuanced than I had room to describe in the comment.
Car systems pass messages to each other using an internal buss. In this particular incident, one of the systems failed in a way that made it continuously spew out messages, using all the bandwidth so that no other system could get a message through.
The brakes will normally abort cruise control, but there's no direct wire to the engine computer - it's all messages passed around on the buss. Similar with the On/Off button (newer cars) and shift-by-wire.
It was determined experimentally that the operator is not strong enough to overpower the engine using the brakes. The engine would just downshift for more power.
It all boils down to the safety "mindset": you code the systems to fail safe instead of fail dangerous.
I maintain that the engine CPU should automatically abort cruise control if it doesn't see a periodic heartbeat from the steering-wheel computer.
My previous was modded up, so here's some more checks.
During boot, the system would execute a representative sample of CPU instructions, in order to test that the CPU wasn't damaged. Every mode of memory storage (ptr, ptr++, --ptr), add, subtract, multiply, divide, increment &c.
During boot, all memory was checked - not a burin-in test, just a quick check for integrity. The system wrote 0, 0xFF, A5, 5A and read the output back. This checked for wires shorted to ground/VCC, and wires shorted together.
During boot, the.bss segment was filled with a pattern, and as a rule, all programs were required to initialize all of their static variables. Each routine had an xxxINIT function which was called at boot. You could never assume a static variable was initialized to zero - this caught a lot of "uninitialized variable" errors.
(This allowed us to reboot specific systems without rebooting the system. Call the SerialINIT function, and don't worry about reinitializing that section's static vars.)
The program code was checksummed (1K at a time) continuously.
When filling memory, what pattern should you use? The theory was that any program using an uninitialized variable would crash immediately because of the pattern. 0xA5 is a good choice:
1) It's not 0, 1, or -1, which are common program constants. 2) It's not a printable character 3) It's a *really big* number (negative or unsigned), so array indexing should fail 4) It's not a valid floating point or double 5) Being odd, it's not a valid pointer
Whenever we use enums, we always start the first one at a different number; ie:
enum Day { Sat = 100, Sun, Mon... } enum Month { Jan = 200, Feb, Mar,... }
Note that the enums for Day aren't the same as Month, so if the program inadvertently stores one in the other, the program will crash. Also, the enums aren't small integers (ie - 0, 1, 2), which are used for lots of things in other places. Storing a zero in a Day will cause an error.
(This was easy to implement. Just grep for "enum" in the code, and ensure that each one starts on a different "hundred" (ie - one starts at 100, one starts at 200, and so on).)
The nice thing about safety cert is that the hardware engineer was completely into it as well. If there was any way for the CPU to test the hardware, he'd put it into the design.
You could loopback the serial port (ARINC on aircraft) to see if the transmitter hardware was working, you could switch the A/D converters to a voltage reference, he put resistors in the control switches so that we could test for broken wires, and so on.
(Recent Australian driver couldn't get his vehicle out of cruise-control because the on/off control wasn't working. He also couldn't turn the engine off (modern vehicle) nor shift to neutral (shift-by-wire). Hilarity ensued. Vehicle CPU should abort cruise control if it doesn't see a periodic heartbeat from the steering-wheel computer. But, I digress...)
If you're interested in the software safety systems, look up the Therac some time. Particularly, the analysis of the software bugs. Had the system been peppered with ASSERTs, no deaths would have occurred.
P.S. - If you happen to be building a safety cert system, I'm available to answer questions.
If you suspect the compiler is generating invalid machine code, try to make a minimal test case for it. If you succeed, file a bug report and add that test case; the compiler developers will appreciate it. If you don't succeed in finding a minimal test case that triggers the same issue, it's likely not a compiler bug but an issue in your program in some place where you weren't expecting it.
Yeah, right. Let's see how that works out in practice.
I go to the home page of the project with bug in hand (including sample code). Where do I log the problem?
I have to register with your site. One more external agent gets my E-mail, or I have to take pains to manage multiple E-mails to avoid spam. (I don't want to be part of your community! I just thought you wanted to make your product better.)
Once registered, I'm subscribed to your newsletter. (My temp E-mail has been getting status updates from the GCC crowd for years. My mail reader does something funky with the subject line, so responding with "unsubscribe" doesn't work for me.)
Once entered, my E-mail and/or name is publicly available on the bug report for the next millenium. In plain text in the bug report, and sometimes in the publicly-accessible changelog - naked for the world to see (CPAN is especially fragrant).
Some times the authors think it's the user's problem (no, really? This program causes gcc to core dump. How can that be *my* fault?) Some times the authors interpret the spec different from everyone else (Opera - I'm looking at you). Some times you're just ignored, some times they say "We're rewriting the core system, see if it's still there at the next release", and some times they say "it's fixed in the next release, should be available in 6 months".
What you really do is figure out the sequence of events that causes the problem, change the code to do the same thing in a different way (which *doesn't* trigger the error), and get on with your life. I've given up reporting bugs. It's a waste of time.
That's how you deal with compiler bugs: figure out how to get around them and get on with your work.
We deal with this type of bug all the time in safety-certified systems (medical apps, aircraft, &c).
Most of the time an embedded program doesn't use up 100% of the CPU time. What can you do in the idle moments?
Each module supplies a function "xxxBIT" (where "BIT" stands for "Built In Test") which checks the module variables for consistency.
The serial driver (SerialBIT) checks that the buffer pointers still point within the buffer, checks that the serial port registers haven't changed, and so on.
The memory manager knows the last-used static address for the program (ie - the end of.data), and fills all unused memory with a pattern. In it's spare time (MemoryBIT) it checks to make sure the unused memory still has the pattern. This finds all sorts of "thrown pointer" errors. (Checking all of memory takes a long time, so MemoryBIT only checked 1K each call.)
The stack pointer was checked - we put a pattern at the end of the stack, and if it ever changed we knew something want recursive or used too much stack.
The EEPROM was checksummed periodically.
Every module had a BIT function and we check every imaginable error in the processor's spare time - over and over continuously.
Also, every function began with a set of ASSERTs that check the arguments for validity. These were active in the released code. The extra time spent was only significant in a handful of functions, so we removed the ASSERTs only in those cases. Overall the extra time spent was negligible.
The overall effect was a very "stiff" program - one that would either work completely or wouldn't work at all. In particular, it wouldn't give erroneous or misleading results: showing a blank screen is better than showing bad information, or even showing a frozen screen.
(Situation specific: Blank screen is OK for aircraft, but not medical. You can still detect errors, log the problem, and alert the user.)
Everyone says to only use error checking during development, and remove it on released code. I don't see it that way - done right, error checking has negligible impact, and coupled with good error logging it can turbocharge your bug-fixing.
Languages which are simple to learn (c++, for example)
WHAT?
Ahem. "Languages which are simple to learn (c++, for example)".
Perl has lots more reserved words than c++.
(Examples: "say", "not", "and", "open")
Perl has lots more operators than c++
(Example: "//" is an operator in perl. So is "<=>", "+/*", "..", and "eq").
(See if you can understand the flip flop operator on first reading.)
Perl has several contexts, and the meaning of an operator or function is context dependent.
(Example contexts: "scalar", "list", "null", "string")
(Example differences: Saying "$i = sort @array" has a completely different meaning from "@i = sort @array")
Perl distinguishes a variable from its value.
(Example: $i = 12; followed by $i = "twelve". The same variable, points to one of two values in memory. C++ binds the variable to the memory location, perl does not. Programmers have trouble wrapping their mind around this.)
Perl references are not pointers (but have some similarities). C++ programmers have a hard time with this also.
Perl has all the overloading and class syntax found in c++.
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.
In the demo phase, you're not really worried about performance. The goal is to have something working as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language which can be more easily optimized.
Languages which are simple to learn (c++, for example) are generally not very expressive. You end up wasting tons of time debugging issues of memory allocation, library interface details, and datatype conversion.
Languages which are expressive are a little harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.
Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher.
And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.
Perl was written by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it it's much more expressive. The following single line:
unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:
@Files = ;
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
Those of us old enough to remember times before the space station will recall that scientists at the time felt that the space station would be a waste. They felt that more important and useful science could be accomplished by spending the money in other areas of space research.
Furthermore, when various sources of research are ranked by "return on investment", government research always lands on the bottom of the list. Government-funded research is always more expensive and less controversial than research from the private sector. (One reason why research competitions are effective.)
People here may recall those times when, a decade-or-so ago, NASA was euphemistically called "No Access to Space for Anyone" because they stood four-square against anyone from the private sector making any attempts at space launch.
The big picture is good, and the space station has rewarded us with many new research results, but I have to wonder whether those $150 billion would have been better spent as prize money for private-research breakthroughs.
Feel free to push your own personal agenda by appealing to people's emotions.
For policy, what do scientific studies say?
Would you still advocate more restrictive gun laws if doing so increases crime?
Would you still advocate more restrictive gun laws if doing so resulted in more children being massacred, on average?
Would you still advocate more restrictive gun laws if it allowed for more abusive police?
Would you still advocate more restrictive gun laws if doing so allowed the country to perform genocide?
Give it a rest already. My sympathies go out to the families and survivors of the tragedy in Connecticut, but using the incident to drive wrong-headed policy will only make matters worse.
We're engineers and scientists, we think for a living. Don't let your heart rule your head.
This debate occurred in the 19th century. It's over. The answer is a resounding no. As in not at at all. Forget it. Give it up.
Did we know everything about economics back then? That comes a quite a surprise.
I was under the impression that we thought (at the time) that:
1) Population would grow exponentially (see Malthus). 2) Individual consumption would grow without bounds
It's clear that population tends to level off and then decline - it's doing that for all of the first-world countries right now. This wasn't obvious for a long time, and it wasn't expected back then. This is a pretty basic change in assumptions - shouldn't that lead to a rethinking of those 1800's theories?
It's also clear that consumption is not infinite either: once people reach a level of comfort that they enjoy, there is a decreasing level of need. Not true for all people of course, but there's a sizeable downshifter movement.
Economics is a series of stories dressed up with a little math. It's "schools of thought" and "expert opinions" - if you don't believe this, try to determine the value of inflation that is best. If the answer is "it depends", then try to determine the dependency formula.
If you study economics as history you'll be able to repeat statements like the one above. That's what economics majors are taught to do.
If you take the trouble to actually analyze economics, as a scientist would, you will realize that there is a tsunami of economic upheaval on the way: obvious and predictable by anyone.
Yes, technology is eroding jobs... but that's the wrong way to look at it.
Technology makes high levels of production, but doesn't increase human leisure.
I see no reason why any country should bow to pressure to stop developing weaponry.
For one thing, it speaks to the sovereignty of the nation in question in the most basic way possible. Weapons can be used to protect citizens from the overbearing dictates of another country. Open yourself to unbridled foreign dictates and they could sack your country. See Danegeld.
For another, as pointed out regularly here on Slashdot, weapons don't kill people - people kill people. If you can argue that the problem is the weapon and not the people (and their interactions), then you're starting down the slippery slope of intercession, pre-emptive war, and so on. Where do you draw the line? Can you dictate to stop other behaviours that don't affect you directly, but that you don't like? Drug farming? Copyright infringement? Smoking? Stem cell research?
And finally, the general feel here on Slashdot is that places like Iran, NK, et al should not be allowed to have weapons because they would probably use them.As others have pointed out, as soon as a country gets nuclear capability the US stops meddling and takes a more respective stance (viz: India, Pakistan). At the same time we decry US policies that anger other countries and make the world our enemy. If Iran has nuclear capability, it will cause our government to step back from imperialist meddling.
NK should be free to develop whatever they want in whatever form they want. It is only when they start affecting the people of other nations that remedial measures should be taken.
And yes - this may mean that a tragic incident happens followed by overwhelming response. This scenario will be better in the long run than leaving things to fester unaddressed. The stark aftermath of the Japan [nuclear] bombing caused the world to be more cautious and circumspect. Had the US *not* bombed Japan, the first nuclear exchange (in the cold war) would have been with improved technology and better delivery vehicles. Much, much worse.
Let them develop whatever they want. There is no upside to us being a bully.
Note that this risk reduction is associated with death due specifically to oral/pharyngeal cancer, not the cancer alone -- it does not follow from these results that drinking coffee reduces your risk of getting cancer. If you get oral/pharyngeal cancer, but die from being impaled by an angry unicorn, it doesn't count for the purposes of this result / association.
Thank you! A beacon of logic in an attic of doubt and uncertainty.
In order to assess the risk, we need to compare the total risk of drinking coffee with the total risk of not drinking coffee. Just examining and comparing one aspect is not enough - we need to take everything into account.
I've been considering starting to drink coffee now that I'm getting older (>50 yrs), and have been doing a bunch of research on it. I've found a number of benefits in the literature to drinking coffee; for example, it lowers the risk of kidney stones (surprising, in my view).
I have not found any long-term health disadvantages to drinking coffee (setting aside obvious short-term effects), and the number of benefits is surprising. I'm not ready to consider coffee as "safe" quite yet, but so far as I can tell it's a good bet.
We need a study of the total risk associated with drinking coffee, in the manner that we have total risks associated with smoking and drinking.
Compare a course where you would retain 30% of the content with a course where you would retain 70% of the same content: which would you choose?
Everyone whining about "pandering to the unmotivated" is missing the point: the current class/lecture model started over a thousand years ago and is not optimized for learning. In this century we now know much more about the neurological underpinnings of how people learn, so it makes sense that we should try to optimize the process.
College (or an online course, or work-related training) should be as effective as possible. Some lecturers have this figured out, but most don't.
Stanford is considered a hard school not because the material is difficult, but because it's presented in a way that's hard to learn. Only the brightest and most motivated students can thrive in that situation, which helps to build the "best and brightest" reputation. The reputation comes not from quality of education, but difficulty of education.
(Check out the online videos for Probabilistic Graphical Models by Dr. Daphne Koller at Stanford. Alternately, check out her book on the subject. The book is largely unreadable, and the videos are dreadfully obtuse. Her class at Stanford is well known as a weeder.)
One great aspect of the ongoing MOOC revolution is that everyone is competing on an open field. Instructors using more effective techniques will be perceived as better teachers while the "old-school, cannot change, it's always worked for me" crowd will be left in the dust.
Gamification is a technique for more effective teaching.
Geeks are to blame for most of the loss of human rights on the net.
We write so much software that other geeks use, but can't seem to get a handle on ease-of-use or taking action.
If Thunderbird incorporated the equivalent of Enigmail from the start, lots of people would be using it now. The extra security would be a selling point, causing other applications to compensate by becoming compatible. Over time, every E-mail client would have been secure, some committee would have come up with a standard, and that would be the end of it.
If linux had encryption built into the OS (what are the functions of an OS anyway, if not to manage such things?) so that secure sockets were trivially available, the same thing would happen for other protocols.
Instead, we leave it as an exercise for the user. The user has to know that they want security, then know where and how to get it, then learn how to use it, then convince other people how to do the same. We leave encryption as an exercise to the coder, an add-on to be implemented in every new application.
We have a "reply to all" button, why can't we have a "make private if the recipient has encryption" button?
This sort of mass surveillance can only happen when the surveillance is easy. Why don't we just make it hard?
Instead of wailing and gnashing of teeth, how about we actually solve the problem?
Nota Bene: Yes, there are issues to be resolved, none of which are very difficult. No, perfect security is not attainable, but "good enough" security will help a lot. And no, none of the problems that come to mind are insurmountable.
Okay, I'm not Anonymous, and I haven't taken any Richard Buckland courses.
I have been involved with the MOOC movement since last year (Dr. Thrun's AI class), taken several online courses, and study human learning for my day job. I've evaluated and compared the teaching styles of MOOCs for my own purposes.
From what I've seen of his work online (YouTube videos), Richard Buckland is the best.
In my opinion his style of presentation maximizes the student interest. Regardless of the content, Richard Buckland will make learning enjoyable; he will cultivate the student's interest and perceived value.
Coursera and edX believe in the "learning is hard" model - they present artificial barriers and difficulties so that only the most intelligent and dedicated student will complete the course. For an example, watch the first lecture or two of Daphne Koller's "Probabalistic Graphical Models" online course.
Richard Buckland takes the view of "learning is fun", and does everything he can to motivate the students. He's been trying out different techniques over the years, keeping what works and dropping what doesn't. At this point in his career, he's got a pretty good handle on what encourages students to learn.
I predict that "The Art of Programming" will have the highest completion rate of all the online courses.
Of the course offerings and business models I've seen, this is likely to be the best one to date.
Slashdot Mirror
...what other obvious things we didn't really bother to check?
Well, let's see here:
Economics:
1) Sovereign debt is not like ordinary debt, so it's OK for the US to have a large deficit
2) A little inflation is good (but we can't tell you what the best value actually is)
Medicine:
1) Depression is a disease, and not a consequence of another disorder (as "fever" is)
2) Depression meds actually work
3) Obesity can be fixed by a) diet, b) exercise, or c) eating less
4) Every medical study that hasn't been replicated at least once
Psychology:
1) Seeing a psychiatrist has more benefit than not seeing one
2) Every study which hasn't been replicated at least once (More info)
Social sciences:
1) Every study which hasn't been replicated at least once
Physics, Chemistry, other "hard" sciences:
Nothing, really. Most everything of note has been replicated and confirmed by independent experimenters.
Typo'ed my post. The path to citizenship should read inexpensive.
If you have a better idea, please elaborate. For some reason completely oblivious to you, preparation against catastrophic events costs money.
Well, then. Let's see what we have here:
1) Reduce the number of aircraft carriers from 10 (+3 under construction) to 5
2) Spend less on military than the rest of the world combined. Reduce the amount by half.
3) Stop waging war in Afghanistan. Pull out of Afghanistan entirely and bring our people home.
4) Stop the war on drugs. Release everyone jailed for non-violent drug-related crime.
5) Stop the war on immigrants. Allow an easy and expensive path to citizenship. (Note: Our population is declining and we need more taxpayers.)
6) Stop the war on tourism. Disband homeland security, allow unencumbered and easy travel within the US. Redirect the TSA money away from worthless scanners and put it towards intelligence.
That's just off the top of my head. Search for "ways the federal government can save money" and get a zillion hits. Google is your friend.
(Ending Saturday delivery of mail would save an est. $1.7 - $3.1 billion alone. How much did you say those satellites cost?)
Someone care to do a cultural translation for an european why its okay for kids to play with tanks and guns(both seen in TFA video) yet them seeing naked people is like your kids life is ruined?
Because the universe was created by an all-powerful all-knowing being who came down to us in the form of a cosmic Jewish Zombie who was his own father who can make you live forever if you symbolically eat his flesh and telepathically tell him you accept him as your master.
He can remove an evil force from your soul that is present in humanity because a rib-woman was convinced by a talking snake to eat from a magical tree.
He has defined a category of behaviours which are biologically imperative but which we should not do, lest he judge us unworthy in his eyes and stick us in his personal torture chamber for all eternity.
Showing naked people to children encourages them to have sex in ways which are not permitted, which will get them sent to the eternal torture chamber.
Does this answer your question?
If you have difficulty expressing yourself in front of others for whatever reason (stage fright, for instance) consider joining Toastmasters.
It's a club for people who want to learn to speak in front of an audience. It's got branch clubs all over the world, so there's probably one near you. They meet twice a month (more or less - depending on the club) and have a nominal yearly dues.
After about two years of going you start to "get the hang of it" and become more relaxed and fluent when talking to groups.
If you think you might get a Skype interview and if you have trouble with presentations, you should check them out.
Bull. [...] Breaks can apply many times more force to the wheels than the engine.
Incorrect. Source.
I read a more in-depth report of the incident. Mr. Weir phoned the police, who suggested all of the things one would expect: turning off the engine, shifting to neutral, &c.
Mr. Weir was unable to stop the car using the foot brake alone, and only "just barely" managed to stop the car using both the handbrake *and* the foot brake *while* hopped up on adrenaline.
Anyone in worse physical shape than Mr. Weir (a 22-year old male) would have considerable difficulty stopping a vehicle under those circumstances.
Oh, and read the report: he was speeding for 30 minutes and had time to call the police. He didn't inadvertently have his foot on the gas.
This might indeed be bull, but I've got good evidence in support of my statements.
Like!
Will add to my list of "Best Practices for Safety".
The actual error was more nuanced than I had room to describe in the comment.
Car systems pass messages to each other using an internal buss. In this particular incident, one of the systems failed in a way that made it continuously spew out messages, using all the bandwidth so that no other system could get a message through.
The brakes will normally abort cruise control, but there's no direct wire to the engine computer - it's all messages passed around on the buss. Similar with the On/Off button (newer cars) and shift-by-wire.
It was determined experimentally that the operator is not strong enough to overpower the engine using the brakes. The engine would just downshift for more power.
It all boils down to the safety "mindset": you code the systems to fail safe instead of fail dangerous.
I maintain that the engine CPU should automatically abort cruise control if it doesn't see a periodic heartbeat from the steering-wheel computer.
My previous was modded up, so here's some more checks.
During boot, the system would execute a representative sample of CPU instructions, in order to test that the CPU wasn't damaged. Every mode of memory storage (ptr, ptr++, --ptr), add, subtract, multiply, divide, increment &c.
During boot, all memory was checked - not a burin-in test, just a quick check for integrity. The system wrote 0, 0xFF, A5, 5A and read the output back. This checked for wires shorted to ground/VCC, and wires shorted together.
During boot, the .bss segment was filled with a pattern, and as a rule, all programs were required to initialize all of their static variables. Each routine had an xxxINIT function which was called at boot. You could never assume a static variable was initialized to zero - this caught a lot of "uninitialized variable" errors.
(This allowed us to reboot specific systems without rebooting the system. Call the SerialINIT function, and don't worry about reinitializing that section's static vars.)
The program code was checksummed (1K at a time) continuously.
When filling memory, what pattern should you use? The theory was that any program using an uninitialized variable would crash immediately because of the pattern. 0xA5 is a good choice:
1) It's not 0, 1, or -1, which are common program constants.
2) It's not a printable character
3) It's a *really big* number (negative or unsigned), so array indexing should fail
4) It's not a valid floating point or double
5) Being odd, it's not a valid pointer
Whenever we use enums, we always start the first one at a different number; ie:
enum Day { Sat = 100, Sun, Mon... } ... }
enum Month { Jan = 200, Feb, Mar,
Note that the enums for Day aren't the same as Month, so if the program inadvertently stores one in the other, the program will crash. Also, the enums aren't small integers (ie - 0, 1, 2), which are used for lots of things in other places. Storing a zero in a Day will cause an error.
(This was easy to implement. Just grep for "enum" in the code, and ensure that each one starts on a different "hundred" (ie - one starts at 100, one starts at 200, and so on).)
The nice thing about safety cert is that the hardware engineer was completely into it as well. If there was any way for the CPU to test the hardware, he'd put it into the design.
You could loopback the serial port (ARINC on aircraft) to see if the transmitter hardware was working, you could switch the A/D converters to a voltage reference, he put resistors in the control switches so that we could test for broken wires, and so on.
(Recent Australian driver couldn't get his vehicle out of cruise-control because the on/off control wasn't working. He also couldn't turn the engine off (modern vehicle) nor shift to neutral (shift-by-wire). Hilarity ensued. Vehicle CPU should abort cruise control if it doesn't see a periodic heartbeat from the steering-wheel computer. But, I digress...)
If you're interested in the software safety systems, look up the Therac some time. Particularly, the analysis of the software bugs. Had the system been peppered with ASSERTs, no deaths would have occurred.
P.S. - If you happen to be building a safety cert system, I'm available to answer questions.
If you suspect the compiler is generating invalid machine code, try to make a minimal test case for it. If you succeed, file a bug report and add that test case; the compiler developers will appreciate it. If you don't succeed in finding a minimal test case that triggers the same issue, it's likely not a compiler bug but an issue in your program in some place where you weren't expecting it.
Yeah, right. Let's see how that works out in practice.
I go to the home page of the project with bug in hand (including sample code). Where do I log the problem?
I have to register with your site. One more external agent gets my E-mail, or I have to take pains to manage multiple E-mails to avoid spam. (I don't want to be part of your community! I just thought you wanted to make your product better.)
Once registered, I'm subscribed to your newsletter. (My temp E-mail has been getting status updates from the GCC crowd for years. My mail reader does something funky with the subject line, so responding with "unsubscribe" doesn't work for me.)
Once entered, my E-mail and/or name is publicly available on the bug report for the next millenium. In plain text in the bug report, and sometimes in the publicly-accessible changelog - naked for the world to see (CPAN is especially fragrant).
Some times the authors think it's the user's problem (no, really? This program causes gcc to core dump. How can that be *my* fault?) Some times the authors interpret the spec different from everyone else (Opera - I'm looking at you). Some times you're just ignored, some times they say "We're rewriting the core system, see if it's still there at the next release", and some times they say "it's fixed in the next release, should be available in 6 months".
What you really do is figure out the sequence of events that causes the problem, change the code to do the same thing in a different way (which *doesn't* trigger the error), and get on with your life. I've given up reporting bugs. It's a waste of time.
That's how you deal with compiler bugs: figure out how to get around them and get on with your work.
No, I'm not bitter...
We deal with this type of bug all the time in safety-certified systems (medical apps, aircraft, &c).
Most of the time an embedded program doesn't use up 100% of the CPU time. What can you do in the idle moments?
Each module supplies a function "xxxBIT" (where "BIT" stands for "Built In Test") which checks the module variables for consistency.
The serial driver (SerialBIT) checks that the buffer pointers still point within the buffer, checks that the serial port registers haven't changed, and so on.
The memory manager knows the last-used static address for the program (ie - the end of .data), and fills all unused memory with a pattern. In it's spare time (MemoryBIT) it checks to make sure the unused memory still has the pattern. This finds all sorts of "thrown pointer" errors. (Checking all of memory takes a long time, so MemoryBIT only checked 1K each call.)
The stack pointer was checked - we put a pattern at the end of the stack, and if it ever changed we knew something want recursive or used too much stack.
The EEPROM was checksummed periodically.
Every module had a BIT function and we check every imaginable error in the processor's spare time - over and over continuously.
Also, every function began with a set of ASSERTs that check the arguments for validity. These were active in the released code. The extra time spent was only significant in a handful of functions, so we removed the ASSERTs only in those cases. Overall the extra time spent was negligible.
The overall effect was a very "stiff" program - one that would either work completely or wouldn't work at all. In particular, it wouldn't give erroneous or misleading results: showing a blank screen is better than showing bad information, or even showing a frozen screen.
(Situation specific: Blank screen is OK for aircraft, but not medical. You can still detect errors, log the problem, and alert the user.)
Everyone says to only use error checking during development, and remove it on released code. I don't see it that way - done right, error checking has negligible impact, and coupled with good error logging it can turbocharge your bug-fixing.
WHAT?
Ahem. "Languages which are simple to learn (c++, for example)".
Perl has lots more reserved words than c++.
(Examples: "say", "not", "and", "open")
Perl has lots more operators than c++
(Example: "//" is an operator in perl. So is "<=>", "+/*", "..", and "eq").
(See if you can understand the flip flop operator on first reading.)
Perl has several contexts, and the meaning of an operator or function is context dependent.
(Example contexts: "scalar", "list", "null", "string")
(Example differences: Saying "$i = sort @array" has a completely different meaning from "@i = sort @array")
Perl distinguishes a variable from its value.
(Example: $i = 12; followed by $i = "twelve". The same variable, points to one of two values in memory. C++ binds the variable to the memory location, perl does not. Programmers have trouble wrapping their mind around this.)
Perl references are not pointers (but have some similarities). C++ programmers have a hard time with this also.
Perl has all the overloading and class syntax found in c++.
Perl doesn't have a precompiler.
OK, that last paragraphs should read:
The following line:
@Files = <c:/Windows/*.exe>
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.
In the demo phase, you're not really worried about performance. The goal is to have something working as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language which can be more easily optimized.
Languages which are simple to learn (c++, for example) are generally not very expressive. You end up wasting tons of time debugging issues of memory allocation, library interface details, and datatype conversion.
Languages which are expressive are a little harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.
Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher.
And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.
Perl was written by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it it's much more expressive. The following single line:
@Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;
unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:
@Files = ;
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
Was there a thunderstorm raging outside when this experiment was conducted?
This just seems like the kind of experiment that would be conducted with a thunderstorm raging outside.
Just saying...
Those of us old enough to remember times before the space station will recall that scientists at the time felt that the space station would be a waste. They felt that more important and useful science could be accomplished by spending the money in other areas of space research.
Furthermore, when various sources of research are ranked by "return on investment", government research always lands on the bottom of the list. Government-funded research is always more expensive and less controversial than research from the private sector. (One reason why research competitions are effective.)
People here may recall those times when, a decade-or-so ago, NASA was euphemistically called "No Access to Space for Anyone" because they stood four-square against anyone from the private sector making any attempts at space launch.
The big picture is good, and the space station has rewarded us with many new research results, but I have to wonder whether those $150 billion would have been better spent as prize money for private-research breakthroughs.
We need the ability to take control if the vessel is somehow taken over by terrorists. Or at least disable it.
How about an override switch?
Feel free to push your own personal agenda by appealing to people's emotions.
For policy, what do scientific studies say?
Would you still advocate more restrictive gun laws if doing so increases crime?
Would you still advocate more restrictive gun laws if doing so resulted in more children being massacred, on average?
Would you still advocate more restrictive gun laws if it allowed for more abusive police?
Would you still advocate more restrictive gun laws if doing so allowed the country to perform genocide?
Give it a rest already. My sympathies go out to the families and survivors of the tragedy in Connecticut, but using the incident to drive wrong-headed policy will only make matters worse.
We're engineers and scientists, we think for a living. Don't let your heart rule your head.
This debate occurred in the 19th century. It's over. The answer is a resounding no. As in not at at all. Forget it. Give it up.
Did we know everything about economics back then? That comes a quite a surprise.
I was under the impression that we thought (at the time) that:
1) Population would grow exponentially (see Malthus).
2) Individual consumption would grow without bounds
It's clear that population tends to level off and then decline - it's doing that for all of the first-world countries right now. This wasn't obvious for a long time, and it wasn't expected back then. This is a pretty basic change in assumptions - shouldn't that lead to a rethinking of those 1800's theories?
It's also clear that consumption is not infinite either: once people reach a level of comfort that they enjoy, there is a decreasing level of need. Not true for all people of course, but there's a sizeable downshifter movement.
Economics is a series of stories dressed up with a little math. It's "schools of thought" and "expert opinions" - if you don't believe this, try to determine the value of inflation that is best. If the answer is "it depends", then try to determine the dependency formula.
If you study economics as history you'll be able to repeat statements like the one above. That's what economics majors are taught to do.
If you take the trouble to actually analyze economics, as a scientist would, you will realize that there is a tsunami of economic upheaval on the way: obvious and predictable by anyone.
Yes, technology is eroding jobs... but that's the wrong way to look at it.
Technology makes high levels of production, but doesn't increase human leisure.
I see no reason why any country should bow to pressure to stop developing weaponry.
For one thing, it speaks to the sovereignty of the nation in question in the most basic way possible. Weapons can be used to protect citizens from the overbearing dictates of another country. Open yourself to unbridled foreign dictates and they could sack your country. See Danegeld.
For another, as pointed out regularly here on Slashdot, weapons don't kill people - people kill people. If you can argue that the problem is the weapon and not the people (and their interactions), then you're starting down the slippery slope of intercession, pre-emptive war, and so on. Where do you draw the line? Can you dictate to stop other behaviours that don't affect you directly, but that you don't like? Drug farming? Copyright infringement? Smoking? Stem cell research?
And finally, the general feel here on Slashdot is that places like Iran, NK, et al should not be allowed to have weapons because they would probably use them.As others have pointed out, as soon as a country gets nuclear capability the US stops meddling and takes a more respective stance (viz: India, Pakistan). At the same time we decry US policies that anger other countries and make the world our enemy. If Iran has nuclear capability, it will cause our government to step back from imperialist meddling.
NK should be free to develop whatever they want in whatever form they want. It is only when they start affecting the people of other nations that remedial measures should be taken.
And yes - this may mean that a tragic incident happens followed by overwhelming response. This scenario will be better in the long run than leaving things to fester unaddressed. The stark aftermath of the Japan [nuclear] bombing caused the world to be more cautious and circumspect. Had the US *not* bombed Japan, the first nuclear exchange (in the cold war) would have been with improved technology and better delivery vehicles. Much, much worse.
Let them develop whatever they want. There is no upside to us being a bully.
Note that this risk reduction is associated with death due specifically to oral/pharyngeal cancer, not the cancer alone -- it does not follow from these results that drinking coffee reduces your risk of getting cancer. If you get oral/pharyngeal cancer, but die from being impaled by an angry unicorn, it doesn't count for the purposes of this result / association.
Thank you! A beacon of logic in an attic of doubt and uncertainty.
In order to assess the risk, we need to compare the total risk of drinking coffee with the total risk of not drinking coffee. Just examining and comparing one aspect is not enough - we need to take everything into account.
I've been considering starting to drink coffee now that I'm getting older (>50 yrs), and have been doing a bunch of research on it. I've found a number of benefits in the literature to drinking coffee; for example, it lowers the risk of kidney stones (surprising, in my view).
I have not found any long-term health disadvantages to drinking coffee (setting aside obvious short-term effects), and the number of benefits is surprising. I'm not ready to consider coffee as "safe" quite yet, but so far as I can tell it's a good bet.
We need a study of the total risk associated with drinking coffee, in the manner that we have total risks associated with smoking and drinking.
Compare a course where you would retain 30% of the content with a course where you would retain 70% of the same content: which would you choose?
Everyone whining about "pandering to the unmotivated" is missing the point: the current class/lecture model started over a thousand years ago and is not optimized for learning. In this century we now know much more about the neurological underpinnings of how people learn, so it makes sense that we should try to optimize the process.
College (or an online course, or work-related training) should be as effective as possible. Some lecturers have this figured out, but most don't.
Stanford is considered a hard school not because the material is difficult, but because it's presented in a way that's hard to learn. Only the brightest and most motivated students can thrive in that situation, which helps to build the "best and brightest" reputation. The reputation comes not from quality of education, but difficulty of education.
(Check out the online videos for Probabilistic Graphical Models by Dr. Daphne Koller at Stanford. Alternately, check out her book on the subject. The book is largely unreadable, and the videos are dreadfully obtuse. Her class at Stanford is well known as a weeder.)
One great aspect of the ongoing MOOC revolution is that everyone is competing on an open field. Instructors using more effective techniques will be perceived as better teachers while the "old-school, cannot change, it's always worked for me" crowd will be left in the dust.
Gamification is a technique for more effective teaching.
Geeks are to blame for most of the loss of human rights on the net.
We write so much software that other geeks use, but can't seem to get a handle on ease-of-use or taking action.
If Thunderbird incorporated the equivalent of Enigmail from the start, lots of people would be using it now. The extra security would be a selling point, causing other applications to compensate by becoming compatible. Over time, every E-mail client would have been secure, some committee would have come up with a standard, and that would be the end of it.
If linux had encryption built into the OS (what are the functions of an OS anyway, if not to manage such things?) so that secure sockets were trivially available, the same thing would happen for other protocols.
Instead, we leave it as an exercise for the user. The user has to know that they want security, then know where and how to get it, then learn how to use it, then convince other people how to do the same. We leave encryption as an exercise to the coder, an add-on to be implemented in every new application.
We have a "reply to all" button, why can't we have a "make private if the recipient has encryption" button?
This sort of mass surveillance can only happen when the surveillance is easy. Why don't we just make it hard?
Instead of wailing and gnashing of teeth, how about we actually solve the problem?
Nota Bene: Yes, there are issues to be resolved, none of which are very difficult. No, perfect security is not attainable, but "good enough" security will help a lot. And no, none of the problems that come to mind are insurmountable.
Don't have a Commodore Basic interpreter? this Perl 1-liner will do the same thing:
print ["/","\\"]->[rand(2)] while 1;
It has no start or end point, and for two arbitrary points you can't guarantee that a path exists.
Okay, I'm not Anonymous, and I haven't taken any Richard Buckland courses.
I have been involved with the MOOC movement since last year (Dr. Thrun's AI class), taken several online courses, and study human learning for my day job. I've evaluated and compared the teaching styles of MOOCs for my own purposes.
From what I've seen of his work online (YouTube videos), Richard Buckland is the best.
In my opinion his style of presentation maximizes the student interest. Regardless of the content, Richard Buckland will make learning enjoyable; he will cultivate the student's interest and perceived value.
Coursera and edX believe in the "learning is hard" model - they present artificial barriers and difficulties so that only the most intelligent and dedicated student will complete the course. For an example, watch the first lecture or two of Daphne Koller's "Probabalistic Graphical Models" online course.
Richard Buckland takes the view of "learning is fun", and does everything he can to motivate the students. He's been trying out different techniques over the years, keeping what works and dropping what doesn't. At this point in his career, he's got a pretty good handle on what encourages students to learn.
I predict that "The Art of Programming" will have the highest completion rate of all the online courses.
Of the course offerings and business models I've seen, this is likely to be the best one to date.