gardarh

Closer to 9 miles (15km). That's plenty (even though it doesn't sound like much), considering what kind of eruption this would be and how the fault lines lie.

Already exists: https://vaxafarm.is/pages/english . They are growing for the local market only.

To be entirely fair I had the exact same problem with a "knob" interface. The variable resistor in the AC knob broke down putting the AC in the "just blow air as hard as you can, always" mode.

With a fully digital solution it should even be easier to provide workarounds for situations like that (e.g. remote screen on your phone). I'm not a big fan of touchscreens in cars though, but this particular argument doesn't feel strong to me.

Reminds me of the time I decided to always start using braces for if statements. I was figuring out why this line didn't work:

  if(condition)
     doSomething()

  if(condition)
    logSomething()
    doSomething()

I spent two summers planting for the Icelandic forrest service and I imagine that is more or less how I and my coworkers looked like (well, somewhat less feminine I suppose). You shouldn't extrapolate too much from the newspaper picture.

It's actually fish, aluminum being a close second:

http://px.hagstofa.is/pxen/pxweb/en/Efnahagur/Efnahagur__uta...

To answer child, the type of electricity production is split 70 hydro/30 geothermal.

A few years back I had a short interaction with Kenneth Reitz. I sent an email about some issue in requests and got a reply within a minute telling me that the issue had been fixed in a release published a few hours prior.

Considering how hugely popular requests is I imagine my message was just one of so many he answered on day to day basis and he did all this without really needing to do any of it.

I guess I understand how he and other people in similar situations get tired of it all after a while. For whatever its worth requests is an amazing project and has made my life easier in my personal and professional hacking.

Well if the official stance is that there is no problem then why should they do that?

I think you're forgetting the cookie warning.

Actually, I think the strictness of python3 with regards to bytes/strings is particularly useful for people who speak English as their first language. python3 will force them into writing software that can work with international strings whereas python2 code written by an English speaking person would in many cases just be broken for the international users.

And believe me, as an "international" person, this is profoundly annoying and has trained me in avoiding using the non-ASCII letters of my language which of course "castrates" the written language somewhat (i.e. When people use non-ASCII letters for folder names I think they are just asking for trouble - how normal is that?)

I love how upfront python3 is with the difference between raw bytes and strings. I work a lot with python and in particular I do a lot of work with serializing and deserializing stuff from/to binary blobs. Due to platform issues that I hope will change in the next year or so I can't use python3 currently but I keep all my code compatible with both and all tests should run with python2 and python3. Yes, I am firmly in the python3 camp :)

pycharm inspection definitely helps with keeping code compatible with 2 and 3.

Generally speaking, if you have physical access to device, all bets are off. Which when you think about it is the point of the whole article.

Huh, the first thing that came to my mind when I saw the name was this thing: https://matt.ucc.asn.au/dropbear/dropbear.html . Apparently forest animals are popular in the SSL implementation writing crowd.

I'm an Icelander and I quite like this article, it is one of the better written pieces I have seen on a cultural phenomenon I relate with - and it is no exaggeration, swimming pools are quite central to our culture. I have two young kids and I take them to an outdoors swimming pool nearly every week, also in the wintertime. Since I live in the capital area we have a few swimming pools to choose from and we rotate between them.

The title hints that this is the reason for the country's high score in happiness surveys such is this one: http://www.independent.co.uk/news/world/europe/denmark-happi... . While I don't think it's that simple I can forgive the author, the title "A survey on Icelandic swimming pool culture" just doesn't have the same ring to it. Usually when I see these surveys the first question that pops up is "How do they measure that?" and it seems journalists generally are not to keen on pursuing that question.

My point is that isolating one thing from a culture and pinning that down as a "cause for happiness" seems a bit silly to me. But apart from that the article is pretty accurate.

Or better yet, build your own: http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi

You'd want to separate that complexity from your kernel modules by using some intermediate, e.g. mqueues, named pipes or shared memory.

I always viewed the cause for slow IPv6 adoption as a lack of incentive - while IPv4 addresses are effectively free then where is the ROI in building an IPv6 infrastructure?

I guess that when IPv4 addresses are traded in a free market it is easier to realise the cost of not adopting IPv6, eventually leading to a faster adoption (which is a good thing for everyone, NAT is essentially making the internet a lot less cooler place than it could be).

Also, what would the alternative be? Just not handing out IPv4 blocks to new players and telling them "tough luck"? Or a lottery? I really don't know a better alternative to a free market.

... and street cleaning is on the 2nd and 4th monday of each month (got towed on that premise once)

That's a really clever site, seems like an elaborate way to say "It depends" when the question is "What is the best country in the world".

Cost reduction being a key factor!

The greatest breakthroughs provide something for the masses at a lower cost than previously possible. An important part of engineering is leveraging existing infrastructure to improve service quality. As an example of this it has been technically possible to put fibre into every home for years but apparently not feasible, price-wise. Speed is speed whether it's copper or fibre.

I think the main issue with fragmentation is dealing with 2.3 (as the article mentions). Now that that's going away it's getting much better very soon so I can't agree that "it is not going to get any better". The latest Android project I'm working on will only work for ICS and newer and I've had very few cross-platform issues (two minor issues that I can think of).

The raspi has a hardware video decoder for some codecs (e.g. H.264) whereas the bbb doesn't. Hence the bbb is not very practical for htpc setup.

Namecheap. Also just bought SSL certs from them and felt the the service was really good.

One thing I'm really curious about: How can you measure the accuracy of the world's most accurate clock?

By definition there would be no more accurate timing device to benchmark it against so is the accuracy cited in the article only theoretical?

They might be running AS/400 as their backend systems, I recently saw a terminal to one of those in a bank and to my shocking surprise the passwords were not even encrypted on that system.

I imagine that passwords are kept in the same database as transactions so I'm not sure the passwords would be the primary concern in the case of a break in.

From what I hear from my co-workers in the quality department (I work in a medical device company) it's even harder to get approval to go through regulation in China than in the US. And you most certainly cannot just base your company from Asia and sell your stuff to the rest of the world (unless of course you go through regulation in the rest of the world).

You might be able to find countries where regulation is less strict or non-existent but I'd imagine that people's trust in medicine in said countries is less than in the regulated ones (as you most certainly would have rouge players abusing the lack of regulation).

edit: Added last sentence in 1st paragraph

I don't agree with that. I'd say don't worry about south if you're just starting out playing with django and willing to manually delete tables every now and then to get make sure your db matches your models.

As soon as you are doing something that anyone relies on and to save you endless effort you should use South, IMO. Even if it's a one-person project (I have a few of those) South saves you both a lot of time and aggravation.

We noticed similar delays at our office (a lot fewer people though). Somehow all the test email we sent seem to have ended in the 1.5%. Odd.

The problem with the battery statistics is that even though an app that is causing battery drain it might not be registered with that app. Imagine an app that sends a 1kb probe message every 15 seconds in the background thus keeping the radio alive the entire time (i.e. never allowing it to idle). I believe that the battery drain caused by the radio usage would count towards "Android System" and not the app when in reality the app would be shortening your phone battery lifetime significantly.

Assigning battery usage to apps is a hard thing as there are so many grey areas. OTOH you will notice apps that are stuck in CPU expensive loops that will not terminate, however this is not that common in my experience.

The Android battery statistics are nice but they usually don't provide me with a useful answer to the question: Which app is really draining my battery.

Yes, and along the road we have accumulated some entropy.

Anyhow, that was a rather crappy answer, the "How much entropy does the "data about a volume in space" have?" answer basically captures it.

You can't really, by definition. By the same logic you should be able to store 1 cubic meter's worth of data storage cube into a 1 cubic micrometer of data storage cube, which in turn could be stored in a smaller cube ad infinitum.

Going by the same logic you could store all entropy of the universe in an infinitely small cube which is not possible unless the universe had zero entropy.