Where did you get polling for a JSON packet? In TFA it sounded like there would be pre-defined hook functions whose default definitions just throw an exception. To enable communication with a module, you provide hook functions. There is no polling; when one side wants to send a message, it calls the library function with the JSON text, and that calls the hook, which either executes your code (if you provided a hook function) or throws the exception (if you left the default hook in place.)
The immediate problem I see with this is that the module author and page author probably don't know each other and aren't coordinating, so there's no way for the module author to know whether or not it's ok to send a JSON message. If the messages are optional, just catching and ignoring the exception is reasonable only if the page author isn't trying to receive the message and expecting to see error messages if there is a problem. There needs to be a way for the module author to query the outer module and find out which hooks are implemented and which are not, so that the module can make intelligent choices about whether or not to send messages.
There were a lot of problems with the original trilogy but I think the biggest two were the Ewoks and having 2 Death Stars (they couldn't make 3 movies without recycling that plot).
Having the Empire try to rebuild the Death Star instead of something else actually makes a lot of sense. The Sith were working on the plans in EpII, and it took around twenty years to complete the Death Star and start testing its planet-destroying weapon. I imagine most of that time was spent finishing the plans and building the construction infrastructure needed for such a large project.
After it got blown up, if they started from scratch it might have been another 20 or more years before they got a different design constructed. Instead, they reused the existing design, because they probably still had all of the factories and workers available. I imagine they fixed the 'shoot here to destroy' hole, which is why in EpVI the rebels had to fly all the way inside and blow up the reactor directly. By reusing the existing design, they had it half built in just a year or two. (Hmm... is there an official timespan for the periods between the original films? It can't be as long as the actual timespans, can it?)
A lightweight well-balanced wooden knob might not tend to rotate around its axis as much when vibrating as a heavier unbalanced knob might. In other words, if the original knobs have a center of gravity that is between the axis and the pointer (because the knob is asymmetric) and it is mounted with a non-vertical axis, then if it vibrates enough to overcome static friction, the gravitational force on the knob will cause it to rotate.
If the replacement knobs are either lighter weight or balanced (by being symmetric or by having a counter-weight added) then they would have less tendency to rotate under the same conditions.
Of course, this sort of condition would make the knob move in a single direction until the pointer was pointing down, rather than rotating back and forth slightly... at least until it reached the bottom or end of its travel, I guess.
In any case, if someone is really having this sort of a problem, they need to replace the thing the knobs are attached to, not the knobs.
Wow, that's just about almost believable. If the sound from the speakers is able to act on the knobs with enough force to make the volume pots vibrate, then the volume will fluctuate at the frequency of the sound. That's an interesting way to introduce distortion, and I could definitely see how loose pots and off-balance knobs could make it worse, perhaps even audible.
Turning the volume down would probably help more than new knobs, though... especially since the real problem in such a setup would be the loose pots.
The really good snake-oil claims, like any lie, have just enough of an element of truth to make you wonder if they're onto something real.
If a symmetrical object is moved through the air, there will be equal displacement on each side, and no lift will be generated. A wing is asymmetric, the air traveling underneath experiences little disturbance, the air displaced around the top becomes more spread out, spreading out a gas decreases the temperature and pressure, the differential pressure between lesser displaced air beneath the wing and the more displaced air above the wing generates lift. Again, the air beneath the wing tries to fill the void created above the wing.
Please explain how a plane flies upside down, then. They can do so for extended periods of time.
Generally, I imagine that it has to do with the fact that word processing files don't carry fonts with them. Even if the file specification were 100% open and implementable, most fonts are licensed in a way that doesn't allow them to be redistributed. As a result, you can only print the document and send paper around, or export to PDF which renders the characters as lines and fills but doesn't include the font information itself.
A desktop publishing package would have the same limitation, I would imagine, except the file formats might enable embedding the fonts (putting the license-compliance burden on the user), or a particular package might come with a standard set of fonts you can count on being available.
Every efficiency improvement has a cost associated with it. At some point, the value of the improvement, even if it is positive, is too small relative to the cost to be worthwhile. For example, would you spend $10,000 to improve the insulation on your home if it's only going to save you $50 per year? No, because even though it's a savings, it's not worthwhile.
I leave them in until they're uncomfortable. When I'm healthy, they can last for two months. When I have a cold, they might not last a day (I usually switch to my glasses.) After 25 years of wearing contacts, I know how to tell when they need to be changed: they feel dry or gritty and saline drops don't help, or I get a 'my contacts are too tight' headache and I have to take them out.
If I take them out, I don't bother reusing them. Sometimes though, I'll take them out one at a time, clean them with saline, and put them right back in. I might have to do that after a spicy meal, or during the beginning stages of a cold, because my eyes are dumping junk out my tear ducts. (Did you know your tear ducts are one of your body's garbage dumps. More than two of your holes are used to get rid of waste...)
I imagine the problem with reusing contacts is people who don't clean them properly. If you take them out and leave them sitting overnight in a case that wasn't cleaned properly, with saline that isn't sterile, then you can get bacteria growth which infects you when you the contacts back in. That's why I touch my contacts as little as possible, I'm careful about cleanliness when I do touch them, and I ditch them right away if they're going to be out of my eyes for more time than it takes to rinse them and stick them back in.
Also in zero-G, putting on and removing contacts might be a problem.
You must not wear contacts, as least not the soft ones. They're always wet, so they stick to things (the case, your finger, your eye) using the surface tension. They're not going to float away unless you try to flick them away. There might be a problem with saline solution blobs getting loose, but with the disposable contacts, you generally don't even need to rinse them before putting them in, and I imagine the saline solution would stay in the case if you don't shake it around too much. Besides, you always see astronauts playing with floating blobs of fluid, so cleanup must be reasonably easy.
Also, some people (including me) are able to sleep in the 'daily wear' disposable contacts for weeks at a time; when they first came out they were 'monthly wear', but the manufacturers have been backing off of that even as they've made them more porous to oxygen and less prone to drying out. I don't know if they're protecting themselves from lawsuits by stupid people who don't listen to their own bodies, or if they've just figured out that the more frequently people dispose their contacts, the more they spend on new ones. In any case, it's possible to wear the same contacts for the duration of a typical shuttle mission, and to change them just a handful of times for the duration of a typical space station sleepover.
This paper sounds like they're relating the amount of heat put into a tank, and the tank's temperature. From this relationship, they're getting a better determination of the total hydrazine in each tank, and thus they can better balance the fuel in each tank.
Basically, yes. I did an internship with GE AstroSpace during the summer of 1991, and I worked with an engineer in their propulsion group testing exactly this concept. We had a small tank, which we covered with heating elements and temperature sensors, wrapped with typical insulating materials as it would be on a satellite, filled it with various amounts of fluid and helium, stuck it in a vacuum chamber (to eliminate convection effects), and ran it through some heating and cooling cycles while measuring the temperature response.
There's a formula from thermodynamics (which I no longer remember) that relates the change in temperature to the energy added to a system, the mass of the system, and the thermodynamic properties of the materials in the system. In our experiment we knew the values of all of the variables within a certain error, and we were able to verify that the equation was accurately modeling the test. We were also able to invert the equation to solve for the mass of the propellant, and with some fancy analysis we determined the error range for that mass, given the error ranges of our other variables. (eg: the amount of energy going into the tanks depends on the voltage and current going to the heating elements, which the satellite telemetry could measure and report but not precisely, and the temperature could also be measured and reported but not precisely.)
What's really key in the end result isn't the mass of the propellant left in the tank; it's the error. As you noted, the traditional approach is bookkeeping, where the amount of fuel used for each burn is estimated, and over time the errors in that estimate add up. So, near the end of life, you know that you have 2 years worth of propellant, plus or minus six months. With the temperature-response approach, we were able to show that you can reduce the error to plus or minus two months (for example). With bookkeeping, the satellite has to be replaced at 2 years - six months, but with temperature-response it can be replaced at 2 years - two months: four additional months of service, which saves millions of dollars by delaying the new satellite.
It's not a "science is wrong" argument, it's a total denial of all knowledge, usually requires a deceitful God should he exist, and that therefore no claim is valid. It makes the Flying Spaghetti Monster just as valid as whatever agenda they're trying to push.
It's none of that. It's an acknowledgment that science in general, and the scientific method specifically, is based on axioms that cannot be proven within the system, and must be accepted on faith. The same is true of mathematics. As long as you accept and believe the axioms (ie: observation is reasonably reliable) then then the rest follows in a rigorous and logical manner.
My problem is with people who say "faith is meaningless and worthless, I only believe what I can observe" without even thinking about it enough to realize how hypocritical that statement is.
Personally, I stick to category 1 and am a devout athiest.
You have faith that your observations accurately reflect reality. This is a faith that underlies all of science, and generally goes unacknowledged.
You know that your observations are all analyzed by your brain, and you know that your brain gets its information from your nervous system and your senses. You also know that it's possible to stimulate your nerves in ways which can create false readings from your senses, and that there are people with medical conditions that alter their senses. (Blindness and deafness being the most obvious, but also color blindness, heightened or decreased sensitivity to tastes and smells, and even people who see sounds or hear colors.) Therefore, logically, you can't trust your senses or your observations, even if they seem to be internally consistent. For all you know, you're just a brain in a jar with a very accurate and consistent reality being presented to you.
You might think that's unlikely, and I tend to agree with you, because I have faith in my observations as well. But it's still just faith; there's no way to prove it one way or another using the scientific method. Trying to do so is no more reasonable that someone using statements of facts from the Bible to prove that the statements of facts in the Bible are true. You also can't prove that your observations reflect reality using logic, because logically there's every reason to believe observations are untrustworthy.
Nope, you're wrong. There's lots of special behavior that you get with the empty <> that you don't get with <STDIN>. The special behaviors are particularly useful for writing filters (programs that read from and write to other programs via pipes) but they can be useful for standalone programs too. In fact, <STDIN> is particularly bad for writing filters.
Now, not only can the program echo in reverse from the command line, but it can do so from a file, a list of files, a pipe (ie: the output of another program), or a socket... pretty much anything that can produce a list of string lines.
Do that a similarly short Java program.
Re:it's not that mysterious what caused extinction
on
Baby Mammoth Found Intact
·
· Score: 3, Interesting
There was a massive extinction of larger animals in North America 10,000 years ago, coincident with a new migration of people across the Siberian land bridge. Giant sloth, cave bear, sabertooth, mastodon, etc. were wiped out.
Also coincident with the end of the ice age environment these species were adapted to. The humans back then probably scavenged more than they hunted; easy pickings.
Also, one has to wonder why the buffalo, the moose, and the deer, which replaced the ice age herbivores in North America, weren't wiped out by human over-hunting. They seem a lot easier to kill than mastodon. Maybe it's because humans didn't start over-hunting other species until we developed guns?
I don't think there was a viable strategy either; especially without international support. (Real support, not bullied token support.) Bush should've taken a completely different approach.
My perferred approach, then and today, is to eliminate the US' dependence on foreign oil. That would take most of the power and greed out of the Middle East situation, as well as much of the foreign interference with local politics. Ultimately, I think that's what most folks who live there want, too: independence from foreign powers.
I've got a three-pronged strategy for getting off the foreign oil:
1. Short-term: develop US sources again; we've still got plenty.
2. Medium-term: develop the infrastructure to convert domestic organic waste into crude oil.
3. Long-term: build enough nuclear power plants to supply the electricity we currently make by burning fossil fuels. (We'd need 5x to 6x as many as we have now.)
The easy answer is that in Iraq, you've got civilians, trained and untrained soldiers on two sides, and the soldiers from the US and its allies. The problem is that the first three groups all blend in together when they're not actively fighting, and the US and its allies are trying not to hurt the civilians.
If we were really at war with Iraq as a whole, we'd do much better. This was the case early on, when we were fighting Saddam's army. We still tried to minimize hurting civilians; we could have won even quicker if we didn't.
Yes, I said won. We won that first war, then got stuck in a no-win situation in the follow-on war to decide how to fill the power-vacuum we created. Bush's biggest crime here was starting the first war without a viable plan for winning or avoiding the second one.
A mixed group is a mixed group, and should be represented as such. If you spend 80% of your time on external software development, and 20% of your time on internal systems development, your costs should be allocated proportionally. Your accounting department probably has different codes for these different kinds of costs, because they can be treated differently in financial and tax reports.
I consider for-profit software development as product development. The fact that it's software may make it a subset of IT, but the vast majority of IT jobs are internal-only support positions. There is a qualitative difference between what those folks do and what the software-for-profit folks do, in the way their work impacts the profitability of the company.
Then you shouldn't call it IT, and get lumped in with the guys who write database Apps for the finance group.
I develop software for customers, but my team doesn't "add to the bottom line" either. Nor the top line. My team produces the products that the sales and marketing groups sell, and they're the ones that being in the revenue. My team plays a critical role in that, and our cost is justified by that role, but it is still a cost that enables another group to being in revenue. My team cannot, by itself, generate revenue.
My company has a somewhat enlightened approach to this cost... We treat the develoment effort of producing new software as a capital investment rather than as a sunk cost; we're building assets, not heating the office or pushing paper in circles. This is a good mindset for the executives to have; I can't imagine my CEO asking me "why are we investing so much in the corporate assets our company earns revenue selling?" At worst, she'll ask whether the revenue is larger than the cost, which luckily it is.
IT doesn't add anything to the bottom line. IT takes away from the top line, just like HR, management, administrative positions, the mailroom, etc.
IT should be measured three ways (from the CEO's perspective):
1) To what extent is the IT department reducing risks to the business? This covers backups, software updates, choice of software and hardware, ticket resolution (NOT closing) times, etc. All of these should be presented as "To prevent X, we did Y."
2) To what extent does IT improve the productivity of other departments? This includes any custom software that is built, automation of various systems (like trouble ticket reporting and processing) and so on. A survey would be helpful here to get quotes from other departments saying how Project Q has improved their productivity.
3) How has IT measured and improved its own cost efficency, and reduced the cost of other departments? This is where you trumpet any transitions to OSS, if that went well. Mostly you just need to justify the IT department's cost. After 1 and 2, that should be easier to do.
1) It has no keys; it's a sealed box. As I understand it, on-site maintenance involves keeping the pool filled, and taking care of the electrical connection to the grid. The box is shielded so that no radiation can escape, and given the small size it can't have that much nuclear material in it. Yeah, blowing it up would be bad, so it needs physical security, but that's true of any power plant, chemical plant, most manufacturing plants, etc.
2) I'll bet the plant is a lot cleaner and safer than coalmine, oil rig, or any fossil fuel burning power plant. It's probably no more dangerous than a plant that makes solar panels; I understand lots of nasty chemicals are needed to process silicon wafers.
3) I think the waste disposal cost was probably included in the maintenance fee. Having this centralized at the manufacturing plant probably provides an economy of scale, too... not that there's much volume for this material. It's probably less waste to dispose of than the waste coming our of a massive silicon solar array panel manufacturing plant.
4) No, you're making this up. It can't melt down, and doesn't need all of that. It is a sealed box transportable on a rail car, and it requires a pool of water to sit in for five years. My understanding is that all you otherwise need is the hookup to the power grid.
You're leaving out the cost of maintenance (which is not zero) and the cost of land. And, as someone else mentioned, solar panels only work during sunny days; you'll need a completely different infrastructure to store and/or generate electricity at night and when it's raining. Maybe, in one small corner of the huge solar array property, you can have a swimming pool with a reactor that generates 3.5 times as much power as the whole array...
Here is a link: http://www.mediamerica.net/obm2005_12Nuclear.php/ The reactor I'm talking about is described in the middle of the article. They describe it as 35MW with enough power for 21000 homes. This article is 1.5 years old; maybe they've ramped up the power since then.
I read that nuclear engineers at a university in Oregon are developing a reactor that is a sealed box that can be transported on a flatbed rail car. You transport it from the factory to where you want power, and install it in a pool of water. It lasts for five years, at which time you send it back to the factory for maintenance and refueling, and you replace it with a new one.
The reactor can generate enough power for 35000 homes, which I guess is 140MW. It costs 3.5 cents per kilowatt-hour, including fuel, maintenance, leasing, and shipping.
Not only is this much cheaper than the solar array in the story, I estimate you can put 30000 of these reactors in the 1.4 square miles that the array would take up, enough to power over 1 billion homes rather than just 10000.
Slashdot Mirror
Where did you get polling for a JSON packet? In TFA it sounded like there would be pre-defined hook functions whose default definitions just throw an exception. To enable communication with a module, you provide hook functions. There is no polling; when one side wants to send a message, it calls the library function with the JSON text, and that calls the hook, which either executes your code (if you provided a hook function) or throws the exception (if you left the default hook in place.)
The immediate problem I see with this is that the module author and page author probably don't know each other and aren't coordinating, so there's no way for the module author to know whether or not it's ok to send a JSON message. If the messages are optional, just catching and ignoring the exception is reasonable only if the page author isn't trying to receive the message and expecting to see error messages if there is a problem. There needs to be a way for the module author to query the outer module and find out which hooks are implemented and which are not, so that the module can make intelligent choices about whether or not to send messages.
Having the Empire try to rebuild the Death Star instead of something else actually makes a lot of sense. The Sith were working on the plans in EpII, and it took around twenty years to complete the Death Star and start testing its planet-destroying weapon. I imagine most of that time was spent finishing the plans and building the construction infrastructure needed for such a large project.
After it got blown up, if they started from scratch it might have been another 20 or more years before they got a different design constructed. Instead, they reused the existing design, because they probably still had all of the factories and workers available. I imagine they fixed the 'shoot here to destroy' hole, which is why in EpVI the rebels had to fly all the way inside and blow up the reactor directly. By reusing the existing design, they had it half built in just a year or two. (Hmm... is there an official timespan for the periods between the original films? It can't be as long as the actual timespans, can it?)
A lightweight well-balanced wooden knob might not tend to rotate around its axis as much when vibrating as a heavier unbalanced knob might. In other words, if the original knobs have a center of gravity that is between the axis and the pointer (because the knob is asymmetric) and it is mounted with a non-vertical axis, then if it vibrates enough to overcome static friction, the gravitational force on the knob will cause it to rotate.
If the replacement knobs are either lighter weight or balanced (by being symmetric or by having a counter-weight added) then they would have less tendency to rotate under the same conditions.
Of course, this sort of condition would make the knob move in a single direction until the pointer was pointing down, rather than rotating back and forth slightly... at least until it reached the bottom or end of its travel, I guess.
In any case, if someone is really having this sort of a problem, they need to replace the thing the knobs are attached to, not the knobs.
Wow, that's just about almost believable. If the sound from the speakers is able to act on the knobs with enough force to make the volume pots vibrate, then the volume will fluctuate at the frequency of the sound. That's an interesting way to introduce distortion, and I could definitely see how loose pots and off-balance knobs could make it worse, perhaps even audible.
Turning the volume down would probably help more than new knobs, though... especially since the real problem in such a setup would be the loose pots.
The really good snake-oil claims, like any lie, have just enough of an element of truth to make you wonder if they're onto something real.
Please explain how a plane flies upside down, then. They can do so for extended periods of time.
You might want to look at http://amasci.com/wing/airfoil.html/ for a hint.
Generally, I imagine that it has to do with the fact that word processing files don't carry fonts with them. Even if the file specification were 100% open and implementable, most fonts are licensed in a way that doesn't allow them to be redistributed. As a result, you can only print the document and send paper around, or export to PDF which renders the characters as lines and fills but doesn't include the font information itself.
A desktop publishing package would have the same limitation, I would imagine, except the file formats might enable embedding the fonts (putting the license-compliance burden on the user), or a particular package might come with a standard set of fonts you can count on being available.
Can't you do something like this with Apache?
It's not as straightforward to configure as SlimFTP seems, but it's a lot more flexible, and it's available.
Every efficiency improvement has a cost associated with it. At some point, the value of the improvement, even if it is positive, is too small relative to the cost to be worthwhile. For example, would you spend $10,000 to improve the insulation on your home if it's only going to save you $50 per year? No, because even though it's a savings, it's not worthwhile.
I leave them in until they're uncomfortable. When I'm healthy, they can last for two months. When I have a cold, they might not last a day (I usually switch to my glasses.) After 25 years of wearing contacts, I know how to tell when they need to be changed: they feel dry or gritty and saline drops don't help, or I get a 'my contacts are too tight' headache and I have to take them out.
If I take them out, I don't bother reusing them. Sometimes though, I'll take them out one at a time, clean them with saline, and put them right back in. I might have to do that after a spicy meal, or during the beginning stages of a cold, because my eyes are dumping junk out my tear ducts. (Did you know your tear ducts are one of your body's garbage dumps. More than two of your holes are used to get rid of waste...)
I imagine the problem with reusing contacts is people who don't clean them properly. If you take them out and leave them sitting overnight in a case that wasn't cleaned properly, with saline that isn't sterile, then you can get bacteria growth which infects you when you the contacts back in. That's why I touch my contacts as little as possible, I'm careful about cleanliness when I do touch them, and I ditch them right away if they're going to be out of my eyes for more time than it takes to rinse them and stick them back in.
You must not wear contacts, as least not the soft ones. They're always wet, so they stick to things (the case, your finger, your eye) using the surface tension. They're not going to float away unless you try to flick them away. There might be a problem with saline solution blobs getting loose, but with the disposable contacts, you generally don't even need to rinse them before putting them in, and I imagine the saline solution would stay in the case if you don't shake it around too much. Besides, you always see astronauts playing with floating blobs of fluid, so cleanup must be reasonably easy.
Also, some people (including me) are able to sleep in the 'daily wear' disposable contacts for weeks at a time; when they first came out they were 'monthly wear', but the manufacturers have been backing off of that even as they've made them more porous to oxygen and less prone to drying out. I don't know if they're protecting themselves from lawsuits by stupid people who don't listen to their own bodies, or if they've just figured out that the more frequently people dispose their contacts, the more they spend on new ones. In any case, it's possible to wear the same contacts for the duration of a typical shuttle mission, and to change them just a handful of times for the duration of a typical space station sleepover.
Basically, yes. I did an internship with GE AstroSpace during the summer of 1991, and I worked with an engineer in their propulsion group testing exactly this concept. We had a small tank, which we covered with heating elements and temperature sensors, wrapped with typical insulating materials as it would be on a satellite, filled it with various amounts of fluid and helium, stuck it in a vacuum chamber (to eliminate convection effects), and ran it through some heating and cooling cycles while measuring the temperature response.
There's a formula from thermodynamics (which I no longer remember) that relates the change in temperature to the energy added to a system, the mass of the system, and the thermodynamic properties of the materials in the system. In our experiment we knew the values of all of the variables within a certain error, and we were able to verify that the equation was accurately modeling the test. We were also able to invert the equation to solve for the mass of the propellant, and with some fancy analysis we determined the error range for that mass, given the error ranges of our other variables. (eg: the amount of energy going into the tanks depends on the voltage and current going to the heating elements, which the satellite telemetry could measure and report but not precisely, and the temperature could also be measured and reported but not precisely.)
What's really key in the end result isn't the mass of the propellant left in the tank; it's the error. As you noted, the traditional approach is bookkeeping, where the amount of fuel used for each burn is estimated, and over time the errors in that estimate add up. So, near the end of life, you know that you have 2 years worth of propellant, plus or minus six months. With the temperature-response approach, we were able to show that you can reduce the error to plus or minus two months (for example). With bookkeeping, the satellite has to be replaced at 2 years - six months, but with temperature-response it can be replaced at 2 years - two months: four additional months of service, which saves millions of dollars by delaying the new satellite.
It's none of that. It's an acknowledgment that science in general, and the scientific method specifically, is based on axioms that cannot be proven within the system, and must be accepted on faith. The same is true of mathematics. As long as you accept and believe the axioms (ie: observation is reasonably reliable) then then the rest follows in a rigorous and logical manner.
My problem is with people who say "faith is meaningless and worthless, I only believe what I can observe" without even thinking about it enough to realize how hypocritical that statement is.
You have faith that your observations accurately reflect reality. This is a faith that underlies all of science, and generally goes unacknowledged.
You know that your observations are all analyzed by your brain, and you know that your brain gets its information from your nervous system and your senses. You also know that it's possible to stimulate your nerves in ways which can create false readings from your senses, and that there are people with medical conditions that alter their senses. (Blindness and deafness being the most obvious, but also color blindness, heightened or decreased sensitivity to tastes and smells, and even people who see sounds or hear colors.) Therefore, logically, you can't trust your senses or your observations, even if they seem to be internally consistent. For all you know, you're just a brain in a jar with a very accurate and consistent reality being presented to you.
You might think that's unlikely, and I tend to agree with you, because I have faith in my observations as well. But it's still just faith; there's no way to prove it one way or another using the scientific method. Trying to do so is no more reasonable that someone using statements of facts from the Bible to prove that the statements of facts in the Bible are true. You also can't prove that your observations reflect reality using logic, because logically there's every reason to believe observations are untrustworthy.
Nope, you're wrong. There's lots of special behavior that you get with the empty <> that you don't get with <STDIN>. The special behaviors are particularly useful for writing filters (programs that read from and write to other programs via pipes) but they can be useful for standalone programs too. In fact, <STDIN> is particularly bad for writing filters.
See perlop - I/O Operators, scrolling down a bit to "The null filehandle <> is special...", and Perl Best Practices #135, Avoid using *STDIN unless you really mean it.
This line:
Should be:
Now, not only can the program echo in reverse from the command line, but it can do so from a file, a list of files, a pipe (ie: the output of another program), or a socket... pretty much anything that can produce a list of string lines.
Do that a similarly short Java program.
Also coincident with the end of the ice age environment these species were adapted to. The humans back then probably scavenged more than they hunted; easy pickings.
Also, one has to wonder why the buffalo, the moose, and the deer, which replaced the ice age herbivores in North America, weren't wiped out by human over-hunting. They seem a lot easier to kill than mastodon. Maybe it's because humans didn't start over-hunting other species until we developed guns?
I don't think there was a viable strategy either; especially without international support. (Real support, not bullied token support.) Bush should've taken a completely different approach.
My perferred approach, then and today, is to eliminate the US' dependence on foreign oil. That would take most of the power and greed out of the Middle East situation, as well as much of the foreign interference with local politics. Ultimately, I think that's what most folks who live there want, too: independence from foreign powers.
I've got a three-pronged strategy for getting off the foreign oil:
1. Short-term: develop US sources again; we've still got plenty.
2. Medium-term: develop the infrastructure to convert domestic organic waste into crude oil.
3. Long-term: build enough nuclear power plants to supply the electricity we currently make by burning fossil fuels. (We'd need 5x to 6x as many as we have now.)
The easy answer is that in Iraq, you've got civilians, trained and untrained soldiers on two sides, and the soldiers from the US and its allies. The problem is that the first three groups all blend in together when they're not actively fighting, and the US and its allies are trying not to hurt the civilians.
If we were really at war with Iraq as a whole, we'd do much better. This was the case early on, when we were fighting Saddam's army. We still tried to minimize hurting civilians; we could have won even quicker if we didn't.
Yes, I said won. We won that first war, then got stuck in a no-win situation in the follow-on war to decide how to fill the power-vacuum we created. Bush's biggest crime here was starting the first war without a viable plan for winning or avoiding the second one.
Wendy's deli sandwiches are pretty good, and they offer naked potatoes too. That's really not bad, especially for a fast food joint.
A mixed group is a mixed group, and should be represented as such. If you spend 80% of your time on external software development, and 20% of your time on internal systems development, your costs should be allocated proportionally. Your accounting department probably has different codes for these different kinds of costs, because they can be treated differently in financial and tax reports.
I consider for-profit software development as product development. The fact that it's software may make it a subset of IT, but the vast majority of IT jobs are internal-only support positions. There is a qualitative difference between what those folks do and what the software-for-profit folks do, in the way their work impacts the profitability of the company.
Then you shouldn't call it IT, and get lumped in with the guys who write database Apps for the finance group.
I develop software for customers, but my team doesn't "add to the bottom line" either. Nor the top line. My team produces the products that the sales and marketing groups sell, and they're the ones that being in the revenue. My team plays a critical role in that, and our cost is justified by that role, but it is still a cost that enables another group to being in revenue. My team cannot, by itself, generate revenue.
My company has a somewhat enlightened approach to this cost... We treat the develoment effort of producing new software as a capital investment rather than as a sunk cost; we're building assets, not heating the office or pushing paper in circles. This is a good mindset for the executives to have; I can't imagine my CEO asking me "why are we investing so much in the corporate assets our company earns revenue selling?" At worst, she'll ask whether the revenue is larger than the cost, which luckily it is.
IT doesn't add anything to the bottom line. IT takes away from the top line, just like HR, management, administrative positions, the mailroom, etc.
IT should be measured three ways (from the CEO's perspective):
1) To what extent is the IT department reducing risks to the business? This covers backups, software updates, choice of software and hardware, ticket resolution (NOT closing) times, etc. All of these should be presented as "To prevent X, we did Y."
2) To what extent does IT improve the productivity of other departments? This includes any custom software that is built, automation of various systems (like trouble ticket reporting and processing) and so on. A survey would be helpful here to get quotes from other departments saying how Project Q has improved their productivity.
3) How has IT measured and improved its own cost efficency, and reduced the cost of other departments? This is where you trumpet any transitions to OSS, if that went well. Mostly you just need to justify the IT department's cost. After 1 and 2, that should be easier to do.
1) It has no keys; it's a sealed box. As I understand it, on-site maintenance involves keeping the pool filled, and taking care of the electrical connection to the grid. The box is shielded so that no radiation can escape, and given the small size it can't have that much nuclear material in it. Yeah, blowing it up would be bad, so it needs physical security, but that's true of any power plant, chemical plant, most manufacturing plants, etc.
2) I'll bet the plant is a lot cleaner and safer than coalmine, oil rig, or any fossil fuel burning power plant. It's probably no more dangerous than a plant that makes solar panels; I understand lots of nasty chemicals are needed to process silicon wafers.
3) I think the waste disposal cost was probably included in the maintenance fee. Having this centralized at the manufacturing plant probably provides an economy of scale, too... not that there's much volume for this material. It's probably less waste to dispose of than the waste coming our of a massive silicon solar array panel manufacturing plant.
4) No, you're making this up. It can't melt down, and doesn't need all of that. It is a sealed box transportable on a rail car, and it requires a pool of water to sit in for five years. My understanding is that all you otherwise need is the hookup to the power grid.
You're leaving out the cost of maintenance (which is not zero) and the cost of land. And, as someone else mentioned, solar panels only work during sunny days; you'll need a completely different infrastructure to store and/or generate electricity at night and when it's raining. Maybe, in one small corner of the huge solar array property, you can have a swimming pool with a reactor that generates 3.5 times as much power as the whole array...
Here is a link: http://www.mediamerica.net/obm2005_12Nuclear.php/ The reactor I'm talking about is described in the middle of the article. They describe it as 35MW with enough power for 21000 homes. This article is 1.5 years old; maybe they've ramped up the power since then.
I read that nuclear engineers at a university in Oregon are developing a reactor that is a sealed box that can be transported on a flatbed rail car. You transport it from the factory to where you want power, and install it in a pool of water. It lasts for five years, at which time you send it back to the factory for maintenance and refueling, and you replace it with a new one.
The reactor can generate enough power for 35000 homes, which I guess is 140MW. It costs 3.5 cents per kilowatt-hour, including fuel, maintenance, leasing, and shipping.
Not only is this much cheaper than the solar array in the story, I estimate you can put 30000 of these reactors in the 1.4 square miles that the array would take up, enough to power over 1 billion homes rather than just 10000.
The fashion industry folks wouldn't know what a hammer is, either.