We have a space faring capability which is sufficient to allow us to move LARGE masses of material to Venus and construct massive structures there. That would presuppose we had already a very large scale space based manufacturing capability (or else an equivalent which would be the ability to manufacture under the surface conditions prevalent on Venus).
What would motivate a society with that kind of technological and industrial capability to want to live on the surface of ANY planet? I don't see it. You would just live in space! Space, where practically limitless energy is free for the taking, construction is simple and easy, and whatever goods you need or produce can be shipped anywhere without needing to go up a massive gravity well.
The same argument applies for ANY planetary surface. Perhaps the Moon, being close to Earth and possessing a gravity well 1/81st as deep as that of Earth is a bit different case, but colonizing either Mars or Venus fails, under any conditions I can imagine, to be an economically sensible scenario.
In fact I will propose Tod's Laws of space exploitation.
1) The viability of colonization or exploitation of any area of space is inversely proportional to the energy required to enter or leave that region of space, and directly proportional to the amount of raw material and energy available in that location.
2) No autonomous space based facility can remain under the control of Earth.
Think about it, if you were 'the Republic of The Moon' why would you need anything from Earth? What would Earth have that was of value they could exchange with you? Not raw materials, they will ALWAYS be cheaper to obtain outside the Earth's gravity well (in that sense the main belt asteroids are cheaper sources of raw materials even from LEO than the Earth itself is). Energy? Obviously Earth has nothing to provide there. People? Maybe to some extent at first, but once a population existed in space that grew on its own there would be little incentive to import 'landlubbers'. Culture? Yeah, but in the longer term that isn't a substantive basis for trade. Luxury Goods? This is the only category I can think of, it probably would be hard to produce a good Merlot on the Moon...
The same arguments would apply to any other planet. Planetary surfaces are actually the SLUM real estate of the Solar System. They're 'dirty', they come with stupidly expensive gravity wells, and the more valuable raw materials all sank to the core billions of years ago.
No, space itself, and the minor bodies found in it are the natural home of technological spacefaring civilization.
This sort of ant-scale concern is just too trivial to waste time on. Instead of chasing around trying to make everyone put their braces where you want them, spend the time on good code reviews, good design, and other things which actually ARE important.
Coding is MAYBE 10% of the total work involved in creating a piece of software, and by far the least critical 10% at that. Even in the category of coding practices such trivia as what you name local variables and how you indent blocks is at the very low end of the scale of importance.
I started out coding in FORTH, and I really do believe that experience taught me a lot. Never make a function more than 5 lines long. If you have 40 lines of junk inside a block, it should be a function/method of its own. NAME things descriptively and design your APIs to expose WHAT people want to do and not HOW it is accomplished. Learn and understand patterns and refactoring.
Forget about where the stupid brackets go. No one coder should be the only one working on a piece of code anyway, the whole team should be looking at it within 2 days of its birth. So if your process is right, then code style will just naturally converge to a consensus.
You don't have to be an XP zealot, but a lot of XP practices are very well suited to teams of 2-10 programmers.
Pair programming. I know everyone says they hate it, but a lot of people hate taking their medicine too... Fact is if you are working together on the same piece of code most of the time, you don't NEED a lot of other avenues of communication when you have a 2 person team.
My group develops fairly large and complex financial apps. Yet we maintain a small team and often have people from other organizations working on specific modules, so communication can sometimes be an issue. We've found that there are plenty of OSS apps that can be helpful to use, but the PROCESS has to drive application use, you can't build a good process around a tool.
To outline what we do. First of all I'm not a real big fan of coding standards. At least not the garden variety "you must format your source like XYZ" sort. In any case no one coder should "own" a particular piece of code, so if everyone works on each thing some of the time a "consensus style" will develop pretty quickly. In any case bad practices will get outed during code reviews pretty quickly and my feeling is that a couple rounds of "that's ugly and we don't want to do things that way" followed by a bit of refactoring which ends up with much nicer code will educate people a lot better than just a flat "you may not do XYZ", which doesn't really get into people's heads WHY they should do or not do certain things.
We do all our team communications via TWiki. All system documentation, javadocs, source jars, etc are there, as well as whatever amount of ancillary documentation any particular module or project needs. Its simple enough to use and there are plenty of plugins available for particular needs. If something can't be done directly in TWiki, then at least you can attach a file to a topic and that way people can get it and do what they need with it.
I'm not sure why you say SVN doesn't document team processes very well. The SVN book certainly gives you all the info you need to understand how to do specific things. Again we document revision control procedures on the wiki and there are some standard perl scripts to consistently do common operations (branch, tag, merge, etc) which makes it simple for coders to do these things. The SVN support in Eclipse is good too and generally the team features let you deal with whatever comes up.
Continuous integration is of course a great thing. Frankly I found most of the existing tools to be inflexible, overly complex, and hard to maintain. We have master build scripts written using our own build framework in perl. A simple cron job will do a master build and post the results to a section of the wiki, along with test results, dependency, test coverage analysis, etc.
95% of the work in my experience was just perfecting the process itself. Specific tools are secondary. As things became desirable or necessary to do, we just found a tool that would do that thing and made it fit in with our process. If it wasn't flexible enough, we went on to another one that was.
In the end we're pretty much just using Eclipse, SVN, TWiki, Cobertura, perl, and bugzilla.
Health risks are going to be identical no matter how you categorize a material.
Consider asbestos. Asbestos particles are certainly very similar in many respects to some of the engineered nanomaterials. If I manufacture artificial asbestos, it will have the same toxology as 'natural' asbestos.
The meaningful question in my mind is 'Is there a significant source of natural exposure to material X?' If so then we would be reasonably justified in making the assumption that similar exposure to the same material from man made sources will have similar effects, and we also have grounds for making a default assumption that the human body can tolerate the material to a certain extent.
However it seems to me that there are or will be a large class of nanomaterials which are substantially different from anything found in nature. It would seem prudent to study the toxicity of such materials carefully before they see wide use.
Personally I don't see a close correspondence between GMOs and nanomaterials. GMOs incorporate genetic elements which are already found naturally in a variety of organisms. Furthermore even if we designed some 'artificial genes' the proteins expressed via those genes are not going to be radically different from those found in existing organisms. Obviously such a protein would need to be tested for toxicity, but it would be no more likely to be hazardous than one isolated from a natural source.
To my mind the majority of the fears the public has about GMOs are largely unfounded. There are various issues, but it is far more tenable to believe GMOs are largely benign than it would be to believe that nanomaterials are. Thus a stance of 'GMOs are safe unless proven otherwise' is not unreasonable, but a similar stance with regard to nanomaterials probably is not.
So my opinion would be that engineered nanomaterials should be studied for biological effects before widespread commercial deployment. That might not be necessary for certain limited engineering uses, but we SHOULD be reasonably cautious. If you want to sell me a consumer good which contains engineered nanomaterials, they should require review and approval in some fashion similar to the rules in place for potentially toxic chemicals. And those rules themselves probably require beefing up.
The other issue that has never been addressed with any types of materials is synergistic effects. Any given material might be safe in and of itself, but in the real world we get exposed to a 'soup' of compounds and materials every day. Seems to me the major thing we should all be worried about is just how thick does that broth get before we're done in by the entirely unknown and unforeseen interactions between them?
You DON'T (in theory) have to worry too much about scalability. At least not the infrastructure side of it. So if you're caught being slashdotted, you're OK.
Not saying these services are all the way there yet, but it appears to me that there is a whole class of sites that more and more are likely to have high traffic variability. It can be pretty hard to predict too. Cloud style utility computing is definitely one answer to that.
So it would seem to me that 'learning how to size their solution' may be exactly what web devs WON'T need to worry about for much longer. This seems to me almost inevitable, they are orthogonal concerns. In general such things eventually get segregated into different parts of the IT skill stack, and the less one factor influences another, the more effective the overall technology.
OK, so I pay my $95 or whatever that is 'windows tax' and then $20 for Ubuntu and $150 to have it installed (maybe that includes the $20, not sure).
So I can have windows for $95, or Ubuntu for $265. Now, if I can loose the windows tax, that helps, but the windows tax is 'invisible' to the consumer, so even then they'll be contrasting $150-$170 vs 'free' in their minds.
That windows tax is what needs to go. As long as that stands Linux is gimped.
For myself I don't even WANT pre-installed anything. I'm just saying that for the average user it really is just about a must.
Actually there's nothing even slightly wrong with me, lol. I know it feels good to rant, but I'm not a 'fanboi' of anything in particular. I just made an observation. There's nothing WRONG with BB selling Linux Distros. It isn't going to hurt anything, though I will remain skeptical that it will somehow initiate, or even portends, a mass adoption of Linux on consumer desktops/laptops.
I figure if people want Linux and it is a 'no more cost than windows' option, then they'll pick it up. The most likely scenario IMHO is that it will seem mighty convenient to people at the point where it is already on their other home appliance and mobile devices. Especially if we start to see a lot of desktops with a zero boot time ROMed OS.
Your average Joe already paid for Windows. So now for $19.99 he can have the pleasure of doing an OS install? Which he has no clue about and for his purposes Ubuntu isn't even as good as Windows because inevitably the kids want to play some game or he has some app that won't (easily) run under Linux.
I doubt Best Buy thinks it is a real big deal. Not even sure why they're bothering. I'd guess a PHB someplace thought "We should sell this Linux thing, it might be getting popular." lol.
Now, if BB will INSTALL it for me, and support it, and make sure the hardware they sell me works with it, and let me buy a machine sans windoze tax, then it starts to be interesting.
Oh, I'm not knocking it down especially. Perhaps I'm jaded, I've seen fashions in data representation come and go, etc. Technologically it just isn't a big deal, thats all.
I think there are a few things the XML haters still haven't figured out though. Serialized XML is obviously no prize format efficiency-wise. I don't think anyone ever believed it would be. But the more different formats we have, the more balkanized data becomes. All these various formats don't do a thing about that problem.
XML did 2 things for us, it advanced the cause of separation of logical and physical formats, and it gave us a format which can at least represent the vast majority of data, which at least lets us have SOME common way of interchanging all this lovely 'my wonderful new glossy data format' data with all the systems that use someone else's wonderful glossy data format.
I wouldn't have expected Google to be using FAST since it didn't exist 5 years ago. I just think all the big 'hoorays' are a yawn is all.
What can I say? Your logic overwhelmed me! Heaven forbid I should question the suitability of javascript for complex applications, or the appropriateness of HTTP for stateful bi-directional data interchange.
And it really boils down to the fact that the web (html/javascript on top of http) is just a rotten way for a client and server to interact in any sort of tightly coupled way. The 'wire formats' available for data marshalling and unmarshalling are poor, at best. JSON is an abomination born out of a desperate attempt to shoehorn some sort of usable data format in on top of a client and communications infrastructure which is totally inappropriate at a fundamental design level for the task. Just go through that AJAX wishlist that everyone was talking about the other day. Virtually all of the issues simply stem from inappropriate use of technology.
Web clients are designed basically to deal with largely static content and a very simplistic page based UI model. Screen update and network operations are coupled in awkward ways, etc. No amount of hacking will fix that. True superior INTERNET applications are going to require a total rethink of client side technology and deployment of protocols that elegantly deal with complex data, state, transactions, and full duplex communication.
Without that, web apps will remain ugly kludges which are hard to program, harder to maintain, and perform poorly at best.
Here's the thing. If you want to manage development projects or programmers you will be 100x more effective if you have significant development experience.
There are plenty of other types of IT jobs that aren't programming jobs, though I suspect most or all have been hit upon here already.
Software engineering and programming should be done by skilled engineers and programmers. A lot of the reason we have such a huge amount of crap software in the world today is that people who have NO clue about the appropriate and effective uses of technology get into positions where they have to make technical decisions.
That is the long term concern. Is it wise to begin editing out portions of our genetic diversity? Many of these genes have complex and little understood effects. Declaring a particular genetic trait 'defective' may well be quite short sighted. In fact it is already well known that many genes have forms which are both beneficial under some conditions and harmful under others, or at least offer a trade off. This is in fact why many of them have persisted in the human genome.
Even beyond that, ALL the genetic diversity of the human race is material upon which evolutionary pressures can act. The more narrow that diversity is, the weaker the overall evolutionary potential of the species.
Do we really think we're wise enough to start deciding what to keep and what to discard? I have my doubts.
Eh. OK, you have to actually download the JRE. Assuming you're not running any of a number of distros that package commercial binaries, like Mandriva. Honestly, I don't find it to be a big deal. Sure it WILL be slightly more convenient now, and that's cool, but I hardly think the license has been holding back java apps much, or at all tttt.
Pretty much the same thing in terms of improvements. 99.999% of improvements are extensions to existing APIs, SPI implementations, or variations on existing APIs. None of that was seriously encumbered. Significant parts of the standard java libs source has been available for a good long time anyway, or at the very least spec compliant alternative implementations.
As for the core JVM, that is the one place there is a real win. However, though you may consider the Sun 'reference implementation' of the JVM to be in some fashion less perfected than it might be, it is actually far and away one of the most sophisticated and performant VM implementations of ANY sort already. Few and far between are those who have much business mucking around in there, and fewer and further between are those who will be able to do much to improve it.
I just don't see the whole release as earth shaking. Yeah, it is nice that it is going open source, but its closed sourcedness was basically zero deterrent to to most of us using it already.
Yeah, Taco is getting a bit rambunctious there, lol.;)
After writing maybe a million LOC in both perl and java, all you can say is they each have certain things going for them. Scripting languages are not going to kill off Java any time soon, if ever. Apples and Oranges.
As for OS Java, big yawn. I mean more OSS is always a good thing, but at least in the sort of business I'm in OS Java is no biggie. What we desire is stability and performance. JRockit aside, that has never even been close to existing in any implementation outside of Sun's. In fact the performance difference is usually an order of magnitude, sometimes more. Given that the JDK/JRE have always been no cost software from the beginning I just don't see this whole thing changing my life one bit.
At most I think it is possible some of the standard class library, collections obviously coming to mind, MIGHT benefit a bit from wider scrutiny. At this point though they've probably achieved close to their realistic performance limits given the need for compatibility etc. If you need something faster, there are always 3rd party libraries anyway that are more optimized for specific use cases.
LOL, lets be real, all the grunt work is going overseas. Nobody is going to be paying programmers in the US inflated wages to do work that someone better qualified and much cheaper can do over there in 10 years.
So, if you REALLY do want to learn what you're going to have to know, then managing contractors is it, because that's all the jobs that will be left.
Oh, both types of futures contracts work similarly from the perspective of someone who is just buying and selling pieces of paper, but their economic meaning and impact is completely different. Apples and Oranges are both fruit, that doesn't make them the same.
There is no secondary market in oil, there is in gold. Gold is a repository of value in its own right and is the most fungible thing you can own. Oil is completely different. The way the gold markets work is completely different from the way the oil markets work. Demand for gold is also almost infinitely elastic. Very few people MUST have gold, and the vast majority of those are going to be able to pass the cost of it directly on to their customers (since the customer can always resell the gold in effect it isn't a "cost").
So, I have to disagree. You cannot make much out of a comparison between the two.
Gold is a completely different thing. You cannot compare them. The function of gold futures in the gold market is completely different than the function of oil futures in the oil market. Gold itself is a completely different kind of thing from oil. So I wouldn't consider that a particularly useful comparison.
It gets a bit complicated actually. If say you wanted actual crude oil, which only a refinery would, you can do what is called "Exchange for Physical" (EFP) and take delivery of the product at the specified location. And even that really just means you end up with the product at the location where you need it and some additional financial arrangements get made to pay for that.
Anyone else would financial settle the contract at maturity. That would be someone like a trucking company that is hedging its fuel prices. Effectively someone else takes delivery of the actual physical product and you get paid a fixed settlement price which is based on some formula that depends on closing prices on the exchange. That normally all happens by default.
All of that depends on someone being willing to do that financial settlement. Obviously for the market to function that is guaranteed, but the available numbers of contracts will depend on direct consumers of crude stepping up. If the prices on the futures market consistently continue to greatly exceed supply and demand indicated prices then there is no reason say a refiner would continue to want to do that.
The futures market in oil is intended to indicate what prices people are willing to pay for products, not what prices they may actually end up commanding, and it is totally decoupled from the supply side. The producers and refiners simply end up racking up huge profits when the futures market goes off into cloud nine like it is now. Which is exactly what is happening. Prices could go back to what they were 2 years ago and the business is still plenty profitable.
My point is that it is increasing demand vs supply that is driving up prices. Speculation is just a way for someone with some money to bet on that and cut in on a bit of the excess profit. So one can SAY that the futures market is 'driving up the price of oil' but it is really just indicating that the price IS being driven up.
Well, I won't argue with you about it. I know quite a bit. The fraction of crude that is traded on the futures markets is a very small fraction of what is bought and sold every day. Although prices may be benchmarked off certain contracts, the commodity markets themselves (in the case of oil) have very little actual pricing power.
Well, the underlying reasons for the price rises must be in place. And STILL the futures market has NO actual pricing power. The last time I looked there were a few 100k contracts of open interest on the NYMEX, (Looking now, 172k open interest on the CLN8). That is 172k contracts at 1,000 bbl each, for July delivery. There are other contracts of course, but compared to the actual volume of imports, the futures market is tiny, so its pricing power is also pretty small.
Now, that being said, I'm not disputing that OPEC is USING the high prices of these contracts as the reason they raise their prices. They 'benchmark' their bulk deliveries based on futures. Still, it is a bit like the way your bank decides to raise your MasterCard rate because 'the prime rate went up'. In fact there is even less connection than that.
Truth is, if supply exceeds demand, then the futures will fall and the price will fall. It isn't and it hasn't. So far. All markets fluctuate between oversupply and overdemand. Just as all other control loops do. Basic engineering theory, you don't even need to know a bit of economics. The difference here is that OPEC can squeeze supply as they see fit. Which they seem to do so that in the long run oil is cheaper than the alternatives. Just plain good business sense.
No doubt oil prices will come down due to extinguished demand at some point. Hard to say how much or for how long, but it is like betting the ponies, usually the odds on favorites win, and usually history repeats itself too.
'Wild speculation' is not a problem at all. Anyone dumb enough to pay too much for a contract is going to loose money. The price of the underlying governs the price of the derivative, not the other way around. At least not in a market like the oil market. Other types of derivatives have different characteristics.
Slashdot Mirror
We have a space faring capability which is sufficient to allow us to move LARGE masses of material to Venus and construct massive structures there. That would presuppose we had already a very large scale space based manufacturing capability (or else an equivalent which would be the ability to manufacture under the surface conditions prevalent on Venus).
What would motivate a society with that kind of technological and industrial capability to want to live on the surface of ANY planet? I don't see it. You would just live in space! Space, where practically limitless energy is free for the taking, construction is simple and easy, and whatever goods you need or produce can be shipped anywhere without needing to go up a massive gravity well.
The same argument applies for ANY planetary surface. Perhaps the Moon, being close to Earth and possessing a gravity well 1/81st as deep as that of Earth is a bit different case, but colonizing either Mars or Venus fails, under any conditions I can imagine, to be an economically sensible scenario.
In fact I will propose Tod's Laws of space exploitation.
1) The viability of colonization or exploitation of any area of space is inversely proportional to the energy required to enter or leave that region of space, and directly proportional to the amount of raw material and energy available in that location.
2) No autonomous space based facility can remain under the control of Earth.
Think about it, if you were 'the Republic of The Moon' why would you need anything from Earth? What would Earth have that was of value they could exchange with you? Not raw materials, they will ALWAYS be cheaper to obtain outside the Earth's gravity well (in that sense the main belt asteroids are cheaper sources of raw materials even from LEO than the Earth itself is). Energy? Obviously Earth has nothing to provide there. People? Maybe to some extent at first, but once a population existed in space that grew on its own there would be little incentive to import 'landlubbers'. Culture? Yeah, but in the longer term that isn't a substantive basis for trade. Luxury Goods? This is the only category I can think of, it probably would be hard to produce a good Merlot on the Moon...
The same arguments would apply to any other planet. Planetary surfaces are actually the SLUM real estate of the Solar System. They're 'dirty', they come with stupidly expensive gravity wells, and the more valuable raw materials all sank to the core billions of years ago.
No, space itself, and the minor bodies found in it are the natural home of technological spacefaring civilization.
This sort of ant-scale concern is just too trivial to waste time on. Instead of chasing around trying to make everyone put their braces where you want them, spend the time on good code reviews, good design, and other things which actually ARE important.
Coding is MAYBE 10% of the total work involved in creating a piece of software, and by far the least critical 10% at that. Even in the category of coding practices such trivia as what you name local variables and how you indent blocks is at the very low end of the scale of importance.
I started out coding in FORTH, and I really do believe that experience taught me a lot. Never make a function more than 5 lines long. If you have 40 lines of junk inside a block, it should be a function/method of its own. NAME things descriptively and design your APIs to expose WHAT people want to do and not HOW it is accomplished. Learn and understand patterns and refactoring.
Forget about where the stupid brackets go. No one coder should be the only one working on a piece of code anyway, the whole team should be looking at it within 2 days of its birth. So if your process is right, then code style will just naturally converge to a consensus.
You don't have to be an XP zealot, but a lot of XP practices are very well suited to teams of 2-10 programmers.
Pair programming. I know everyone says they hate it, but a lot of people hate taking their medicine too... Fact is if you are working together on the same piece of code most of the time, you don't NEED a lot of other avenues of communication when you have a 2 person team.
My group develops fairly large and complex financial apps. Yet we maintain a small team and often have people from other organizations working on specific modules, so communication can sometimes be an issue. We've found that there are plenty of OSS apps that can be helpful to use, but the PROCESS has to drive application use, you can't build a good process around a tool.
To outline what we do. First of all I'm not a real big fan of coding standards. At least not the garden variety "you must format your source like XYZ" sort. In any case no one coder should "own" a particular piece of code, so if everyone works on each thing some of the time a "consensus style" will develop pretty quickly. In any case bad practices will get outed during code reviews pretty quickly and my feeling is that a couple rounds of "that's ugly and we don't want to do things that way" followed by a bit of refactoring which ends up with much nicer code will educate people a lot better than just a flat "you may not do XYZ", which doesn't really get into people's heads WHY they should do or not do certain things.
We do all our team communications via TWiki. All system documentation, javadocs, source jars, etc are there, as well as whatever amount of ancillary documentation any particular module or project needs. Its simple enough to use and there are plenty of plugins available for particular needs. If something can't be done directly in TWiki, then at least you can attach a file to a topic and that way people can get it and do what they need with it.
I'm not sure why you say SVN doesn't document team processes very well. The SVN book certainly gives you all the info you need to understand how to do specific things. Again we document revision control procedures on the wiki and there are some standard perl scripts to consistently do common operations (branch, tag, merge, etc) which makes it simple for coders to do these things. The SVN support in Eclipse is good too and generally the team features let you deal with whatever comes up.
Continuous integration is of course a great thing. Frankly I found most of the existing tools to be inflexible, overly complex, and hard to maintain. We have master build scripts written using our own build framework in perl. A simple cron job will do a master build and post the results to a section of the wiki, along with test results, dependency, test coverage analysis, etc.
95% of the work in my experience was just perfecting the process itself. Specific tools are secondary. As things became desirable or necessary to do, we just found a tool that would do that thing and made it fit in with our process. If it wasn't flexible enough, we went on to another one that was.
In the end we're pretty much just using Eclipse, SVN, TWiki, Cobertura, perl, and bugzilla.
Staring at their pictures online isn't quite the same thing as MEETING them... ;)
Health risks are going to be identical no matter how you categorize a material.
Consider asbestos. Asbestos particles are certainly very similar in many respects to some of the engineered nanomaterials. If I manufacture artificial asbestos, it will have the same toxology as 'natural' asbestos.
The meaningful question in my mind is 'Is there a significant source of natural exposure to material X?' If so then we would be reasonably justified in making the assumption that similar exposure to the same material from man made sources will have similar effects, and we also have grounds for making a default assumption that the human body can tolerate the material to a certain extent.
However it seems to me that there are or will be a large class of nanomaterials which are substantially different from anything found in nature. It would seem prudent to study the toxicity of such materials carefully before they see wide use.
Personally I don't see a close correspondence between GMOs and nanomaterials. GMOs incorporate genetic elements which are already found naturally in a variety of organisms. Furthermore even if we designed some 'artificial genes' the proteins expressed via those genes are not going to be radically different from those found in existing organisms. Obviously such a protein would need to be tested for toxicity, but it would be no more likely to be hazardous than one isolated from a natural source.
To my mind the majority of the fears the public has about GMOs are largely unfounded. There are various issues, but it is far more tenable to believe GMOs are largely benign than it would be to believe that nanomaterials are. Thus a stance of 'GMOs are safe unless proven otherwise' is not unreasonable, but a similar stance with regard to nanomaterials probably is not.
So my opinion would be that engineered nanomaterials should be studied for biological effects before widespread commercial deployment. That might not be necessary for certain limited engineering uses, but we SHOULD be reasonably cautious. If you want to sell me a consumer good which contains engineered nanomaterials, they should require review and approval in some fashion similar to the rules in place for potentially toxic chemicals. And those rules themselves probably require beefing up.
The other issue that has never been addressed with any types of materials is synergistic effects. Any given material might be safe in and of itself, but in the real world we get exposed to a 'soup' of compounds and materials every day. Seems to me the major thing we should all be worried about is just how thick does that broth get before we're done in by the entirely unknown and unforeseen interactions between them?
You DON'T (in theory) have to worry too much about scalability. At least not the infrastructure side of it. So if you're caught being slashdotted, you're OK.
Not saying these services are all the way there yet, but it appears to me that there is a whole class of sites that more and more are likely to have high traffic variability. It can be pretty hard to predict too. Cloud style utility computing is definitely one answer to that.
So it would seem to me that 'learning how to size their solution' may be exactly what web devs WON'T need to worry about for much longer. This seems to me almost inevitable, they are orthogonal concerns. In general such things eventually get segregated into different parts of the IT skill stack, and the less one factor influences another, the more effective the overall technology.
OK, so I pay my $95 or whatever that is 'windows tax' and then $20 for Ubuntu and $150 to have it installed (maybe that includes the $20, not sure).
So I can have windows for $95, or Ubuntu for $265. Now, if I can loose the windows tax, that helps, but the windows tax is 'invisible' to the consumer, so even then they'll be contrasting $150-$170 vs 'free' in their minds.
That windows tax is what needs to go. As long as that stands Linux is gimped.
For myself I don't even WANT pre-installed anything. I'm just saying that for the average user it really is just about a must.
Actually there's nothing even slightly wrong with me, lol. I know it feels good to rant, but I'm not a 'fanboi' of anything in particular. I just made an observation. There's nothing WRONG with BB selling Linux Distros. It isn't going to hurt anything, though I will remain skeptical that it will somehow initiate, or even portends, a mass adoption of Linux on consumer desktops/laptops.
I figure if people want Linux and it is a 'no more cost than windows' option, then they'll pick it up. The most likely scenario IMHO is that it will seem mighty convenient to people at the point where it is already on their other home appliance and mobile devices. Especially if we start to see a lot of desktops with a zero boot time ROMed OS.
Lets see...
Your average Joe already paid for Windows. So now for $19.99 he can have the pleasure of doing an OS install? Which he has no clue about and for his purposes Ubuntu isn't even as good as Windows because inevitably the kids want to play some game or he has some app that won't (easily) run under Linux.
I doubt Best Buy thinks it is a real big deal. Not even sure why they're bothering. I'd guess a PHB someplace thought "We should sell this Linux thing, it might be getting popular." lol.
Now, if BB will INSTALL it for me, and support it, and make sure the hardware they sell me works with it, and let me buy a machine sans windoze tax, then it starts to be interesting.
Oh, I'm not knocking it down especially. Perhaps I'm jaded, I've seen fashions in data representation come and go, etc. Technologically it just isn't a big deal, thats all.
I think there are a few things the XML haters still haven't figured out though. Serialized XML is obviously no prize format efficiency-wise. I don't think anyone ever believed it would be. But the more different formats we have, the more balkanized data becomes. All these various formats don't do a thing about that problem.
XML did 2 things for us, it advanced the cause of separation of logical and physical formats, and it gave us a format which can at least represent the vast majority of data, which at least lets us have SOME common way of interchanging all this lovely 'my wonderful new glossy data format' data with all the systems that use someone else's wonderful glossy data format.
I wouldn't have expected Google to be using FAST since it didn't exist 5 years ago. I just think all the big 'hoorays' are a yawn is all.
lol. Not that FAST is IDENTICAL, but it is essentially just a much more sophisticated implementation of the same basic idea...
What can I say? Your logic overwhelmed me! Heaven forbid I should question the suitability of javascript for complex applications, or the appropriateness of HTTP for stateful bi-directional data interchange.
Whatever shall I do? My career is in ruins. ;)
And it really boils down to the fact that the web (html/javascript on top of http) is just a rotten way for a client and server to interact in any sort of tightly coupled way. The 'wire formats' available for data marshalling and unmarshalling are poor, at best. JSON is an abomination born out of a desperate attempt to shoehorn some sort of usable data format in on top of a client and communications infrastructure which is totally inappropriate at a fundamental design level for the task. Just go through that AJAX wishlist that everyone was talking about the other day. Virtually all of the issues simply stem from inappropriate use of technology.
Web clients are designed basically to deal with largely static content and a very simplistic page based UI model. Screen update and network operations are coupled in awkward ways, etc. No amount of hacking will fix that. True superior INTERNET applications are going to require a total rethink of client side technology and deployment of protocols that elegantly deal with complex data, state, transactions, and full duplex communication.
Without that, web apps will remain ugly kludges which are hard to program, harder to maintain, and perform poorly at best.
lol.
Here's the thing. If you want to manage development projects or programmers you will be 100x more effective if you have significant development experience.
There are plenty of other types of IT jobs that aren't programming jobs, though I suspect most or all have been hit upon here already.
Software engineering and programming should be done by skilled engineers and programmers. A lot of the reason we have such a huge amount of crap software in the world today is that people who have NO clue about the appropriate and effective uses of technology get into positions where they have to make technical decisions.
That is the long term concern. Is it wise to begin editing out portions of our genetic diversity? Many of these genes have complex and little understood effects. Declaring a particular genetic trait 'defective' may well be quite short sighted. In fact it is already well known that many genes have forms which are both beneficial under some conditions and harmful under others, or at least offer a trade off. This is in fact why many of them have persisted in the human genome.
Even beyond that, ALL the genetic diversity of the human race is material upon which evolutionary pressures can act. The more narrow that diversity is, the weaker the overall evolutionary potential of the species.
Do we really think we're wise enough to start deciding what to keep and what to discard? I have my doubts.
Eh. OK, you have to actually download the JRE. Assuming you're not running any of a number of distros that package commercial binaries, like Mandriva. Honestly, I don't find it to be a big deal. Sure it WILL be slightly more convenient now, and that's cool, but I hardly think the license has been holding back java apps much, or at all tttt.
Pretty much the same thing in terms of improvements. 99.999% of improvements are extensions to existing APIs, SPI implementations, or variations on existing APIs. None of that was seriously encumbered. Significant parts of the standard java libs source has been available for a good long time anyway, or at the very least spec compliant alternative implementations.
As for the core JVM, that is the one place there is a real win. However, though you may consider the Sun 'reference implementation' of the JVM to be in some fashion less perfected than it might be, it is actually far and away one of the most sophisticated and performant VM implementations of ANY sort already. Few and far between are those who have much business mucking around in there, and fewer and further between are those who will be able to do much to improve it.
I just don't see the whole release as earth shaking. Yeah, it is nice that it is going open source, but its closed sourcedness was basically zero deterrent to to most of us using it already.
Yeah, Taco is getting a bit rambunctious there, lol. ;)
After writing maybe a million LOC in both perl and java, all you can say is they each have certain things going for them. Scripting languages are not going to kill off Java any time soon, if ever. Apples and Oranges.
As for OS Java, big yawn. I mean more OSS is always a good thing, but at least in the sort of business I'm in OS Java is no biggie. What we desire is stability and performance. JRockit aside, that has never even been close to existing in any implementation outside of Sun's. In fact the performance difference is usually an order of magnitude, sometimes more. Given that the JDK/JRE have always been no cost software from the beginning I just don't see this whole thing changing my life one bit.
At most I think it is possible some of the standard class library, collections obviously coming to mind, MIGHT benefit a bit from wider scrutiny. At this point though they've probably achieved close to their realistic performance limits given the need for compatibility etc. If you need something faster, there are always 3rd party libraries anyway that are more optimized for specific use cases.
LOL, lets be real, all the grunt work is going overseas. Nobody is going to be paying programmers in the US inflated wages to do work that someone better qualified and much cheaper can do over there in 10 years.
So, if you REALLY do want to learn what you're going to have to know, then managing contractors is it, because that's all the jobs that will be left.
Oh, both types of futures contracts work similarly from the perspective of someone who is just buying and selling pieces of paper, but their economic meaning and impact is completely different. Apples and Oranges are both fruit, that doesn't make them the same.
There is no secondary market in oil, there is in gold. Gold is a repository of value in its own right and is the most fungible thing you can own. Oil is completely different. The way the gold markets work is completely different from the way the oil markets work. Demand for gold is also almost infinitely elastic. Very few people MUST have gold, and the vast majority of those are going to be able to pass the cost of it directly on to their customers (since the customer can always resell the gold in effect it isn't a "cost").
So, I have to disagree. You cannot make much out of a comparison between the two.
Gold is a completely different thing. You cannot compare them. The function of gold futures in the gold market is completely different than the function of oil futures in the oil market. Gold itself is a completely different kind of thing from oil. So I wouldn't consider that a particularly useful comparison.
It gets a bit complicated actually. If say you wanted actual crude oil, which only a refinery would, you can do what is called "Exchange for Physical" (EFP) and take delivery of the product at the specified location. And even that really just means you end up with the product at the location where you need it and some additional financial arrangements get made to pay for that.
Anyone else would financial settle the contract at maturity. That would be someone like a trucking company that is hedging its fuel prices. Effectively someone else takes delivery of the actual physical product and you get paid a fixed settlement price which is based on some formula that depends on closing prices on the exchange. That normally all happens by default.
All of that depends on someone being willing to do that financial settlement. Obviously for the market to function that is guaranteed, but the available numbers of contracts will depend on direct consumers of crude stepping up. If the prices on the futures market consistently continue to greatly exceed supply and demand indicated prices then there is no reason say a refiner would continue to want to do that.
The futures market in oil is intended to indicate what prices people are willing to pay for products, not what prices they may actually end up commanding, and it is totally decoupled from the supply side. The producers and refiners simply end up racking up huge profits when the futures market goes off into cloud nine like it is now. Which is exactly what is happening. Prices could go back to what they were 2 years ago and the business is still plenty profitable.
My point is that it is increasing demand vs supply that is driving up prices. Speculation is just a way for someone with some money to bet on that and cut in on a bit of the excess profit. So one can SAY that the futures market is 'driving up the price of oil' but it is really just indicating that the price IS being driven up.
Well, I won't argue with you about it. I know quite a bit. The fraction of crude that is traded on the futures markets is a very small fraction of what is bought and sold every day. Although prices may be benchmarked off certain contracts, the commodity markets themselves (in the case of oil) have very little actual pricing power.
Well, the underlying reasons for the price rises must be in place. And STILL the futures market has NO actual pricing power. The last time I looked there were a few 100k contracts of open interest on the NYMEX, (Looking now, 172k open interest on the CLN8). That is 172k contracts at 1,000 bbl each, for July delivery. There are other contracts of course, but compared to the actual volume of imports, the futures market is tiny, so its pricing power is also pretty small.
Now, that being said, I'm not disputing that OPEC is USING the high prices of these contracts as the reason they raise their prices. They 'benchmark' their bulk deliveries based on futures. Still, it is a bit like the way your bank decides to raise your MasterCard rate because 'the prime rate went up'. In fact there is even less connection than that.
Truth is, if supply exceeds demand, then the futures will fall and the price will fall. It isn't and it hasn't. So far. All markets fluctuate between oversupply and overdemand. Just as all other control loops do. Basic engineering theory, you don't even need to know a bit of economics. The difference here is that OPEC can squeeze supply as they see fit. Which they seem to do so that in the long run oil is cheaper than the alternatives. Just plain good business sense.
No doubt oil prices will come down due to extinguished demand at some point. Hard to say how much or for how long, but it is like betting the ponies, usually the odds on favorites win, and usually history repeats itself too.
'Wild speculation' is not a problem at all. Anyone dumb enough to pay too much for a contract is going to loose money. The price of the underlying governs the price of the derivative, not the other way around. At least not in a market like the oil market. Other types of derivatives have different characteristics.
Ah, yes, well, I'm sure you MUST know 10x more than I do about it... lol.
Heck, I only DO it. What would I know?