Larger shifts in CO2 and temp have occurred historically, and just as quickly, long before humans showed up.
I would be interested to know how you justify that claim. We do have decent historical carbon dioxide records via ice cores, and temperature proxies, but the high resolution short term data doesn't support your claim at all, and the longer term data which does, at least, provide significant changes in carbon dioxide and temperature are simply of far too poor a resolution to make any claims about "just as quickly": ice core co2 records that cover previous interglacial periods have resolution of around 500 years; moreover they don't show changes in carbon dioxide as large as what we are currently witnessing; records that go further back to periods with significantly higher carbon dioxide levels have resolution that is orders of magnitude worse.
Is the result of climate warming bad? NOBODY seems to know, although we managed to live quite successfully at lower tech levels and higher temps at regular periods in our history.
When mankind lived through previous changes in glacial/interglacial change the rate of change was more than likely slower. More significantly the lower technology levels of the time (and, equally importantly, lower populations) likely actually helped: humans were sparsely spread and nomadic - if climate changed then groups ould easily move to new areas. What we face now is a far denser population where any movement of significant percentages of population with have dramatic effects, and significant amounts of investment in fixed non-moile infrastructure. We can't just pick up and move all our farming infrastructure somewhere else at the drop of a hat - any transition would be costly and significant. Ultimately if you want an accounting of costs then ask an economist. The UK government did, and the result is the Stern Review from Nicholas Stern, a world respected economist. By his accounting (and it was an extremely detailed and in depth study - some 700 pages of report) the effects will be detrimental. Expect more such reports from other economists in the near future.
Can the human activity be changed such that the effect is altered, and what is the opportunity cost for doing so? [This is] really [what is] under argument. Environmentalists stamping their sandal-clad feet and crying that "we have to" is unpersuasive. And a report claiming that global warming is going to cost X is (nearly) meaningless unless it's compared to the Y cost of mitigation.
At this point I would again direct you to the Stern Review which is specifically what you ask for: an accounting of the costs of both inaction, and a comparison of those costs with an equally detailed accounting of the costs of mitigation. The results were that, providing mitigation action was taken sooner rather than later, the costs of mitigation efforts would more than repay themselves within 50 years. Indeed, costs of mitigation could amount to around 1% of global GDP if taken now, while inaction was expected to cost between 5% and 20% of global GDP by 2050. And just to reiterate: this was a detailed report from a respected economist (former chief economist for the World Bank), not a bunch of "sandal clad hippies".
Is the planet warming at the moment? - we aren't sure, but probably yes. We have a fair bit of data about temperature variations, though interpretation and comparison is still a problem. The Southern Hemisphere, in particular, does not seem to be warming noticeably.
What gave you the impression that the southern hemisphere wasn't warming noticeably? The raw data is freely available, and it is quite apparent that the southern hemisphere is warming noticeably; it just isn't warming as dramatically as the northern hemisphere.
I think the simple answer is critical mass: you need a sufficient number of developers developing not just the platform itself, but applications to run on it. Without a sufficient base of applications you're going to inevitably be perceived as a minority player and fail to attract many users, and hence many extra developers. Past a certain threshold you can be roughly self sustaining - Linux is across it, and so is MacOS X, but I don't think the projects you mention are even close. There is simply too much software built up on the GNU and X11 toolchain (and increasingly on GNOME and KDE) that people would have to leave behind to move to a new open source OS - it just isn't that tempting when the alternatives look so application poor.
To succeed you really need some base to start with (as Apple had when they moved to MacOS X, although even they lean on X11 and apps built on the GNU toolchain to some extent), or you need to support the toolchains of the applications (see OpenSolaris and BSD, which lean on X11, GNOME, KDE, etc.). Depending on what it is you wish to get rid off things can go from easy to very hard. Just ditching the Linux kernel is feasible - see the BSD and OpenSolaris options, among others. If you want to get rid of X11 as well... well that's trickier, but if you have a graphics system that will run GTK+ and or QT you might get by because you'll still have the rich supply of GTK+ apps, and can probably get KDE ported. If you want to ditch everything up to GNOME and KDE... well that means rewriting all your applications from scratch, and really that's a huge and incredibly daunting task. It's not just the big applications like web browsers and email clients, its all the different little niche applications that make the environment so rich. Its that that keeps many people on Windows - the one little application that few other people have any interest in, but happens to be vital to them; because everyone has a slightly different vital niche program it adds up to a lot of applications to reproduce before you can truly draw a large user base.
Linux has crossed the first threshold: it has enough users and application developers working on it that its self sustaining. It has yet to cross the next threshold where it provides a rich enough ecosystem of applications to entice the myriad of home users. It is, however, slowly crawling toward that goal.
Oh, I agree. My point was more that people often are prepared to put their foot down and say "No, we can't do that", and no one blinks when it happens. Sure someone working by the hour might make late changes, but they'll also be making new deadlines and other renogotiation a condition on such changes. The end result is that, if a fixed deadline or fixed costs exist then you have to put your foot down and have a harsh attitude toward late change requests - the is much less common in software development however.
Well you're talking about a blank cheque (I presume you're getting paid for each new feature or change the customer decides he wants) and an indefinite timeframe - the customer doesn't care when the "final" product with all the changes he can dream up is delivered, it an be next week, or 25 years from now. As I said, with no such constraints of course you aren't going to worry about deadlines - there are none - or costs - they can inflate as high as you like.
Most people, however, generally have some idea of core necessary functionality, the costs for that functionality, and a deadline that they'd like to have that core functionality up and fully running by. These demands, of course, provide long term deadlines that make a measure of project success - if you manage to get all their changes and new extra features included but miss a couple of core features by the deadline then yes, I would consider that a failure (unless of course the client renegotiates deadlines for core functionality along with the change requests). In other words: more often than not people hve some fixed idea of when they'd like certain things working by even from the outset; those ideas define long-term deadlines that are measures of product success. If your clients never have such things, more power to you - it sounds like you have very understanding and flexible clients.
But at the end of the day, a bridge is still a bridge no matter what parameters you throw at it. If all software was a web browser, we'd have solved the problem a long time ago. But it's not. It's like expecting someone to build a bridge this week, and then next week do some shoring up of the design of the Eiffel Tower, then maybe an undersea tunnel between America and Europe
You jest, but I think you underestimate civil engineers. They don't spend their whole careers designing very particular inds of bridges. You refer to the Eiffel tower, so perhaps that can furnish an instructive example. Gustave Eiffel, who designed the tower that bears his name, also designed the armature for the statue of liberty, an array of different (and quite notable) bridges, the observatory in Nice, a church in Manila, along with train stations, gas works, and viaducts, among other things. All of those have their own unique demands and required him to understand different disciplines (the needs of a church are quite different to the various things one needs to know to design a good functioning gas works, or a working observatory). And lets' be realistic, very few software engineers are asked to design a robust transactional database one week, a word processor the next week, and then maybe an air traffic control system. Sure they have a lot of variety, but so do other engineers - you just aren't as familiar with the odd and diverse specialisations within their fields. Again, I'm not claiming software engineering is easy, and certainly there is plenty of complain about in the field of management of software engineering, but you really shouldn't dismiss other fields of engineering so easily.
I think my definition of success would be finding as good a compromise as is feasible between customer demands in terms of features, timelines, and costs. I don't see meeting your clients every whim in terms of desired features while running massively over their required timeline and massively over their afforable budget any better than completing on time and on budget but failing to meet fundamental customer requirements. Soemtimes features, timeline and budget all fit together happily. More often they do not. That means late changes either cost a lot more, require a completely reassessed timeline, or don't make it in. If your clients are willing to given you a blank check and indefinite time to produce a shipping product, fine, meet every whim. In the case that they don't then at some point your going to have to draw lines as to when new features or changes can occur.
Has anything ever been completely nailed down with perfectly defined requirements and perfectly predictable deadlines? No, of course not. There are, however, cases where requirements have been adequately defined and projects were completed on time and on budget - it does happen occasionally.
It's not about "not giving the users what they want" and still succeeding, and likewise that doesn't require "completely nailing down requirements up front before beginning to code", it's being clear with regard to changes in requirements. Requirements will undoubtedly change as the project progresses, but I really don't think its that hard to make clear to customers that the later on the change occurs the smaller it will have to be, and that there will be some final deadline for changes near the end of development when new changes won't be accepted (and let's be honest, this happens all the time with code freezes when no new features are accepted prior to release and the focus is on debugging). The building client who wanted to add an extra floor when the building was already half constructed can moan that the builders are not "giving them what they want" but I suspect they'll get little sympathy. At some point reality hs to kick in.
Home builders have architectural plans. Machinist have blueprints. Electronic equipment builders have schematics. Software specifications are uniformly deplorable.
Software does have robust specification languages. Try Z, JML, SPARK, CASL etc. or things like CSP or CCS for specifying concurrent systems. Specification languages exist, and they provide sufficient power to nail down very specific specifications against which implementations can be verified. Sure, some of them are rather technical, but then you have to spend some time learning how to read complex electronic schematics too. For a variety of reasons such specfication languages are rarely used.
* There is no such thing as "all the requirements." The only thing you can count on in software development is that the requirements will change * The end users have no idea what to expect or what they want. They may think they want X, but they really want Y after seeing what X looks like.
Of course that is, to a certain extent, a problem that we make for ourselves by having a forgiving attitude toward such things. If a client that asked for a 3 story building comes back part-way into the construction process and asks for an extra story to be added between the second and third floors they'll simply get told "No". In the case of software projects, however, most people are afraid to say no to clients, or to set limits on defining the requirements. We've trained users to be fickle and change their minds by allowing them to do so. Of course such tolerance and flexibility has also been a boon for the software industry in that the end products have evolved much faster than they would have otherwise. There are pros and cons - but we should accept the consequences of our choices.
We've had a couple of thousand years of practice building bridges, and bridges solve a known problem: connect points A and B when there's a gap or a river inbetween. Software engineering is "Do X, Y, and Z except when A, B, but not C except when A and B and when user isnt E except when user is E and A and B and X and Y are not Z but Z is B when F is..."
This is a silly comparison. Saying that building a bridge (as an example of civil engineering) is just a matter of "connect points A and B when there's a gap" is akin to saying a software project is just a matter of "present users data from a database when they need to know it": you're making it sound easy and simple by glossing over all the myriad of complex and important details that need to be considered. For the software project you might want to consider what the data is, how it needs to be presented, where the users are (over a network, worldwide perhaps?), what sort of security is needed, etc. For the bridge you'll need to worry about exactly where to build the bridge, what sort of traffic it needs to be able to carry, what the weather is like in the area and what stresses the bridge will need to tolerate, etc.
Each case has a lot of details that need to be properly nailed down and dealt with. This is not to say that software engineering is easy; rather it is to point out that other forms of engineering (be it civil, electrical, aerospace, or otherwise) are, in their own way, just as hard - something that I think far too many slashdotters don't really seem to have an appreciation for.
Compilable in a very broad sense, and not of any real practical value (that prolog is kind enough to assume bubblesort as opposed to bogosort is just icing). The reality is that the specification is far shorter than any decent implementation. As to whether much real world code can be specified this way: try actually looking at code written with specifications such as SPARK-Ada code, JML annotated Java, or Eiffel. A surprising amount of real world code can, if you're actually willing to try, be specified efficiently. Sure, some things, like printing output, or GUIs, don't lend themselves to specification - that doesn't mean that there aren't lots of things that do however.
It's specifications, pre- and post-conditions, all that "theoretical bullshit" we learned in university. It's just that writing code that way is very un-exciting, and that's a vast understatement.
That depends really. As a math geek I find a certain amount of pedantry and formlisation natural. I mean many people are happy to spend the extra time writing annotations to define types signatures for functions (and even types for variables in some languages) which is, really, just a light form of specification. Using Eiffel, or Java with JML, or Spec#, or D, really isn't as bad as you might think - you mostly end up writing things you'll have to get around to writing anyway (when it comes time to properly document APIs etc.), you just get to write it along with the code in a slightly more formal way...
There are a few misconceptions here which deserve comment.
You can't prove, for example, whether a lambda program will terminate (Halting Problem), and in fact you can prove that you can't prove this.
This simply isn't the case - there are lots of programs for which you can easily prove termination. The catch with the Halting problem is that you cannot find a procedure that will work for all programs. In other words you may find yourself in a situation where you cannot prove termination for certain programs; that does not mean, however, that you can't prove termination for others, nor that such proofs are invalid. Trying to prove termination is far from futile - the Halting problem will at worst tell you that you might not be able to do it, but if you can (and often enough you can indeed) then the proof is perfectly valid.
If you have a sufficiently well expressed specification for your program, you can verify that the program and the specification match. Unfortunately, if you have a specification that concrete, you can just compile it and run it.
Again, this isn't quite true. Certainly, for some problems, an accurate specification will be equivalent in complexity to an implementation. On the other hand, there are a great many problems where that isn't the case. Take a specification for finding a square root (to within a specified error tolerance epsilon): given an input number x, the function must produce a value y such that abs(x - y*y) < epsilon. That's a complete specification (and it isn't hard to formalise that into a suitable specification language) but you certainly can't compile and run it and get anything useful - the actual implementation of how to find the square root is going to be more detailed, and quite important.
Similarly we can specificy a sort function: given a list of items (comparable by '<') the function must return a list that is a permutation of the input list (that is, they contain the same elements), and such that for each list index i (except the index of the last element) result[i] < result[i+1]. Again, that's a complete specification for a sort function - it ensures that the function does indeed sort the list. On the other hand it is not compilable (except, maybe, into bogosort), and any particular sort implementation will have to use a specific sorting algorithm (be it quicksort, mergesort, or otherwise) which will be undoubtedly more complex than the simple specification given.
The OLPC stuff I've seen has been running GTK+ applications, so presumably anything using GTK would be acceptable. If that's the case then GTK+ WebCore, which Nokia are working on, might be an option. It is, admittedly, alpha currently - but the rendering engine is ported, and it may be worth looking at.
Indeed. I just wrote a long email detailing my concerns (primarily the issue of treating copyright as a property right, that copyright should be about providing incentive for content creators and any laws should be made with this fact firmly in mind, the protection of fair use rights - to allow individuals full access to do as they wish with works for personal use, and about the steady creep of ever longer copyright terms) to the MPs who provided personal addresses (as opposed to their official parliamentry addesses). I think as long as you sound reasonable, serious, and actually raise deeper issues for them to think about, many MPs will actually pay some attention to this. The reality is that most people, politicians included, simply haven't really thought about copyright issues all that seriously. Giving them some reasons to dwell on, and think a little more deeply, about the full implications can, I strongly suspect, make a difference.
In case you're interested in writing as well, here is the list of email addresses. I strongly suggest that anyone who can write an intelligent thoughtful email to help get MPs seriously thinking about these issues should do so.
You're essentially correct, under this model you end up with a continuous space. Perhaps the easier way to see how it works is with a simpler example like a torus: you can make a torus (donut shape) from a flat piece of paper by first rolling it up into a tube (identifying the top edge with the bottom edge) and then looping the tube around (identifying the two ends of the tube with each other). Thus you can think of the flat piece of paper as a torus by imagining that when you pass off the top edge you appear at the bottom edge, and when you pass off of one side you appear on the other. Now, what happens at the corner (the equivalent of an edge of the dodecahedron)? A quick check and you'll see it all works out: in some sense you might be "broken up" with half of yourself on one side of the paper, and half on the other, but remember those sides are connected together, so so are you.
The same trick works with the dodecahedron, you just have to get the identification of faces right. On passing out through a fae you'll appear on the opposite face, rotated. Take a quick look at a dodecahedron (here's an example that is translucent and rotatable so you can look around) and you'll get the idea. Looking through the dodecahedron from one face you can see the opposite face doesn't align: it's at an angle - hence the rotation. Visualsing where you'll come out as you approach an edge (and where the other face of that edge will result in you appearing) you'll see that the whole thing in indeed continuous; the edges present no problems.
As far as your cheap shot with little elephants, surely you are well aware that little elephants can be disproven. That can't be the case with God as a source (for "random design", for morality, for the universe, etc.).
The disprovability of the minature invisible tartan elephants really rather depends on the exact nature of the elephants, just as the disprovability of God rather depends on the nature of God (a God that is active in making repeated, predictable, measurable interventions in the operation of the universe, for instance, is falsfiable - that doesn't falsify God as something less actively involved, but it does falsify a particular conception of God). If the elephants are completely undetectable via any means and are completely consistent in their behaviour which, by sheer chance, turns out to be utterly indistinguishable from a successful merging of general relativity and quantum mechanics... well you'll have a hard time disproving such elephants. If you choose to believe in God for personal reasons then that is your choice, but the fact that your particular conception of God is unable to be disproved is not terribly convincing as an argument. There are a whole host of things which are both possible (not ruled out by anything) and not disprovable which I fully expect you have no belief in.
Just to be pedantic, neither postscript nor PDF make that formatting guarantee either unless you embed all necessary fonts. Ask yourself how many people know how to do that....:-)
That depends on how the PDF is generated. If you're using PDFTeX then it isn't very hard at all.
To put it simply, just because the theory of evolution does not require an active designer, it does not mean that the process has not been designed to yield specific goals, similarly to how we use randomness as a design tool today.
Sure, but then there is no reason to assume that it does either. The question is why should you assume a goal or a designer? Previously you could assume a designer - it was mandatory in fact - because nobody could conceive of any other explanation. Now we know that it isn't necessary. Sure, it doesn't obviate the possibility, but gravity as curvature of spacetime as a theory doesn't obviate the possibility of miniature invisible tartan elephants pushing everything around. The reality is that there is no reason to suppose any goal, or designer, unless you are predisposed to do so - there is no longer an argument that can be made from design to suggest that God exists. This is my only real point, and you seem determined to ignore it.
I like the position my ISP's HR people take: The posting said "No Word documents accepted."
I can't understand the appeal of submitting your resume in Word format anyway. If I'm writing a resume I'm normally going through and being a perfectionist and getting everything "just so". The last thing I want to do is spend all that time and then have my resume appear completely differently on my employers computer due to font issues or something. If layout matters (and really, for a resume, you should care) then surely you want to use a format that will consistently display the same anywhere like postscript, or PDF.
I think we need to be clear. The theory of evolution discredits the Argument from Design, but does not falsify God. The theory of evolution demonstrates that the appearance of design can be achieved without an intelligent agent to produce the design. The strength and power of the Argument from Design was, quite simply, that prior to the theory of evolution it was inconcievable (in the literal sense that no-one could conceive of a process) to produce appearance of design without a designer. Thus the Argument from Design works as "the appearance of design exists, ergo a designer must exist". The theory of evolution takes away the entailment: the appearance of design no longer requires a designer; a designer is not necessary. You can argue that a designer is still possible, but that was never the argument. Claiming "the appearance of design exists, ergo is is possible that a designer might exist" is rather moot: you can leap straight to the conclusion with no prior argument necessary, and it fails to enforce any conclusion on existence.
There's one thing that puzzles me, why do some extreme creationists believe the universe is only a few thousand years old? Is there an actual, clear reference in the bible or is it traditional humbug?
In theory the date is arrived at via calculations based on the explicit lineages described in the bible. In practice the calculations are rather dodgy and inexact, and when you combine that with the fact that lineages in the bible are hairy (consider the two very different lineages provided for Joseph for example), and the least bit of "not absolutely literal" interpretation the whole thing looks sketchy. Still, if you want to take everything literally then 10,000 years old is the basic lineage calculation, plus a healthy dose of leeway. You do have to be awfully literal to get that out of the bible though.
What evoluton does not claim:... 2. God didn't create the planet or the universe. 3. God doesn't exist....
You are quite correct that the theory of evolution makes no claims as to God's existence, the origins of the universe, or even the actual origins of life. One of the reasons it raises the ire of many religious people, besides contradicting literal readings of their chosen holy book, is that it it goes a long way to refuting one of the remaining strong arguments for the existence of God, the Argument from Design. The Argument from Design essentially says "Given how remarkably well suited and pieced together everything is, how designed it looks, the only reasnable explanation is that it has been designed by some intelligence". For a long time, up until Darwin really, this was a devastatingly strong argument for the existence of God. The great Scottish philosopher Hume shredded the argument but, in failing to find any better explanation for the appearance of design, eventually capitulated - he could see the argument was flawed, but couldn't offer anything better in it's stead. Then along came Darwin with the theory of evolution by natural selection, and we have an entirely credible and reasonable explanation for the appearance of design: the hard work of R&D is done by the blind, mindless, but most certainly not random, process of natural selection; given enough time the appearance of design is the natural result.
Of course evolution says nothing about the universe, just the appearance of design amongst life. However, in refuting the case of design with regard to life, and with Hume's powerful critique of the Argument from Design, one has to be more cautious with regard to playing the "finely tuned universe" Argument from Design card - sure, we don't have an alternative explanation for it yet (though there are a few potential candidates - see Smolin's evolutionary universe model), but we know that explanations for the appearance of design that don't involve a creator can be found from the example of evolution. The fact that alternative explanations exist means the appearance of design is no longer enough to conclude the existence of God.
What this has meant is that there really aren't any solid rational arguments for the existence of God, and a lot of people miss that, hence the desire to fight or try and discredit the theory of evolution. Instead arguments for the existence of God must now take the form of emotional, or personal arguments, which while effective and powerful for those who are receptive to religion, are decidedly unconvincing for those who harbour doubt or are skeptical. Ultimately I tend to see those who feel the need to discredit evolution as people who have doubts about their faith: emotional arguments are not enough for them.
(Disclaimer: I am a (weak) atheist; I am naturally skeptical, and certainly haven't had any religious experiences that might convince me)
Ain't it funny his writing was entitled, "The Origin of the Species." When he did not mean origin. Heh.
Not at all, the title is entirely accurate: it is about The Origin of Species, as in the origin of the wide variety of different kinds of plants animals; a reasonable rephrasing might be "The Origin of Diversity"; it is not titled The Origin of Life.
Slashdot Mirror
I would be interested to know how you justify that claim. We do have decent historical carbon dioxide records via ice cores, and temperature proxies, but the high resolution short term data doesn't support your claim at all, and the longer term data which does, at least, provide significant changes in carbon dioxide and temperature are simply of far too poor a resolution to make any claims about "just as quickly": ice core co2 records that cover previous interglacial periods have resolution of around 500 years; moreover they don't show changes in carbon dioxide as large as what we are currently witnessing; records that go further back to periods with significantly higher carbon dioxide levels have resolution that is orders of magnitude worse.
When mankind lived through previous changes in glacial/interglacial change the rate of change was more than likely slower. More significantly the lower technology levels of the time (and, equally importantly, lower populations) likely actually helped: humans were sparsely spread and nomadic - if climate changed then groups ould easily move to new areas. What we face now is a far denser population where any movement of significant percentages of population with have dramatic effects, and significant amounts of investment in fixed non-moile infrastructure. We can't just pick up and move all our farming infrastructure somewhere else at the drop of a hat - any transition would be costly and significant. Ultimately if you want an accounting of costs then ask an economist. The UK government did, and the result is the Stern Review from Nicholas Stern, a world respected economist. By his accounting (and it was an extremely detailed and in depth study - some 700 pages of report) the effects will be detrimental. Expect more such reports from other economists in the near future.
At this point I would again direct you to the Stern Review which is specifically what you ask for: an accounting of the costs of both inaction, and a comparison of those costs with an equally detailed accounting of the costs of mitigation. The results were that, providing mitigation action was taken sooner rather than later, the costs of mitigation efforts would more than repay themselves within 50 years. Indeed, costs of mitigation could amount to around 1% of global GDP if taken now, while inaction was expected to cost between 5% and 20% of global GDP by 2050. And just to reiterate: this was a detailed report from a respected economist (former chief economist for the World Bank), not a bunch of "sandal clad hippies".
What gave you the impression that the southern hemisphere wasn't warming noticeably? The raw data is freely available, and it is quite apparent that the southern hemisphere is warming noticeably; it just isn't warming as dramatically as the northern hemisphere.
I think the simple answer is critical mass: you need a sufficient number of developers developing not just the platform itself, but applications to run on it. Without a sufficient base of applications you're going to inevitably be perceived as a minority player and fail to attract many users, and hence many extra developers. Past a certain threshold you can be roughly self sustaining - Linux is across it, and so is MacOS X, but I don't think the projects you mention are even close. There is simply too much software built up on the GNU and X11 toolchain (and increasingly on GNOME and KDE) that people would have to leave behind to move to a new open source OS - it just isn't that tempting when the alternatives look so application poor.
To succeed you really need some base to start with (as Apple had when they moved to MacOS X, although even they lean on X11 and apps built on the GNU toolchain to some extent), or you need to support the toolchains of the applications (see OpenSolaris and BSD, which lean on X11, GNOME, KDE, etc.). Depending on what it is you wish to get rid off things can go from easy to very hard. Just ditching the Linux kernel is feasible - see the BSD and OpenSolaris options, among others. If you want to get rid of X11 as well... well that's trickier, but if you have a graphics system that will run GTK+ and or QT you might get by because you'll still have the rich supply of GTK+ apps, and can probably get KDE ported. If you want to ditch everything up to GNOME and KDE... well that means rewriting all your applications from scratch, and really that's a huge and incredibly daunting task. It's not just the big applications like web browsers and email clients, its all the different little niche applications that make the environment so rich. Its that that keeps many people on Windows - the one little application that few other people have any interest in, but happens to be vital to them; because everyone has a slightly different vital niche program it adds up to a lot of applications to reproduce before you can truly draw a large user base.
Linux has crossed the first threshold: it has enough users and application developers working on it that its self sustaining. It has yet to cross the next threshold where it provides a rich enough ecosystem of applications to entice the myriad of home users. It is, however, slowly crawling toward that goal.
Oh, I agree. My point was more that people often are prepared to put their foot down and say "No, we can't do that", and no one blinks when it happens. Sure someone working by the hour might make late changes, but they'll also be making new deadlines and other renogotiation a condition on such changes. The end result is that, if a fixed deadline or fixed costs exist then you have to put your foot down and have a harsh attitude toward late change requests - the is much less common in software development however.
Well you're talking about a blank cheque (I presume you're getting paid for each new feature or change the customer decides he wants) and an indefinite timeframe - the customer doesn't care when the "final" product with all the changes he can dream up is delivered, it an be next week, or 25 years from now. As I said, with no such constraints of course you aren't going to worry about deadlines - there are none - or costs - they can inflate as high as you like.
Most people, however, generally have some idea of core necessary functionality, the costs for that functionality, and a deadline that they'd like to have that core functionality up and fully running by. These demands, of course, provide long term deadlines that make a measure of project success - if you manage to get all their changes and new extra features included but miss a couple of core features by the deadline then yes, I would consider that a failure (unless of course the client renegotiates deadlines for core functionality along with the change requests). In other words: more often than not people hve some fixed idea of when they'd like certain things working by even from the outset; those ideas define long-term deadlines that are measures of product success. If your clients never have such things, more power to you - it sounds like you have very understanding and flexible clients.
You jest, but I think you underestimate civil engineers. They don't spend their whole careers designing very particular inds of bridges. You refer to the Eiffel tower, so perhaps that can furnish an instructive example. Gustave Eiffel, who designed the tower that bears his name, also designed the armature for the statue of liberty, an array of different (and quite notable) bridges, the observatory in Nice, a church in Manila, along with train stations, gas works, and viaducts, among other things. All of those have their own unique demands and required him to understand different disciplines (the needs of a church are quite different to the various things one needs to know to design a good functioning gas works, or a working observatory). And lets' be realistic, very few software engineers are asked to design a robust transactional database one week, a word processor the next week, and then maybe an air traffic control system. Sure they have a lot of variety, but so do other engineers - you just aren't as familiar with the odd and diverse specialisations within their fields. Again, I'm not claiming software engineering is easy, and certainly there is plenty of complain about in the field of management of software engineering, but you really shouldn't dismiss other fields of engineering so easily.
I think my definition of success would be finding as good a compromise as is feasible between customer demands in terms of features, timelines, and costs. I don't see meeting your clients every whim in terms of desired features while running massively over their required timeline and massively over their afforable budget any better than completing on time and on budget but failing to meet fundamental customer requirements. Soemtimes features, timeline and budget all fit together happily. More often they do not. That means late changes either cost a lot more, require a completely reassessed timeline, or don't make it in. If your clients are willing to given you a blank check and indefinite time to produce a shipping product, fine, meet every whim. In the case that they don't then at some point your going to have to draw lines as to when new features or changes can occur.
Has anything ever been completely nailed down with perfectly defined requirements and perfectly predictable deadlines? No, of course not. There are, however, cases where requirements have been adequately defined and projects were completed on time and on budget - it does happen occasionally.
It's not about "not giving the users what they want" and still succeeding, and likewise that doesn't require "completely nailing down requirements up front before beginning to code", it's being clear with regard to changes in requirements. Requirements will undoubtedly change as the project progresses, but I really don't think its that hard to make clear to customers that the later on the change occurs the smaller it will have to be, and that there will be some final deadline for changes near the end of development when new changes won't be accepted (and let's be honest, this happens all the time with code freezes when no new features are accepted prior to release and the focus is on debugging). The building client who wanted to add an extra floor when the building was already half constructed can moan that the builders are not "giving them what they want" but I suspect they'll get little sympathy. At some point reality hs to kick in.
Software does have robust specification languages. Try Z, JML, SPARK, CASL etc. or things like CSP or CCS for specifying concurrent systems. Specification languages exist, and they provide sufficient power to nail down very specific specifications against which implementations can be verified. Sure, some of them are rather technical, but then you have to spend some time learning how to read complex electronic schematics too. For a variety of reasons such specfication languages are rarely used.
Of course that is, to a certain extent, a problem that we make for ourselves by having a forgiving attitude toward such things. If a client that asked for a 3 story building comes back part-way into the construction process and asks for an extra story to be added between the second and third floors they'll simply get told "No". In the case of software projects, however, most people are afraid to say no to clients, or to set limits on defining the requirements. We've trained users to be fickle and change their minds by allowing them to do so. Of course such tolerance and flexibility has also been a boon for the software industry in that the end products have evolved much faster than they would have otherwise. There are pros and cons - but we should accept the consequences of our choices.
This is a silly comparison. Saying that building a bridge (as an example of civil engineering) is just a matter of "connect points A and B when there's a gap" is akin to saying a software project is just a matter of "present users data from a database when they need to know it": you're making it sound easy and simple by glossing over all the myriad of complex and important details that need to be considered. For the software project you might want to consider what the data is, how it needs to be presented, where the users are (over a network, worldwide perhaps?), what sort of security is needed, etc. For the bridge you'll need to worry about exactly where to build the bridge, what sort of traffic it needs to be able to carry, what the weather is like in the area and what stresses the bridge will need to tolerate, etc.
Each case has a lot of details that need to be properly nailed down and dealt with. This is not to say that software engineering is easy; rather it is to point out that other forms of engineering (be it civil, electrical, aerospace, or otherwise) are, in their own way, just as hard - something that I think far too many slashdotters don't really seem to have an appreciation for.
Compilable in a very broad sense, and not of any real practical value (that prolog is kind enough to assume bubblesort as opposed to bogosort is just icing). The reality is that the specification is far shorter than any decent implementation. As to whether much real world code can be specified this way: try actually looking at code written with specifications such as SPARK-Ada code, JML annotated Java, or Eiffel. A surprising amount of real world code can, if you're actually willing to try, be specified efficiently. Sure, some things, like printing output, or GUIs, don't lend themselves to specification - that doesn't mean that there aren't lots of things that do however.
That depends really. As a math geek I find a certain amount of pedantry and formlisation natural. I mean many people are happy to spend the extra time writing annotations to define types signatures for functions (and even types for variables in some languages) which is, really, just a light form of specification. Using Eiffel, or Java with JML, or Spec#, or D, really isn't as bad as you might think - you mostly end up writing things you'll have to get around to writing anyway (when it comes time to properly document APIs etc.), you just get to write it along with the code in a slightly more formal way...
This simply isn't the case - there are lots of programs for which you can easily prove termination. The catch with the Halting problem is that you cannot find a procedure that will work for all programs. In other words you may find yourself in a situation where you cannot prove termination for certain programs; that does not mean, however, that you can't prove termination for others, nor that such proofs are invalid. Trying to prove termination is far from futile - the Halting problem will at worst tell you that you might not be able to do it, but if you can (and often enough you can indeed) then the proof is perfectly valid.
Again, this isn't quite true. Certainly, for some problems, an accurate specification will be equivalent in complexity to an implementation. On the other hand, there are a great many problems where that isn't the case. Take a specification for finding a square root (to within a specified error tolerance epsilon): given an input number x, the function must produce a value y such that abs(x - y*y) < epsilon. That's a complete specification (and it isn't hard to formalise that into a suitable specification language) but you certainly can't compile and run it and get anything useful - the actual implementation of how to find the square root is going to be more detailed, and quite important.
Similarly we can specificy a sort function: given a list of items (comparable by '<') the function must return a list that is a permutation of the input list (that is, they contain the same elements), and such that for each list index i (except the index of the last element) result[i] < result[i+1]. Again, that's a complete specification for a sort function - it ensures that the function does indeed sort the list. On the other hand it is not compilable (except, maybe, into bogosort), and any particular sort implementation will have to use a specific sorting algorithm (be it quicksort, mergesort, or otherwise) which will be undoubtedly more complex than the simple specification given.
The OLPC stuff I've seen has been running GTK+ applications, so presumably anything using GTK would be acceptable. If that's the case then GTK+ WebCore, which Nokia are working on, might be an option. It is, admittedly, alpha currently - but the rendering engine is ported, and it may be worth looking at.
Indeed. I just wrote a long email detailing my concerns (primarily the issue of treating copyright as a property right, that copyright should be about providing incentive for content creators and any laws should be made with this fact firmly in mind, the protection of fair use rights - to allow individuals full access to do as they wish with works for personal use, and about the steady creep of ever longer copyright terms) to the MPs who provided personal addresses (as opposed to their official parliamentry addesses). I think as long as you sound reasonable, serious, and actually raise deeper issues for them to think about, many MPs will actually pay some attention to this. The reality is that most people, politicians included, simply haven't really thought about copyright issues all that seriously. Giving them some reasons to dwell on, and think a little more deeply, about the full implications can, I strongly suspect, make a difference.
In case you're interested in writing as well, here is the list of email addresses. I strongly suggest that anyone who can write an intelligent thoughtful email to help get MPs seriously thinking about these issues should do so.
You're essentially correct, under this model you end up with a continuous space. Perhaps the easier way to see how it works is with a simpler example like a torus: you can make a torus (donut shape) from a flat piece of paper by first rolling it up into a tube (identifying the top edge with the bottom edge) and then looping the tube around (identifying the two ends of the tube with each other). Thus you can think of the flat piece of paper as a torus by imagining that when you pass off the top edge you appear at the bottom edge, and when you pass off of one side you appear on the other. Now, what happens at the corner (the equivalent of an edge of the dodecahedron)? A quick check and you'll see it all works out: in some sense you might be "broken up" with half of yourself on one side of the paper, and half on the other, but remember those sides are connected together, so so are you.
The same trick works with the dodecahedron, you just have to get the identification of faces right. On passing out through a fae you'll appear on the opposite face, rotated. Take a quick look at a dodecahedron (here's an example that is translucent and rotatable so you can look around) and you'll get the idea. Looking through the dodecahedron from one face you can see the opposite face doesn't align: it's at an angle - hence the rotation. Visualsing where you'll come out as you approach an edge (and where the other face of that edge will result in you appearing) you'll see that the whole thing in indeed continuous; the edges present no problems.
The disprovability of the minature invisible tartan elephants really rather depends on the exact nature of the elephants, just as the disprovability of God rather depends on the nature of God (a God that is active in making repeated, predictable, measurable interventions in the operation of the universe, for instance, is falsfiable - that doesn't falsify God as something less actively involved, but it does falsify a particular conception of God). If the elephants are completely undetectable via any means and are completely consistent in their behaviour which, by sheer chance, turns out to be utterly indistinguishable from a successful merging of general relativity and quantum mechanics... well you'll have a hard time disproving such elephants. If you choose to believe in God for personal reasons then that is your choice, but the fact that your particular conception of God is unable to be disproved is not terribly convincing as an argument. There are a whole host of things which are both possible (not ruled out by anything) and not disprovable which I fully expect you have no belief in.
That depends on how the PDF is generated. If you're using PDFTeX then it isn't very hard at all.
Sure, but then there is no reason to assume that it does either. The question is why should you assume a goal or a designer? Previously you could assume a designer - it was mandatory in fact - because nobody could conceive of any other explanation. Now we know that it isn't necessary. Sure, it doesn't obviate the possibility, but gravity as curvature of spacetime as a theory doesn't obviate the possibility of miniature invisible tartan elephants pushing everything around. The reality is that there is no reason to suppose any goal, or designer, unless you are predisposed to do so - there is no longer an argument that can be made from design to suggest that God exists. This is my only real point, and you seem determined to ignore it.
I can't understand the appeal of submitting your resume in Word format anyway. If I'm writing a resume I'm normally going through and being a perfectionist and getting everything "just so". The last thing I want to do is spend all that time and then have my resume appear completely differently on my employers computer due to font issues or something. If layout matters (and really, for a resume, you should care) then surely you want to use a format that will consistently display the same anywhere like postscript, or PDF.
I think we need to be clear. The theory of evolution discredits the Argument from Design, but does not falsify God. The theory of evolution demonstrates that the appearance of design can be achieved without an intelligent agent to produce the design. The strength and power of the Argument from Design was, quite simply, that prior to the theory of evolution it was inconcievable (in the literal sense that no-one could conceive of a process) to produce appearance of design without a designer. Thus the Argument from Design works as "the appearance of design exists, ergo a designer must exist". The theory of evolution takes away the entailment: the appearance of design no longer requires a designer; a designer is not necessary. You can argue that a designer is still possible, but that was never the argument. Claiming "the appearance of design exists, ergo is is possible that a designer might exist" is rather moot: you can leap straight to the conclusion with no prior argument necessary, and it fails to enforce any conclusion on existence.
In theory the date is arrived at via calculations based on the explicit lineages described in the bible. In practice the calculations are rather dodgy and inexact, and when you combine that with the fact that lineages in the bible are hairy (consider the two very different lineages provided for Joseph for example), and the least bit of "not absolutely literal" interpretation the whole thing looks sketchy. Still, if you want to take everything literally then 10,000 years old is the basic lineage calculation, plus a healthy dose of leeway. You do have to be awfully literal to get that out of the bible though.
You are quite correct that the theory of evolution makes no claims as to God's existence, the origins of the universe, or even the actual origins of life. One of the reasons it raises the ire of many religious people, besides contradicting literal readings of their chosen holy book, is that it it goes a long way to refuting one of the remaining strong arguments for the existence of God, the Argument from Design. The Argument from Design essentially says "Given how remarkably well suited and pieced together everything is, how designed it looks, the only reasnable explanation is that it has been designed by some intelligence". For a long time, up until Darwin really, this was a devastatingly strong argument for the existence of God. The great Scottish philosopher Hume shredded the argument but, in failing to find any better explanation for the appearance of design, eventually capitulated - he could see the argument was flawed, but couldn't offer anything better in it's stead. Then along came Darwin with the theory of evolution by natural selection, and we have an entirely credible and reasonable explanation for the appearance of design: the hard work of R&D is done by the blind, mindless, but most certainly not random, process of natural selection; given enough time the appearance of design is the natural result.
Of course evolution says nothing about the universe, just the appearance of design amongst life. However, in refuting the case of design with regard to life, and with Hume's powerful critique of the Argument from Design, one has to be more cautious with regard to playing the "finely tuned universe" Argument from Design card - sure, we don't have an alternative explanation for it yet (though there are a few potential candidates - see Smolin's evolutionary universe model), but we know that explanations for the appearance of design that don't involve a creator can be found from the example of evolution. The fact that alternative explanations exist means the appearance of design is no longer enough to conclude the existence of God.
What this has meant is that there really aren't any solid rational arguments for the existence of God, and a lot of people miss that, hence the desire to fight or try and discredit the theory of evolution. Instead arguments for the existence of God must now take the form of emotional, or personal arguments, which while effective and powerful for those who are receptive to religion, are decidedly unconvincing for those who harbour doubt or are skeptical. Ultimately I tend to see those who feel the need to discredit evolution as people who have doubts about their faith: emotional arguments are not enough for them.
(Disclaimer: I am a (weak) atheist; I am naturally skeptical, and certainly haven't had any religious experiences that might convince me)
Not at all, the title is entirely accurate: it is about The Origin of Species , as in the origin of the wide variety of different kinds of plants animals; a reasonable rephrasing might be "The Origin of Diversity"; it is not titled The Origin of Life.