The day that two of the most efficiency-bound on-road ICE applications (cross-country 18-wheel trucking and NASCAR racing) switch to automatic transmissions is the day I'll consider one for my personal vehicle.
They're buying off-the-shelf batteries from the same suppliers that build batteries for the rest of the portable electronics industry. Since batteries are a resource intensive product (they're made from commodity materials that must be mined and processed), there is always going to be a fixed cost associated with their production. Here's a free hint: more electric cars being sold will only put more demand on battery manufacturers, and I don't have to explain how supply and demand works.
You are dead-on with with the reflection on the maturity of electric vehicles. They've been around a LONG time.
But regarding battery manufacturing, you may have missed the recent news about Tesla's plans for building the world's largest battery factory this year - it seems that Musk has anticipated your concern: http://gigaom.com/2014/02/19/t...
I haven't done the math, but I suspect that even if MANY millions of people were charging cars at night, it still wouldn't approach the daytime load of the grid. Keep in mind that most people would only need to top off their charge from their short (25 miles perhaps) daily commute.
This is exactly my description. I have a 12.5 mile commute each way to work and back. I am currently converting a 2002 Ford Focus to full electric. I expect to have a total range of about 40 miles per charge.
The charger I'm using is what I would consider a middle-of-the-road charger, in terms of power consumption (about 4.8KW). It is wired for a 240 VAC, 20 amp circuit, and should be able to charge my 144 volt, 28 KWH pack in about 6 hours. Keep in mind, 4.8KW is less than the steady state power consumption of a typical 1.5 ton capacity heat pump. The grid will trivially be able to handle this kind of load during the night.
By the way, what's the "it" in "It's enough for basic point and shoot needs"? Are you talking about 16 MP??
Yes. The 5D is still considered "prosumer," albeit high-end.
It's enough for basic point and shoot needs (i.e. grandma who uses the $5 disposable and runs down to the 1-hour photo lab at Wal Mart). Beyond that- no.
1. Film resolution is measured by granularity of the crystals used. In other words, MOLECULES. Digital resolution is measured in pixels. Molecules are more granular than pixels.
2. Color saturation of prosumer image capture devices are about an order of magnitude worse than good film. This is why all the mucking about in photoshop, etc is required to artificially enhance digital photos and make them "pop." Even so, in many cases, no amount of postprocessing can correct this deficiency. Remember that rule #1 in photography is "good light."
3. Longevity. What's the longevity of a pixel on digital media? I have lots of negatives and slides, over 100 years old, which still produce very nice prints.
That reminds me many years ago, when my friend worked as a programmer in a major bank writing small programs for an online international financial system. He issued an 'shutdown' command through JCL(Job Control Language) and that really shutdown the entire system. He didn't realize he had the privilege to issue administration commands.
[rant]
I'm forced to wonder, did the sysadmin who granted a programmer (one responsible for "small programs," natch) administrative priveledge get fired? How about the manager that signed off on it (assuming a proper change control system)? How about the executive that probably wrote off the proper change control system as "unnecessary overhead"?
[/rant]
Re:Are they better, or just different?
on
eSATA Connectors
·
· Score: 1
This is a poor case design. The best way to use a SATA drive is to have NO CABLE. The drives are designed to they can be pushed onto a socket that is soldered to a printed circuit board. All new design computers should be designed this way, with no cable. How do you propose to connect this secondary board to the motherboard?
The backplane doesn't solve the problem, it just moves the problem- to an extra piece of hardware that increases cost and complexity (no doubt every single case manufacturer will insist that their "exclusive" approach is "superior" - look at the current crap with 3.5 and 5.25 slide rails).
I guess you could be careful to route this mobo-to-backplane cable out of the way... But you could (and should) also do this with the mobo-to-drive cable.
I've had exactly the same problem as the OP with SATA cables - the solution is to secure them out of your maintenance path in some way, or as the OP said, check them when you're done.
Drive push into the computer from the front like SCSI drives with SCA connectors Do note that the SCA backplane must connect to the controller or motherboard using, you guessed it, a cable.
SCSI cables, however, don't seem to have this problem, perhaps due to their enterprise engineering pedigree.
SATA, IMNSHO, is just a solution looking for a problem.
Some users have reported anecdotally that Google Checkout mistakenly canceled sales without warning
This happened to me. Ordered a Creative webcam from buy.com and used Google checkout to get $10 off.
A few weeks later I wondered where it was, went to Google's and buy.com's status pages, which reported "Order was cancelled. Reason: Order was cancelled." Great. Did not even receive an email notification. They did postback the charge to my credit card, though.
I'm not downing your comment, overall very informative. However I thought I'd hang my own off of it since it's topical...
From an engineering standpoint, the concept sucks. Here are a few of my gripes about blades:
Convergent infrastructure causes issues. Blades combine power, management, network, cooling, a single CDROM, single floppy, and servers all into one box. Management module crashed? There went all your servers in that chassis! Want to physically split networks for security purposes? Sorry! Want to burn a bunch of CDs or floppies to flash many boxes in parallel? Too bad!
Not as expandable. What happens when you need multiple NICs, a SCSI controller, a modem, etc, each allocated to a different server? The answer: you don't.
Less serviceable. For example, IBM's lightpath is supposed to be designed to indicate where the problem is on the server so you can make a service call to get the parts in while coordinating downtime. With their blades you have to PULL OUT THE BLADE to see what the problem is! Mostly because there is no front panel to show faults at the blade level.
Density is a myth for real servers. Every SCSI option out there only allows for 7 servers in 7U. With only two disks. Pop Quiz: How many 1U servers can you get into 7Us?
Hot-Swappable is not a new feature. How hot swappable are individual 1U servers?
"Integrated mass deployment tools" are again not specific to blades. There's nothing magical about fancy network-enabled ghost-like tools that operate across a LAN.
"Cheaper" is a myth. $20G for the blade chassis, and $2000 per blade? That's $34k for 7 servers. How much for a 1U server? Times 7?
How can these be fixed? Here are some thoughts.
Drop a PCI slot into each blade with back-end access.
Put a freaking jumper or internal dip switch on each blade to allocate it to different physical networks/ports on the back. Better yet just put separate ports for each blade on the back of the unit- along with a switch- and use something physical to connect the blade to the switch or to the external port.
Put a CDROM and floppy drive on the front of each blade.
Put more LEDs on the front of the blade
Make them WAY more dense- say 24 SCSI servers per 7U.
Of course you're basically approaching "vertical 1U servers". Notice how there's already a nicely engineered solution to all the "problems" that blades pretend to solve?
Thanks for listening to my rant. I have 8 bladecenters in my care and feeding - none of which I had input on for procurement - And I've give anything to swap them out for 1U boxes.
Sorry sir, but your post was a crock of crap. Had to be said.
There's this thing called "fork and exec" which has been out for awhile, which very easily enables an application to scale to N CPUs. Apache for example, will nicely scale to lots of CPUs assuming the underlying OS efficiently does copy-on-write, thread/process management, etc. Solaris does.
If you believe "Oracle didn't scale on Sun E10Ks period", check out the site called eBay. It's the only way they are able to handle the massive workload...
Oracle is pushing clustering now for the reason a previous poster gave- Cheaper hardware means more $$ for licensing, with a static budget.
Lastly your claim about Oracle scaling effectively across 120-240 Linux CPUs appals me. Are you claiming that RAC can be deployed to 30-60 quad-CPU boxes? 15-30 8-CPU boxes? You may be interested to know that 9i RAC degrades in performance beyond 3 nodes- a 3 node cluster performs better than a 4 node cluster. Oracle themselves tout RAC more as an "accessibility" technology that removes single points of failure, rather than a scalability approach. Heck, there are even companies that sell third-party tools to make RAC more scalable...
In conclusion, I do not believe you have any clue with regards to the subjects you are addressing in your post.
Find a local consultancy (ask around, get recommendations, and perform interviews, maybe start with your local sage group) that's full of a bunch of Unix gurus, and contract one or two to act as mentors for about two weeks. Do not settle for anyone with less than about 7 years experience with Unix, and 5 years experience with Linux. Make sure and have a list of tasks (setup an email server, setup a webserver, configure backups, that kind of thing) that are indicative of your needs, as exercises which will help you learn the platform. These folks will be top-notch- do not expect to pay $40-60/hour "Windowz" type rates. For an 80 hour engagement, $12,000 per guru would not be unusual. Negotiate a money-back guarantee at least based on your task list as a set of deliverables. (We do this frequently).
After your two weeks, make sure you contract with either the same company, or RedHat (or whomever) for ongoing escalation support for when you get stuck.
I'm a strong proponent of the mentor approach. I've been on both sides and can attest to the success, IF you have a good mentor. Books are a good reference, and a class is a good generic 'crash approach', but consider how valuable it would be to have a guru or two immersed in your environment, with you and your staff present and participating.
The answer to this is pretty simple, right?- you take a chance, just totally guess.
Of course that's bogus. You have to understand the market (and your product!), well enough to know how many you might sell. Selling hot dogs at a football game? Well, you can look at how many sold at the last 100 football games in the same stadium... If that info is not available, you plan for the worst case, which might be 2 hot dogs for every ticket sold... That's pretty simplistic, but you get the idea.
I should add, I do NOT believe "we can't anticipate the demand!" is a valid argument for arbitrary pricing models, except when dealing with new technology (curiously, software might fall into this category, but fortunately production costs are not tightly coupled to quantity shipped).
I have found Don Lancaster's site to be most helpful on these topics- his paper "The case against patents" is especially interesting. Check it out.
Come on so how do you explain that people are paying 200$ for 256 or 512 Mo iRiver player?
You have a good point, but the numbers are probably better than you suggest.
I got an iRiver IGP100 for Christmas. It has a 1.5gb Cornice hard disk in it. Apparently you can get them for well under $200 after rebate from breast buy.
Is it just me, or does anyone else detect a sloppiness in our current program that didn't exist before? Maybe it's a symptom of the "Me! Now!" generation-X (and now gen-Y) attitude (disclaimer: I'm not even 30 yet).
Yes, but they dont make this fact clear and thus it's what is causing the trouble and uproar. This fact is not CLEARLY defined and can be interpeted in an overly broad manner.
4. REPORTING AND AUDIT. If Customer wishes to increase the number of Installed Servers, then Customer will purchase from Red Hat additional Services for each additional Installed Server.
Seems pretty clear to me. You are not allowed to do any installations that you don't purhase "support" for.
A pretty clear violation of the GPL (restricting redistribution) there.
I've thought about this, alot, lately. We have a lot of clients beginning to deploy lots of Linux.
My concerns are the following:
Advanced server is costly. Paying >$2000/year sure does dispell that "linux is free" myth doesn't it?
RedHat seems motivated to prematurely end support for the previous, non-AS versions. I.e., when the next inevitable OpenSSH hole is uncovered, you have to change your upgrade path after each version is EOL'ed. Perhaps they are focusing more energy on the AS versions...
All the changes that go into the kernel to make it "AS" don't seem to make it into the mainstream as readily. I.e. scheduler, bigmem, etc.
With bandwidth issues, and a "You must use our servers" ideology, I don't think RedHat Network is worth it.
All that being said, I don't know the right answer. Perhaps there is now room in the market for 3rd party support of the "consumer" versions or RedHat.
In such a situation, overclocking turns out to be a losing proposition, because if the processor is overclocked the detection and thwarting system will actually make it run more slowly than if it were running at the normal specified clock speed.
The solution, of course, is to keep the temperature in the "safe" range at the higher clock speed.
Sounds like a pretty fair tradeoff, all things considering.
Slashdot Mirror
The day that two of the most efficiency-bound on-road ICE applications (cross-country 18-wheel trucking and NASCAR racing) switch to automatic transmissions is the day I'll consider one for my personal vehicle.
They're buying off-the-shelf batteries from the same suppliers that build batteries for the rest of the portable electronics industry. Since batteries are a resource intensive product (they're made from commodity materials that must be mined and processed), there is always going to be a fixed cost associated with their production. Here's a free hint: more electric cars being sold will only put more demand on battery manufacturers, and I don't have to explain how supply and demand works.
You are dead-on with with the reflection on the maturity of electric vehicles. They've been around a LONG time.
But regarding battery manufacturing, you may have missed the recent news about Tesla's plans for building the world's largest battery factory this year - it seems that Musk has anticipated your concern:
http://gigaom.com/2014/02/19/t...
This is exactly my description. I have a 12.5 mile commute each way to work and back. I am currently converting a 2002 Ford Focus to full electric. I expect to have a total range of about 40 miles per charge.
The charger I'm using is what I would consider a middle-of-the-road charger, in terms of power consumption (about 4.8KW). It is wired for a 240 VAC, 20 amp circuit, and should be able to charge my 144 volt, 28 KWH pack in about 6 hours. Keep in mind, 4.8KW is less than the steady state power consumption of a typical 1.5 ton capacity heat pump. The grid will trivially be able to handle this kind of load during the night.
By the way, what's the "it" in "It's enough for basic point and shoot needs"? Are you talking about 16 MP??
Yes. The 5D is still considered "prosumer," albeit high-end.
It's enough for basic point and shoot needs (i.e. grandma who uses the $5 disposable and runs down to the 1-hour photo lab at Wal Mart). Beyond that- no.
1. Film resolution is measured by granularity of the crystals used. In other words, MOLECULES. Digital resolution is measured in pixels. Molecules are more granular than pixels.
2. Color saturation of prosumer image capture devices are about an order of magnitude worse than good film. This is why all the mucking about in photoshop, etc is required to artificially enhance digital photos and make them "pop." Even so, in many cases, no amount of postprocessing can correct this deficiency. Remember that rule #1 in photography is "good light."
3. Longevity. What's the longevity of a pixel on digital media? I have lots of negatives and slides, over 100 years old, which still produce very nice prints.
[rant] I'm forced to wonder, did the sysadmin who granted a programmer (one responsible for "small programs," natch) administrative priveledge get fired? How about the manager that signed off on it (assuming a proper change control system)? How about the executive that probably wrote off the proper change control system as "unnecessary overhead"? [/rant]
The backplane doesn't solve the problem, it just moves the problem- to an extra piece of hardware that increases cost and complexity (no doubt every single case manufacturer will insist that their "exclusive" approach is "superior" - look at the current crap with 3.5 and 5.25 slide rails).
I guess you could be careful to route this mobo-to-backplane cable out of the way... But you could (and should) also do this with the mobo-to-drive cable.
I've had exactly the same problem as the OP with SATA cables - the solution is to secure them out of your maintenance path in some way, or as the OP said, check them when you're done.
Drive push into the computer from the front like SCSI drives with SCA connectors Do note that the SCA backplane must connect to the controller or motherboard using, you guessed it, a cable.
SCSI cables, however, don't seem to have this problem, perhaps due to their enterprise engineering pedigree.
SATA, IMNSHO, is just a solution looking for a problem.
Some users have reported anecdotally that Google Checkout mistakenly canceled sales without warning
This happened to me. Ordered a Creative webcam from buy.com and used Google checkout to get $10 off.
A few weeks later I wondered where it was, went to Google's and buy.com's status pages, which reported "Order was cancelled. Reason: Order was cancelled." Great. Did not even receive an email notification. They did postback the charge to my credit card, though.
... Can anyone tell me when there will be a Linux client released?
Surely it can be done.
So the hangover is the problem, not the drinking?
To continue your analogy:
Being an alcoholic, then, is only a problem when you run out of alcohol?
From an engineering standpoint, the concept sucks. Here are a few of my gripes about blades:
- Convergent infrastructure causes issues. Blades combine power, management, network, cooling, a single CDROM, single floppy, and servers all into one box. Management module crashed? There went all your servers in that chassis! Want to physically split networks for security purposes? Sorry! Want to burn a bunch of CDs or floppies to flash many boxes in parallel? Too bad!
- Not as expandable. What happens when you need multiple NICs, a SCSI controller, a modem, etc, each allocated to a different server? The answer: you don't.
- Less serviceable. For example, IBM's lightpath is supposed to be designed to indicate where the problem is on the server so you can make a service call to get the parts in while coordinating downtime. With their blades you have to PULL OUT THE BLADE to see what the problem is! Mostly because there is no front panel to show faults at the blade level.
- Density is a myth for real servers. Every SCSI option out there only allows for 7 servers in 7U. With only two disks. Pop Quiz: How many 1U servers can you get into 7Us?
- Hot-Swappable is not a new feature. How hot swappable are individual 1U servers?
- "Integrated mass deployment tools" are again not specific to blades. There's nothing magical about fancy network-enabled ghost-like tools that operate across a LAN.
- "Cheaper" is a myth. $20G for the blade chassis, and $2000 per blade? That's $34k for 7 servers. How much for a 1U server? Times 7?
How can these be fixed? Here are some thoughts.- Drop a PCI slot into each blade with back-end access.
- Put a freaking jumper or internal dip switch on each blade to allocate it to different physical networks/ports on the back. Better yet just put separate ports for each blade on the back of the unit- along with a switch- and use something physical to connect the blade to the switch or to the external port.
- Put a CDROM and floppy drive on the front of each blade.
- Put more LEDs on the front of the blade
- Make them WAY more dense- say 24 SCSI servers per 7U.
Of course you're basically approaching "vertical 1U servers". Notice how there's already a nicely engineered solution to all the "problems" that blades pretend to solve?Thanks for listening to my rant. I have 8 bladecenters in my care and feeding - none of which I had input on for procurement - And I've give anything to swap them out for 1U boxes.
1886, that is.
Switching-mode power supplies are a little bit newer than that, aren't they?
Sorry sir, but your post was a crock of crap. Had to be said.
There's this thing called "fork and exec" which has been out for awhile, which very easily enables an application to scale to N CPUs. Apache for example, will nicely scale to lots of CPUs assuming the underlying OS efficiently does copy-on-write, thread/process management, etc. Solaris does.
If you believe "Oracle didn't scale on Sun E10Ks period", check out the site called eBay. It's the only way they are able to handle the massive workload...
Oracle is pushing clustering now for the reason a previous poster gave- Cheaper hardware means more $$ for licensing, with a static budget.
Lastly your claim about Oracle scaling effectively across 120-240 Linux CPUs appals me. Are you claiming that RAC can be deployed to 30-60 quad-CPU boxes? 15-30 8-CPU boxes? You may be interested to know that 9i RAC degrades in performance beyond 3 nodes- a 3 node cluster performs better than a 4 node cluster. Oracle themselves tout RAC more as an "accessibility" technology that removes single points of failure, rather than a scalability approach. Heck, there are even companies that sell third-party tools to make RAC more scalable...
In conclusion, I do not believe you have any clue with regards to the subjects you are addressing in your post.
Find a local consultancy (ask around, get recommendations, and perform interviews, maybe start with your local sage group) that's full of a bunch of Unix gurus, and contract one or two to act as mentors for about two weeks. Do not settle for anyone with less than about 7 years experience with Unix, and 5 years experience with Linux. Make sure and have a list of tasks (setup an email server, setup a webserver, configure backups, that kind of thing) that are indicative of your needs, as exercises which will help you learn the platform. These folks will be top-notch- do not expect to pay $40-60/hour "Windowz" type rates. For an 80 hour engagement, $12,000 per guru would not be unusual. Negotiate a money-back guarantee at least based on your task list as a set of deliverables. (We do this frequently).
After your two weeks, make sure you contract with either the same company, or RedHat (or whomever) for ongoing escalation support for when you get stuck.
I'm a strong proponent of the mentor approach. I've been on both sides and can attest to the success, IF you have a good mentor. Books are a good reference, and a class is a good generic 'crash approach', but consider how valuable it would be to have a guru or two immersed in your environment, with you and your staff present and participating.
This link might also help you find good mentors.
Good luck!
The answer to this is pretty simple, right?- you take a chance, just totally guess.
Of course that's bogus. You have to understand the market (and your product!), well enough to know how many you might sell. Selling hot dogs at a football game? Well, you can look at how many sold at the last 100 football games in the same stadium... If that info is not available, you plan for the worst case, which might be 2 hot dogs for every ticket sold... That's pretty simplistic, but you get the idea.
I should add, I do NOT believe "we can't anticipate the demand!" is a valid argument for arbitrary pricing models, except when dealing with new technology (curiously, software might fall into this category, but fortunately production costs are not tightly coupled to quantity shipped).
I have found Don Lancaster's site to be most helpful on these topics- his paper "The case against patents" is especially interesting. Check it out.
Come on so how do you explain that people are paying 200$ for 256 or 512 Mo iRiver player?
You have a good point, but the numbers are probably better than you suggest.
I got an iRiver IGP100 for Christmas. It has a 1.5gb Cornice hard disk in it. Apparently you can get them for well under $200 after rebate from breast buy.
You're forgetting one key fact-
There are no Martians on comets, so there was no one to shoot this one down.
Wait a minute, don't we have math and engineering to deal with all those problems (we certainly did in the 60's and 70's)?
But the units matter.
Is it just me, or does anyone else detect a sloppiness in our current program that didn't exist before? Maybe it's a symptom of the "Me! Now!" generation-X (and now gen-Y) attitude (disclaimer: I'm not even 30 yet).
here ya go:
TerraSoft's briQ
Been around for a long time, based on powerpc (350 or 800mhz G3, or 500mhz G4), 168pin DIMMs, VFD display included, and runs linux to boot!
...for ~$12US + S&H
So your total cost was about $75?
(Geeks who've picked up this keyboard will know what I mean...)
...a variation of a game of postal soccer...
So how does that work, you run around in funny jerseys, kicking round balls and, uh, shooting people?
Interesting that the last great, stable RH is considered too "old" for mozilla...
Or am I just overreacting? I like my 7.3 boxes, dammit.
Yes, but they dont make this fact clear and thus it's what is causing the trouble and uproar. This fact is not CLEARLY defined and can be interpeted in an overly broad manner.
4. REPORTING AND AUDIT. If Customer wishes to increase the number of Installed Servers, then Customer will purchase from Red Hat additional Services for each additional Installed Server.
Seems pretty clear to me. You are not allowed to do any installations that you don't purhase "support" for.
A pretty clear violation of the GPL (restricting redistribution) there.
My concerns are the following:
- Advanced server is costly. Paying >$2000/year sure does dispell that "linux is free" myth doesn't it?
- RedHat seems motivated to prematurely end support for the previous, non-AS versions. I.e., when the next inevitable OpenSSH hole is uncovered, you have to change your upgrade path after each version is EOL'ed. Perhaps they are focusing more energy on the AS versions...
- All the changes that go into the kernel to make it "AS" don't seem to make it into the mainstream as readily. I.e. scheduler, bigmem, etc.
- With bandwidth issues, and a "You must use our servers" ideology, I don't think RedHat Network is worth it.
All that being said, I don't know the right answer. Perhaps there is now room in the market for 3rd party support of the "consumer" versions or RedHat.Of course, I'm just one guy, I could be wrong.
In such a situation, overclocking turns out to be a losing proposition, because if the processor is overclocked the detection and thwarting system will actually make it run more slowly than if it were running at the normal specified clock speed.
The solution, of course, is to keep the temperature in the "safe" range at the higher clock speed.
Sounds like a pretty fair tradeoff, all things considering.