Comment same here (Score 1) 285
I'm up in the Canadian prairies...farming country. We've got a 1-mile grid road system here too, and we could probably get rid of some of them as well.
I'm up in the Canadian prairies...farming country. We've got a 1-mile grid road system here too, and we could probably get rid of some of them as well.
If it's anything like around here, many of these roads could provide access to fields, not homes.
I live in the Canadian prairies. Around here we have a whole grid of gravel roads (roughly every mile or so). These roads are not for providing access to homes, but rather for providing access to *fields*.
Back in the day farms were a lot smaller than they are now. Since then there has been a lot of consolidation, so they could probably remove a bunch of roads going in one direction (north/south or east/west) but they'd have to leave the roads going the other direction to continue to provide access to the fields.
I worked on a telecom switch that ran processing on cards that had two CPUs in lockstep. If the output of the two ever differed the card was taken out of service and its last transaction was rolled back. Memory contents were stored in at least three places at any given time. The dataplane was inductively coupled to avoid the possibility of DC current damaging things.
We replaced it with commodity hardware and smarter software. It wasn't *quite* as reliable, but it was a whole lot cheaper and the speeds ramped up much faster.
I don't think I'd ever go to the cloud because it's cheaper or more secure or more reliable. The main benefit that I see is flexibility.
If your loads are stable and known in advance, it's likely cheaper to buy hardware and staff people to take care of it. On the other hand if loads spike wildly from one day to the next the cloud makes perfect sense. Need a thousand cores of compute power right this second? Amazon/Google/Rackspace/HP would be happy to rent it to you.
A restaraunt my wife frequents has completely separate grills and utensils for gluten free cooking. That's pretty much fanaticism.
There are people with celiac (I know one) who are *incredibly* sensitive to gluten, so that actually sounds like a really great place for people with celiac to eat at. And even if it's not strictly necessary, it's an excellent way to avoid accidental contamination.
I did kernel hacking for 10 years. I've fixed bugs in Ethernet drivers and helped document (and work around) hardware errata. I've also had to deal with trying to rebuild Nvidia drivers when the binary blob was no longer compatible with the latest kernel source. Having open-source drivers is key for those of us that actually *do* work on this stuff.
We'll have to see what the benchmarks look like, but it has potential at least.
Even without DMA accesses, a USB device can pretend to be a keyboard and type commands into your current session.
I'm rocking a purchased-outright Moto G 2014. Works fine, no hassles, on a cheap no-data prepaid plan that does everything I need.
The reason why this thing uses the front legs for the initial vertical push is that the back legs are shorter than on most running animals. Notice when it's running that the back legs and front legs never overlap, while on an actual cheetah their back legs stretch forwards past the front legs in order to allow the more powerful hind muscles to do more of the work.
Sometimes the bomb squad will use a directed charge designed to shake the crap out of suspicious objects, but without blowing them to smithereens. The idea is to ensure that it can't go off, while still leaving behind evidence that can be analyzed.
and if so, did they reimburse the guy?
For regular typing the "truly ergonomic keyboard" is actually really nice. Symmetric stagger but the rows are not straight...they curve to match finger length.
For coding I found that the punctuation keys (the huge cluster by the right pinky) were moved around too much and it was hard to switch between it and a normal keyboard.
There's a recent post on the openstack-operators mailing list talking about this, but the basic gist is that pretty much all versions of qemu are susceptible to the bug, but that in practice it's not quite as big a deal as it sounds.
The thing to note is that the major linux distros by default enable something called "sVirt" which basically locks down qemu to using only the resources that have been explicitly assigned to it. This should make it hard (ideally impossible) to break out and compromise the host or other qemu processes.
Also, on most major linux distros qemu doesn't run as root but rather as a separate user with lower privileges.
You can measure a programmer's perspective by noting his attitude on the continuing viability of FORTRAN. -- Alan Perlis