AngryParsley

While most people are never going to write software, those who do will be hurt by the drop in PC sales. In the past, PC R&D costs were borne by the general public. Now the public is moving to mobile devices, but developers still need to buy full-fledged computers. Lower PC sales means costs will go up (since R&D can't be spread across as many units) or manufacturers won't develop new features as quickly.

There's some silver lining: the technologies used in tablets overlap quite a bit with those used in laptops. Developers won't be stuck completely in the past, but future PCs might be a little too tablet-y for their tastes. (This is already happening with Windows 8).

The current Bloglines is nothing like the original. It looks like MerchantCircle kept only the name after acquiring it from Ask. The archived feed data is gone, and the current UI appears to be a re-skin/fork of Netvibes. It's a poor imitation of its former self.

The Ivy Bridge version is supposed to ship in Q4. It should have even better performance.

His form of protest is to miss a flight he already paid for and hike/bum rides back to Texas? And asking for donations? This guy is a software engineer at Automattic. He's a WordPress developer. His blog is mostly pictures of vegan meals and unboxings: http://ryan.boren.me/. Considering his lifestyle and likely income, asking for donations seems to be rather poor taste.

Again I agree with his opinions, but his protest is not accomplishing anything useful. The net effect will be to transfer some money and resources from sympathetic people.

I had epi-LASEK in both eyes, spaced apart by 10 days. Even though healing times for my surgery are measured in weeks, I could certainly tell the difference between my corrected eye and my uncorrected eye. LASIK is much more pronounced, since one's vision improves within days instead of weeks.

1. http://www.medicalnewstoday.com/releases/103194.php

There are many small advantages you'll notice with your improved vision. You can decrease your font size and fit more code on your screen. This is equivalent to using a larger monitor, and it works on portable devices. You can wake up and see. I can't properly convey how that feels, especially if you have east-facing windows to catch the sunrise. When traveling, you don't have to worry about logistics related to contact lenses or glasses. It's amazing.

If you have myopia or astigmatism, please please consider eye surgery. You won't regret it.

I agree with your point though. Lots of natural things are deadly. In fact, the most toxic compound known is natural: http://en.wikipedia.org/wiki/Botulinum_toxin

That said, this solution has a couple of issues:

1. It encrypts the entire file instead of individual secrets in the settings file. Encrypted files can't take advantage of many version control features. A small change in plaintext creates a huge diff in ciphertext. Git blame doesn't work anymore. Git diff gets a lot more spammy, since you'll see a diff for the entire settings file if there's the slightest change in it.

2. It uses symmetric key encryption. If a developer knows the password to encrypt a secret setting, they can decrypt all the other secret settings. This is true until someone rotates the passphrase and re-encrypts the file.

To fix both of these problems, I recommend using Keyczar (http://code.google.com/p/keyczar/). If you write the right wrappers, it allows you to encrypt individual settings with a public key. Decrypting them requires a private key that exists only on production servers.

At a past job (Cloudkick), sensitive things in our settings.py looked like this:

  from cloudkick.crypto_wrappers import kz_decrypt
  ...
  BORING_THING = "whatever"
  SECRET_THING = kz_decrypt("kz::xxxx....", "/path/to/private/key")

This set-up would require a some extra work for settings files that don't allow code execution. Still, once you've set it up, it's pretty close to the most secure and convenient way to store secrets.

Have you ever been in a situation where a manager proposes a technical solution that everyone else has already dismissed as preposterous? Now you know how it feels to be on the other side of that.

With that mockery out of the way, I'll give my understanding of the situation: The lithium ion batteries on the 787 are much smaller and lighter than their predecessors. They also take up less space and require different input and output voltages and currents. They have different charging profiles. Swapping them out with an older battery technology is infeasible. It would require redesigning other components to make room, building new transformers and voltage regulators, and writing new software to charge the batteries safely. It would also reduce the range, capacity, and/or efficiency of the 787.

I do apologize if I went overboard with the mockery. Please don't take it personally; it's fun to write.

I actually use TextMate 1.5 more than I use Sublime Text. Unfortunately, TextMate 1.5 was never open-sourced and TextMate 2 broke plugins designed for 1.5. So for me, it is abandonware. :(

I started to port one of my plugins to Sublime Text 3 beta, but basic things are broken. Importing urllib.request raises an exception on OS X:

    >>> import urllib.request
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "X/urllib/request.py", line 2456, in <module>
    ImportError: No module named '_scproxy'

That said, I am a fan of Sublime Text. (Otherwise what am I wasting my time writing plugins for?) It's like TextMate, but cross-platform and not abandonware. :)

strlcpy's behavior is the same as snprintf: return what the length would have been if there was enough room. That way one can recover from the error and realloc enough space. C programmers are used to this pattern.

    //C11, safe version of strcat
    errno_t strcat_s(char * restrict s1, 
                     rsize_t s1max, 
                     const char * restrict s2);

    //C11, safe version of strcpy
    errno_t strcpy_s(char * restrict s1, 
                     rsize_t s1max, 
                     const char * restrict s2);

There are so many problems with this. Yet another slightly different string manipulation function? Why not standardize on one of the already existing ones, such as strlcat/strlcpy? I can see people making some big mistakes with strcat_s, since the size passed is the number of unused characters left in s1, not the size of s1. And strcpy_s can cause a segfault if given an s1max that is greater than the size of s2. Why not only copy up to the first null character?

Also, these functions have the same name as the VC++ functions, but behave differently. In VC++, strcat_s takes the size of s1, not the space remaining. People are going to google for strcat_s, read the MSDN docs, and unknowingly add buffer overflows to their code.

Finally, these functions have annoying behavior. If they hit the limits passed to them, they erase s1. No best-effort. No copy whatever fits. Just destroy the data in the destination string.

strlcat/strlcpy solve all of the problems I've mentioned. See http://www.courtesan.com/todd/papers/strlcpy.html for more info about them. It's sad to see them only supported by *BSD and OS X.

Note: I typically use the Apache 2.0 license for my personal projects, but I don't have strong opinions on the matter.

It's interesting to contrast this with the stories from Nothing to Envy: Ordinary Lives in North Korea.

Yet another gratuitous cruelty: the killer targets the most innocent, the people who would never steal food, lie, cheat, break the law, or betray a friend. It was a phenomenon that the Italian writer Primo Levi identified after emerging from Auschwitz, when he wrote that he and his fellow survivors never wanted to see one another again after the war because they had all done something of which they were ashamed. As Mrs. Song would observe a decade later, when she thought back on all the people she knew who died during those years in Chongjin, it was the “simple and kindhearted people who did what they were told—they were the first to die.”

That book has many tales of people surviving by cheating, stealing, and ignoring the plights of others. That's the real truth: In a starvation situation, nice people die first. A sense of meaning contains zero calories.

Even on a log-log graph, the data looks like a shotgun spread. Species of similar mass have lifetimes that vary by up to a factor of 1,000. Species with similar life-spans differ in mass by up to a factor of a trillion.

If cryonics works, this is the sort of evidence you'd expect to see today. Demanding a revival doesn't make sense, because cryonics relies on the vast gap between preservation tech and revival tech.

I didn't quote the cheapest price. I quoted what I pay. I have no idea how much older people pay for life insurance. If you looked at their website, you'd see that Alcor dues are $800/year. Neuropreservation is $80k and whole-body is $200k (http://alcor.org/BecomeMember/scheduleA.html). This may sound like a lot, but the standard way to pay is to buy life insurance. When you die, the policy pays Alcor. You can see the cost break-down in my GP comment.

Alcor is expensive. Cryonics Institute is the budget option. CI dues are $120/year and whole-body preservation costs $35k. CI members usually pay with life insurance as well. CI can charge less because they have less staff. Their research budget is practically zero. Most importantly, they won't camp at your deathbed. IIRC, Eliezer is signed up with CI and pays around $300/year. That's the cheapest price possible.

It's often said that getting cryopreserved is the second-worst thing that can happen to you. Cryonics gives you a small chance of living a much longer life. I'll be the first to admit that it's highly unlikely to work. But for myself and many others, the expected value calculation heavily favors signing up. After all, consider the alternative: You die slightly wealthier.

1. http://lesswrong.com/lw/wj/is_that_your_true_rejection/

Alcor has published a cost break-down http://www.alcor.org/Library/html/CostOfCryonicsTables.txt and explained it at http://www.alcor.org/Library/html/CostOfCryonics.html

A big chunk of cash is spent keeping a team on-site while waiting for the person to die. Assisted suicide for the terminally ill would help reduce costs significantly.

Except for GPU performance, modern laptops are pretty much on-par with desktops. Laptops cost more, but people with desktops usually own laptops. Having two machines creates the annoyance of switching between them. It's small, but it's there. For most devs, it makes more sense to buy one really nice laptop instead of a nice desktop and a mid-range laptop.

My current set-up is an 11" Air that I connect to a 27" screen. If I want more real estate, I could buy another 27" display and chain it. It's stupidly fast: 2Ghz Core i7, 8GB of RAM, 256GB SSD.

Oh and while I enjoy using big screens, I find my most productive times are when I'm on a plane. The lack of distractions and the knowledge that I won't be interrupted for hours helps me stay focused.

I don't want to come across as insulting the intelligence of everyone who doesn't buy expensive laptops. The right combination of environment, mindset, and knowledge are worth more than any fancy hardware. When it comes to tools, use what you love and don't pay much attention to cost.

It looks like the law is similar in DC. Possession of a magazine with >10 round capacity is a crime. Other firearm laws are irrelevant to the case you linked to.

1. Insurance companies can invest payments from young people to cover costs when those people are older.

2. Not everyone gets old and sick. Healthy people who die in car accidents contribute much more than they take out.

3. While many people get old and sick, medical costs vary significantly and aren't very predictable for a given individual.

4. People are risk-averse. They would rather pay $1,500 every year than have a 1% chance of losing $100,000 in any given year. This is true even though 0.01 * $100,000 = $1,000 expected loss per year.

I wonder if it's related to the leap second bug discovered in July. Apparently, a some popular NTP servers incorrectly sent out leap seconds at midnight. Even if it's not that specific issue, I bet the root cause is a time-keeping bug.