Forgot your password?
typodupeerror

Comment: Re:electricity is expensive (Score 1) 585

by hawguy (#48003911) Attached to: The Great Lightbulb Conspiracy

LEDs are only expensive if your electricity is free.

Clearly not. If my electricity is $0.01/kWh, then it will take 8.5 years just to pay for a $10 LED. Is anyone paying only a penny per kWh? No, but I just refuted your claim. FWIW, I'm paying about $0.10 a kWH-- including the delivery charges, which people forget about-- so it would take me about a year to pay for a $10 LED. A lot of people aren't getting even a year out of theirs, so you can see why they are upset.

You refuted my claim with a made-up rate that you admit that no one is actually paying? Why didn't you just make up a negative number and claim that the power company pays *you* for energy you consume so LED's actually make you lose money?

Comment: Re:My Compact Flurorscents die (Score 1) 585

by hawguy (#48003669) Attached to: The Great Lightbulb Conspiracy

I repeat the part of my comment that you did not understand "Yeah, most of them will last a lot longer than the printed date, because chances are you won't buy them and install them on the day they make them."

I am talking about bulbs that should have lasted 2 years of constant use, 12 years of actual, use, but I had to replace 8 months after I bought them.

If they had a 2 year past manufacture date guarantee, it would solve my problem.

But to be honest, I did not even try to return the curly bulb 8 months after I bought it. But I seriously doubt a normal retailer would have accepted it's return.

So that is why I want a guarantee printed on the bulb, based on constant use from date of manufacture. To get the manufacturer to stand behind their product, not screw everyone over ridiculously.

What good is a 2 year "sell by" date on a product that the manufacturer says will last 15 years? Does that really provide the consumer with useful information? The buld doesn't age appreciably when it's sitting on a store shelf, so what good is a fake "expiration" date that has no correlation at all to expected lifetime? All it will do is drive up the cost of bulbs when merchants and manufacturers have to carefully control inventory to make sure they don't have bulbs sitting in a warehouse long enough to appreciably affect the expiration date - and merchants may be left holding unsellable inventory as consumers dig through the boxes to buy "expires March 2015" bulbs before the "Expires January 2015" bulbs even though there's no real difference in expected lifetime.

If you're going to ask for a change that makes a different to consumers, why not require merchants to exchange bulbs for X years after purchase, and require manufacturers to do a mail-in exchange for the full advertised lifetime? Purchase date (well, in-use date) is much more relevant than manufacture date.

That said, I exchanged two 6 month old CFL's (expensive high wattage lamps) at Home Depot when they burnt out within weeks of each other, but others from the same purchase were still running fine (and 3 years later, they are still fine)

Comment: Re:My Compact Flurorscents die (Score 1) 585

by hawguy (#48002197) Attached to: The Great Lightbulb Conspiracy

way too early.

I want a required "Good till" date printed on them, that guarantees they last at least X days, just like soda.

Yeah, most of them will last a lot longer than the printed date, because chances are you won't buy them and install them on the day they make them.

But still, if a curly bulb is supposed to last 5 years, and it dies one year after you install it, there should be an easy way to get a refund.

While lifetime is complicated and involves on/off cycles in addition to runtime, a bulb rated to last 16,000/hours will be past its lifetime after 2 years of 24x7 use (but would last 12 years at 4 hours/day). So a simple expiration date is not realistic.

If you gave trouble returning bulbs that died after a day, you need a better retailer.

Comment: Re:migratable vms? (Score 1) 94

by hawguy (#47997789) Attached to: Amazon Forced To Reboot EC2 To Patch Bug In Xen

Not trying to be contentious here, but if you wanted optimal resource usage, you'd be looking more at blade-style compute nodes with no local drives.

Who would you be contentious with? I'm just telling you what Amazon says in their published docs. If you don't believe what they say, or if you think they could do it better you can bring it up with them, or start your own cloud service that does things "right".

But I can tell you that some use cases are perfect for Amazon's model of providing locally attached instance storage since I/O rates are much better than we can get with EBS volumes.

Comment: Re:migratable vms? (Score 1) 94

by hawguy (#47996145) Attached to: Amazon Forced To Reboot EC2 To Patch Bug In Xen

Xen is software, not AWS, AWS is an entire infrastructure, and they can not (or will not) live migrate customer VM's.

They are very clear in their documentation that customers should be able to tolerate VM restarts and to use multiple AZ's and regions to help mitigate downtime. I have several hundred instances scheduled for reboot, but they are doing one AZ at a time.

Since Xen is rumored to be the VM host for AWS (or at least large parts of it), I'd have to think it's "will not".

I can believe it's "can not", since amazon provides gigabytes (or terabytes) of local instance storage for most of their instance types - that's a lot of data to live migrate. Even if the underlying Xen software technically *can* live migrate VM's, that doesn't mean their infrastructure can support migrating thousands of customer instances.

Except that in a cloud, storage is part of the cloud, not part of the server. The only thing that has to physically move is the RAM image of the running VM from one host to another. And it's almost certainly going to be faster to replicate that than to destroy and rebuild it (reboot).

No, Amazon says that instance storage is directly attached to the host machine, so if they live-migrate a VM, they'd have to carry along the instance storage.

http://docs.aws.amazon.com/AWS...

Many Amazon EC2 instance types can access disk storage from disks that are physically attached to the host computer. This disk storage is referred to as instance store.

And there's no evidence that they use any type of shared SAN for instance storage -- instance storage only stays around for as long as the machine is running (or rebooted). If you stop the machine (as opposed to rebooting), or if Amazon has to migrate to a new physical host, you lose the instance store.

Comment: Re:static versus dynamic, access & post proces (Score 2) 178

by hawguy (#47995381) Attached to: Ask Slashdot: Is Reporting Still Relevant?

A screenshot of a report is a poor substitute for an Excel or PDF report where you can copy and paste the data.

This is where picatext or other OCR software comes in handy.

Also... in principle, you could make or use screenshot software which also captures the text from the window shown.

I can't think of a worse use for OCR software than for reporting. "Hey, why are all of the category zero items showing up under category O? And why were all of the accent marks turned into apostrophes?"

Comment: Reports are static (Score 1) 178

by hawguy (#47995305) Attached to: Ask Slashdot: Is Reporting Still Relevant?

When the manager looks at an old PDF report a year from now, he knows that the numbers will be exactly the same as the last time he looked at it.

When he runs a new report for that time period, he has no such assurance that the numbers will be the same or even there at all. "Oh, we reclassified some of the expense categories last month, so the numbers are a little different" or "Oh yeah, when we migrated from the old database 6 months ago, and it was too hard to import some of the older data, so we left it out" or "Oh yeah, we decided that we only need to keep 9 months of historical data" or "Oh really? The numbers are different now? Maybe that's a bug, file a bug report and we'll bring it up with the vendor".

Comment: Re:static versus dynamic, access & post proces (Score 3, Informative) 178

by hawguy (#47995209) Attached to: Ask Slashdot: Is Reporting Still Relevant?

Dashboards & online reports are great when you have access to them. But what if the dashboard isn't available, or you need to provide the data to someone who doesn't have access to the dashboard?

Open the dashboard in a web browser, take a screenshot, export it to JPEG, and send it as an e-mail attachment.

A screenshot of a report is a poor substitute for an Excel or PDF report where you can copy and paste the data.

Comment: Re:migratable vms? (Score 1) 94

by hawguy (#47994425) Attached to: Amazon Forced To Reboot EC2 To Patch Bug In Xen

Xen is software, not AWS, AWS is an entire infrastructure, and they can not (or will not) live migrate customer VM's.

They are very clear in their documentation that customers should be able to tolerate VM restarts and to use multiple AZ's and regions to help mitigate downtime. I have several hundred instances scheduled for reboot, but they are doing one AZ at a time.

Since Xen is rumored to be the VM host for AWS (or at least large parts of it), I'd have to think it's "will not".

I can believe it's "can not", since amazon provides gigabytes (or terabytes) of local instance storage for most of their instance types - that's a lot of data to live migrate. Even if the underlying Xen software technically *can* live migrate VM's, that doesn't mean their infrastructure can support migrating thousands of customer instances.

Comment: Re:migratable vms? (Score 1) 94

by hawguy (#47994355) Attached to: Amazon Forced To Reboot EC2 To Patch Bug In Xen

Amazon doesn't have the capacity to failover all the vm's to other hardware (maybe some but not all or big ones). Or they don't want to bother and force the work on to their customers.

I think you meant "and charge customers for the much larger infrastructure required". Amazon is cheap, and they are clear that what you're buying from them is just a bunch of machines. If you want reliability, use multiple AZ's and regions. Some of their VM's come with a TB or more of instance storage, that's a lot of data to live-migrate when they want to reboot a physical host machine.

If you want live migration, check out Google Compute Engine, but if availability is important to you, you're better off architecting multiple machine redundancy than relying on a single long-lived machine since there are a lot more things than host maintenance that can trigger a crash and/or reboot of a VM.

Comment: Re:migratable vms? (Score 1) 94

by hawguy (#47994277) Attached to: Amazon Forced To Reboot EC2 To Patch Bug In Xen

A lot of people want the convenience of a virtual server, but not the price tag or hassle of several servers and a load balancer. They don't "get" why they would pay for lots of small machines when one big one would do. Once you do convince them to go with several small servers and a load balancer, they don't understand why their FTP changes take a moment to show up online. Then they don't don't want to invest in someone to setup the system with puppet or ansible or the like... The list goes on, but it usually comes down to people not having the money or desire(usually both) to do things "the cloud way."

Most of these small players would be happier with a single 2-drive RAID-1 server in their closet, except they are too cheap to shell out for a decent machine in the first place as well as business tier internet (they usually don't have the traffic to warrant it, but is required for ISPs to be OK with it). $5/month for a VPS is much more palatable, even if what they get is a lot less powerful then they could have in their office.

There's no business tier small office internet that's going to give users the same uptime as a cheap VPS somewhere. No business that wants to maintain a 24x7 internet presence should be running their server on a small server in their closet.

Comment: Re:migratable vms? (Score 1) 94

by hawguy (#47994231) Attached to: Amazon Forced To Reboot EC2 To Patch Bug In Xen

How much longer would it take to migrate the existing vms to patched version. (even if you only have 10% unutilized resources it'd only take at most nine swaps) I agree it's a bad solution to move every machine over night but it's better than forcing an outage.

AWS can't live migrate VM's.

Xen can.

Well, actually, for about 100ms, the system isn't technically running, but the point is that you can bounce a VM from one host to another without rebooting it.

Xen is software, not AWS, AWS is an entire infrastructure, and they can not (or will not) live migrate customer VM's.

They are very clear in their documentation that customers should be able to tolerate VM restarts and to use multiple AZ's and regions to help mitigate downtime. I have several hundred instances scheduled for reboot, but they are doing one AZ at a time.

"In matters of principle, stand like a rock; in matters of taste, swim with the current." -- Thomas Jefferson

Working...