That is it will tell us what actually happens. Right now, statistics are what we have, and they do predict that if you are a betting man, you'd bet against Mr McCain. Don't put too vast a faith in medical science. No matter how good your health care is it is far from guaranteeing anything, as you'll find out soon enough about the time you hit 40 or so.
Now, if McCain was running for a Senate seat, I'd not consider his age a big deal, worst case he doesn't finish his term. But right now I can think of few things worse than a dying president and a lunatic no nothing VP running things. Not my idea of a wise choice anyway.
Statistics absolutely do apply. That's ridiculous.
Here, here's a simple reductio ad absurdum for you...
Statistics don't apply to single data points. Just because a die comes up 6 1/6th of the time has no bearing on the chance that it will come up 6 this time.
You using some o' that 'new statistics' or something? lol. I bet there are some Casino's that will find that funny too.
Now, the argument about health care might carry some weight, but I could just as easily point out that the man would be spending the next 4-8 years in a highly stressful job, probably about as stressful as any job one can imagine, and THAT is certainly a factor as well.
Another point is that the probability of John McCain dying is not based on some random statistics about the whole population. It is based on statistics about people LIKE HIM, who have had 3 bouts of a very serious form of skin cancer, and are 72 years old.
The statistical likelyhood of a man of Mr McCain's age and having his medical history surviving for even FOUR, let alone 8, years is well under 50%.
Just because Ronny Raygun lived to age X has no bearing on John McCain living to the same age beyond being an existence proof, and we really needed proof that people CAN live to be 80? Besides, the last 6 years of Reagan's presidency he was pretty much out of it. That's exactly what we need, a senile president and a fool for a VP. Yeah, I'll go for that.
Honestly I'm sorry, but even if I supported John McCain I think it would be irresponsible to vote for him under the present circumstances.
The whole concept that wireless devices are doing jack squat to the flight control systems of airliners is just balderdash.
I worked on this stuff quite extensively a few years back.
First of all, the actual communications between all the components in the aircraft takes place over a series of multiply redundant high speed serial data buses (AIRINC 429, MIL1553B, etc). Those buses are designed to reject even serious EMI. Naturally beyond that all data is heavily checksummed in both hardware and software, etc.
Furthermore every single system on the aircraft which is 'flight critical' or even deemed to involve 'safety of flight' is a multiply redundant brick wall. The systems I worked on (fuel management/center of gravity management) contained TWO completely redundant systems. Within EACH of those systems were 9 processor cards. For either box to fail a minimum of 4 of the 9 cards would have to cease to function. All power supplies are redundant, each box had two AIRINC429 bus interfaces, each of which transmits on 2 redundant physical buses. The other systems (navigation, flight control, autopilot, etc) are all similarly designed.
The software in these things is built to standards 5 orders of magnitude more stringent than what runs your bank. In the A330/340 FCGMS systems we had over 100 software engineers developing the flight software for a period of several YEARS, and I'd say there's maybe 20k SLOC (all written in Ada of course). So essentially every single line of code represents 100's of hours of work. My group actually constructed a physical and logical simulation of ALL digital and analog inputs to that system and literally took boxes off the production floor and simply ran every single flight scenario the aircraft is physically capable of performing into that system and verified that under no circumstances could it behave improperly.
I am quite sure the other vendors were equally thorough with their parts of the system.
But beyond even that, all these systems maintain comprehensive sanity checks on all input data. If any system sees weird or unexpected inputs (say all of a sudden a fuel tank reports that 1000 pounds of fuel just vanished from the tank) it would start flagging faults to the cockpit, provide estimates of what the readings SHOULD be, what they actually are, etc. Again, I'm quite positive all other subsystems have the same type of capabilities. So even if a blue tooth mouse were to say cause the navigation system get bad GPS data, that data would be flagged, rejected, and the cockpit notified. And that doesn't even count the fact that AT LEAST two independent copies of that system are operating at all times and it would be vastly unlikely both of them would be interfered with in exactly the same way at the same time.
The most likely explanation is that, like all complex systems, there are situations where if the pilots have set things up a certain way, and certain subsystems have suffered faults, and several other conditions occur at the same time that you will end up with something like this happening. No amount of systems engineering and verification can ever eliminate every single possible failure mode, unfortunately.
I'll bet serious money there was some sort of seemingly inconsequential maintenance issue with some part of the avionics which contributed to the incident and that the airline would naturally not want to take the blame for that. Same goes for the manufacturer and the vendors. It is mighty convenient for them to blame some external factor instead of having to admit they flew an aircraft with a bad card in one of the boxes, etc.
I think the previous post has some pretty reasonable ideas to consider, and there are other voices I've heard saying some of the same things, maybe banking should be a 'utility' like electricity, not a competitive enterprise.
However, you've certainly raised the contervailing objections. There are other 'systemic' problems with such a proposal as well. One would be 'how do you initiate economic development in an underdeveloped segment of the economy?' If a bank say wants to go into a town where there is little development, how would they write mortgages if they can't bring in outside capital and leverage it? This was one of the problems the US had internally in the 19th century which motivated the creation of the regional Federal Reserve banks.
The last point you made is also a good one. Such a system is unlikely to work unless it is applied at least to some extent worldwide. We have to face the fact that there are no such things anymore as 'National Economies'. The whole topic of world governance has to be addressed as part of any solution. This is going to be neither easy nor quick.
the relentless drive for greater and greater profits is a built-in feature of the entire system. While regulations certainly work in the sense that they can prevent specific activities there will always be ways to 'route around the damage'. Outlaw naked shorting and someone simply comes up with some new class of instrument that does basically the same thing some other way, etc.
I don't have any brilliant solutions, but in the final analysis I also don't think that any regulatory regime could have prevented what is happening now. Look at Europe, they have much more comprehensive banking and financial regulations than the US, and yet they're still swirling around the drain just like we are. It would seem to be time for some serious out of the box thinking.
Naturally being a tech geek myself I have to wonder if perhaps there is an engineering approach to the whole question. Banking as a utility? Some way of buffering crazy flows of capital moving around in the system? Dunno...
The libertarians amongst us will scream at the heresy of course, but I can't help but point out that freehold ownership and unrestricted markets seem to lead to socially undesirable results. I'm thinking it is sacred cow slaying day.
analysis. Sure, there was talk along those lines, but the rhetoric didn't match with what actually happened. The Fed engineered a rather LARGE bailout of LTC. Essentially what they did was spread the losses around enough to insure that the overall structure withstood the collapse of one part. There was obviously enough flexibility in the system to do this at the time, coupled with the fact that the Asian markets were enough decoupled from the rest of the financial industry that a cascade failure could be averted.
Essentially what they're attempting now is the same sort of strategy on a gigantic global scale. The difference is there is no longer a stable part of the system to isolate the damage from nor is there some portion of the system that will remain standing once the affected elements inevitably reach their end state (some level of collapse). No strategy is going to fix this, and the reaction of the markets to all attempts to do so thus far bear this view out.
What exactly the end result of this collapse is, what is left standing and what isn't, is likely to be almost impossible to determine, which is in and of itself enough to create the panic which is just serving to amplify the effects.
In a year or two when the dust settles we'll have some idea of where we stand. One would hope the situation is that enough of the really core elements of the financial system remain in place and able to function that we HAVE a global economy still. Here we can ask the question "what actions would best insure that", but notice that those are questions dealing with longer term strategy. Mere TACTICS, bailing out this, that, or the other thing, etc is just largely irrelevant. Nobody knows for sure what CAN be saved nor what MUST be saved.
Consequently it would seem the only prudent strategy would be to decouple oneself (as either a business or an individual) as much as possible from the whole system for the time being and hope to step back in after the dust settles.
First let me say, I don't think your analysis is wrong per se. At the level of the mechanics of where the crisis happened and how it played out in the minds of the people in the middle of it, it is perfectly valid.
However, this whole line of analysis is very much like analyzing a car wreck and concluding that the cause of accident was the driver's excessive application of braking and over correction. The driver was dead drunk. The underlying cause was the fact that his reflexes were so shot he couldn't react properly. It is largely irrelevant what the details are of how he lost control of the car, he was bound to do so under the circumstances.
Likewise the so called 'financial crisis'. Think of our economy/financial system as a bit like a building. Every part of the structure both adds 'load' to the building, and also supports the weight of the other component parts. As long as enough structural integrity exists to support the load at every given moment, the building stands.
Unfortunately what our whole society from top to bottom has been doing is looking at this structure and saying to themselves "you know, it is a waste of money to have that beam be 150% stronger than the load it is carrying" and then someone comes along and removes the beam and replaces it with one that's only 105% strong enough so they can use the extra materials someplace else, make more return on their investment.
Well, that could only go on for so long, and naturally people got a bit nervous and engineers pointed out that the building maybe was a bit shaky, so we invented a way to tie all the beams together more securely "well, if one fails its ok, if we spread out the load enough then no one part of the building will be overloaded".
Until finally one day the wind started to blow... Once one single part, ANY part of this massively over leveraged structure reached its failure point there was no margin left anywhere to take up the extra load anymore! Every part was already stressed to the absolute maximum limits of its capacity. And as long as things had kept going on an even keel it was inevitable that the search for profit would create even more leverage until inevitably the whole structure became so intolerant of even the slightest disturbance that it had to come crashing down.
The really disturbing part of this is that, as any engineer can tell you, when you reach this kind of situation of critical instability any small problem results in a cascade failure of the entire system. Every industry, practically every business, is leveraged out so far that even the smallest dips in cash flow result in immediate insolvency, which then propagates down the supply chain and up the 'wage chain'.
This thing is like an avalanche coming down the side of a mountain at 300 mph. The snow all around it looks all nice and quiet, but that means nothing. This thing has momentum, large momentum, and there isn't any stopping it because there's no redundancy left in the economy to act as a brake. No bailout plan or insurance scheme or nationalizing of banks or any other action anyone can take now is going to stop it until it gets to the bottom of the mountain.
The sad fact is we clearly saw, or should have seen, it coming. The system gave us every sign of being ready to fail. What was the 97 Asian financial crisis except a localized version of the same thing? It just didn't get big enough to build up the momentum to smash the whole system. Only one wing of the building fell off that time. If we had exercised any prudence whatsoever we would have taken the hint. But 'This American Life' certainly has it right in the sense that greed and hubris overrode common sense.
And look at where we are now. Hope you all have a nice supply of canned goods stashed. Best case scenario is they're about to get a lot more expensive.
Yeah, well, it would be a pointless debate in the sense that it is well and truly water under the bridge at this point, but there WERE choices. We could argue about the technical merits of different VMs, but there were choices in 2001. Have been for 20 years before that for that matter. Pointless to get into it at this juncture.
The proof will be in the pudding in any case. Personally I think P6 missed the window of opportunity unfortunately.
Oh, I think it will be interesting to see what all the P6 people come up with. I think they made a big mistake though by writing a whole new VM. There are some REALLY excellent VMs they could have at least adapted to their use. Things like JSR threading that the FORTH community figured out decades ago.
So I have to wonder at the thought process of a team which makes that monumental a mistake. Just my opinion, but I am writing applications and not theory and P5 still more than fills the need.
Heck, I basically duplicated ALL of the major functionality and a good bit of the 'add-on' stuff that Maven2 does in a bazzillion lines of java in perl in 30 days. Actually EASIER to rewrite it in perl than maintain 30+ POM files. Nah, Perl is still by far the glue of choice.
LOL, well, in some respects I CAN see how people who have spent a lot of time with other languages get a bit frustrated with Perl syntax. I don't think it is because it is BAD, just certain aspects of it (and the typing system it reflects) are subtly different semantics than what people are used to.
One problem with Python though is just the whole whitespace issue. Not that I think it is particularly a big deal in terms of just writing code, but have you ever tried autogenerating Python? That whitespace can be a royal PITA... lol.
My feeling overall is that nits about one syntax vs another (assuming they are equally expressive) is really missing the whole point of software engineering. The actual authoring of code is such a trivial part of the whole process of successfully developing an application for someone. So I just have little patience for the language wars.
"Likewise, Bruce Hogman provided a vertiable trove of COBOL information. According to Gartner, Bruce reports, there are 250 billion lines of COBOL source code being used, with 15 billion new lines each year. A major AAA national company has some 35,000 COBOL modules plus supporting COPY books and so on in its inventory. A major airlines has 848 COBOL modules in its crew management system with some 3,000,000+ SLOC of code. Merrill-Lynch runs 70 percent of its daily business on COBOL systems."
I can't say how Gartner comes up with the 250 billion number, but it is one which has been often repeated.
Its funny, see I feel the same way about the other 'P' languages, why should I need to learn another language which does EXACTLY the same things as the one I am already a master of? There is just no compelling reason to use Python, PHP, or Ruby vs Perl. People being what they are, they will always reinvent the wheel, but frankly had all that effort gone into Perl development I have a feeling we'd have one single much better implementation of dynamic scripting...
There are 250 BILLION lines of running COBOL code today. In fact there is more COBOL running out there than all the other code in all other languages combined (at least counting just business applications, but even counting everything this may be true). Many of them are truly gargantuan pieces of software, dwarfing things like Linux kernel in both size and at least some measures of complexity.
COBOL is in fact not dead at all, and is a.NET supported language, even MS knows better than to shun it. There is a real need for COBOL programmers as well, and there has been for several years now a concerted effort by industry to increase the number of people trained in COBOL programming. Believe it or not COBOL supports OOP and pretty much all the other commonly seen features of other procedural languages.
Likewise Perl is FAR from dead. There are vast quantities of web application code written in Perl.
Neither may be considered by 'cool' by the self proclaimed 3L1t3 hackers of the world, but if you think businesses really care much about that, you'd be mistaken.
Not to say I think everyone should code in or would LIKE coding in either COBOL or Perl, but calling either one of them dead is just contrafactual in the extreme...
In fact the way OO is implemented in perl is nice, you can do all sorts of handy things that are nearly impossible, even in other dynamic scripting languages.
As for the 'plumbing hanging out' it actually doesn't in practice 99.9% of the time. I mean materially what is the big difference between notations like:
this->{attributename}; # perl
and
this.attributename;// most anything else
And ouch, you have to call 'bless', but actually that gives you considerable flexibility since you can choose what package to bless to, and even rebless an object to a (possibly totally different) class at run time. Purists will tell you how HORRIBLE this is, but when was the last time you tried to stuff an X into a variable that was supposedly a Y? It just isn't that big of a problem, and if it IS something to worry about, you can easily add type checking to any variable via a tie.
There are a couple of minor annoyances, like the lack of implicit lexically scoped variables for parameters which might be nice to do away with, but again if you look at the syntax overall it makes little difference.
Finally if you are using a package (class) which produces blessed references (instances) as long as you use the defined API provided by the developer it should hide anything like 'is this class implemented using blessed hashes or blessed arrays'. Why would you care? How many of you have used CGI.pm for years? Does ANYONE here know off the top of their head if an instance is a hashref or not? I seriously doubt it.
"It is also possible to create a backdoor without modifying the source code of a program, or even modifying it after compilation. This can be done by rewriting the compiler so that it recognizes code during compilation that triggers inclusion of a backdoor in the compiled output. When the compromised compiler finds such code, it compiles it as normal, but also inserts a backdoor (perhaps a password recognition routine). So, when the user provides that input, he gains access to some (likely undocumented) aspect of program operation. This attack was first outlined by Ken Thompson in his famous paper Reflections on Trusting Trust."
In any case an effort like this is, for the truly paranoid, feeble. The mechanisms available, proven mechanisms, are well known.
First of all you cannot trust any binary which was compiled with a toolchain which is not itself trusted at least as much as the code you are compiling. It is a well known fact that Ken Ritchie (IIRC it was he) added a block of code to pcc (the portable C compiler) which detected the compilation of the 'login' program and added a back door to it. Then he also added a piece of code which caused pcc when compiling ITSELF added both of these behaviors to the new pcc binary. This resulted in a period of a number of years in which the backdoor existed in virtually all Unix based systems. The pernicious part is, pcc's SOURCE code contained no trace of any of this because the source for the hack only existed ONCE, in the orginal 'ancestor' copy of pcc from which all others descended. It would be at best VERY difficult to know that some similar technique was not used on any given distribution. In theory one could do analysis of every binary, but then how do you know your debugger and disassembler aren't lying to you? Etc.
Even assuming you have by some process guaranteed you have a clean set of binaries, why would you think that the hardware you're running them on is trustworthy? It would be foolish to assume that of the billions of transistors of which your CPU is composed that some small fraction are not dedicated to nefarious purposes...
No, the people working on this may think they're paranoid, but frankly if they thought about it a bit more, they would realize they are not 1/10th paranoid enough...
They WILL do so. Personally I'm not one of the rabid originalist type. I think society has to function and OK, it is true that the original intent was probably that gold and silver were the only money Congress was allowed to make. Yet our modern society could not function on that basis. Unfortunately the debate was never had as to how the authority of Congress should have been altered in order to accommodate changing circumstance.
Instead the existing terms of the document were stretched out of all recognition one small increment at a time.
I think part of the problem is that when these mortgages were 'packaged' and sold, the securities were sold at values which were far in excess of the reasonable value of the underlying surety (the home). Frankly I doubt most of the people who bought them really understood that.
Deregulation has lead to a scenario where the large financial institutions dealings have become almost totally opaque. Trust but verify became 'oh, what the heck, everyone is doing it.'
The SCALE of the insanity is almost impossible to even measure. Credit default swaps for example (basically insurance taken on these instruments) reached a total net payout value of 74 TRILLION DOLLARS in 2006. The total net asset value of the ENTIRE HUMAN RACE is only about 54 trillion dollars!!! The entire thing was literally insane, beyond any conceivable reason.
No bailout is going to fix all this because the fundamentals simply cannot support the whole way the industry is being run. Truth is the banking system porked itself. Time to start thinking about how money works. Deep thinking required now.
If you assume that Congress has UNLIMITED AUTHORITY, then why do we have a Constitution at all? The Constitution is a compact between the people, of the comity of the people, WITH EACH OTHER which vests certain defined and limited portions of the absolute sovereignty of the people in a Congress, etc. That power is clearly and explicitly limited. What part of 'reserved to the people' is not clear here?
When Congress assumes for itself powers not vested in it they are overthrowing the authority of the people. MY ancestors stood literally in the face of British cannon fire in order to guarantee EVERYONE the protection of those rights. Now, does anyone doubt that it does us dishonor if we fail to respect that? I WILL NOT yield those rights, not to Congress nor to anyone else. And if fools insist on giving them away, then I will withdraw my permission for those people to use those rights, and there is NO LIMIT to my right to do so, nor to the just means which I may avail myself of in that cause.
No no no. Remember there is a 'time value of money'. There is substantial opportunity cost associated with making ANY loan. Not to mention the risk of inflation. If I put my money into an investment at 5% return, and even a small fraction of my principle is written down, I'm immediately in the red.
See the flaw with all these mortgage backed securities is this. The house is worth 100k lets say, the bank loans 100k, they sell the mortgage for 200k, THAT 200k IS PRINCIPLE. It is really just as if the buyers of these securities paid 150-200% of market value for houses! ANY declines in value loose them money. The whole scheme was just crazy.
mark-to-market (MTM accounting, which is rule 157) no doubt isn't helping the banks, but the real problem IMHO is the way these mortgages were packaged.
Say you make a mortgage for $100k to someone for 20 years, and the total repayment is $250k principal plus interest. Now you take 10 of these things and you package them up and sell the paper for $1.5 million (150k per mortgage). SOUNDS like a good deal, except what happens if ONE of those mortgages goes bad? The buyer of the paper is now out 250k and all of a sudden the return on his paper is approaching zippo grande and it is now basically a worthless piece of paper.
In theory the paper might still be worth quite a bit, but the holder IS going to lose money, and the risk on the paper is still the same.
The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
Amendment X.
There is something unclear about this? POWERS NOT DELEGATED, the key phrase. All that is not permitted explicitly is EXPLICITLY forbidden. There MAY be arguments as to the extent of the power of Congress which could be made with regards to commerce and regulating the money, but they are at best weak arguments. The point is, your analysis is simply wrong and not only directly contravened by the 10th amendment, but also discussed at length by the authors in the Federalist Papers (in all fairness Hamilton made some arguments similar to yours, but it is a dangerous position to take).
What if Congress decides that 'the common welfare' would be served by having the FBI throw you in a pit for 30 years? Is that OK because 'hey, it is good for everyone else, and they can do whatever they think is good'. Sorry, not in my United States.
between 'no design at all' and what agile methodologies advocate. In XP methodology for example you would first develop your system requirements in the form of user stories. Those are used to prioritize features, then you engage in a series of iterations, each one adds certain features. Another tool you use is a system metaphor or model, which provides a way of reasoning about the overall system architecture.
Any given iteration only deals with those requirements which are assigned to that one iteration. Code is written (tests first) to accomplish the requirements of that iteration, and the customer supplies a set of functional tests which verify that the software meets those specific requirements.
During later iterations new tests will be written and either more code written or existing code refactored and extended to add the additional features. More functional tests are developed as well, and the added features plus the existing features are all tested for compliance to the new requirements.
There is no single overall design 'phase'. There could be various points at which the large scale features of the system are fleshed out. In some cases a 'spike' might be used to explore different options. Spike code is considered throw away and simply allows you to determine which of several designs are likely to work best. Usually there will be some specific 'problematic' areas (say 'how can the system achieve the required latency requirements') which a spike would address.
The whole philosophy of agile development essentially rests on the observation that even in what are supposedly more 'up front design' type methodologies that the real shape of the system ends up being determined over the process of development. It is like applying the 'Wu Wei' concept of Daoism to software, don't fight the way things REALLY flow. Waterfall style development is a myth, and pretending it isn't is just paddling upstream.
In my long experience of writing complex applications I have yet to encounter a situation where the requirements forced me to write code which wasn't modular. I am not at all sure what the conditions would be where that is true.
I can only surmise that the model/metaphor was poorly chosen or not well mapped onto the requirements. This kind of thing is one of the big issues with strict 'top down' waterfall style development, and one of the reasons it is slowly but surely being abandoned. The expectation is that some 'analysts' will have by some process nailed down EXACTLY how everything is going to work. That is at variance with reality, nobody really knows how a large piece of software is going to work at the outset. The system architect probably has a pretty good general idea in mind, and any number of constraints could be defined, use cases, etc. But these projects often fail simply because someone writes up some thing that says 'The foomazoo SHALL perform the calculation' and it turns out, that was a horrible way to structure the software. Thus things like agile development...
Of course you may not be in the position to design an individual module when you're part of a larger team, or it may be legacy code, etc. Some code truly is not testable, but that is as I have said before a problem with the CODE not the concept of TDD.
Slashdot Mirror
That is it will tell us what actually happens. Right now, statistics are what we have, and they do predict that if you are a betting man, you'd bet against Mr McCain. Don't put too vast a faith in medical science. No matter how good your health care is it is far from guaranteeing anything, as you'll find out soon enough about the time you hit 40 or so.
Now, if McCain was running for a Senate seat, I'd not consider his age a big deal, worst case he doesn't finish his term. But right now I can think of few things worse than a dying president and a lunatic no nothing VP running things. Not my idea of a wise choice anyway.
Statistics absolutely do apply. That's ridiculous.
Here, here's a simple reductio ad absurdum for you...
Statistics don't apply to single data points. Just because a die comes up 6 1/6th of the time has no bearing on the chance that it will come up 6 this time.
You using some o' that 'new statistics' or something? lol. I bet there are some Casino's that will find that funny too.
Now, the argument about health care might carry some weight, but I could just as easily point out that the man would be spending the next 4-8 years in a highly stressful job, probably about as stressful as any job one can imagine, and THAT is certainly a factor as well.
Another point is that the probability of John McCain dying is not based on some random statistics about the whole population. It is based on statistics about people LIKE HIM, who have had 3 bouts of a very serious form of skin cancer, and are 72 years old.
The statistical likelyhood of a man of Mr McCain's age and having his medical history surviving for even FOUR, let alone 8, years is well under 50%.
Just because Ronny Raygun lived to age X has no bearing on John McCain living to the same age beyond being an existence proof, and we really needed proof that people CAN live to be 80? Besides, the last 6 years of Reagan's presidency he was pretty much out of it. That's exactly what we need, a senile president and a fool for a VP. Yeah, I'll go for that.
Honestly I'm sorry, but even if I supported John McCain I think it would be irresponsible to vote for him under the present circumstances.
The whole concept that wireless devices are doing jack squat to the flight control systems of airliners is just balderdash.
I worked on this stuff quite extensively a few years back.
First of all, the actual communications between all the components in the aircraft takes place over a series of multiply redundant high speed serial data buses (AIRINC 429, MIL1553B, etc). Those buses are designed to reject even serious EMI. Naturally beyond that all data is heavily checksummed in both hardware and software, etc.
Furthermore every single system on the aircraft which is 'flight critical' or even deemed to involve 'safety of flight' is a multiply redundant brick wall. The systems I worked on (fuel management/center of gravity management) contained TWO completely redundant systems. Within EACH of those systems were 9 processor cards. For either box to fail a minimum of 4 of the 9 cards would have to cease to function. All power supplies are redundant, each box had two AIRINC429 bus interfaces, each of which transmits on 2 redundant physical buses. The other systems (navigation, flight control, autopilot, etc) are all similarly designed.
The software in these things is built to standards 5 orders of magnitude more stringent than what runs your bank. In the A330/340 FCGMS systems we had over 100 software engineers developing the flight software for a period of several YEARS, and I'd say there's maybe 20k SLOC (all written in Ada of course). So essentially every single line of code represents 100's of hours of work. My group actually constructed a physical and logical simulation of ALL digital and analog inputs to that system and literally took boxes off the production floor and simply ran every single flight scenario the aircraft is physically capable of performing into that system and verified that under no circumstances could it behave improperly.
I am quite sure the other vendors were equally thorough with their parts of the system.
But beyond even that, all these systems maintain comprehensive sanity checks on all input data. If any system sees weird or unexpected inputs (say all of a sudden a fuel tank reports that 1000 pounds of fuel just vanished from the tank) it would start flagging faults to the cockpit, provide estimates of what the readings SHOULD be, what they actually are, etc. Again, I'm quite positive all other subsystems have the same type of capabilities. So even if a blue tooth mouse were to say cause the navigation system get bad GPS data, that data would be flagged, rejected, and the cockpit notified. And that doesn't even count the fact that AT LEAST two independent copies of that system are operating at all times and it would be vastly unlikely both of them would be interfered with in exactly the same way at the same time.
The most likely explanation is that, like all complex systems, there are situations where if the pilots have set things up a certain way, and certain subsystems have suffered faults, and several other conditions occur at the same time that you will end up with something like this happening. No amount of systems engineering and verification can ever eliminate every single possible failure mode, unfortunately.
I'll bet serious money there was some sort of seemingly inconsequential maintenance issue with some part of the avionics which contributed to the incident and that the airline would naturally not want to take the blame for that. Same goes for the manufacturer and the vendors. It is mighty convenient for them to blame some external factor instead of having to admit they flew an aircraft with a bad card in one of the boxes, etc.
I think the previous post has some pretty reasonable ideas to consider, and there are other voices I've heard saying some of the same things, maybe banking should be a 'utility' like electricity, not a competitive enterprise.
However, you've certainly raised the contervailing objections. There are other 'systemic' problems with such a proposal as well. One would be 'how do you initiate economic development in an underdeveloped segment of the economy?' If a bank say wants to go into a town where there is little development, how would they write mortgages if they can't bring in outside capital and leverage it? This was one of the problems the US had internally in the 19th century which motivated the creation of the regional Federal Reserve banks.
The last point you made is also a good one. Such a system is unlikely to work unless it is applied at least to some extent worldwide. We have to face the fact that there are no such things anymore as 'National Economies'. The whole topic of world governance has to be addressed as part of any solution. This is going to be neither easy nor quick.
the relentless drive for greater and greater profits is a built-in feature of the entire system. While regulations certainly work in the sense that they can prevent specific activities there will always be ways to 'route around the damage'. Outlaw naked shorting and someone simply comes up with some new class of instrument that does basically the same thing some other way, etc.
I don't have any brilliant solutions, but in the final analysis I also don't think that any regulatory regime could have prevented what is happening now. Look at Europe, they have much more comprehensive banking and financial regulations than the US, and yet they're still swirling around the drain just like we are. It would seem to be time for some serious out of the box thinking.
Naturally being a tech geek myself I have to wonder if perhaps there is an engineering approach to the whole question. Banking as a utility? Some way of buffering crazy flows of capital moving around in the system? Dunno...
The libertarians amongst us will scream at the heresy of course, but I can't help but point out that freehold ownership and unrestricted markets seem to lead to socially undesirable results. I'm thinking it is sacred cow slaying day.
analysis. Sure, there was talk along those lines, but the rhetoric didn't match with what actually happened. The Fed engineered a rather LARGE bailout of LTC. Essentially what they did was spread the losses around enough to insure that the overall structure withstood the collapse of one part. There was obviously enough flexibility in the system to do this at the time, coupled with the fact that the Asian markets were enough decoupled from the rest of the financial industry that a cascade failure could be averted.
Essentially what they're attempting now is the same sort of strategy on a gigantic global scale. The difference is there is no longer a stable part of the system to isolate the damage from nor is there some portion of the system that will remain standing once the affected elements inevitably reach their end state (some level of collapse). No strategy is going to fix this, and the reaction of the markets to all attempts to do so thus far bear this view out.
What exactly the end result of this collapse is, what is left standing and what isn't, is likely to be almost impossible to determine, which is in and of itself enough to create the panic which is just serving to amplify the effects.
In a year or two when the dust settles we'll have some idea of where we stand. One would hope the situation is that enough of the really core elements of the financial system remain in place and able to function that we HAVE a global economy still. Here we can ask the question "what actions would best insure that", but notice that those are questions dealing with longer term strategy. Mere TACTICS, bailing out this, that, or the other thing, etc is just largely irrelevant. Nobody knows for sure what CAN be saved nor what MUST be saved.
Consequently it would seem the only prudent strategy would be to decouple oneself (as either a business or an individual) as much as possible from the whole system for the time being and hope to step back in after the dust settles.
First let me say, I don't think your analysis is wrong per se. At the level of the mechanics of where the crisis happened and how it played out in the minds of the people in the middle of it, it is perfectly valid.
However, this whole line of analysis is very much like analyzing a car wreck and concluding that the cause of accident was the driver's excessive application of braking and over correction. The driver was dead drunk. The underlying cause was the fact that his reflexes were so shot he couldn't react properly. It is largely irrelevant what the details are of how he lost control of the car, he was bound to do so under the circumstances.
Likewise the so called 'financial crisis'. Think of our economy/financial system as a bit like a building. Every part of the structure both adds 'load' to the building, and also supports the weight of the other component parts. As long as enough structural integrity exists to support the load at every given moment, the building stands.
Unfortunately what our whole society from top to bottom has been doing is looking at this structure and saying to themselves "you know, it is a waste of money to have that beam be 150% stronger than the load it is carrying" and then someone comes along and removes the beam and replaces it with one that's only 105% strong enough so they can use the extra materials someplace else, make more return on their investment.
Well, that could only go on for so long, and naturally people got a bit nervous and engineers pointed out that the building maybe was a bit shaky, so we invented a way to tie all the beams together more securely "well, if one fails its ok, if we spread out the load enough then no one part of the building will be overloaded".
Until finally one day the wind started to blow... Once one single part, ANY part of this massively over leveraged structure reached its failure point there was no margin left anywhere to take up the extra load anymore! Every part was already stressed to the absolute maximum limits of its capacity. And as long as things had kept going on an even keel it was inevitable that the search for profit would create even more leverage until inevitably the whole structure became so intolerant of even the slightest disturbance that it had to come crashing down.
The really disturbing part of this is that, as any engineer can tell you, when you reach this kind of situation of critical instability any small problem results in a cascade failure of the entire system. Every industry, practically every business, is leveraged out so far that even the smallest dips in cash flow result in immediate insolvency, which then propagates down the supply chain and up the 'wage chain'.
This thing is like an avalanche coming down the side of a mountain at 300 mph. The snow all around it looks all nice and quiet, but that means nothing. This thing has momentum, large momentum, and there isn't any stopping it because there's no redundancy left in the economy to act as a brake. No bailout plan or insurance scheme or nationalizing of banks or any other action anyone can take now is going to stop it until it gets to the bottom of the mountain.
The sad fact is we clearly saw, or should have seen, it coming. The system gave us every sign of being ready to fail. What was the 97 Asian financial crisis except a localized version of the same thing? It just didn't get big enough to build up the momentum to smash the whole system. Only one wing of the building fell off that time. If we had exercised any prudence whatsoever we would have taken the hint. But 'This American Life' certainly has it right in the sense that greed and hubris overrode common sense.
And look at where we are now. Hope you all have a nice supply of canned goods stashed. Best case scenario is they're about to get a lot more expensive.
Yeah, well, it would be a pointless debate in the sense that it is well and truly water under the bridge at this point, but there WERE choices. We could argue about the technical merits of different VMs, but there were choices in 2001. Have been for 20 years before that for that matter. Pointless to get into it at this juncture.
The proof will be in the pudding in any case. Personally I think P6 missed the window of opportunity unfortunately.
Oh, I think it will be interesting to see what all the P6 people come up with. I think they made a big mistake though by writing a whole new VM. There are some REALLY excellent VMs they could have at least adapted to their use. Things like JSR threading that the FORTH community figured out decades ago.
So I have to wonder at the thought process of a team which makes that monumental a mistake. Just my opinion, but I am writing applications and not theory and P5 still more than fills the need.
Heck, I basically duplicated ALL of the major functionality and a good bit of the 'add-on' stuff that Maven2 does in a bazzillion lines of java in perl in 30 days. Actually EASIER to rewrite it in perl than maintain 30+ POM files. Nah, Perl is still by far the glue of choice.
LOL, well, in some respects I CAN see how people who have spent a lot of time with other languages get a bit frustrated with Perl syntax. I don't think it is because it is BAD, just certain aspects of it (and the typing system it reflects) are subtly different semantics than what people are used to.
One problem with Python though is just the whole whitespace issue. Not that I think it is particularly a big deal in terms of just writing code, but have you ever tried autogenerating Python? That whitespace can be a royal PITA... lol.
My feeling overall is that nits about one syntax vs another (assuming they are equally expressive) is really missing the whole point of software engineering. The actual authoring of code is such a trivial part of the whole process of successfully developing an application for someone. So I just have little patience for the language wars.
"Likewise, Bruce Hogman provided a vertiable trove of COBOL information. According to Gartner, Bruce reports, there are 250 billion lines of COBOL source code being used, with 15 billion new lines each year. A major AAA national company has some 35,000 COBOL modules plus supporting COPY books and so on in its inventory. A major airlines has 848 COBOL modules in its crew management system with some 3,000,000+ SLOC of code. Merrill-Lynch runs 70 percent of its daily business on COBOL systems."
-- http://www.drdobbs.com/blog/portal/archives/2006/10/cobol_and_then.html
I can't say how Gartner comes up with the 250 billion number, but it is one which has been often repeated.
Its funny, see I feel the same way about the other 'P' languages, why should I need to learn another language which does EXACTLY the same things as the one I am already a master of? There is just no compelling reason to use Python, PHP, or Ruby vs Perl. People being what they are, they will always reinvent the wheel, but frankly had all that effort gone into Perl development I have a feeling we'd have one single much better implementation of dynamic scripting...
Wrong just isn't a strong enough word for this.
There are 250 BILLION lines of running COBOL code today. In fact there is more COBOL running out there than all the other code in all other languages combined (at least counting just business applications, but even counting everything this may be true). Many of them are truly gargantuan pieces of software, dwarfing things like Linux kernel in both size and at least some measures of complexity.
COBOL is in fact not dead at all, and is a .NET supported language, even MS knows better than to shun it. There is a real need for COBOL programmers as well, and there has been for several years now a concerted effort by industry to increase the number of people trained in COBOL programming. Believe it or not COBOL supports OOP and pretty much all the other commonly seen features of other procedural languages.
Likewise Perl is FAR from dead. There are vast quantities of web application code written in Perl.
Neither may be considered by 'cool' by the self proclaimed 3L1t3 hackers of the world, but if you think businesses really care much about that, you'd be mistaken.
Not to say I think everyone should code in or would LIKE coding in either COBOL or Perl, but calling either one of them dead is just contrafactual in the extreme...
In fact the way OO is implemented in perl is nice, you can do all sorts of handy things that are nearly impossible, even in other dynamic scripting languages.
As for the 'plumbing hanging out' it actually doesn't in practice 99.9% of the time. I mean materially what is the big difference between notations like:
this->{attributename}; # perl
and
this.attributename; // most anything else
And ouch, you have to call 'bless', but actually that gives you considerable flexibility since you can choose what package to bless to, and even rebless an object to a (possibly totally different) class at run time. Purists will tell you how HORRIBLE this is, but when was the last time you tried to stuff an X into a variable that was supposedly a Y? It just isn't that big of a problem, and if it IS something to worry about, you can easily add type checking to any variable via a tie.
There are a couple of minor annoyances, like the lack of implicit lexically scoped variables for parameters which might be nice to do away with, but again if you look at the syntax overall it makes little difference.
Finally if you are using a package (class) which produces blessed references (instances) as long as you use the defined API provided by the developer it should hide anything like 'is this class implemented using blessed hashes or blessed arrays'. Why would you care? How many of you have used CGI.pm for years? Does ANYONE here know off the top of their head if an instance is a hashref or not? I seriously doubt it.
"It is also possible to create a backdoor without modifying the source code of a program, or even modifying it after compilation. This can be done by rewriting the compiler so that it recognizes code during compilation that triggers inclusion of a backdoor in the compiled output. When the compromised compiler finds such code, it compiles it as normal, but also inserts a backdoor (perhaps a password recognition routine). So, when the user provides that input, he gains access to some (likely undocumented) aspect of program operation. This attack was first outlined by Ken Thompson in his famous paper Reflections on Trusting Trust."
http://en.wikipedia.org/wiki/Backdoor_(computing)
In any case an effort like this is, for the truly paranoid, feeble. The mechanisms available, proven mechanisms, are well known.
First of all you cannot trust any binary which was compiled with a toolchain which is not itself trusted at least as much as the code you are compiling. It is a well known fact that Ken Ritchie (IIRC it was he) added a block of code to pcc (the portable C compiler) which detected the compilation of the 'login' program and added a back door to it. Then he also added a piece of code which caused pcc when compiling ITSELF added both of these behaviors to the new pcc binary. This resulted in a period of a number of years in which the backdoor existed in virtually all Unix based systems. The pernicious part is, pcc's SOURCE code contained no trace of any of this because the source for the hack only existed ONCE, in the orginal 'ancestor' copy of pcc from which all others descended. It would be at best VERY difficult to know that some similar technique was not used on any given distribution. In theory one could do analysis of every binary, but then how do you know your debugger and disassembler aren't lying to you? Etc.
Even assuming you have by some process guaranteed you have a clean set of binaries, why would you think that the hardware you're running them on is trustworthy? It would be foolish to assume that of the billions of transistors of which your CPU is composed that some small fraction are not dedicated to nefarious purposes...
No, the people working on this may think they're paranoid, but frankly if they thought about it a bit more, they would realize they are not 1/10th paranoid enough...
Well, I was replying to you, but I was agreeing with you disagreeing with him... ;)
They WILL do so. Personally I'm not one of the rabid originalist type. I think society has to function and OK, it is true that the original intent was probably that gold and silver were the only money Congress was allowed to make. Yet our modern society could not function on that basis. Unfortunately the debate was never had as to how the authority of Congress should have been altered in order to accommodate changing circumstance.
Instead the existing terms of the document were stretched out of all recognition one small increment at a time.
I think part of the problem is that when these mortgages were 'packaged' and sold, the securities were sold at values which were far in excess of the reasonable value of the underlying surety (the home). Frankly I doubt most of the people who bought them really understood that.
Deregulation has lead to a scenario where the large financial institutions dealings have become almost totally opaque. Trust but verify became 'oh, what the heck, everyone is doing it.'
The SCALE of the insanity is almost impossible to even measure. Credit default swaps for example (basically insurance taken on these instruments) reached a total net payout value of 74 TRILLION DOLLARS in 2006. The total net asset value of the ENTIRE HUMAN RACE is only about 54 trillion dollars!!! The entire thing was literally insane, beyond any conceivable reason.
No bailout is going to fix all this because the fundamentals simply cannot support the whole way the industry is being run. Truth is the banking system porked itself. Time to start thinking about how money works. Deep thinking required now.
If you assume that Congress has UNLIMITED AUTHORITY, then why do we have a Constitution at all? The Constitution is a compact between the people, of the comity of the people, WITH EACH OTHER which vests certain defined and limited portions of the absolute sovereignty of the people in a Congress, etc. That power is clearly and explicitly limited. What part of 'reserved to the people' is not clear here?
When Congress assumes for itself powers not vested in it they are overthrowing the authority of the people. MY ancestors stood literally in the face of British cannon fire in order to guarantee EVERYONE the protection of those rights. Now, does anyone doubt that it does us dishonor if we fail to respect that? I WILL NOT yield those rights, not to Congress nor to anyone else. And if fools insist on giving them away, then I will withdraw my permission for those people to use those rights, and there is NO LIMIT to my right to do so, nor to the just means which I may avail myself of in that cause.
http://www.constitution.org/fed/federa00.htm
No no no. Remember there is a 'time value of money'. There is substantial opportunity cost associated with making ANY loan. Not to mention the risk of inflation. If I put my money into an investment at 5% return, and even a small fraction of my principle is written down, I'm immediately in the red.
See the flaw with all these mortgage backed securities is this. The house is worth 100k lets say, the bank loans 100k, they sell the mortgage for 200k, THAT 200k IS PRINCIPLE. It is really just as if the buyers of these securities paid 150-200% of market value for houses! ANY declines in value loose them money. The whole scheme was just crazy.
mark-to-market (MTM accounting, which is rule 157) no doubt isn't helping the banks, but the real problem IMHO is the way these mortgages were packaged.
Say you make a mortgage for $100k to someone for 20 years, and the total repayment is $250k principal plus interest. Now you take 10 of these things and you package them up and sell the paper for $1.5 million (150k per mortgage). SOUNDS like a good deal, except what happens if ONE of those mortgages goes bad? The buyer of the paper is now out 250k and all of a sudden the return on his paper is approaching zippo grande and it is now basically a worthless piece of paper.
In theory the paper might still be worth quite a bit, but the holder IS going to lose money, and the risk on the paper is still the same.
The powers not delegated to the United States by the Constitution, nor prohibited by it to the States, are reserved to the States respectively, or to the people.
Amendment X.
There is something unclear about this? POWERS NOT DELEGATED, the key phrase. All that is not permitted explicitly is EXPLICITLY forbidden. There MAY be arguments as to the extent of the power of Congress which could be made with regards to commerce and regulating the money, but they are at best weak arguments. The point is, your analysis is simply wrong and not only directly contravened by the 10th amendment, but also discussed at length by the authors in the Federalist Papers (in all fairness Hamilton made some arguments similar to yours, but it is a dangerous position to take).
What if Congress decides that 'the common welfare' would be served by having the FBI throw you in a pit for 30 years? Is that OK because 'hey, it is good for everyone else, and they can do whatever they think is good'. Sorry, not in my United States.
between 'no design at all' and what agile methodologies advocate. In XP methodology for example you would first develop your system requirements in the form of user stories. Those are used to prioritize features, then you engage in a series of iterations, each one adds certain features. Another tool you use is a system metaphor or model, which provides a way of reasoning about the overall system architecture.
Any given iteration only deals with those requirements which are assigned to that one iteration. Code is written (tests first) to accomplish the requirements of that iteration, and the customer supplies a set of functional tests which verify that the software meets those specific requirements.
During later iterations new tests will be written and either more code written or existing code refactored and extended to add the additional features. More functional tests are developed as well, and the added features plus the existing features are all tested for compliance to the new requirements.
There is no single overall design 'phase'. There could be various points at which the large scale features of the system are fleshed out. In some cases a 'spike' might be used to explore different options. Spike code is considered throw away and simply allows you to determine which of several designs are likely to work best. Usually there will be some specific 'problematic' areas (say 'how can the system achieve the required latency requirements') which a spike would address.
The whole philosophy of agile development essentially rests on the observation that even in what are supposedly more 'up front design' type methodologies that the real shape of the system ends up being determined over the process of development. It is like applying the 'Wu Wei' concept of Daoism to software, don't fight the way things REALLY flow. Waterfall style development is a myth, and pretending it isn't is just paddling upstream.
In my long experience of writing complex applications I have yet to encounter a situation where the requirements forced me to write code which wasn't modular. I am not at all sure what the conditions would be where that is true.
I can only surmise that the model/metaphor was poorly chosen or not well mapped onto the requirements. This kind of thing is one of the big issues with strict 'top down' waterfall style development, and one of the reasons it is slowly but surely being abandoned. The expectation is that some 'analysts' will have by some process nailed down EXACTLY how everything is going to work. That is at variance with reality, nobody really knows how a large piece of software is going to work at the outset. The system architect probably has a pretty good general idea in mind, and any number of constraints could be defined, use cases, etc. But these projects often fail simply because someone writes up some thing that says 'The foomazoo SHALL perform the calculation' and it turns out, that was a horrible way to structure the software. Thus things like agile development...
Of course you may not be in the position to design an individual module when you're part of a larger team, or it may be legacy code, etc. Some code truly is not testable, but that is as I have said before a problem with the CODE not the concept of TDD.