jerdfelt

"Lost" bitcoins would just cause all of the other bitcoins to effectively increase in value. It's really only a problem for the person losing the bitcoins and a (small) positive for the rest of the bitcoin community.

It's conceivable that most lost coins will only be lost until the keys can be cracked. Bitcoin keys are extraordinarily difficult to crack right now, but at some distant point in the future, it's conceivable they could be cracked.

IIRC, there are some bitcoins that have been irretrievably lost because it was sent to an invalid key. It's a very small number however.

Hi Vish! When you say "proprietary pieces around the control plane", does that mean inside or outside of nova?

I don't remember which motherboard it was, sorry. Looking at my resume, this was back in the 2000-2001 time frame.

In my experience dealing with a similar bug (see my other post in the thread), the vendors will immediately assume it's not their problem.

They spent a long time "showing" us that a different version of the Linux kernel didn't exhibit the problem so it must be a Linux kernel bug. Turned out the different version just sent data differently so it didn't trigger the same bug with the same data. Other data would have triggered it.

I wouldn't be surprised if the majority of "bugs" they receive reports on turn out to not be bugs in their hardware. There's probably parallels with the reports of compiler bugs, most end up not being bugs in the compiler.

The unfortunate truth is that responsibility of proving it's the vendors bug falls on the customer.

I had to write a proof-of-concept "exploit" to show the problem was with their hardware, effectively troubleshooting most of the problem for them.

I ran into a similar problem with an Intel motherboard about 10 years ago.

We had problems when some NFS traffic would end up getting stalled. Our NFS server would use UDP packets larger than the MTU and they would end up getting fragmented.

Turns out the NIC would not look at the fragmentation headers of the IP packet and always assume a UDP header was present. From time to time, the payload of the NFS packet would have user data that matched the UDP port number the NIC would scan for to determine if the packet should be forwarded to the BMC. This motherboard had no BMC but it was configured as if it did have one.

It would time out after a second or so but in the meantime drop a bunch of packets. The NFS server would retransmit the packet but since the payload didn't change, the NIC would reliably drop the rest of the fragments of the packet.

Of course Intel claimed it wasn't their bug ("it's a bug in the Linux NFS implementation") but they quickly changed their tune when I coded up a sample program that would send one packet a second and reliably cause the NIC to drop 99% of packets received.

While it turned out to be a fairly lame implementation problem on Intel's part (both by ignoring the fragmentation headers and the poor implementation of the motherboard) I have to say it was very satisfying to solve the mystery.

The queue of usage events is an API for collecting usage information, but it sounds like it's not as high a layer as you'd like to see.

There is also the (new) Ceilometer project which sounds like it implements what you're looking for:

https://github.com/stackforge/ceilometer

It is new, so it's probably not as mature as other options, but it has had a lot of activity recently.

I guess it depends on what perspective you're looking for. OpenStack sends usage information to an AMQP queue for consumption. This is generally for use by the provider and not the end-user however.

This is how the currently deployed public clouds collect usage data.

I saw this on my Fedora 17 laptop. Chrome started eating up 100% CPU and my laptop started getting really hot. I tried restarting Chrome, updating Chrome, etc. Nothing worked. Rebooting fixed the problem.

Surprisingly, none of my servers have had problems, but I don't run Java anywhere.

While not exactly what you are proposing, NixOS does something similar. It's not perfect, but it's far from hacky.

http://nixos.org/

In my experience interviewing at Google, the article is accurate. Granted this was a handful of years ago and things may be different now, but I wasn't asked brain teasers and I was asked to code on the white board.

Where my experience does slightly differ than the article, was their use of your academic records. They didn't care about my GPA, mostly because I dropped out of college very quickly and I don't have a GPA to care about, but they did care I didn't have a college degree and used that to justify the offer I was given.

I've actually been looking at Amazon recently and found the number of positions available overwhelming. I think I would do well in dozens of the positions posted.

I don't know if I should be applying to a bunch of positions to get a better feel of which one is "best" or if I should approach it differently.

How would you suggest proceeding when so many positions seem to be relevant?

How about the opposite?

A company I turned down a job offer for has been contacting me every about every three months asking if I had changed my mind.

I just recently told them to please stop contacting me and I'll contact them if I change my mind in the future.

It felt a bit assholish asking them to stop contacting me like that, but I can't decide if that's just my personality having difficulty with it or if there was a better of way of telling them "No".

Shortly after I started a job, I noticed that we had large spikes in our traffic stats. Updates would be sent to customers for various pieces of data on a regular basis. They have previously implemented a simple form of incremental updates, but because of the way it was implemented, it would periodically have to send all of the data again. This was happening about once day.

The spikes were often enough to push the 95th percentile up to an absurd amount. I spent a few days making some changes to make all updates incremental and ended up saving the company about $50k/mo in bandwidth charges.

sys/queue.h

It has singly-linked list, lists, simple queues, tail queues and circular queues.

If you're comfortable with Linux kernel style lists, then sys/queue.h will be familiar, and it's shipping in glibc and on BSD systems (where it was originally from).