You appear to be referring to this article. If so, it's clearly marked as a guest posting which does not reflect the views of the MITNSE authors. And even then most of this posting is just background information on reactor basics - the predictions you're referring to appear to have been removed prior to the publication of this modified version of this article on the MITNSE site.
It's nice that the Beeb has released this fairly calm and unbiased recap, but less sensationalistic coverage from the start would have been a whole lot nicer.
I've been watching the coverage of this story on a bunch of different sites for the past few weeks, and
this is the best I've found - the MIT nuclear science and engineering site. Well written factual articles about the situation, almost entirely devoid of speculation and fearmongering, along with background articles on stuff like how toxic Plutonium is, how radiation doses are measured, etc.
Unfortunately Ivo Vegter is entirely correct: Every mainstream journalist out there should hang their heads in shame in regards to how their profession has covered this incident.
It's quite remarkable what people in this condition can accomplish.
Some years back I used to carpool with my father, a doctor. This meant each day I would go to the hospital after work and wait for him to finish making his rounds. But sometimes he would take me on his rounds if there was something he wanted me to see or someone he wanted me to meet.
One of the people I met this way was a man suffering from ALS. The only things he could move were his eyes and one toe. A sensor was fitted to that toe and hooked up to a microcomputer (a SWITZ system, I think - this was in the early 80s). Despite the crudeness of this setup, he was able to write scholarly papers and even a textbook in his field (geology).
Whenever I'm personally inconvenienced by some health issue or other, I often recall that meeting. And then I stop complaining abount my own lot in life.
I've never taken an theoretical CS class of any sort, but I read, enjoyed, and understood large chunks of Vols 1-3 back when I was a high school senior. Methinks you seriously underestimate the quality of these books and overestimate the difficulty of reading them.
Back in 1983, when I was still in school, I published an article in Dr. Dobb's Journal on how to perform various binary operations efficiently. I also sent a letter to. Knuth describing one algorithm in particular: An efficient means of calculating a weighted sum of the bits in a word.
The minute I put the letter in the mailbox I regretted bothering Knuth with such a trivial matter. I was greatly relieved when there was no response; I assumed the letter had circular-filed.
Then about three years ago I got a phone call from someone working with Knuth. They informed me that after 25 years my letter was about to become an exercise in volume 4A, and asking how I wanted my name to appear in the index. And now the book is out, and there it is: Section 7.1.3, exercise 44.
It goes without saying that I was delighted by what happened. But even more than that, I am in awe of the level of scholarship behind this work, where such a little thing as this algorithm was tracked for almost three decades.
I've read all three (one on paper, the other two on my Kindle), and seen the movies. I enjoyed them all, although the books are clearly better.
One thing I did find annoying, though, was the misstatement of Fermat's last theorem in the second and third books. The book (the English translation at least) has it as x^3+y^3=z^3, rather than the correct x^n+y^n=z^n. Proving the n=3 case isn't especially difficult either - it's a straightforward infinite descent proof. I'm a little surprised nobody caught it between the second and third books.
SMTP is not the problem, the way SMTP is used is the problem.
Today's email protocol suite supports end to end encryption, hop by hop encryption, integrity, signatures, authentication, and a host of other capabilities. And there is widespread support for all this stuff in the email software that's currently deployed.
The problem is that in the email service, as it is currently operated, these various capabilities are not set up in a way that be used to deal with the spam problem.
Instead of defining new service with the right characteristics, what's been done instead is to try and build new facilities like DKIM that are simultaneously compatible with the email service and provide better spam protection. The problem with this approach is the design constraints are pretty severe and you almost always end up with less than what you hoped to do.
Is defining a new service with different operational parameters the right answer? I don't know if it is or not. But what I do know is that there have been at least four attempts to develop standards for "next generation email" so far, and they have all cratered.
So by all means advance the argument that "the current email service sucks". But it is a poor workman who blames their tools.
Converting applications isn't that difficult in most cases. My team works on a large application with many components, and a single engineer was able to make it mostly IPv6-aware in about a month. It was mostly a matter of changing API calls around since the the IPv6 support is there in the OS.
The hard part comes when you actually want to test and deploy this stuff. Getting a lab setup for actually testing IPv6 required a protracted wrangle with the IT folks that took more time than the coding.
And the state with routers and other network-level pieces is NOT good. In particular, the lack of a decent SOHO-grade router/firewall with IPv6 support is a serious obstacle.
I'm surprised nobody has mentioned my former classmate Tony Li. When Tony left Cisco he famously wrote a fairly exasperated letter and nailed it to his office door. That didn't stop Cisco from rehiring him once he left Juniper. Of course Tony is considered to be one of the world's experts on routers. so his ability to get rehired is a little atypical.
If Dawn Johnsen, Obama's appointment for head of the Office of Legal Counsel is any indication, our president-elect is very much behind limiting executive power.
Let's first remember that Bush installed John Yoo in this office, author of the infamous "the President can torture anyone he wants" memo.
In contrast, Johnsen, a law professor at Indiana, has been an extremely harsh and very outspoken critic of the expansion of executive power under Bush. Writing for Slate, she said:
I want to second Dahlia's frustration with those who don't see the newly released Office of Legal Counsel (OLC) torture memo as a big deal. Where is
the outrage, the public outcry?! The shockingly flawed content of this memo, the deficient processes that led to its issuance, the horrific acts it encouraged, the fact that it was kept secret for years and that the Bush administration continues to withhold other memos like it--all demand our outrage.
And here is what she had to say about Bush's violation of FISA:
I'm afraid we are growing immune to just how outrageous and destructive it is, in a democracy, for the President to violate federal statutes in
secret. Remember that much of what we know about the Bush administration's violations of statutes (and yes, I realize they claim not to be violating
statutes) came first only because of leaks and news coverage. Incredibly, we still don't know the full extent of our government's illegal surveillance or illegal interrogations (and who knows what else)-despite Congress's failed
efforts to get to the bottom of it. Congress instead resorted to enacting new legislation on both issues largely in the dark.
Given this I am fairly optimistic that we'll see at least some reversal of the executive power grab that took place under Bush.
A friend of mine is a risk assessment quant who was working at Lehman right up to the point where they declared bankruptcy. I asked him about this article the other day. He said that their models started telling them something was very wrong back in 2007. The problem was that Fuld (the CEO) refused to believe what the models were saying.
The most accurate model in the world won't help if you don't pay atention to the results it produces.
There's also apparently an issue with the classical VaR models depending on transparent pricing, which these real estate instruments lack. So some of the most troublesome assets apparently weren't in the model.
Many years ago there was an incident at the college I was attending where the administration searched a number of student rooms without permission. After getting caught various justifications were given for the search.
I was part of a group of concerned students who decided to write the ACLU and ask about the legality of the college's actions. We wrote the letter, but then decided it would look better if it was cosigned by the student council. Of course that brought the existence of letter out into the open.
After the letter was approved and before it was sent, I was summoned to the office of a chemistry professor, someone I had never had dealings with before. Once there, he proceeded to threaten me with expulsion if the letter was sent, claiming, if memory serves, that it would be some sort of honor code violation.
I responded by laughing at the guy and told him that the letter was going out and that if he took any sort of action against me I would sue his ass and the college's all the way from here to doomsday. He was struck dumb by my response - I don't think it had even occurred to him that he wouldn't get his way.
The letter did go out (and got the predictable response - the college's actions were clearly illegal). And I never heard a single word from this professor again. I still see him from time to time. I always smile and wave, but I don't think he recognizes me.
I'll say this for Dan - he is often quite good at analysis and finding problems. But after watching a huge fight between him and the authors of the
delivery status notification format for email, with the result that positions became completely polarized and nobody succeeded in convincing anyone else of the merits of their respective ideas, I decided the best way to deal with him is to listen to his criticisms, evaluate them carefully, and if it makes sense to address them, do so. But attempting to engage in a meaningful discussion with him is a waste of time - he gets angry way too easily and starts throwing all sorts of nasty invective around, and the result is almost always that the interaction spirals straight down the crapper.
Several years back I watched part of a pizza commercial being filmed. The whole point was for this guy to bite the tip off a slice and basically look like it gave him an orgasm.
Apparently the rules are that they have to use an actual pizza from an actual box. So they had several hundred pies in boxes and a couple of people were busy ripping them open, looking for ones with the most and best looking slices of pepperoni or whatever. The handful that met the standard were rearranged so all the toppings were on one slice and cooked. Once they came out of the oven they'd cut a slice and bring it over to the actor, who was stripped to the waist except for a fake shirt front. (Those lights are HOT.)
When they were ready they'd mop off any sweat, touch up his makeup, and hand him a slice and say, "Take 15" or whatever. He bit and chewed and looked like it was the greatest thing ever. Then the director would yell, "Cut!'
The instant that happened the guy would spit the
bite into a bucket right next to him.
I asked one of the people there if this was typical. I mean, hundreds of pizzas and 15 takes just for 5 seconds. They responded that this was the norm except for shots where someone drinks something. You can't just spit that out and forcing them to vomit it up is too dangerous.
I haven't paid much attention to ad content since.
I was a pollworker here in LA this year. The Inkavote system used, which is standardized across the entire county, is pretty close to what you describe: ID check (for new voters), cross your name off the list, get a ballot, etc. The only refinement is that we have a machine that checks to see if there are any obvious errors on the ballot: Ink where it shouldn't be, overvote (more than one vote in a race), or the ballot is entirely blank. This machine only validates, it does NOT count votes. Actual counting is done later at the ballot collection center.
The entire process is completely open and anyone who wants to observe may do so, from the moment we start setting up the polling place to when we finish taking it all down.
Of course the system isn't perfect, but it sure seems to work pretty well. Pollworking was actually quite fun since so many people were so enthusiastic about voting, especially in this election.
I'm a software engineer but I have to say the thought of using a computer for voting completely creeps me out.
You might want to read a little more of Krugman's positions if you believe that. He was adamantly opposed to the original Paulson bailout plan, which was a banker's wet dream. He was much more in favor of the Dodd plan and eventually came down in favor of the final plan that passed here, but he was far from enthusiastic about it. "Better than nothing, but just barely" sums up his take, I think.
The British plan, OTOH, is one he supports much more wholeheartedly. But the banking community is far from haapy with that plan.
So, the other day I managed to damage my esophagus (a pill I took got stuck in there). I went in to see my GP, who immediately figured out what was going on and prescribed Nexium for a week or two to reduce stomach acid and give my esophagus a chance to heal.
As it happened my doctor had a first year resident with him that day. As my examination proceeded he asked the resident all sorts of questions. (After blowing it by answering one of the questions - correctly I might add - I was instructed to keep my mouth shut except to say "ah".) After some questions about how proton pump inhibitors and how they work, he asked, "What's the difference between Nexium and Prilosec OTC and why did I choose Nexium?"
The resident didn't know the answer. My doctor then said, "Perhaps it will help if I tell you that the chemical name for Nexium is esomeprazole while the name for Prilosec is omeprazole."
Now, I'm an engineer by training, not a chemist or a doctor, but I've studied enough chemistry along the way to know that the former is probably a specific stereoisomer of the latter. So the drugs are almost identical and probably have very similar efficacies, especially in a situation like mine where the problem was fairly minor and treatment duration pretty short.
Thinking about it some more, I arrived at what I suspect was the answer (I'm going to ask my doctor if I was right the next time I see him): "The Purple Pill Called Nexium" is relentlessly promoted - there are ads for it all over the place. Prilosec OTC, as the name implies, is an over the counter medication. Drug reps hand out scads of Nexium samples to doctors - I've seen them do it. Prilosec, not so much - why bother? So, while Nexium is far more expensive if you have to pay for it, no price beats "free as in sample".
And sure enough, instead of writing out a prescription for Nexium my doctor handed a bunch of samples. No cost to me other than the doctor visit.
The resident still didn't get it and was instructed to read up on both drugs.
Of course after I got home I looked up both drugs. I found that there's actually a big controversy about whether Nexium is any better or if it's just an cynical attempt to extend patent protection and keep charging high prices.
I have no idea how often such questions arise in
medical practice, but it seems to me this is exactly the sort of thing where a good grounding in organic chemistry might be a handy thing to have.
I have to agree. I haven't ever played with Medecos, but I have fooled around with Emharts, which I believe are similar. Back in my misspent youth we used to make keys out of the sheet metal used for ventilation ducts. It's usually possible to get the stuff to fit the keyway with 1-2 bends, then cutting it is quite simple. The locks with twisting pins like Medecos reqire a little more effort, but not much.
One of the harder things to do is create a so-called control key - this is the key that removes interchangeable cores from cylinders. The problem is since control keys are not normally used you cannot get ahold of one to copy, and picking the control level of a lock is nearly impossible because you can't get tension on the inner part of the core that turns.
This particular problem was solved for us when some fool threw a defective cylinder in the trash. We drilled it open and had a control key in no time.
This more than anything is the system's biggest weakness - every lock contains the information necessary to break the entire system.
My dentist's office is - no fooling - adjacent to a large FBI office that has these scrambling keypads. I used to think they were pretty cool until I happened to be in the hall when an agent walked up and proceeded to use one.
The guy swiped his badge to start the process, then peered at the keypad, then pressed a button, then took his hand away in order to find the next button, peered at the keypad again, then pressed another button, and so on. I would estimate it took four times as long to operate as a conventional pushbutton lock.
Now, the diplay is apparently only readable from a narrow angle, but that angle doesn't appear to coincide with where someone operating the keypad always stands. So if someone were to install a hidden camera across the hall that can see the keypad... You get the idea.
In this particular case there are also surveillance cameras in the hall that would make it hard to install such a device. But really, requiring continuous surveillance of the door in addition to the lock in order for the setup to be secure is not exactly a testimonial to this technology's effectiveness.
My iPhone is the fourth smartphone I've had. I spent enough time with its predecessors to know all the tricks - and there were plenty of those to learn - to use most of their features. Address book, calendar, camera, games, etc. - at one point I even synced the phone with my laptop regularly.
The trouble was doing all this stuff felt about as good as having a root canal. Sure, there was a keyboard shortcut feature that made a few things easier. But over time almost everything fell into disuse because it was just too painful to operate.
The iPhone has changed my habits completely. Everything that was hard to do is now easy. The only thing I didn't like was having to use a cable to sync it. (But unlike its predecessors the sync always worked flawlessly.) Even that is now a nonissue with MobileMe.
I thought maybe it was just me being too picky. But then...
My wife, whose interest in matters technical is fairly limited, has also had a smartphone for quite a while. (Actually a much nicer one than mine.) But after browsing the manual she never did anything with it - she said it was too much trouble.
Last week she got an iPhone. She hasn't had a moment's difficulty operating it. And she's using the phone's capabilities for the first time. For example, her addressbook is already full of entries, entries she typed into Address Book on her computer and synced to her phone with no help from anyone.
Usability really does matter. And while the iPhone
is a long way from perfect, it represents a substantial advance.
I used to have to restart my Airport Extreme every once in a while, but after updating its firmware that's no longer necessary. According to InterMapper it has been running for 84 days without a restart, and if memory serves the reason it was reset 84 days ago was to do some recabling.
That's a good question. I'll do my best to answer it but since the number of security vulnerabilities of any sort we've had is pretty small I'm not sure how relevant my answer will be.
This is a big company and we have lots of software products. There's a group of folks that analyze the data from our change request (CR) system. I've only met with them once for a review of our product's CRs so my knowledge is pretty skimpy and quite possibly not at all representative, but here's what transpired.
They started with a breakdown of defects by various criteria: Component involved, root cause analysis, etc. It was clear some parts of our products are buggier than others but we already knew that. There was no attempt, however, to pin problems on specific engineers.
Beyond the obvious category stuff the data was really too noisy to draw any strong conclusions.
One interesting observation about the process, however, was that the defects they cared most about were ones that had been filed and not fixed quickly - which seemed pretty reasonable to me.
Then they started drilling into requests for enhancement (RFEs) as opposed to defects. Believe it or not, this was a bigger concern. In particular, it seems we had an unacceptably high number of so-called "escalated RFEs". (Escalations happen when customers "take it to the next" level with support.)
We explained that the reason for this was that our releases had been, in hindsight, too far apart and that in our process the only way to get an enhancement backported from development to a production version was by escalating things with support. In other words, we were being yelled at for having used a process hack to get things done.
To be fair, I suspect that had there been a bunch of outstanding defects with associated escalations we would have been yelled at for that. But there were few if any of those.
As you might expect the immediate action we took was to stop using escalations to request backports. And AFAIK we haven't heard from the tracking people since. So the conclusion here is that what really mattered to them was customer satisfaction as measured by the number of escalations filed.
Now, as for using Secure SDLC, we don't use it and I'm not sure how much better off we'd be if we did. The very few security vulnerabilities we have had have mostly been the result of implementation errors, not design errors. (The defect I mentioned previously is actually one of the rare exceptions.) What we do do (in the parts of the product I work on at least) is try very hard to use secure implementation techniques - use carefully vetted routine libraries, avoid known problematic runtimes, and so on.
Oh, and FWIW, I'm not especially worried about being sued for calling a security vulnerability the defect it is. (This is not to say I don't worry about lawsuits - the possibility of a patent infringement suit coming in out of the blue scares the crap out of me.) We try and deal fairly and openly with our customers and that has worked well for us. (It undoubtedly helps a lot that our customers are almost always other companies, not individuals.) Maybe I'm naive, but I think once you start misrepresenting things to your customers you're far more likely to get into trouble.
AFAIK the Airport Extreme only supports having a single public IP address. That's a big problem when you have servers on more than one address.
(I'd appreciate being correct if you know this isn't the case.)
The various Linksys products have similar issues. It's been a while since I checked so I don't recall all the specific models, but the intersection of 6to4-capable routers with ones that support multiple public IPs, NAT, access controls, and all the other stuff you need appeared to be empty. (And again, if you have information to the contrary I'd love to hear more.)
I've been looking for a viable router solution short of a Cisco that handles multiple public IP address and has 6to4 capabilities and I haven't found anything I like. The closest I've come is DD-WRT, but the ipv6 support there is an command-line-only add-on, not fully integrated, and I've heard it's even busted in v24.
It's hard to see how anyone expects ipv6 to become a reality without support for it in inexpensive routers.
We've treated potential vulnerabilities in our products, even extremely minor ones, as defects for over two decades now. And we have always given them very high priority.
To the best of our knowledge we've never had a remote exploit vulnerability, but even so we've gone so far as to scrap thousands of freshly pressed CDs a day before releasing them because I spotted a way to get root access through a tricky bit of business with shared libraries. (And that was for something spotted internally - no customer ever reported it.)
The real question isn't whether to treat security vulnerabilities as a defect - of course you do - but - somewhat paradoxically - whether or not to treat them as security vulnerabilities. We were acquired some time ago and have now adopted (and adapted to) various more complex procedures typical of a large company. There's this little box you're supposed to check in our current bug reporting system that says "this is a security vulnerability". The problem is that checking that box fires up a whole lot of extra process that rarely helps and can actually hinder prompt resolution of the problem and getting the fix into customer's hands.
Slashdot Mirror
You appear to be referring to this article. If so, it's clearly marked as a guest posting which does not reflect the views of the MITNSE authors. And even then most of this posting is just background information on reactor basics - the predictions you're referring to appear to have been removed prior to the publication of this modified version of this article on the MITNSE site.
It's nice that the Beeb has released this fairly calm and unbiased recap, but less sensationalistic coverage from the start would have been a whole lot nicer.
I've been watching the coverage of this story on a bunch of different sites for the past few weeks, and this is the best I've found - the MIT nuclear science and engineering site. Well written factual articles about the situation, almost entirely devoid of speculation and fearmongering, along with background articles on stuff like how toxic Plutonium is, how radiation doses are measured, etc.
Unfortunately Ivo Vegter is entirely correct: Every mainstream journalist out there should hang their heads in shame in regards to how their profession has covered this incident.
It's quite remarkable what people in this condition can accomplish.
Some years back I used to carpool with my father, a doctor. This meant each day I would go to the hospital after work and wait for him to finish making his rounds. But sometimes he would take me on his rounds if there was something he wanted me to see or someone he wanted me to meet.
One of the people I met this way was a man suffering from ALS. The only things he could move were his eyes and one toe. A sensor was fitted to that toe and hooked up to a microcomputer (a SWITZ system, I think - this was in the early 80s). Despite the crudeness of this setup, he was able to write scholarly papers and even a textbook in his field (geology).
Whenever I'm personally inconvenienced by some health issue or other, I often recall that meeting. And then I stop complaining abount my own lot in life.
I've never taken an theoretical CS class of any sort, but I read, enjoyed, and understood large chunks of Vols 1-3 back when I was a high school senior. Methinks you seriously underestimate the quality of these books and overestimate the difficulty of reading them.
Back in 1983, when I was still in school, I published an article in Dr. Dobb's Journal on how to perform various binary operations efficiently. I also sent a letter to. Knuth describing one algorithm in particular: An efficient means of calculating a weighted sum of the bits in a word.
The minute I put the letter in the mailbox I regretted bothering Knuth with such a trivial matter. I was greatly relieved when there was no response; I assumed the letter had circular-filed.
Then about three years ago I got a phone call from someone working with Knuth. They informed me that after 25 years my letter was about to become an exercise in volume 4A, and asking how I wanted my name to appear in the index. And now the book is out, and there it is: Section 7.1.3, exercise 44.
It goes without saying that I was delighted by what happened. But even more than that, I am in awe of the level of scholarship behind this work, where such a little thing as this algorithm was tracked for almost three decades.
I've read all three (one on paper, the other two on my Kindle), and seen the movies. I enjoyed them all, although the books are clearly better. One thing I did find annoying, though, was the misstatement of Fermat's last theorem in the second and third books. The book (the English translation at least) has it as x^3+y^3=z^3, rather than the correct x^n+y^n=z^n. Proving the n=3 case isn't especially difficult either - it's a straightforward infinite descent proof. I'm a little surprised nobody caught it between the second and third books.
SMTP is not the problem, the way SMTP is used is the problem.
Today's email protocol suite supports end to end encryption, hop by hop encryption, integrity, signatures, authentication, and a host of other capabilities. And there is widespread support for all this stuff in the email software that's currently deployed.
The problem is that in the email service, as it is currently operated, these various capabilities are not set up in a way that be used to deal with the spam problem.
Instead of defining new service with the right characteristics, what's been done instead is to try and build new facilities like DKIM that are simultaneously compatible with the email service and provide better spam protection. The problem with this approach is the design constraints are pretty severe and you almost always end up with less than what you hoped to do.
Is defining a new service with different operational parameters the right answer? I don't know if it is or not. But what I do know is that there have been at least four attempts to develop standards for "next generation email" so far, and they have all cratered.
So by all means advance the argument that "the current email service sucks". But it is a poor workman who blames their tools.
As I recall, the line was that the Yanks were "Oversexed, overpaid and over here".
Converting applications isn't that difficult in most cases. My team works on a large application with many components, and a single engineer was able to make it mostly IPv6-aware in about a month. It was mostly a matter of changing API calls around since the the IPv6 support is there in the OS.
The hard part comes when you actually want to test and deploy this stuff. Getting a lab setup for actually testing IPv6 required a protracted wrangle with the IT folks that took more time than the coding.
And the state with routers and other network-level pieces is NOT good. In particular, the lack of a decent SOHO-grade router/firewall with IPv6 support is a serious obstacle.
I'm surprised nobody has mentioned my former classmate Tony Li. When Tony left Cisco he famously wrote a fairly exasperated letter and nailed it to his office door. That didn't stop Cisco from rehiring him once he left Juniper. Of course Tony is considered to be one of the world's experts on routers. so his ability to get rehired is a little atypical.
Let's first remember that Bush installed John Yoo in this office, author of the infamous "the President can torture anyone he wants" memo.
In contrast, Johnsen, a law professor at Indiana, has been an extremely harsh and very outspoken critic of the expansion of executive power under Bush. Writing for Slate, she said:
And here is what she had to say about Bush's violation of FISA:
Given this I am fairly optimistic that we'll see at least some reversal of the executive power grab that took place under Bush.
A friend of mine is a risk assessment quant who was working at Lehman right up to the point where they declared bankruptcy. I asked him about this article the other day. He said that their models started telling them something was very wrong back in 2007. The problem was that Fuld (the CEO) refused to believe what the models were saying.
The most accurate model in the world won't help if you don't pay atention to the results it produces.
There's also apparently an issue with the classical VaR models depending on transparent pricing, which these real estate instruments lack. So some of the most troublesome assets apparently weren't in the model.
Many years ago there was an incident at the college I was attending where the administration searched a number of student rooms without permission. After getting caught various justifications were given for the search.
I was part of a group of concerned students who decided to write the ACLU and ask about the legality of the college's actions. We wrote the letter, but then decided it would look better if it was cosigned by the student council. Of course that brought the existence of letter out into the open.
After the letter was approved and before it was sent, I was summoned to the office of a chemistry professor, someone I had never had dealings with before. Once there, he proceeded to threaten me with expulsion if the letter was sent, claiming, if memory serves, that it would be some sort of honor code violation.
I responded by laughing at the guy and told him that the letter was going out and that if he took any sort of action against me I would sue his ass and the college's all the way from here to doomsday. He was struck dumb by my response - I don't think it had even occurred to him that he wouldn't get his way.
The letter did go out (and got the predictable response - the college's actions were clearly illegal). And I never heard a single word from this professor again. I still see him from time to time. I always smile and wave, but I don't think he recognizes me.
I'll say this for Dan - he is often quite good at analysis and finding problems. But after watching a huge fight between him and the authors of the delivery status notification format for email, with the result that positions became completely polarized and nobody succeeded in convincing anyone else of the merits of their respective ideas, I decided the best way to deal with him is to listen to his criticisms, evaluate them carefully, and if it makes sense to address them, do so. But attempting to engage in a meaningful discussion with him is a waste of time - he gets angry way too easily and starts throwing all sorts of nasty invective around, and the result is almost always that the interaction spirals straight down the crapper.
Several years back I watched part of a pizza commercial being filmed. The whole point was for this guy to bite the tip off a slice and basically look like it gave him an orgasm.
Apparently the rules are that they have to use an actual pizza from an actual box. So they had several hundred pies in boxes and a couple of people were busy ripping them open, looking for ones with the most and best looking slices of pepperoni or whatever. The handful that met the standard were rearranged so all the toppings were on one slice and cooked. Once they came out of the oven they'd cut a slice and bring it over to the actor, who was stripped to the waist except for a fake shirt front. (Those lights are HOT.)
When they were ready they'd mop off any sweat, touch up his makeup, and hand him a slice and say, "Take 15" or whatever. He bit and chewed and looked like it was the greatest thing ever. Then the director would yell, "Cut!' The instant that happened the guy would spit the bite into a bucket right next to him.
I asked one of the people there if this was typical. I mean, hundreds of pizzas and 15 takes just for 5 seconds. They responded that this was the norm except for shots where someone drinks something. You can't just spit that out and forcing them to vomit it up is too dangerous.
I haven't paid much attention to ad content since.
Voting isn't a mess everywhere in the US.
I was a pollworker here in LA this year. The Inkavote system used, which is standardized across the entire county, is pretty close to what you describe: ID check (for new voters), cross your name off the list, get a ballot, etc. The only refinement is that we have a machine that checks to see if there are any obvious errors on the ballot: Ink where it shouldn't be, overvote (more than one vote in a race), or the ballot is entirely blank. This machine only validates, it does NOT count votes. Actual counting is done later at the ballot collection center.
The entire process is completely open and anyone who wants to observe may do so, from the moment we start setting up the polling place to when we finish taking it all down.
Of course the system isn't perfect, but it sure seems to work pretty well. Pollworking was actually quite fun since so many people were so enthusiastic about voting, especially in this election.
I'm a software engineer but I have to say the thought of using a computer for voting completely creeps me out.
You might want to read a little more of Krugman's positions if you believe that. He was adamantly opposed to the original Paulson bailout plan, which was a banker's wet dream. He was much more in favor of the Dodd plan and eventually came down in favor of the final plan that passed here, but he was far from enthusiastic about it. "Better than nothing, but just barely" sums up his take, I think.
The British plan, OTOH, is one he supports much more wholeheartedly. But the banking community is far from haapy with that plan.
So, the other day I managed to damage my esophagus (a pill I took got stuck in there). I went in to see my GP, who immediately figured out what was going on and prescribed Nexium for a week or two to reduce stomach acid and give my esophagus a chance to heal.
As it happened my doctor had a first year resident with him that day. As my examination proceeded he asked the resident all sorts of questions. (After blowing it by answering one of the questions - correctly I might add - I was instructed to keep my mouth shut except to say "ah".) After some questions about how proton pump inhibitors and how they work, he asked, "What's the difference between Nexium and Prilosec OTC and why did I choose Nexium?"
The resident didn't know the answer. My doctor then said, "Perhaps it will help if I tell you that the chemical name for Nexium is esomeprazole while the name for Prilosec is omeprazole."
Now, I'm an engineer by training, not a chemist or a doctor, but I've studied enough chemistry along the way to know that the former is probably a specific stereoisomer of the latter. So the drugs are almost identical and probably have very similar efficacies, especially in a situation like mine where the problem was fairly minor and treatment duration pretty short.
Thinking about it some more, I arrived at what I suspect was the answer (I'm going to ask my doctor if I was right the next time I see him): "The Purple Pill Called Nexium" is relentlessly promoted - there are ads for it all over the place. Prilosec OTC, as the name implies, is an over the counter medication. Drug reps hand out scads of Nexium samples to doctors - I've seen them do it. Prilosec, not so much - why bother? So, while Nexium is far more expensive if you have to pay for it, no price beats "free as in sample".
And sure enough, instead of writing out a prescription for Nexium my doctor handed a bunch of samples. No cost to me other than the doctor visit.
The resident still didn't get it and was instructed to read up on both drugs.
Of course after I got home I looked up both drugs. I found that there's actually a big controversy about whether Nexium is any better or if it's just an cynical attempt to extend patent protection and keep charging high prices.
I have no idea how often such questions arise in medical practice, but it seems to me this is exactly the sort of thing where a good grounding in organic chemistry might be a handy thing to have.
I have to agree. I haven't ever played with Medecos, but I have fooled around with Emharts, which I believe are similar. Back in my misspent youth we used to make keys out of the sheet metal used for ventilation ducts. It's usually possible to get the stuff to fit the keyway with 1-2 bends, then cutting it is quite simple. The locks with twisting pins like Medecos reqire a little more effort, but not much.
One of the harder things to do is create a so-called control key - this is the key that removes interchangeable cores from cylinders. The problem is since control keys are not normally used you cannot get ahold of one to copy, and picking the control level of a lock is nearly impossible because you can't get tension on the inner part of the core that turns.
This particular problem was solved for us when some fool threw a defective cylinder in the trash. We drilled it open and had a control key in no time.
This more than anything is the system's biggest weakness - every lock contains the information necessary to break the entire system.
My dentist's office is - no fooling - adjacent to a large FBI office that has these scrambling keypads. I used to think they were pretty cool until I happened to be in the hall when an agent walked up and proceeded to use one.
The guy swiped his badge to start the process, then peered at the keypad, then pressed a button, then took his hand away in order to find the next button, peered at the keypad again, then pressed another button, and so on. I would estimate it took four times as long to operate as a conventional pushbutton lock.
Now, the diplay is apparently only readable from a narrow angle, but that angle doesn't appear to coincide with where someone operating the keypad always stands. So if someone were to install a hidden camera across the hall that can see the keypad... You get the idea.
In this particular case there are also surveillance cameras in the hall that would make it hard to install such a device. But really, requiring continuous surveillance of the door in addition to the lock in order for the setup to be secure is not exactly a testimonial to this technology's effectiveness.
My iPhone is the fourth smartphone I've had. I spent enough time with its predecessors to know all the tricks - and there were plenty of those to learn - to use most of their features. Address book, calendar, camera, games, etc. - at one point I even synced the phone with my laptop regularly.
The trouble was doing all this stuff felt about as good as having a root canal. Sure, there was a keyboard shortcut feature that made a few things easier. But over time almost everything fell into disuse because it was just too painful to operate.
The iPhone has changed my habits completely. Everything that was hard to do is now easy. The only thing I didn't like was having to use a cable to sync it. (But unlike its predecessors the sync always worked flawlessly.) Even that is now a nonissue with MobileMe.
I thought maybe it was just me being too picky. But then...
My wife, whose interest in matters technical is fairly limited, has also had a smartphone for quite a while. (Actually a much nicer one than mine.) But after browsing the manual she never did anything with it - she said it was too much trouble.
Last week she got an iPhone. She hasn't had a moment's difficulty operating it. And she's using the phone's capabilities for the first time. For example, her addressbook is already full of entries, entries she typed into Address Book on her computer and synced to her phone with no help from anyone.
Usability really does matter. And while the iPhone is a long way from perfect, it represents a substantial advance.
I used to have to restart my Airport Extreme every once in a while, but after updating its firmware that's no longer necessary. According to InterMapper it has been running for 84 days without a restart, and if memory serves the reason it was reset 84 days ago was to do some recabling.
That's a good question. I'll do my best to answer it but since the number of security vulnerabilities of any sort we've had is pretty small I'm not sure how relevant my answer will be.
This is a big company and we have lots of software products. There's a group of folks that analyze the data from our change request (CR) system. I've only met with them once for a review of our product's CRs so my knowledge is pretty skimpy and quite possibly not at all representative, but here's what transpired.
They started with a breakdown of defects by various criteria: Component involved, root cause analysis, etc. It was clear some parts of our products are buggier than others but we already knew that. There was no attempt, however, to pin problems on specific engineers.
Beyond the obvious category stuff the data was really too noisy to draw any strong conclusions. One interesting observation about the process, however, was that the defects they cared most about were ones that had been filed and not fixed quickly - which seemed pretty reasonable to me.
Then they started drilling into requests for enhancement (RFEs) as opposed to defects. Believe it or not, this was a bigger concern. In particular, it seems we had an unacceptably high number of so-called "escalated RFEs". (Escalations happen when customers "take it to the next" level with support.)
We explained that the reason for this was that our releases had been, in hindsight, too far apart and that in our process the only way to get an enhancement backported from development to a production version was by escalating things with support. In other words, we were being yelled at for having used a process hack to get things done.
To be fair, I suspect that had there been a bunch of outstanding defects with associated escalations we would have been yelled at for that. But there were few if any of those.
As you might expect the immediate action we took was to stop using escalations to request backports. And AFAIK we haven't heard from the tracking people since. So the conclusion here is that what really mattered to them was customer satisfaction as measured by the number of escalations filed.
Now, as for using Secure SDLC, we don't use it and I'm not sure how much better off we'd be if we did. The very few security vulnerabilities we have had have mostly been the result of implementation errors, not design errors. (The defect I mentioned previously is actually one of the rare exceptions.) What we do do (in the parts of the product I work on at least) is try very hard to use secure implementation techniques - use carefully vetted routine libraries, avoid known problematic runtimes, and so on.
Oh, and FWIW, I'm not especially worried about being sued for calling a security vulnerability the defect it is. (This is not to say I don't worry about lawsuits - the possibility of a patent infringement suit coming in out of the blue scares the crap out of me.) We try and deal fairly and openly with our customers and that has worked well for us. (It undoubtedly helps a lot that our customers are almost always other companies, not individuals.) Maybe I'm naive, but I think once you start misrepresenting things to your customers you're far more likely to get into trouble.
AFAIK the Airport Extreme only supports having a single public IP address. That's a big problem when you have servers on more than one address. (I'd appreciate being correct if you know this isn't the case.)
The various Linksys products have similar issues. It's been a while since I checked so I don't recall all the specific models, but the intersection of 6to4-capable routers with ones that support multiple public IPs, NAT, access controls, and all the other stuff you need appeared to be empty. (And again, if you have information to the contrary I'd love to hear more.)
I've been looking for a viable router solution short of a Cisco that handles multiple public IP address and has 6to4 capabilities and I haven't found anything I like. The closest I've come is DD-WRT, but the ipv6 support there is an command-line-only add-on, not fully integrated, and I've heard it's even busted in v24.
It's hard to see how anyone expects ipv6 to become a reality without support for it in inexpensive routers.
We've treated potential vulnerabilities in our products, even extremely minor ones, as defects for over two decades now. And we have always given them very high priority.
To the best of our knowledge we've never had a remote exploit vulnerability, but even so we've gone so far as to scrap thousands of freshly pressed CDs a day before releasing them because I spotted a way to get root access through a tricky bit of business with shared libraries. (And that was for something spotted internally - no customer ever reported it.)
The real question isn't whether to treat security vulnerabilities as a defect - of course you do - but - somewhat paradoxically - whether or not to treat them as security vulnerabilities. We were acquired some time ago and have now adopted (and adapted to) various more complex procedures typical of a large company. There's this little box you're supposed to check in our current bug reporting system that says "this is a security vulnerability". The problem is that checking that box fires up a whole lot of extra process that rarely helps and can actually hinder prompt resolution of the problem and getting the fix into customer's hands.