That's true. However, at some of those times this planet has been just about totally uninhabitable by humans.
The real threat is not that the planet will be uninhabitable for humans. That's possible, but unlikely, and we're fairly adaptable. The risk is that the short term changes might be exceptionally inconvenient for humans - and by inconvenient I mean on a scale that makes trying to hew to Kyoto type restrictions* positively trivial. In the long term I expect humans will probably adapt to the changes as they occur. Such adaptation requires significant time and energy of course, and in the shorter term during transition (and who knows exactly how long that will take) things might well get exceptionally unpleasant.
Jedidiah
* (Please note I'm not advocating Kyoto as the answer, merely pointing out that the claim that Kyoto would "damage the economy" may be nothing compared to economic damage wrought by climate change requiring a similar scale of change)
I also notice that the rise in temperature precedes the rise in CO2 for the most part of that graph.
It does, and the interesting thing is that that is actually to be expected. Without some other reason for CO2 to rise (like, for example, creatures burning fossil fuels) something else is required to raise CO2 levels and produce the natural cycles. As it happens warming can often cause an increase in CO2 - warmer oceans hold less CO2. Once a natural warming fluctuation (from, say, solar variation) has become sufficient to introduce enough atmospheric CO2 for it to be a driver the temperature continues to rise as a result. You'll note that the lag of CO2 to temperature is quite small in comparison to the size of the total warm period that results. More detail about this phenomenon can be found here.
What the lag really tells us is that in the natural cycle CO2 is often not the initial trigger for a warm period - that's not surprising as there are many factors affecting climate and generally the carbon cycle keeps CO2 relatively stable. Once CO2 has been pushed out of balance it can certainly act as a forcing and shift the global climate for significant time spans. Instead of a natural climate event causing the most recent significant change in atmospheric CO2 humans have caused it. Unsurprisingly there is, this time, no lag of CO2 behind temperature, instead temperature is lagging behind CO2. What the global climate will do in response and where the new equilibrium will be remains a somewhat open question.
At least 10 to 30 percent of global warming measured during the past two decades may be due to increased solar output rather than factors such as increased heat-absorbing carbon dioxide gas released by various human activities, two Duke University physicists report.
I think you'll find the last IPCC TAR concluded much the same with regard to the effects of increased solar output. Of course they also concluded that the majority of observed warming was most likely due to anthropogenic CO2. Take a look at this chart showing how well CO2 correlates with the historical temperature record and realise that on that scale current CO2 levels are almost 5.5: that is quite literally off the chart. Given that we have good reason to believe in causation (absorption spectra of atmospheric CO2) it should be of concern. Yes the climate has fluctuated quite a bit in the past. Yes it is a complex chaotic system. That doesn't mean messing with it more is a good idea.
Nope, we can't talk in this arguement about how the planet's climate has shifted in the past, but must blame the US, George W. Bush and/or Capitalism for Global Warming.
I'm not sure attacking a strawman helps either. I don't think anyone with an actual clue is blaming George Bush and Capitalism for causing global warming, and certainly people with a clue will readily accept that historically the climate has been variable - that doesn't mean the the current trend in variation is going to in any way beneficial (or even necessarily neutral). Sure there are all those people without a clue who follow the issue as a politicised debate. There are equally shrill and stupid voices on both sides of this argument though. Just ignore them - the more attention we pay them the more pointlessly polarised this debate becomes.
I know that I would, because I have. I have taken a 1/3 pay cut to move jobs once, simply to move to a better and more interesting position. Money only stops you being unhappy, it doesn't make you happy; for that you need do something fulfilling and get recognition for the work that you do. Believe me when I say a better job with better management can easily be worth 1/3rd of your salary. What you really have to ask yourself is "How much is happiness worth to me?"
I agree that that sounds like a good policy. Some of these sorts of ideas are available though - just not so much in mainstream UNIX/Linux use:
handle security
Okay, SELinux and the like don't have quite the same power as what is described (you can still recreate any dialog that the OS might pop up) but it does provide powerful fine grained mediation of all access to resources. A lot of the things you describe as possible with J2ME "handle security" are possible via SELinux: it's all a matter of applications actually taking advantage of the ability to separate and isolate operations into modules of least privilege, the OS can hadle the rest nicely.
on demand granting of privs
Can certainly be done within the SELinux framework, and it is this sort of thing that can be useful to help avoid user based attacks. If the file you received in an email causes a dialog to pop up telling you that it "...has attempted to access file:addressbook.xml and interface:network which is currently does not have access to. Do you want to grant access and restart the program?" it may give the user pause. Sure, some people will grant access and go ahead, but there's not much you can do about them - there are plenty of people who will get the hint who might otherwise have spread the infection.
How do you handle the issue of too many such dialogs? Allow applications to install their requested security privileges, but do so with a dialog "This application will be setting its own access rights. You should not do this unless this is a trusted application. Would you like to run this application in a sandbox first?" Again, it's not a cure all - people will simply abuse the system and ignore warnings. On the other hand it provides an easy enough mechanism for trusted software to be installed, and gives slightly less clueless users the option to try something sandboxed first. While people will always be stupid, it can at least help while providing limited extra annoyance.
traceable effects
This one SELinux does have some facility for. It determines privileges by the absolute file location of the binary being run, so there is no masquerading based on program names. Again, however, the strict ties to the GUI to prevent any mischief simply isn't available.
In summary, I think it all sounds like good ideas, the real dilemma is getting any of it to be actually used in practice - it is hard enough getting sufficient application support for SELinux to make it a practicable choice for a desktop workstation. Time will tell. Perhaps newer projects that lack the legacy issues will be the way forward.
What I continually fail to understand is why everyone I know logs in as an Administrator under Windows
The same reason that Linux users don't have reasonably strict SELinux policies in place on their machines - a lot of applications are still stuck in the older model and don't play nice with Windows if you aren't the Adminstrator, or Linux if you try and confine their access to reasonable least privilege. What I find interesting is that both Linux and Windows have this issue but people keep ignoring the Linux side - more effort needs to be put into making SELinux and similar security systems workable with good policies even on general workstations. Linux users need to start expecting more of their applications with regard to security.
There are no silver bullets no, but there are tools that can help. Splint is a good example of something you can employ to make static checking for buffer overflows, and various dynamic memory errors like misuse of null pointers, dead storage, memory leaks, and dangerous aliasing in C and C++. It doesn't make your code bullet proof, but it can catch a lot of errors that you probably wouldn't otherwise spot. There's a nice paper about what it can do (warning PDF).
Or, if you're actually interested in documenting intentions, catching errors prior to runtime you could have String FUNCTION trimstring(String a, Number b) requires a not NULL and b < a.length ensures result.length == b //code goes here... RETURN result
But then those extra two lines which go a long way toward
Documenting exactly what the function is doing
Allowing static checking to catch a much wider range of errors
Providing assertion checking during testing to find exactly when the function is being misused
Generally improving maintainability of the code
are apparently the sort of thing static type fans see as far too much work (while apparently declaring types everywhere, which in practice has a lower "extra typing to benefit" ratio is fine).
If static typing makes sense (and for a lot of projects they do) then contracts make sense. See my sig for a powerful contract and static checking system available for Java that an save you enourmous amounts of work.
You have to realize that, for the vast majority of programmers, that the structure is necessary. Those programmers working in dynamically-typed languages fail; they produce spaghetti. Sure, you *can* maintain structure in a dynamically typed language such as Smalltalk or Ruby. But programming is a constant struggle to keep the code from descending into chaos.
What gets me though, is that people will make these sorts of comments all the time, and yet when you suggest that it's quite easy to take the same idea justa littlefurther it all of a sudden becomes completely unpalatable and "too much work". Never mind that that's the same argument the dynamic type people use against static types. Never mind that for the extra work of contracts or specifying a little more than just type signatures you can get static checking gains and improvements in maintainability on par with what you get from using static types over dynamic types.
If you really believe that specifying static types really does help reduce bugs and improve maintainability (and it certainly can) then check outthe options for doing a little better again.
That isn't the fear. The fear is a pig/chimp/dog/etc with enough human DNA to become sentient. Imagine the social chaos that is going to erupt when a pig/human at a research lab scrawls "NO KILL I"* on the floor of it's stall. Wouldn't it be a lot better to think that problem out ahead of time and either agree to limits to ensure it NEVER EVER happens or how we plan to treat them once created?
I guess that means we should put a halt to all AI related research as well. A sentient computer managing to print "NO KILL I" to a text console isn going to e just as complicated an ethical dilemma.
Jedidiah.
Re:Lisp not accessible?
on
Beyond Java
·
· Score: 1
I have to concur. After several years of programming C++, switching to Lisp was an awesome experience.
I would think that after several years of C++ pretty much anything is going to look damn good.
I'm firmly in the static typing camp. Not only does it make things more reliable (due to compilers catching errors)
There's a lot more in the way of errors that can be caught statically with very little extra effort - you just have to use a different tool (one specifically designed for the task) to check for errors statically instead of the compiler, and provide a few appropriate hints about your intentions (in a language that's very expressive for stating your intentions) as you write your code. For Java the tool is ESC/Java2, a very powerful static checker. It will catch all the errors a compiler will, plus a vast array of potential errors that mere compilation will never spot.
If that sounds good, then it's worth pointing out that the extra annotations you need to add to explain your intentions can also be automatically converted into runtime assertions during the etsting phase, can be used to automatically generate JUnit unit testing frameworks, and can be automatically included into your Javadoc documentation. For the small cost of adding a few extra annotations - things you would be documenting elsewhere anyway - you get far better static checking, a powerful testing framework and harness for free, and it all goes into your documentation automatically.
Check my sig, or head directly to the JML website to get an idea of what can be done.
Good job completely misinterpreting what I said into a strawman. I didn't say "love it or leave", I said "accept that you have made the choice to stay and attempt to change the system, or choose not to stay". You're perfectly welcome to not love it and stay and try and change it. I'm just suggesting that pretending you are a poor put upon victim with no choice in the matter is remarkably disingenuous.
Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").
If you interested in cutting out more bugs statically and not having to worry about corner cases in testing then I suggest you check out Extended ML and HasCASL which provide expressive language additions for more clearly defining intent and tools that can catch far more busg statically than even Haskell or ML's type systems can.
For the amount of time that i've lost to define a method twice to deal with 2 different types of objects, i've saved tons of time dealing with bugs that result from dynamic typing.
And just think of the extra time you can save by adding a few annotations to your code and allowing a static checking tool like ESC/Java2 or Splint catch all the extra errors for you. Better yet you can get tools that will extract that extra documentation of the method out and include it in the automatically generated documentation - making it much easier to keept your documentation exact and up to date.
To me static checking (that is consistency checks that are done at compile time) are like an Engineer designing a plane, he does it with tools that declare the wings and the parts of the plane sound, even before the tests that have to be done to confirm the project.
And I think something that static typing advocates who use this sort of argument need to realise is that static types are not the be all and end all of declarations you can make to ensure consistency with intended function. In theory the Curry-Howard isomorphism means that indeed types are propositions. In practice most type systems provide a very poor syntax for clearly stating your propositions. The best way to get around that in most languages is to provide extra syntax that allows expressive descriptions of your propositions, or, if you like, your assumptions. Yes, the type signature of a function declares certain properties that ensure a certain amount of consistency that can be checked statically. There is a lot more in the way of assumptions you can decalre that will ensure far more important consistency properties that can still be checked entirely statically.
Check out JML and ESC/Java2 for Java to see how much extra static checking you can get above and beyond simple type checking. The same sorts of things for C are provided by Splint. If you're someone who prefers ML then take the time to check out EML which adds the ability to define and check axioms in Standard ML.
And I am fine with this on a community basis. I see no reason why my money should be forced out of my household to pay for people who are not in my community. I pay for education in other towns, other states, hell even in other countries. Why?
No one is really forcing you to pay. You live in a large community called the USA where people agreed to collectively pay for things like education according to some tax system. If you don't want to pay for education in other towns then all you have to do is move out of the community in which you are currently in. Somalia is presently without government, and has a completely free market capitalist system - I hear they have pretty good wireless service because of that (don't ask about the roads, water supply, electricity or schools though) so if you really don't want to take part in the community of the USA you can move to a community that seems closer to your ideals.
The other option is to accept that you are part of a large community, accept that you are not forced to take part in it and pay taxes if you don't want to, and engage in that community to try and, for example, reduce government within that community. Don't play the victim here though, no-one is forcing you to take part - that's your option.
Jedidiah.
Re:Dynamic typing
on
Beyond Java
·
· Score: 3, Insightful
Whenever there is a debate about static and dynamic typing people always come out to fight with their blinkers on. They seem to be bound by the mindset of the sort of problems and projects they work on. In practice both have their uses and that's the real reason the debate. I use both, and the choice largely depends on what it is that I am coding. Analogies inevitably fail, but let's try one for this case:
If I'm building a treehouse for my kids* I'm probably not going to bother with the same sort of formal measurement that I would use to build a house for myself - line it up and cut it to fit will do most of the time. That flexibility is beneficial because I'm building around a tree, and being able reshape and redesign things easily makes a whole lot more sense in that environment (the other option being spending several weeks surveying the tree, and a lot of long tedious calculations to deal with its twisting organic structure).
If I'm building a house to live in I'm probably not going to just slap it together: I want to have some sort of design and measure everything against that as I go so I can be sure everything will fit together exactly as I want it to when I'm done. This more rigorous checking saves vast amounts of time over a flexible approach because I know that as long as all my measurements match up, the house will stay up - with a more dynamic approach I'll have to be testing everything every step of the way.
If I'm building a bridge or a bank vault I'm probably going to have another level again of formal requirements and calculations to ensure not just that things fit together, but that I can be certain that it will be safe in all weather conditions, or properly secure from potential thieves. Bothering to have detailed specifications from which extensive calculations and proofs of deep properties can be made is going to save me effort in the long run - it's just another level of formality again, above that used to design and build the house.
Now to my mind these three cases represent dynamic typing, static typing, and full formal specification (for those who think static typing in Haskell is as high as you can go, check out HasCASL). Each has their own place, and it's a matter of what it is that you're doing that determines which is the most suitable approach. If you mostly work on treehouses then someone telling you that you need to be properly measuring everything is going to seem like a pedant who just wants to annoy you and slow down your treehouse building. If you mostly build houses then someone telling you to hold up the 2x4 to where it needs to go and cut it to shape is going to seem reckless and foolhardy. As long as you're looking at everything only through the type of things you build the other point of view will always look silly.
Jedidiah * (I am not trying to suggest that dynamic typing is for inconsequential or throwaway projects, I just wanted an example that is fairly dynamic and works best with an evolving approach)
Re:D programming
on
Beyond Java
·
· Score: 2, Insightful
D is nice, and I certainly appreciate it's addition of design by Contract (even if it is a little kludgy), but I will be surprised if it actually takes off as the next "in" language. It doesn't have the right sort of hype engine behind it. I think you'll see Java and C# duking it out, and growing focus on dynamic languages, particularly when Parrot gets finished. The other developing area for "in" languages is probably functional languages - I think eventually there will be a functional language that, by dint of being different, manages to garner suitable hype and attention.
You know our society is in a sad state of affairs when someone demanding a warrant is newsworthy.
Isn't hyped up fear of "terrorism" wonderful? I think the important point here is that, if there really are reasons to be concerned then getting a warrant is not an onerous task! For some reason (maybe it's the joys of TV) people seem to feel that saving people fom getting a warrant really is going to make a difference in how effective they can be - that it really does spare them vast amounts of time and work. In practice that's only going to be the case for boderline cases where considerable explanation is required as to exactly why the particular search or seizure should be justified. This same attitude has infected the NSA wiretapping issue with the President declaring "If you're talkin' to al Qaeda we want to now about it" as if, were it not for secret warrantless wiretaps, we'd never know about it. If you're talking to al Qaeda I'm guessing that's probably enough right there to get a warrant from the FISC.
Honestly, if you're concerned about the process of getting warrants taking up too much time and effort then try and get the process and required paperwork streamlined, don't just forgo the need for warrants altogether!
The referenced chart and that one do not show the rapid heating which you show.
What rapid heating? The chart I linked to shows a rise from a colder period, then levlling off. Of course it doesn't show the more recent rise in temeperature due to the compression of the scale.
According to the records you show on your chart, a rapidly heating period is normal. Blaming this on CO2 is not correlated.
Please note the scale of the chart. We're talking about changes over tens of thousands of years. If we get a chart of temperature over the last few thousand years in detail we see that there has been a signifcant uptick in temperature. Has it hit the heights previously yet? No. Is it out of character with with the observed natural cycle, which was levelling off? Yes. Does this recent uptick correlate closely with the sudden uptick in CO2 levels? Yes. Are current CO2 levels literally off the chart compared to the last 650,000 years? Yes. Has CO2 level previously correlated very closely with global temperature? Yes. Do we have reason (like, say, absorption spectra) to believe in a causal link between CO2 an global temperature? Yes. What exactly is it that you want?
Probably the deforestation is the reason CO2 levels are going up. The normal florishing of flora in a warmer period did not occur.
Yes, that's probably it. I mean, why actually look at evidence and try and work out what the likely contributions to increased CO2 levels are when idle armchair speculation based on no data whatsoever gives you the answers you want to hear. Deforestation certainly has had an effect on CO2 levels. It is undeniable, however, that we have, since the industrial revolution, produced vast amounts of CO2. Interestingly the CO2 produced by burning fossil fuels has a different Carbon12 to Carbon13 ratios (due the the different rates at which plants take up atmospheric carbon, and hence resulting in different ratios for organic matter in general). By tracking the ratios through time via ice cores and tree rings we can see how level these ratios are for atmospheric CO2 historically, and if the ratios have changed. As it turns out these levels do not fluctuate much except for very recently (the last 150 years) when there has been fairly significant change toward ratios closer to that of CO2 produced by burning fossil fuel. That is to say, the recent spike in CO2 level correlates extremely well with the recent change in atmospheric CO2 composition which in turn strongly points toward burning of fossil fuels having a significant impact on levels of atmospheric CO2. But then who wants to worry about data when you can just sit back and take guesses?
According to your chart one would interpolate to the left a trend similar to the others and, thus, a cooling period.
That's what one would expect to be seeing based solely on extrapolating from the apparent natural cycles, the interesting point is that we are not seeing that! Quite the contrary, present temperatures are rising rather than starting to cool. This is partly why there is concern.
And has anyone calculated carbon emissions for dollar GDP for U.S. and China, which is curiously exempt from Kyoto? I'll bet anyone $20 that China emits a whole lot more on per-dollar basis.
Yes, someone has, and yes China finishes well below the US in terms of the ratio. On the other hand, the US figures pretty poorly compared to most European countries and Japan.
I think our problem is we are not used to interpolating backwards. I think hotter temperatures are at the bottom of the referred chart. When you do that, it get hotter.
Unfortunately no. The temperatures on the chart are estimates based on delta D: that is changes in deuterium levels. Higher delta D (which is what is plotted in the chart) occurs with higher temperature. If you think I'm just unclear on what the chart means it may help you to know that I created the chart myself using raw ice core data available from NOAA ftp sites. To reiterate higher temperatures appear on the chart towards the top.
Assuming CO2 concentrations are greater toward the top then the relation is inverted from what people are claiming.
Unfortunately it is not. Wishful thinking about what the chart means is no substitute for actually knowing what it displays. Feel free to check the data sources section in the link and download the original source data yourself.
CO2 maybe an effect of the temperature change.
There is a feedback effect of temperature and CO2. As temperature rises, for example, oceans become less capable of holding CO2, and hence atmospheric CO2 levels rise. Of course there is also a very clear effect of more atmospheric CO2 trapping more energy and raising temperatures. You can sit and do some armchair speculation as to what drives what, or you can actually sit down and do the math, check the data, and run experiments. People who have done the latter find that CO2 tends to be the more powerful driving factor. People who have done the former generally find whatever it is they want to believe.
Two reseachers from Canada, Stephen McIntyre and Ross McKitrick
One of whom is an economist, and the other works in the mining industry. Not exactly "...errors according to climatologists. There's been plenty ofpicking apart of McIntyre and McKitrick so I won't get into that, you can read the links if you're interested. Instead I'll point you to this chart of historical temperature showing 10 different, largely indepedent, historical reconstructions all using different proxy data sets, from glaciers, to ice cores, to tree rings, and various combinations. Sure there isn't perfect agreement, but I think the trend is very clear. The point is that it is not a case of everything resting on Mann's original report. Since that time a great deal more work has been done, by a wide variety of different people, and hile results have varied they have all come to essentially the same basic conclusion.
Slashdot Mirror
That's true. However, at some of those times this planet has been just about totally uninhabitable by humans.
The real threat is not that the planet will be uninhabitable for humans. That's possible, but unlikely, and we're fairly adaptable. The risk is that the short term changes might be exceptionally inconvenient for humans - and by inconvenient I mean on a scale that makes trying to hew to Kyoto type restrictions* positively trivial. In the long term I expect humans will probably adapt to the changes as they occur. Such adaptation requires significant time and energy of course, and in the shorter term during transition (and who knows exactly how long that will take) things might well get exceptionally unpleasant.
Jedidiah
* (Please note I'm not advocating Kyoto as the answer, merely pointing out that the claim that Kyoto would "damage the economy" may be nothing compared to economic damage wrought by climate change requiring a similar scale of change)
Asked and answered already.
Jedidiah.
I also notice that the rise in temperature precedes the rise in CO2 for the most part of that graph.
It does, and the interesting thing is that that is actually to be expected. Without some other reason for CO2 to rise (like, for example, creatures burning fossil fuels) something else is required to raise CO2 levels and produce the natural cycles. As it happens warming can often cause an increase in CO2 - warmer oceans hold less CO2. Once a natural warming fluctuation (from, say, solar variation) has become sufficient to introduce enough atmospheric CO2 for it to be a driver the temperature continues to rise as a result. You'll note that the lag of CO2 to temperature is quite small in comparison to the size of the total warm period that results. More detail about this phenomenon can be found here.
What the lag really tells us is that in the natural cycle CO2 is often not the initial trigger for a warm period - that's not surprising as there are many factors affecting climate and generally the carbon cycle keeps CO2 relatively stable. Once CO2 has been pushed out of balance it can certainly act as a forcing and shift the global climate for significant time spans. Instead of a natural climate event causing the most recent significant change in atmospheric CO2 humans have caused it. Unsurprisingly there is, this time, no lag of CO2 behind temperature, instead temperature is lagging behind CO2. What the global climate will do in response and where the new equilibrium will be remains a somewhat open question.
Jedidiah.
At least 10 to 30 percent of global warming measured during the past two decades may be due to increased solar output rather than factors such as increased heat-absorbing carbon dioxide gas released by various human activities, two Duke University physicists report.
I think you'll find the last IPCC TAR concluded much the same with regard to the effects of increased solar output. Of course they also concluded that the majority of observed warming was most likely due to anthropogenic CO2. Take a look at this chart showing how well CO2 correlates with the historical temperature record and realise that on that scale current CO2 levels are almost 5.5: that is quite literally off the chart. Given that we have good reason to believe in causation (absorption spectra of atmospheric CO2) it should be of concern. Yes the climate has fluctuated quite a bit in the past. Yes it is a complex chaotic system. That doesn't mean messing with it more is a good idea.
Nope, we can't talk in this arguement about how the planet's climate has shifted in the past, but must blame the US, George W. Bush and/or Capitalism for Global Warming.
I'm not sure attacking a strawman helps either. I don't think anyone with an actual clue is blaming George Bush and Capitalism for causing global warming, and certainly people with a clue will readily accept that historically the climate has been variable - that doesn't mean the the current trend in variation is going to in any way beneficial (or even necessarily neutral). Sure there are all those people without a clue who follow the issue as a politicised debate. There are equally shrill and stupid voices on both sides of this argument though. Just ignore them - the more attention we pay them the more pointlessly polarised this debate becomes.
Jedidiah.
I know that I would, because I have. I have taken a 1/3 pay cut to move jobs once, simply to move to a better and more interesting position. Money only stops you being unhappy, it doesn't make you happy; for that you need do something fulfilling and get recognition for the work that you do. Believe me when I say a better job with better management can easily be worth 1/3rd of your salary. What you really have to ask yourself is "How much is happiness worth to me?"
Jedidiah.
I agree that that sounds like a good policy. Some of these sorts of ideas are available though - just not so much in mainstream UNIX/Linux use:
handle security
Okay, SELinux and the like don't have quite the same power as what is described (you can still recreate any dialog that the OS might pop up) but it does provide powerful fine grained mediation of all access to resources. A lot of the things you describe as possible with J2ME "handle security" are possible via SELinux: it's all a matter of applications actually taking advantage of the ability to separate and isolate operations into modules of least privilege, the OS can hadle the rest nicely.
on demand granting of privs
Can certainly be done within the SELinux framework, and it is this sort of thing that can be useful to help avoid user based attacks. If the file you received in an email causes a dialog to pop up telling you that it "...has attempted to access file:addressbook.xml and interface:network which is currently does not have access to. Do you want to grant access and restart the program?" it may give the user pause. Sure, some people will grant access and go ahead, but there's not much you can do about them - there are plenty of people who will get the hint who might otherwise have spread the infection.
How do you handle the issue of too many such dialogs? Allow applications to install their requested security privileges, but do so with a dialog "This application will be setting its own access rights. You should not do this unless this is a trusted application. Would you like to run this application in a sandbox first?" Again, it's not a cure all - people will simply abuse the system and ignore warnings. On the other hand it provides an easy enough mechanism for trusted software to be installed, and gives slightly less clueless users the option to try something sandboxed first. While people will always be stupid, it can at least help while providing limited extra annoyance.
traceable effects
This one SELinux does have some facility for. It determines privileges by the absolute file location of the binary being run, so there is no masquerading based on program names. Again, however, the strict ties to the GUI to prevent any mischief simply isn't available.
In summary, I think it all sounds like good ideas, the real dilemma is getting any of it to be actually used in practice - it is hard enough getting sufficient application support for SELinux to make it a practicable choice for a desktop workstation. Time will tell. Perhaps newer projects that lack the legacy issues will be the way forward.
Jedidiah.
What I continually fail to understand is why everyone I know logs in as an Administrator under Windows
The same reason that Linux users don't have reasonably strict SELinux policies in place on their machines - a lot of applications are still stuck in the older model and don't play nice with Windows if you aren't the Adminstrator, or Linux if you try and confine their access to reasonable least privilege. What I find interesting is that both Linux and Windows have this issue but people keep ignoring the Linux side - more effort needs to be put into making SELinux and similar security systems workable with good policies even on general workstations. Linux users need to start expecting more of their applications with regard to security.
Jedidiah.
There are no silver bullets no, but there are tools that can help. Splint is a good example of something you can employ to make static checking for buffer overflows, and various dynamic memory errors like misuse of null pointers, dead storage, memory leaks, and dangerous aliasing in C and C++. It doesn't make your code bullet proof, but it can catch a lot of errors that you probably wouldn't otherwise spot. There's a nice paper about what it can do (warning PDF).
Jedidiah.
String FUNCTION trimstring(String a, Number b)
requires a not NULL and b < a.length
ensures result.length == b
RETURN result
But then those extra two lines which go a long way toward
are apparently the sort of thing static type fans see as far too much work (while apparently declaring types everywhere, which in practice has a lower "extra typing to benefit" ratio is fine).
If static typing makes sense (and for a lot of projects they do) then contracts make sense. See my sig for a powerful contract and static checking system available for Java that an save you enourmous amounts of work.
Jedidiah.
You have to realize that, for the vast majority of programmers, that the structure is necessary. Those programmers working in dynamically-typed languages fail; they produce spaghetti. Sure, you *can* maintain structure in a dynamically typed language such as Smalltalk or Ruby. But programming is a constant struggle to keep the code from descending into chaos.
What gets me though, is that people will make these sorts of comments all the time, and yet when you suggest that it's quite easy to take the same idea just a little further it all of a sudden becomes completely unpalatable and "too much work". Never mind that that's the same argument the dynamic type people use against static types. Never mind that for the extra work of contracts or specifying a little more than just type signatures you can get static checking gains and improvements in maintainability on par with what you get from using static types over dynamic types.
If you really believe that specifying static types really does help reduce bugs and improve maintainability (and it certainly can) then check out the options for doing a little better again.
Jedidiah.
That isn't the fear. The fear is a pig/chimp/dog/etc with enough human DNA to become sentient. Imagine the social chaos that is going to erupt when a pig/human at a research lab scrawls "NO KILL I"* on the floor of it's stall. Wouldn't it be a lot better to think that problem out ahead of time and either agree to limits to ensure it NEVER EVER happens or how we plan to treat them once created?
I guess that means we should put a halt to all AI related research as well. A sentient computer managing to print "NO KILL I" to a text console isn going to e just as complicated an ethical dilemma.
Jedidiah.
I have to concur. After several years of programming C++, switching to Lisp was an awesome experience.
I would think that after several years of C++ pretty much anything is going to look damn good.
Jedidiah.
I'm firmly in the static typing camp. Not only does it make things more reliable (due to compilers catching errors)
There's a lot more in the way of errors that can be caught statically with very little extra effort - you just have to use a different tool (one specifically designed for the task) to check for errors statically instead of the compiler, and provide a few appropriate hints about your intentions (in a language that's very expressive for stating your intentions) as you write your code. For Java the tool is ESC/Java2, a very powerful static checker. It will catch all the errors a compiler will, plus a vast array of potential errors that mere compilation will never spot.
If that sounds good, then it's worth pointing out that the extra annotations you need to add to explain your intentions can also be automatically converted into runtime assertions during the etsting phase, can be used to automatically generate JUnit unit testing frameworks, and can be automatically included into your Javadoc documentation. For the small cost of adding a few extra annotations - things you would be documenting elsewhere anyway - you get far better static checking, a powerful testing framework and harness for free, and it all goes into your documentation automatically.
Check my sig, or head directly to the JML website to get an idea of what can be done.
Jedidiah.
The love it or move argument doesn't work...
Good job completely misinterpreting what I said into a strawman. I didn't say "love it or leave", I said "accept that you have made the choice to stay and attempt to change the system, or choose not to stay". You're perfectly welcome to not love it and stay and try and change it. I'm just suggesting that pretending you are a poor put upon victim with no choice in the matter is remarkably disingenuous.
Jedidiah.
Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").
If you interested in cutting out more bugs statically and not having to worry about corner cases in testing then I suggest you check out Extended ML and HasCASL which provide expressive language additions for more clearly defining intent and tools that can catch far more busg statically than even Haskell or ML's type systems can.
Jedidiah.
For the amount of time that i've lost to define a method twice to deal with 2 different types of objects, i've saved tons of time dealing with bugs that result from dynamic typing.
And just think of the extra time you can save by adding a few annotations to your code and allowing a static checking tool like ESC/Java2 or Splint catch all the extra errors for you. Better yet you can get tools that will extract that extra documentation of the method out and include it in the automatically generated documentation - making it much easier to keept your documentation exact and up to date.
Jedidiah.
To me static checking (that is consistency checks that are done at compile time) are like an Engineer designing a plane, he does it with tools that declare the wings and the parts of the plane sound, even before the tests that have to be done to confirm the project.
And I think something that static typing advocates who use this sort of argument need to realise is that static types are not the be all and end all of declarations you can make to ensure consistency with intended function. In theory the Curry-Howard isomorphism means that indeed types are propositions. In practice most type systems provide a very poor syntax for clearly stating your propositions. The best way to get around that in most languages is to provide extra syntax that allows expressive descriptions of your propositions, or, if you like, your assumptions. Yes, the type signature of a function declares certain properties that ensure a certain amount of consistency that can be checked statically. There is a lot more in the way of assumptions you can decalre that will ensure far more important consistency properties that can still be checked entirely statically.
Check out JML and ESC/Java2 for Java to see how much extra static checking you can get above and beyond simple type checking. The same sorts of things for C are provided by Splint. If you're someone who prefers ML then take the time to check out EML which adds the ability to define and check axioms in Standard ML.
Jedidiah.
And I am fine with this on a community basis. I see no reason why my money should be forced out of my household to pay for people who are not in my community. I pay for education in other towns, other states, hell even in other countries. Why?
No one is really forcing you to pay. You live in a large community called the USA where people agreed to collectively pay for things like education according to some tax system. If you don't want to pay for education in other towns then all you have to do is move out of the community in which you are currently in. Somalia is presently without government, and has a completely free market capitalist system - I hear they have pretty good wireless service because of that (don't ask about the roads, water supply, electricity or schools though) so if you really don't want to take part in the community of the USA you can move to a community that seems closer to your ideals.
The other option is to accept that you are part of a large community, accept that you are not forced to take part in it and pay taxes if you don't want to, and engage in that community to try and, for example, reduce government within that community. Don't play the victim here though, no-one is forcing you to take part - that's your option.
Jedidiah.
Whenever there is a debate about static and dynamic typing people always come out to fight with their blinkers on. They seem to be bound by the mindset of the sort of problems and projects they work on. In practice both have their uses and that's the real reason the debate. I use both, and the choice largely depends on what it is that I am coding. Analogies inevitably fail, but let's try one for this case:
If I'm building a treehouse for my kids* I'm probably not going to bother with the same sort of formal measurement that I would use to build a house for myself - line it up and cut it to fit will do most of the time. That flexibility is beneficial because I'm building around a tree, and being able reshape and redesign things easily makes a whole lot more sense in that environment (the other option being spending several weeks surveying the tree, and a lot of long tedious calculations to deal with its twisting organic structure).
If I'm building a house to live in I'm probably not going to just slap it together: I want to have some sort of design and measure everything against that as I go so I can be sure everything will fit together exactly as I want it to when I'm done. This more rigorous checking saves vast amounts of time over a flexible approach because I know that as long as all my measurements match up, the house will stay up - with a more dynamic approach I'll have to be testing everything every step of the way.
If I'm building a bridge or a bank vault I'm probably going to have another level again of formal requirements and calculations to ensure not just that things fit together, but that I can be certain that it will be safe in all weather conditions, or properly secure from potential thieves. Bothering to have detailed specifications from which extensive calculations and proofs of deep properties can be made is going to save me effort in the long run - it's just another level of formality again, above that used to design and build the house.
Now to my mind these three cases represent dynamic typing, static typing, and full formal specification (for those who think static typing in Haskell is as high as you can go, check out HasCASL). Each has their own place, and it's a matter of what it is that you're doing that determines which is the most suitable approach. If you mostly work on treehouses then someone telling you that you need to be properly measuring everything is going to seem like a pedant who just wants to annoy you and slow down your treehouse building. If you mostly build houses then someone telling you to hold up the 2x4 to where it needs to go and cut it to shape is going to seem reckless and foolhardy. As long as you're looking at everything only through the type of things you build the other point of view will always look silly.
Jedidiah
* (I am not trying to suggest that dynamic typing is for inconsequential or throwaway projects, I just wanted an example that is fairly dynamic and works best with an evolving approach)
D is nice, and I certainly appreciate it's addition of design by Contract (even if it is a little kludgy), but I will be surprised if it actually takes off as the next "in" language. It doesn't have the right sort of hype engine behind it. I think you'll see Java and C# duking it out, and growing focus on dynamic languages, particularly when Parrot gets finished. The other developing area for "in" languages is probably functional languages - I think eventually there will be a functional language that, by dint of being different, manages to garner suitable hype and attention.
Jedidiah.
You know our society is in a sad state of affairs when someone demanding a warrant is newsworthy.
Isn't hyped up fear of "terrorism" wonderful? I think the important point here is that, if there really are reasons to be concerned then getting a warrant is not an onerous task! For some reason (maybe it's the joys of TV) people seem to feel that saving people fom getting a warrant really is going to make a difference in how effective they can be - that it really does spare them vast amounts of time and work. In practice that's only going to be the case for boderline cases where considerable explanation is required as to exactly why the particular search or seizure should be justified. This same attitude has infected the NSA wiretapping issue with the President declaring "If you're talkin' to al Qaeda we want to now about it" as if, were it not for secret warrantless wiretaps, we'd never know about it. If you're talking to al Qaeda I'm guessing that's probably enough right there to get a warrant from the FISC.
Honestly, if you're concerned about the process of getting warrants taking up too much time and effort then try and get the process and required paperwork streamlined, don't just forgo the need for warrants altogether!
Jedidiah.
The referenced chart and that one do not show the rapid heating which you show.
What rapid heating? The chart I linked to shows a rise from a colder period, then levlling off. Of course it doesn't show the more recent rise in temeperature due to the compression of the scale.
According to the records you show on your chart, a rapidly heating period is normal. Blaming this on CO2 is not correlated.
Please note the scale of the chart. We're talking about changes over tens of thousands of years. If we get a chart of temperature over the last few thousand years in detail we see that there has been a signifcant uptick in temperature. Has it hit the heights previously yet? No. Is it out of character with with the observed natural cycle, which was levelling off? Yes. Does this recent uptick correlate closely with the sudden uptick in CO2 levels? Yes. Are current CO2 levels literally off the chart compared to the last 650,000 years? Yes. Has CO2 level previously correlated very closely with global temperature? Yes. Do we have reason (like, say, absorption spectra) to believe in a causal link between CO2 an global temperature? Yes. What exactly is it that you want?
Probably the deforestation is the reason CO2 levels are going up. The normal florishing of flora in a warmer period did not occur.
Yes, that's probably it. I mean, why actually look at evidence and try and work out what the likely contributions to increased CO2 levels are when idle armchair speculation based on no data whatsoever gives you the answers you want to hear. Deforestation certainly has had an effect on CO2 levels. It is undeniable, however, that we have, since the industrial revolution, produced vast amounts of CO2. Interestingly the CO2 produced by burning fossil fuels has a different Carbon12 to Carbon13 ratios (due the the different rates at which plants take up atmospheric carbon, and hence resulting in different ratios for organic matter in general). By tracking the ratios through time via ice cores and tree rings we can see how level these ratios are for atmospheric CO2 historically, and if the ratios have changed. As it turns out these levels do not fluctuate much except for very recently (the last 150 years) when there has been fairly significant change toward ratios closer to that of CO2 produced by burning fossil fuel. That is to say, the recent spike in CO2 level correlates extremely well with the recent change in atmospheric CO2 composition which in turn strongly points toward burning of fossil fuels having a significant impact on levels of atmospheric CO2. But then who wants to worry about data when you can just sit back and take guesses?
According to your chart one would interpolate to the left a trend similar to the others and, thus, a cooling period.
That's what one would expect to be seeing based solely on extrapolating from the apparent natural cycles, the interesting point is that we are not seeing that! Quite the contrary, present temperatures are rising rather than starting to cool. This is partly why there is concern.
Jedidiah.
And has anyone calculated carbon emissions for dollar GDP for U.S. and China, which is curiously exempt from Kyoto? I'll bet anyone $20 that China emits a whole lot more on per-dollar basis.
Yes, someone has, and yes China finishes well below the US in terms of the ratio. On the other hand, the US figures pretty poorly compared to most European countries and Japan.
Jedidiah.
I think our problem is we are not used to interpolating backwards. I think hotter temperatures are at the bottom of the referred chart. When you do that, it get hotter.
Unfortunately no. The temperatures on the chart are estimates based on delta D: that is changes in deuterium levels. Higher delta D (which is what is plotted in the chart) occurs with higher temperature. If you think I'm just unclear on what the chart means it may help you to know that I created the chart myself using raw ice core data available from NOAA ftp sites. To reiterate higher temperatures appear on the chart towards the top.
Assuming CO2 concentrations are greater toward the top then the relation is inverted from what people are claiming.
Unfortunately it is not. Wishful thinking about what the chart means is no substitute for actually knowing what it displays. Feel free to check the data sources section in the link and download the original source data yourself.
CO2 maybe an effect of the temperature change.
There is a feedback effect of temperature and CO2. As temperature rises, for example, oceans become less capable of holding CO2, and hence atmospheric CO2 levels rise. Of course there is also a very clear effect of more atmospheric CO2 trapping more energy and raising temperatures. You can sit and do some armchair speculation as to what drives what, or you can actually sit down and do the math, check the data, and run experiments. People who have done the latter find that CO2 tends to be the more powerful driving factor. People who have done the former generally find whatever it is they want to believe.
Jedidiah.
Two reseachers from Canada, Stephen McIntyre and Ross McKitrick
One of whom is an economist, and the other works in the mining industry. Not exactly "...errors according to climatologists. There's been plenty of picking apart of McIntyre and McKitrick so I won't get into that, you can read the links if you're interested. Instead I'll point you to this chart of historical temperature showing 10 different, largely indepedent, historical reconstructions all using different proxy data sets, from glaciers, to ice cores, to tree rings, and various combinations. Sure there isn't perfect agreement, but I think the trend is very clear. The point is that it is not a case of everything resting on Mann's original report. Since that time a great deal more work has been done, by a wide variety of different people, and hile results have varied they have all come to essentially the same basic conclusion.
Jedidiah.