If ethanol takes more energy to produce than can be extracted from it, then it is unsustainable and no society can afford to keep producing it long term.
Now if ethanol can be derived from waste or surplus or if the energy can be extracted from ethanol in a more efficient manner, this is no longer a consideration and your consideration, which gives you the biggest bang for the buck becomes the only consideration.
BTW, the 30% number is the amount of energy that can extracted from ethanol through burning it in an internal combustion engine. Converting it to hydrogen and running the hydrogen through a fuel cell may be more efficient.
As long as it takes more energy than can harvested from a gallon of ethanol in order to produce that gallon of ethanol, it is irrelevent as to whether ethanol comes from a renewable resource. If that barrier is broken, then it does begin to matter and I agree with your comment entirely providing it is contingent on ethanol production providing a net gain of usable energy.
Crude oil is pumped out of the ground. This take far less energy than planting and harvesting corn or some other crop. For diesel the expense is even lower because it is a waste product of processing crude oil.
Which is why I mentioned the other point, regarding surplus and waste products. If waste and surplus products can can produce enough ethanol for energy needs, then ethanol suddenly becomes a viable fuel regardless of whether ethanol to hydrogen to electricity pulls more energy out of ethanol than burning it in an engine.
Yes, let's look at this objectively and from an empirical standpoint. What real world examples do you have that I am wrong? What real world examples do you have unit testing will eventually eliminate all bugs prior to putting the product into production?
Also, if the statement that the only way to prove that a software design matches real-world requirements is to implement the design, and completely test its interaction withing the domain is correct, when combined with the statement that the real world is infinitely detailed, and thus so is the problem domain, the conclusion is that it is not possible to prove that a design properly implements real-world requirements. I reject this conclusion.
If I follow your train of thought to its natural conclusions, I should arrive at the idea that when building a bridge, it is not necessary to prove that the finished construction will be able to withstand the load that it bears. Would you agree with that assessment?
As for cost, given the high rate of failure in the current system and the astronomical costs of bugs in current software products, I don't think that cost considerations support your argument.
Further, virtually every software text in existence states that more time spent in design reduces defects and yet very few projects spend sufficient time in the design state. Proper design is currently the path not chosen, so its costs are unknown. One cannot reasonably argue that an unknown cost is higher than a known cost prior to the unknown cost being known.
Lastly, your request for a proof exemplifies my point. You cannot offer such a proof and that is why Apache has to be patched. If Apache had been properly designed and constructed from the beginning, the only updates to Apache would be for new features. The cost of all the bugfixing that has gone into Apache over the years was unnecessary.
Unfortunately, computer science is still in its relative infancy. It is currently more akin to a skilled trade than a science. Also, our system of education (at least in the US) is geared toward producing artisans of computers rather than computer scientists. One hopes that this will continue to change over time.
It takes about 30% more energy to produce a gallon of ethanol that one gets out of burning that same gallon of ethanol. Therefore, each gallon of ethanol pumpled into a car and burnt for energy represents a net energy loss.
But there are two considerations to make here that are not part of the above statement:
Converting surplus and/or waste products into ethanol would not have the same drawback. Only the energy spent in the actual conversion to ethanol (and not the manufacture of) the base products turned into ethanol would need to be considered.
Converting ethanol into hydrogen and then burning the hydrogen may be far more efficient than burning ethanol. If so, it is possible that each gallon of ethanol represents a net gain of energy.
Writing test cases is taking the exact same approach using a slightly different tool. You must test every condition only if you don't know whether or not your program design is functionally correct. This akin to attempting to solve an algebraic equation by writings tests to rule out all of the wrong solutions.
The opposite approach should be taken. A design should first be proven to solve the problem. Then the implementation should be proven to implement the design.
To produce bugless software we need to start with software designs that are provably correct and then produce code that is provably in line with the design. Using more objects that more closely model the "real world" is an invitation to producing larger number of bugs as the ambiguity of the real world infects the design and implementation of the program.
Davidson presents two conclusions, one of which can be refuted by his previous points.
But they have no practical use,
and exist only with the patronage of Microsoft.
The first point is refuted by his earlier statement, one of the few applications that Mono claims it can run is its own C# compiler. Unless one asserts both that (a) a C# compiler is of no practical use and (b) that none of the other programs that mono can run is of any practical use, Davidson's conclusion does not follow. Davidson also admits that, Competition is good for the software industry, good for Microsoft in particular (as Adam Smith pointed out, monopoly is a great enemy to good management), and most importantly, good for consumers. Unless Davidson is now asserting that competition has no practical use, he just refuted his own conclusion.
Further, we only need to find one practical use of mono to demonstrate that the conclusion is categorically wrong. That mono ships with commercial products such as Virtuoso suggests that there is at least one practical use of mono.
On Davidson's second point, I think he misunderstands patronage. Microsoft does not currently fund mono in any way in which I am aware. They do fund some competitors to mono such as rotor and (at least at one time) Corel's attempt to bring dot net to Linux. His only example of Microsoft being a patron consists of a hypothetical chain of events that is exceedingly unlikely. I suspect that perhaps Davidson meant forbearance instead of patronage. If he did, he would do well to explain exactly how Microsoft's patents threaten mono because some people (including people far brighter than me) do not see any clear and present danger.
This marks a departure as previous versions of the Palm OS had long shipped with Mac compatible hotsync software.
It really wasn't all that long ago when synching a Palm device to a Mac required the separate purchase of the Mac connector kit. Part of the reason for this was the hardware. The original Palm cradle was designed for a serial port that Macs didn't have. But part of it was software. Mac software didn't come in the box.
As a third party vendor has already announced that it will step into the void, this means that the Palm world will simply be returning to the way things were.
More interesting to me is the implication of the announcement that Palm apps for 6.x will be built on top of Microsoft tools: The new PIM apps have be re-architected to more closely resemble Microsoft Outlook fields and the internal database use a new SQL like schema to store records. While this could very well reference in house tools, it seems to me that they are thinking of using an MS dev kit to simplify development. I wouldn't be surprised to hear an announcement in the near future which proclaims that Palm OS 6 will support dot net.
That must be the software that leads to service contracts.
Aside from some of the games, I can't think of any IBM software that doesn't lead to hardware sales and/or service contracts. A lot of large companies go IBM because they can be a one stop shop so a lot of software that IBM does to drive hardware sales may not look directly related to hardware at first.
That said, they've opened up quite a few of their boxed software products.
If I might paraphrase, with the exception of the two most popular consoles in all of gaming history, no console in history has had full backwards compatibility.
I think that perhaps you're drawing the wrong conclusion from the data.
At least in Ohio, although I'm pretty sure most states are similar in the way the law works.
Section 2911.13. Breaking and entering.
No person by force, stealth, or deception, shall trespass in an unoccupied structure, with purpose to commit therein any theft offense, as defined in section 2913.01 of the Revised Code, or any felony.
No person shall trespass on the land or premises of another, with purpose to commit a felony.
Whoever violates this section is guilty of breaking and entering, a felony of the fifth degree.
If there is no intent to commit a felony, there is no offense.
going through a closed door without permission, whether the door is locked or not, is called "breaking and entering"
I'm fairly certain that breaking and entering only counts if somebody breaks in. Entering an unlocked door is not breaking in. It could count as tresspessing if there is a posted sign or if the person in question has been told to not enter the premises. To qualify as breaking and entering, a lock must be picked or otherwise subverted. This is because someone locking a lock is taken as an explicit communication that those without the key do not have permission to enter.
Dunno about where you live, but most places in the US, it is legal to go onto someone else's land unless there are posted "no tresspassing" signs or you've been specifically told by that person you are not allowed.
Your question if the files were left in folders on a shared server and not protected then who is at fault? is clearly answered in the article:
A technician hired by the new judiciary chairman, Patrick Leahy, Democrat of Vermont, apparently made a mistake that allowed anyone to access newly created accounts on a Judiciary Committee server shared by both parties -- even though the accounts were supposed to restrict access only to those with the right password.
The Democrats thought that their documents were on a network resource that was protected. This situation is more akin to the staff of one party being told a room is secure that isn't and when the staff of the other part discovers it isn't, instead of both alerting the first party and staying out of the room, they (the second party) keeps swinging by to dig up the new dirt.
I won't argue that this is unambigous in the eyes of the law. I will argue that this is entirely unabiguous with regards to morals.
I can think of a good number of situations where Perl (or Python) should emphatically not be installed. I can also think of situations where a specific version of Perl (or Python) and no other ought to be installed. Because situations like these are not all that rare, it is best to not include Perl or Python in the default install and to allow system admins to choose which (if any) version of these tools get installed.
Hence, your beef seems to me to be with sys admins that aren't providing the tools that the boxes they installed need for the users to get their work done. It doesn't really have anything to do with whether or not a given toolset is part of the default install.
Although, I will also say that it royally pisses me off when the sys admin installs one of the newfangled versions of vi with all the bells and whistles turned on so that I have to edit some.rc file or the other to turn them off so that vi acts like vi. When I want syntax highlighting and autoindent, I'll use xemacs. Few things are more irritating than discovering pasting a sizeable chunk of code only to discover that vi is actually vim and autoindent is turned and all the indentation in twenty lines or so of code you just pasted gets funged because vim's autoindent sucks when the pasting lines already indented.
And I also think it safe to say that the default install of most Linux distributions enable virtually everything except the kitchen sink (and some do that!).
But, I'm also pretty certain that this is a minority position. Most Unix boxes are purchased/leased for a specific purpose and the default install contains very little leaving the administrator to decide which programs to install. The fewer programs installed, the fewer possibilities there are for something to go wrong.
I hold that this is a good thing because the administrator knows better if Perl (or Python) is needed and if so if Perl (or Python) needs to be a specific version or flavor or compiled with specific options and so on and so forth. It is best to keep the defaults to a minimum and assume that the adminstrator knows what to add on and what not to.
Name three major modern unices that does not include a decent scripting language by default. Perl and Python typically do show up in most self-respecting distros or are trivially available as precompiled packages.
You're second sentence is entirely irrelevant to the first. Being available in a software distribution or being trivially available as precompiled packages is not the same as being installed by default.
But the question really is, which flavors of Unix have both Perl and Python installed by default. Once can count on having the Bourne shell (or something compatible) on virtually any Unix installation. If one is to target Perl or Python, one cannot count on it being there.
Tell me which flavors of Unix that ship with both Perl and Python as part of the default install. The new Solaris boxes at my employer do have perl installed, but only as a site specific addition. They do not have python installed except for the webservers where it was specifically installed for certain projects that require it.
... as a rule of thumb multi-cell battery packs should never be completely drained which can destroy individual cells within the pack leaving the capacity of the pack as a whole quite diminished.
If the rank and file are informed by the grand mucky-mucks of exactly what is transpiring with regard to legal strategy, etc., then SCO is a very unique organization.
I recall watching a news magazine program where they mentioned that certain former Enron employees were being snapped up right and left by other energy trading firms after the impending bankruptcy was announced. True, their salaries were much lower than at Enron, but they were still well above average for the industry.
I'd imagine that pretty much the same would hold for SCO employees. If nothing else, being a former SCO employee makes the question "why did you leave your last position?" very easy to answer.
IBM might invest a bit in Novell, but big blue will not be buying the red box anytime soon. IBM does not want control of Linux. They want the ability to add to Linux, but have Linux remain an independent entity. If Linux rules the software world, IBM can compete on its merits as a hardware/services company. Which other vendors would keep serving up Linux if IBM owned its own distribution?
Slashdot Mirror
Now if ethanol can be derived from waste or surplus or if the energy can be extracted from ethanol in a more efficient manner, this is no longer a consideration and your consideration, which gives you the biggest bang for the buck becomes the only consideration.
BTW, the 30% number is the amount of energy that can extracted from ethanol through burning it in an internal combustion engine. Converting it to hydrogen and running the hydrogen through a fuel cell may be more efficient.
As long as it takes more energy than can harvested from a gallon of ethanol in order to produce that gallon of ethanol, it is irrelevent as to whether ethanol comes from a renewable resource. If that barrier is broken, then it does begin to matter and I agree with your comment entirely providing it is contingent on ethanol production providing a net gain of usable energy.
Which is why I mentioned the other point, regarding surplus and waste products. If waste and surplus products can can produce enough ethanol for energy needs, then ethanol suddenly becomes a viable fuel regardless of whether ethanol to hydrogen to electricity pulls more energy out of ethanol than burning it in an engine.
Also, if the statement that the only way to prove that a software design matches real-world requirements is to implement the design, and completely test its interaction withing the domain is correct, when combined with the statement that the real world is infinitely detailed, and thus so is the problem domain, the conclusion is that it is not possible to prove that a design properly implements real-world requirements. I reject this conclusion.
As for cost, given the high rate of failure in the current system and the astronomical costs of bugs in current software products, I don't think that cost considerations support your argument.
Further, virtually every software text in existence states that more time spent in design reduces defects and yet very few projects spend sufficient time in the design state. Proper design is currently the path not chosen, so its costs are unknown. One cannot reasonably argue that an unknown cost is higher than a known cost prior to the unknown cost being known.
Lastly, your request for a proof exemplifies my point. You cannot offer such a proof and that is why Apache has to be patched. If Apache had been properly designed and constructed from the beginning, the only updates to Apache would be for new features. The cost of all the bugfixing that has gone into Apache over the years was unnecessary.
Unfortunately, computer science is still in its relative infancy. It is currently more akin to a skilled trade than a science. Also, our system of education (at least in the US) is geared toward producing artisans of computers rather than computer scientists. One hopes that this will continue to change over time.
But there are two considerations to make here that are not part of the above statement:
The opposite approach should be taken. A design should first be proven to solve the problem. Then the implementation should be proven to implement the design.
To produce bugless software we need to start with software designs that are provably correct and then produce code that is provably in line with the design. Using more objects that more closely model the "real world" is an invitation to producing larger number of bugs as the ambiguity of the real world infects the design and implementation of the program.
Further, we only need to find one practical use of mono to demonstrate that the conclusion is categorically wrong. That mono ships with commercial products such as Virtuoso suggests that there is at least one practical use of mono.
On Davidson's second point, I think he misunderstands patronage. Microsoft does not currently fund mono in any way in which I am aware. They do fund some competitors to mono such as rotor and (at least at one time) Corel's attempt to bring dot net to Linux. His only example of Microsoft being a patron consists of a hypothetical chain of events that is exceedingly unlikely. I suspect that perhaps Davidson meant forbearance instead of patronage. If he did, he would do well to explain exactly how Microsoft's patents threaten mono because some people (including people far brighter than me) do not see any clear and present danger.
As a third party vendor has already announced that it will step into the void, this means that the Palm world will simply be returning to the way things were.
More interesting to me is the implication of the announcement that Palm apps for 6.x will be built on top of Microsoft tools: The new PIM apps have be re-architected to more closely resemble Microsoft Outlook fields and the internal database use a new SQL like schema to store records. While this could very well reference in house tools, it seems to me that they are thinking of using an MS dev kit to simplify development. I wouldn't be surprised to hear an announcement in the near future which proclaims that Palm OS 6 will support dot net.
Aside from some of the games, I can't think of any IBM software that doesn't lead to hardware sales and/or service contracts. A lot of large companies go IBM because they can be a one stop shop so a lot of software that IBM does to drive hardware sales may not look directly related to hardware at first.
That said, they've opened up quite a few of their boxed software products.
I think that perhaps you're drawing the wrong conclusion from the data.
Dunno about where you live, but most places in the US, it is legal to go onto someone else's land unless there are posted "no tresspassing" signs or you've been specifically told by that person you are not allowed.
I won't argue that this is unambigous in the eyes of the law. I will argue that this is entirely unabiguous with regards to morals.
Hence, your beef seems to me to be with sys admins that aren't providing the tools that the boxes they installed need for the users to get their work done. It doesn't really have anything to do with whether or not a given toolset is part of the default install.
Although, I will also say that it royally pisses me off when the sys admin installs one of the newfangled versions of vi with all the bells and whistles turned on so that I have to edit some .rc file or the other to turn them off so that vi acts like vi. When I want syntax highlighting and autoindent, I'll use xemacs. Few things are more irritating than discovering pasting a sizeable chunk of code only to discover that vi is actually vim and autoindent is turned and all the indentation in twenty lines or so of code you just pasted gets funged because vim's autoindent sucks when the pasting lines already indented.
But, I'm also pretty certain that this is a minority position. Most Unix boxes are purchased/leased for a specific purpose and the default install contains very little leaving the administrator to decide which programs to install. The fewer programs installed, the fewer possibilities there are for something to go wrong.
I hold that this is a good thing because the administrator knows better if Perl (or Python) is needed and if so if Perl (or Python) needs to be a specific version or flavor or compiled with specific options and so on and so forth. It is best to keep the defaults to a minimum and assume that the adminstrator knows what to add on and what not to.
I guess that means that you've yet to have any sort of job in the IT industry.
But the question really is, which flavors of Unix have both Perl and Python installed by default. Once can count on having the Bourne shell (or something compatible) on virtually any Unix installation. If one is to target Perl or Python, one cannot count on it being there.
Here's a clue: there's more to *nix than Linux.
... as a rule of thumb multi-cell battery packs should never be completely drained which can destroy individual cells within the pack leaving the capacity of the pack as a whole quite diminished.
If the rank and file are informed by the grand mucky-mucks of exactly what is transpiring with regard to legal strategy, etc., then SCO is a very unique organization.
I'd imagine that pretty much the same would hold for SCO employees. If nothing else, being a former SCO employee makes the question "why did you leave your last position?" very easy to answer.
IBM might invest a bit in Novell, but big blue will not be buying the red box anytime soon. IBM does not want control of Linux. They want the ability to add to Linux, but have Linux remain an independent entity. If Linux rules the software world, IBM can compete on its merits as a hardware/services company. Which other vendors would keep serving up Linux if IBM owned its own distribution?