I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
It is possible, however, to write a complex application and have formal assurances that the system is secure with respect to certain properties. You can write a complex system and have formal verification that it does not contain any beffer overflow exploits. You can write a complex application and prove that the code fully, correctly, and completely implements a security protocol, and that anything not fully conforming to said protocol is guaranteed to be denied access. You may not be able to guarantee everything, but you should be able to guarantee something.
An engineer who builds a skyscraper cannot guarantee that it will never fall down: powerful earthquakes, amazing freak weather, planes crashing into it, and other unforseen things may occur. What the engineer will provide legal guarantees on is conditions under which it will not fall down: certain classes of earthquake, weather conditions under which it should stand, and what sort of structural damage it can sustain before falling.
While you are unlikely to be able to say your code will always work perfectly, you should be able to say what aspects are guaranteed, and under what conditions it is assured to work.
I wonder if they can get around it by claiming the code as the documentation as to what the program does. That way if it does something wrong it is perfectly documented that that is what it is suppose to do.
And this is exactly why specification is actually important. Unless you have a specification (preferrably a formal one) on what the intended behaviour is, then it is impossible to have incorrect behaviour: by definition anything the software does is the correct thing for the software to do.
It's also worth noting that your specification doesn't need to cover all possible behaviours for the software, it might be as simple as saying "in the particular case of X, then Y will occur", for which you can then provide formal verification.
Software doesn't need to behave perfectly, but it would be nice if software came with formal assurances that, while not everything will necessarily work perfectly, X, Y and Z are guaranteed.
Yes, software has bugs and mistakes and errors, and in a large project it can become infeasible to guarantee that there aren't issues somewhere. That doesn't mean, however, that software should simply ignore the issue. It's a matter of contracts and assurance: It is possible to make certain assurances about a piece of software and spend the time making sure it fulfills those properties. For instance, while you might not go to the trouble of ensuring a word processor is completely bug free, it may be worth providing assurances, for instance, that files cannot be corrupted when the program crashes, and that the print preview is exactly what will be printed. There are methods for proving and verifying such properties, and if you restrict it to key properties that the client wants formal assurance on then it is not significant extra work to use those methods.
The same principle applies to security. While you may not be able to say your system in completely invulnerable without expending enourmous amounts of time and money, you can make certain formal assurances like "no buffer overflow exploits exist in this software" or "the software will always fully and correctly carry security protocol X, or abort with an error and deny access". Such things don't ensure 100% security, but being able to formally make such assurances does significantly improve the expected security of the software.
For some reason software has gotten stuck in an "all or nothing" mentality, claiming that obviously you can't ensure perfection, therefore you should assume nothing, and make no assurances at all. That is neither necessary, nor productive. Being able to formally guarantee certain properties of software is both possible, and only as much extra work as the amount of assurance you choose to provide.
This all seems to be a rehash of the "worse is better" meme... that those damn software programers/companies aren't doing what we want. The only problem is, it's all crack. Almost no customers, even now, are willing to pay more for "quality".
That is slowly changing as the security and reliability meme becomes more common in the mainstream. In practice it was Microsofts horrible run with security, which got a lot of press time, which began to bring security into public focus. It's still not entirely mainstream, but people are more aware than they were, and more and more people are beginning to care.
No its a problem with an easy solution. You people seem to think that packages are the only way to install software. Do you know what the real easiest way is for a vendor to setup a universal installer? A perl script.
The problem with this is the maintenance/patch/upgrade/uninstall process. Part of the beauty of package management is that is provides a central registry of everything that is installed, making it a lot easier to maintain your system. At worst I would ask for something like autopackage which at least provides a single point for all third party software installed. Hopefully package manager integration will arrive in autopackage soon so that autopackages can register with the package manager and we can be back to a single system to track what has been installed on the system.
Wow, you're right, I can't find much beyond this which is a mutlipurpose plugin, but does at least support Objective C, though only really providing syntax highlighting and not all the goodies you can expect from other eclipse plugins.
Screw that! What really makes the women wet is a man that washes the dishes after dinner! I suspect your wife is only hanging around your neck to get you to clean up after yourself!
I think that depends on the quality of your cooking. A good enough cook is politely shuffled out of the kitchen come washing up time and not expected to do dishes. A poor cook, on the other hand, doesn't tend to engender such a gracious response.
I think there is a plug in that should scratch just about any itch. Nice.
Indeed, the Python and Perl plugins are both very nice and from the look of it more featureful than the Ruby plugin at the moment (though I expect it's only a short matter of time before that evens out). I think its more a matter of what languages aren't currently covered? There are apparently plugins for Eiffel and Haskell and Ocaml and SPARK and Scheme (though I can't vouch for quality on any of those) and pretty much anything else you can imagine (given that those were random searches on my part).
Certainly, but I think it remains a point of pride for the infosec guys to see that th webserver remains unhacked regardless of the consequences, and it seems they have done a good job.
It depends on who is running it really. Being SIS rather than something more computer security oriented (like GCHQ), I'd expect it is possible that they will get hacked. Places like GCHQ and the NSA on the other hand, who deal with information assurance and computer security as part of their role, tend to have far better records on that front. The NSA website has never been hacked, and given their profile you can be sure it isn't from lack of trying.
I should point out that Archos has been selling devices that do just that, for quite some time now. I'm sure there are other companies that do this, as well.
Yup, I can name another one. Neuros has had multimedia player with PVR abilities for a while as well now. Better yet they have exceptionally good OSS support, including open source firmware on many of their devices, and an open development process.
First of all, let's be clear: we are facing warming. Using proxy data from a variety of sources such as tree rings and ice cores it is possible to calculate some decent estimates of global temperatures over the last ten thousand years or so. There are obvious cycles, and a fair amount of fluctuation, but current temperatures represent a significant upswing - that is acceleration - in warming over the last century or so.
On the other side of things: Our present understanding of physics is fairly unequivocal that CO2 and other gases can cause warming by trapping heat. Using ice cores and other methods to reconstruct historical CO2 levels we find that CO2 correlates extremely well with global temperature. We also find that CO2 levels have spiked beyond anything in recent history (recent history being the last four hundred thousand years) in just the last 150 years - again correlating extremely well with the recent acceleration in warming. Given the extremely good correlations and the clear reasons to believe in causation (which is to say, physics) it would seem that the burden of proof should fall to those who suggest human CO2 emissions are not having a significant impact on global temperatures.
Are we killing the earth? I doubt it - I expect the earth will simply get warmer and keep on going. The question is: are we making life for ourselves much harder and much more costly, and is that preventable? There is strong evidence that human CO2 emissions are having a significant impact on climate, and that is certainly the cause over which we have the most direct influence. It makes sense to do something about it if we can.
I suppose LaTeX support is nice for the math geeks, though you would think that they are already using a program with support for it if they need it.
I am a math geek, and unsurprisingly I do indeed use LaTeX. I am quite happy to see the TeX style math support in AbiWord though: not for me, but for others. As a math geek I read a lot of math, and seeing the ugly, badly rendered, hard to read, amateurish garbage produced by some word processors pains me. I'm realistic though. There are a lot of people who only need a little math and aren't going to learn how to write documents in LaTeX just for that. To have someting like AbiWords new equation editing is a good thing: it doesn't render quite as well as LaTeX, but it is streets ahead MS Word and nicer than OO.o currently manages: it's actually somewhat readable.
Personally I would prefer people use this OO.o macro which allows embedding of rendered LaTeX in an editable way, but to be fair you still need to know a little LaTeX to really be ale to use it (unlike AbiWord's offering).
And exactly how do we know that? How many ice ages has "recorded history" gone through? None, I'm pretty sure. Didn't we just discover fire before the last ice-age? We don't even have weather statistics for the entire past century - but we somehow know for sure that global warming is real, is entirely caused by humans and is going to kill us all?
Do we have direct temperature records reaching back more than a century or so? No. We do have a variety of other sources such as tree ring data and ice cores that can provide estimates of temperature stretching back thousands and even tens of thousands of years. Collect enough of those proxy data sets from a decent variety of locations and types of sources and can calculate a reasonably accurate estimate of global temperatures stretching back about ten thousand years. There is, of course, room for interpretation on which proxy data series to include or exclude and exactly how tight the error margins on historical temperature estimation are based on the temperature calculation techniques. The result, however, is that unless you are very selective in how you interpret the data there is a notable upswing - that is to say acceleration beyond the roughly cyclical behaviour - in global temperature for the last century or so. The data we have so far is pretty clear, we are experiencing notable global warming.
Is global warming entirely caused by humans? I think it's safe to say no. I doubt you'll find any serious scientist or non-politically motivated person saying otherwise. What we do know is that according to our understanding of physics CO2 will tend to trap heat. We also have (via those ice cores etc.) historical C02 records. It turns out that C02 levels and global temperature correlate extremely well (though not perfectly - there are clearly other factors at play). That is we have good correlation (over a roughly 400,000 years via the vostok ice core, less via other methods but with similar results), and via basic physics we have sound reasons to believe in causation. We also know that C02 levels have spiked dramatically over the last 150 years, above any previous levels from the last 400,000 years or so.
Given all of that I think we can reasonably suggest that there is good evidence that human actions may well be having a significant effect on the global climate, and that the global climate is indeed warming. Of course we may still be mistaken, but given the evidence I think the burden of proof now falls on those who deny any signficant impact from humanity in terms of global warming.
Ironically, I think your essay, while in jest, almost exactly captures the ID "argument" - don't be surprised if you see the (terrorist) Pat Robertson use it as another example of "scientists" supporting the theory !
Well that was very much what I was going for. While I appreciate things like FSM I felt they failed to adequately communicate with fence sitters or people leaning toward ID. The response is "but that's just stupid" and they ignore it. The principle of "Uncaused Force" was to hew as closely as possible to ID style arguments, sounding as plausible as ID, yet using the same argument form (which is where the flaw really lies) to conclude something ridiculous (that gravity is false). If people actually try to use the piece seriously... I think that will do more to discredit them in the long term, so I'm not really concerned.
Because the spec will still be wrong and incomplete until theres a concrete implementation to work from.
And the implementation will be wrong and incomplete with no assurances until it has been verified against some formal requirements. Not every project needs such assurances, but some projects do, and that can include some business software (where a bug or unforseen security issue may cost millions if not found until post-release). Bothering to spend the time working on a spec can save you vast amounts of time in the test/debug cycle due to the vastly larger amount of static checking and verification you can do on more completely specified code. Some things, like security, can be particularly difficult to refactor into existing code (as Microsoft has often found). Having some level of formal specification makes it possible to identify such issues before you become wedded to (and potentially mired in) a particular implementation.
In the business world, it generally goes something like this: Customer provides a spec (normally a word document written up by the one person who actually knows how they do business there, and then distorted beyond recognition by 2 months of committee meetings). You read the spec, mutter to yourself about what the hell they're thinking, and begin to write code to match the spec. When you deliver the first iteration, your customer suddenly identifies a need which they didn't spec and which totally breaks your design.
Why is it that programmers are so quick to embrace iterative approaches to development such as Agile and Test Driven development, but when it comes to the design and specification part they assume it is a one off deal? Developing a specification is an iterative process too, going back and forth with the customer solidifying and fleshing out precisely what the requirements are - and the person writing the spec ought to be someone skilled in specification writing working with the customer (the same way the person writing the program ought to be someone skilled in programming working with the customer). Ideally you could fold this process into an Agile development process, blending later iterations of spec development with iterations of implementation development providing mock ups of what the current spec would likely mean in terms of application.
Specs should, in my opinion, be a language-independent description of the task - not implementation, but structures and interfaces only.
Exactly. Further to that point, here is a discussion on that very subject, including examples of implementation and spec, and how they differ, and what the spec offers that the implementation doesn't.
Bad analogy. Safety is the major consideration in this example. If we wrote our business software the same way, it would cost a few million dollars instead of a few hundred.
Sure, but there's a sliding scale and just because going to the level of formality that Lockheed-Martin do over the shuttle would be too expensive, that doesn't mean it isn't worth doing anything at all. Hell, Linux is formally specified to some degree. It is in C, which means it uses static types, which means the type signatures for functions are formally specified (and statically checked!). Specifying a little bit more about the function (like, perhaps, some more specific requirements of input parameters than just the type and constraints on the return value other than just its type), particularly if you only do so for more critical functions, is hardly vastly more work costing many orders of magnitude more to produce, but it does offer you more options for static (and runtime!) checking and hence greater assurance. Use as much as you need, but don't pretend that its useless.
I wouldn't go to the same trouble in terms of specifications and plans to slap together a doghouse as I would to build my own home. I would expect someone building a skyscraper to go to more trouble again. The same applies to software.
Ah, see, that's the point. In other forms of engineering it's indeed possible to get that type of feedback, and use it in productive ways. When trying to apply the same techniques to software we find (oh horror!) that no two projects are alike - not even sufficiently alike to use the measurements we took in a way that actually works to our benefit in the new project.
Yes, because every bridge is identical to the last - the problem constraints are the same because the required span, surrounding topography, anticipated weather etc. are all identical wherever you go... and all civil engineering projects are bridges.
In the same way that there are classes of bridges, and buildings, and canal systems and aircraft that are similar, there are classes of software projects that are similar. Is software engineering identical to physical engineering disciplines? No, of course not, and any analogy or comparison is going to become strained because of the differences. I would suggest that there are more parallels than you make out however.
And there are ways to measure correctness for software projects, it's called formal specification. There are reasonable odds that you are doing some with whatever code you are writing now: static types are a form of formal specification, and they do provide some measures on correctness (whether function calls are correct with respect to the specification (type signature) of the function). You can also use contracts to provide a more detailed specification for functions and procedures. Going a little further you can fully specify your contracts and invariants allowing automated tools to generate proof obligations for all your code paths, and do verification of the code against the contracts and invariants. You can use those to prove theorems about properties of the code, or even go as far as full correctness proofs. You can do as much, or as little as the project calls for, depending on how badly you need to be sure of correctness: from type checking to full correctness proofs there is a range of options available.
There can be a lot of fun to be had in watching bad films. One of my favourites is "Raider of the Living Dead" a particularly awful film that is unbelievably funny (though a decent sized audience and some alcohol generally help). You should note, however, that a large number of the user reviews of The Rollerblade Seven begin along the lines of "I really like B-grade film, so this sounded great" and finish along the lines of "this is a truly evil, horrible film, nothing can truly prepare you, or describe to you how bad it is". That was pretty much my experience: I love watching B-grade crap sometimes. Heading along to the marathon at the the Incredibly Strange Film Festival is great fun, and you get to see a lot of truly appalling low budget crap. The Rollerblade Seven really is something else though, and there's just no decribing it. People talk about "getting the barf bag" for crap films in a joking manner, but I've known people who were literally physically ill from watching TRB7 - mostly due to the extended strobe light scene (great for epileptics and migraine sufferers too!). If you want to collect bad film then truly TRB7 should be in your collection as it is a whole new level of Bad. Just beware, the film was recut by the executive producers and released as "Legend of the Rollerblade Seven" and "Return of the Rollerblade Seven" - but don't accept editing by a sane person who was actually trying to make money out of the shit presented to him, go to the original version "The Rollerblade Seven".
Well at least we're talking about similar levels of Bad now. Personally I find TRB7 to be considerably more unbearable - the strobe light scene being the ultimate cap to what had been, up to that point, generally intolerable. Could some of the other people out there who have actually seen TRB7 speak up - I know there are some of you out there. Help explain the misery.
See, that's just a way of sayin you don't get it. Obtain a copy of The Rollerblade Seven. Watch it. Now watch a film like Glitter or From Justin to Kelly and marvel at how remarkably easy to watch it is, not featuring 3 or 4 consecutive replays of a 30 second shot of a fight scene so badly choreographed your grandmother could do better filmed from the worst possible angle and without anything even vaguely resembling actual dialogue or plot to motivate the mind numbing repitition of pointless things you don't want to see. As bad as the acting and story in Glitter may be, you can at least only find yourself bored and, after TRB7, spend your time admiring the camerawork, sets, foley work and simply laugh at what a poor job the editor has done rather than wonder what hallucinogens he was taking and fighting the urge to hunt him down and kill him.
Look, there are bad films, and then there are Bad Films. As crap as Showgirls may be it has features like semi-professional camera work, audible dialog, a plot that is not only coherent, but can actually be discerned just from watching the film, and a complete lack of 5 minute long nausea inducing strobe light scenes. Until you have seen the true horror of something like The Roller Blade Seven you don't really know bad films. Try reading some of the user reviews to get some idea - but be aware, until you've seen TRB7 you can never truly understand how bad it is; you'll think you know, but believe me, you don't.
Slashdot Mirror
I'm sick and tired of hearing talk about holding vendors or developers legally responsible for writing insecure code. It's impossible to write any complex application and not have security problems.
It is possible, however, to write a complex application and have formal assurances that the system is secure with respect to certain properties. You can write a complex system and have formal verification that it does not contain any beffer overflow exploits. You can write a complex application and prove that the code fully, correctly, and completely implements a security protocol, and that anything not fully conforming to said protocol is guaranteed to be denied access. You may not be able to guarantee everything, but you should be able to guarantee something.
An engineer who builds a skyscraper cannot guarantee that it will never fall down: powerful earthquakes, amazing freak weather, planes crashing into it, and other unforseen things may occur. What the engineer will provide legal guarantees on is conditions under which it will not fall down: certain classes of earthquake, weather conditions under which it should stand, and what sort of structural damage it can sustain before falling.
While you are unlikely to be able to say your code will always work perfectly, you should be able to say what aspects are guaranteed, and under what conditions it is assured to work.
Jedidiah.
I wonder if they can get around it by claiming the code as the documentation as to what the program does. That way if it does something wrong it is perfectly documented that that is what it is suppose to do.
And this is exactly why specification is actually important. Unless you have a specification (preferrably a formal one) on what the intended behaviour is, then it is impossible to have incorrect behaviour: by definition anything the software does is the correct thing for the software to do.
It's also worth noting that your specification doesn't need to cover all possible behaviours for the software, it might be as simple as saying "in the particular case of X, then Y will occur", for which you can then provide formal verification.
Software doesn't need to behave perfectly, but it would be nice if software came with formal assurances that, while not everything will necessarily work perfectly, X, Y and Z are guaranteed.
Jedidiah.
Yes, software has bugs and mistakes and errors, and in a large project it can become infeasible to guarantee that there aren't issues somewhere. That doesn't mean, however, that software should simply ignore the issue. It's a matter of contracts and assurance: It is possible to make certain assurances about a piece of software and spend the time making sure it fulfills those properties. For instance, while you might not go to the trouble of ensuring a word processor is completely bug free, it may be worth providing assurances, for instance, that files cannot be corrupted when the program crashes, and that the print preview is exactly what will be printed. There are methods for proving and verifying such properties, and if you restrict it to key properties that the client wants formal assurance on then it is not significant extra work to use those methods.
The same principle applies to security. While you may not be able to say your system in completely invulnerable without expending enourmous amounts of time and money, you can make certain formal assurances like "no buffer overflow exploits exist in this software" or "the software will always fully and correctly carry security protocol X, or abort with an error and deny access". Such things don't ensure 100% security, but being able to formally make such assurances does significantly improve the expected security of the software.
For some reason software has gotten stuck in an "all or nothing" mentality, claiming that obviously you can't ensure perfection, therefore you should assume nothing, and make no assurances at all. That is neither necessary, nor productive. Being able to formally guarantee certain properties of software is both possible, and only as much extra work as the amount of assurance you choose to provide.
Jedidiah.
This all seems to be a rehash of the "worse is better" meme ... that those damn software programers/companies aren't doing what we want. The only problem is, it's all crack. Almost no customers, even now, are willing to pay more for "quality".
That is slowly changing as the security and reliability meme becomes more common in the mainstream. In practice it was Microsofts horrible run with security, which got a lot of press time, which began to bring security into public focus. It's still not entirely mainstream, but people are more aware than they were, and more and more people are beginning to care.
Jedidiah.
No its a problem with an easy solution. You people seem to think that packages are the only way to install software. Do you know what the real easiest way is for a vendor to setup a universal installer? A perl script.
The problem with this is the maintenance/patch/upgrade/uninstall process. Part of the beauty of package management is that is provides a central registry of everything that is installed, making it a lot easier to maintain your system. At worst I would ask for something like autopackage which at least provides a single point for all third party software installed. Hopefully package manager integration will arrive in autopackage soon so that autopackages can register with the package manager and we can be back to a single system to track what has been installed on the system.
Jedidiah.
Wow, you're right, I can't find much beyond this which is a mutlipurpose plugin, but does at least support Objective C, though only really providing syntax highlighting and not all the goodies you can expect from other eclipse plugins.
Jedidiah.
Cooking?!?
Screw that! What really makes the women wet is a man that washes the dishes after dinner! I suspect your wife is only hanging around your neck to get you to clean up after yourself!
I think that depends on the quality of your cooking. A good enough cook is politely shuffled out of the kitchen come washing up time and not expected to do dishes. A poor cook, on the other hand, doesn't tend to engender such a gracious response.
Jedidiah.
I think there is a plug in that should scratch just about any itch. Nice.
Indeed, the Python and Perl plugins are both very nice and from the look of it more featureful than the Ruby plugin at the moment (though I expect it's only a short matter of time before that evens out). I think its more a matter of what languages aren't currently covered? There are apparently plugins for Eiffel and Haskell and Ocaml and SPARK and Scheme (though I can't vouch for quality on any of those) and pretty much anything else you can imagine (given that those were random searches on my part).
Jedidiah.
Certainly, but I think it remains a point of pride for the infosec guys to see that th webserver remains unhacked regardless of the consequences, and it seems they have done a good job.
Jedidiah.
It depends on who is running it really. Being SIS rather than something more computer security oriented (like GCHQ), I'd expect it is possible that they will get hacked. Places like GCHQ and the NSA on the other hand, who deal with information assurance and computer security as part of their role, tend to have far better records on that front. The NSA website has never been hacked, and given their profile you can be sure it isn't from lack of trying.
Jedidiah.
I should point out that Archos has been selling devices that do just that, for quite some time now. I'm sure there are other companies that do this, as well.
Yup, I can name another one. Neuros has had multimedia player with PVR abilities for a while as well now. Better yet they have exceptionally good OSS support, including open source firmware on many of their devices, and an open development process.
Jedidiah.
First of all, let's be clear: we are facing warming. Using proxy data from a variety of sources such as tree rings and ice cores it is possible to calculate some decent estimates of global temperatures over the last ten thousand years or so. There are obvious cycles, and a fair amount of fluctuation, but current temperatures represent a significant upswing - that is acceleration - in warming over the last century or so.
Given that, the question of causes remains. Volvano activity certainly throws out a lot of C02, around one hundred and thirty to two hundred and thirty million metric tons a year. In comparison the US produces around five billion metric tonnes a year by itself convincingly dwarfing volcanic output. You also point the finger at solar activity, claiming it is ignored - it isn't. As you point out the IPCC includes it in their considerations and found, depending on the model used, that it accounted for effects of sixteen to thirty six percent that of those caused by CO2 and other greenhouse emissions. There are questions as to how well solar activity actually correlates with global temperature as well, so it's an open topic.
On the other side of things: Our present understanding of physics is fairly unequivocal that CO2 and other gases can cause warming by trapping heat. Using ice cores and other methods to reconstruct historical CO2 levels we find that CO2 correlates extremely well with global temperature. We also find that CO2 levels have spiked beyond anything in recent history (recent history being the last four hundred thousand years) in just the last 150 years - again correlating extremely well with the recent acceleration in warming. Given the extremely good correlations and the clear reasons to believe in causation (which is to say, physics) it would seem that the burden of proof should fall to those who suggest human CO2 emissions are not having a significant impact on global temperatures.
Are we killing the earth? I doubt it - I expect the earth will simply get warmer and keep on going. The question is: are we making life for ourselves much harder and much more costly, and is that preventable? There is strong evidence that human CO2 emissions are having a significant impact on climate, and that is certainly the cause over which we have the most direct influence. It makes sense to do something about it if we can.
Jedidiah.
I suppose LaTeX support is nice for the math geeks, though you would think that they are already using a program with support for it if they need it.
I am a math geek, and unsurprisingly I do indeed use LaTeX. I am quite happy to see the TeX style math support in AbiWord though: not for me, but for others. As a math geek I read a lot of math, and seeing the ugly, badly rendered, hard to read, amateurish garbage produced by some word processors pains me. I'm realistic though. There are a lot of people who only need a little math and aren't going to learn how to write documents in LaTeX just for that. To have someting like AbiWords new equation editing is a good thing: it doesn't render quite as well as LaTeX, but it is streets ahead MS Word and nicer than OO.o currently manages: it's actually somewhat readable.
Personally I would prefer people use this OO.o macro which allows embedding of rendered LaTeX in an editable way, but to be fair you still need to know a little LaTeX to really be ale to use it (unlike AbiWord's offering).
Jedidiah.
And exactly how do we know that? How many ice ages has "recorded history" gone through? None, I'm pretty sure. Didn't we just discover fire before the last ice-age? We don't even have weather statistics for the entire past century - but we somehow know for sure that global warming is real, is entirely caused by humans and is going to kill us all?
Do we have direct temperature records reaching back more than a century or so? No. We do have a variety of other sources such as tree ring data and ice cores that can provide estimates of temperature stretching back thousands and even tens of thousands of years. Collect enough of those proxy data sets from a decent variety of locations and types of sources and can calculate a reasonably accurate estimate of global temperatures stretching back about ten thousand years. There is, of course, room for interpretation on which proxy data series to include or exclude and exactly how tight the error margins on historical temperature estimation are based on the temperature calculation techniques. The result, however, is that unless you are very selective in how you interpret the data there is a notable upswing - that is to say acceleration beyond the roughly cyclical behaviour - in global temperature for the last century or so. The data we have so far is pretty clear, we are experiencing notable global warming.
Is global warming entirely caused by humans? I think it's safe to say no. I doubt you'll find any serious scientist or non-politically motivated person saying otherwise. What we do know is that according to our understanding of physics CO2 will tend to trap heat. We also have (via those ice cores etc.) historical C02 records. It turns out that C02 levels and global temperature correlate extremely well (though not perfectly - there are clearly other factors at play). That is we have good correlation (over a roughly 400,000 years via the vostok ice core, less via other methods but with similar results), and via basic physics we have sound reasons to believe in causation. We also know that C02 levels have spiked dramatically over the last 150 years, above any previous levels from the last 400,000 years or so.
Given all of that I think we can reasonably suggest that there is good evidence that human actions may well be having a significant effect on the global climate, and that the global climate is indeed warming. Of course we may still be mistaken, but given the evidence I think the burden of proof now falls on those who deny any signficant impact from humanity in terms of global warming.
Jedidiah.
Ironically, I think your essay, while in jest, almost exactly captures the ID "argument" - don't be surprised if you see the (terrorist) Pat Robertson use it as another example of "scientists" supporting the theory !
Well that was very much what I was going for. While I appreciate things like FSM I felt they failed to adequately communicate with fence sitters or people leaning toward ID. The response is "but that's just stupid" and they ignore it. The principle of "Uncaused Force" was to hew as closely as possible to ID style arguments, sounding as plausible as ID, yet using the same argument form (which is where the flaw really lies) to conclude something ridiculous (that gravity is false). If people actually try to use the piece seriously... I think that will do more to discredit them in the long term, so I'm not really concerned.
Jedidiah.
You do realise "Uncaused Force" is a parody right?
Because the spec will still be wrong and incomplete until theres a concrete implementation to work from.
And the implementation will be wrong and incomplete with no assurances until it has been verified against some formal requirements. Not every project needs such assurances, but some projects do, and that can include some business software (where a bug or unforseen security issue may cost millions if not found until post-release). Bothering to spend the time working on a spec can save you vast amounts of time in the test/debug cycle due to the vastly larger amount of static checking and verification you can do on more completely specified code. Some things, like security, can be particularly difficult to refactor into existing code (as Microsoft has often found). Having some level of formal specification makes it possible to identify such issues before you become wedded to (and potentially mired in) a particular implementation.
Jedidiah.
In the business world, it generally goes something like this: Customer provides a spec (normally a word document written up by the one person who actually knows how they do business there, and then distorted beyond recognition by 2 months of committee meetings). You read the spec, mutter to yourself about what the hell they're thinking, and begin to write code to match the spec. When you deliver the first iteration, your customer suddenly identifies a need which they didn't spec and which totally breaks your design.
Why is it that programmers are so quick to embrace iterative approaches to development such as Agile and Test Driven development, but when it comes to the design and specification part they assume it is a one off deal? Developing a specification is an iterative process too, going back and forth with the customer solidifying and fleshing out precisely what the requirements are - and the person writing the spec ought to be someone skilled in specification writing working with the customer (the same way the person writing the program ought to be someone skilled in programming working with the customer). Ideally you could fold this process into an Agile development process, blending later iterations of spec development with iterations of implementation development providing mock ups of what the current spec would likely mean in terms of application.
Jedidiah.
Specs should, in my opinion, be a language-independent description of the task - not implementation, but structures and interfaces only.
Exactly. Further to that point, here is a discussion on that very subject, including examples of implementation and spec, and how they differ, and what the spec offers that the implementation doesn't.
Jedidiah.
Bad analogy. Safety is the major consideration in this example. If we wrote our business software the same way, it would cost a few million dollars instead of a few hundred.
Sure, but there's a sliding scale and just because going to the level of formality that Lockheed-Martin do over the shuttle would be too expensive, that doesn't mean it isn't worth doing anything at all. Hell, Linux is formally specified to some degree. It is in C, which means it uses static types, which means the type signatures for functions are formally specified (and statically checked!). Specifying a little bit more about the function (like, perhaps, some more specific requirements of input parameters than just the type and constraints on the return value other than just its type), particularly if you only do so for more critical functions, is hardly vastly more work costing many orders of magnitude more to produce, but it does offer you more options for static (and runtime!) checking and hence greater assurance. Use as much as you need, but don't pretend that its useless.
I wouldn't go to the same trouble in terms of specifications and plans to slap together a doghouse as I would to build my own home. I would expect someone building a skyscraper to go to more trouble again. The same applies to software.
Jedidiah.
Ah, see, that's the point. In other forms of engineering it's indeed possible to get that type of feedback, and use it in productive ways. When trying to apply the same techniques to software we find (oh horror!) that no two projects are alike - not even sufficiently alike to use the measurements we took in a way that actually works to our benefit in the new project.
Yes, because every bridge is identical to the last - the problem constraints are the same because the required span, surrounding topography, anticipated weather etc. are all identical wherever you go... and all civil engineering projects are bridges.
In the same way that there are classes of bridges, and buildings, and canal systems and aircraft that are similar, there are classes of software projects that are similar. Is software engineering identical to physical engineering disciplines? No, of course not, and any analogy or comparison is going to become strained because of the differences. I would suggest that there are more parallels than you make out however.
And there are ways to measure correctness for software projects, it's called formal specification. There are reasonable odds that you are doing some with whatever code you are writing now: static types are a form of formal specification, and they do provide some measures on correctness (whether function calls are correct with respect to the specification (type signature) of the function). You can also use contracts to provide a more detailed specification for functions and procedures. Going a little further you can fully specify your contracts and invariants allowing automated tools to generate proof obligations for all your code paths, and do verification of the code against the contracts and invariants. You can use those to prove theorems about properties of the code, or even go as far as full correctness proofs. You can do as much, or as little as the project calls for, depending on how badly you need to be sure of correctness: from type checking to full correctness proofs there is a range of options available.
Jedidiah.
There can be a lot of fun to be had in watching bad films. One of my favourites is "Raider of the Living Dead" a particularly awful film that is unbelievably funny (though a decent sized audience and some alcohol generally help). You should note, however, that a large number of the user reviews of The Rollerblade Seven begin along the lines of "I really like B-grade film, so this sounded great" and finish along the lines of "this is a truly evil, horrible film, nothing can truly prepare you, or describe to you how bad it is". That was pretty much my experience: I love watching B-grade crap sometimes. Heading along to the marathon at the the Incredibly Strange Film Festival is great fun, and you get to see a lot of truly appalling low budget crap. The Rollerblade Seven really is something else though, and there's just no decribing it. People talk about "getting the barf bag" for crap films in a joking manner, but I've known people who were literally physically ill from watching TRB7 - mostly due to the extended strobe light scene (great for epileptics and migraine sufferers too!). If you want to collect bad film then truly TRB7 should be in your collection as it is a whole new level of Bad. Just beware, the film was recut by the executive producers and released as "Legend of the Rollerblade Seven" and "Return of the Rollerblade Seven" - but don't accept editing by a sane person who was actually trying to make money out of the shit presented to him, go to the original version "The Rollerblade Seven".
Jedidiah.
Well at least we're talking about similar levels of Bad now. Personally I find TRB7 to be considerably more unbearable - the strobe light scene being the ultimate cap to what had been, up to that point, generally intolerable. Could some of the other people out there who have actually seen TRB7 speak up - I know there are some of you out there. Help explain the misery.
Jedidiah.
See, that's just a way of sayin you don't get it. Obtain a copy of The Rollerblade Seven. Watch it. Now watch a film like Glitter or From Justin to Kelly and marvel at how remarkably easy to watch it is, not featuring 3 or 4 consecutive replays of a 30 second shot of a fight scene so badly choreographed your grandmother could do better filmed from the worst possible angle and without anything even vaguely resembling actual dialogue or plot to motivate the mind numbing repitition of pointless things you don't want to see. As bad as the acting and story in Glitter may be, you can at least only find yourself bored and, after TRB7, spend your time admiring the camerawork, sets, foley work and simply laugh at what a poor job the editor has done rather than wonder what hallucinogens he was taking and fighting the urge to hunt him down and kill him.
Jedidiah.
Look, there are bad films, and then there are Bad Films. As crap as Showgirls may be it has features like semi-professional camera work, audible dialog, a plot that is not only coherent, but can actually be discerned just from watching the film, and a complete lack of 5 minute long nausea inducing strobe light scenes. Until you have seen the true horror of something like The Roller Blade Seven you don't really know bad films. Try reading some of the user reviews to get some idea - but be aware, until you've seen TRB7 you can never truly understand how bad it is; you'll think you know, but believe me, you don't.
Jedidiah.