AngryParsley

The sad thing about this is that tablets and phones aren't nearly as good at content creation. A physical keyboard is still the fastest brain --> computer interface in town. Also, tablets and phones aren't self-hosting. You can't develop iOS apps on an iOS device. This makes it much harder for inexperienced people to get into programming. Taking the plunge into programming will be like deciding to buy an instrument and learning to play it.

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).

I was part of the Bloglines team from 2007 to 2009.

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.

Although Intel's Westermere-EX was last updated in late 2011, the specs are still pretty good. Those CPUs have up to 10 physical cores (20 virtual thanks to hyperthreading) and 30MB of L3 cache. The clock speed isn't amazing, but that's to be expected when you have to deal with the heat from 2.5 billion transistors.

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

I opt-out of backscatter and millimeter-wave screening every time. I think the TSA is a waste of money and I'd love to see the government take a more calculated approach to security instead of the typical CYA behavior. With that said...

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.

Anecdotes aren't worth much. What matters is statistics. What fraction of those who have corrective surgery regret it? The answer: less than 1 in 20. Most of that fraction includes those who are unhealthy: mainly people with high blood pressure. Those who are in risk groups shouldn't go for it. Everyone else should. The FDA, an extremely risk-averse organization, advocates laser eye surgery [1]. In almost all circumstances, those who undergo surgery vouch for it.

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

I got PRK (epi-LASEK actually) in 2011. It is without a doubt the best money I have spent. Beforehand I was 20/450 in each eye. Now I'm 20/15 in each eye and 20/10 combined. Although the healing process did take a couple of months, it was definitely worth it. If you wear glasses or use contacts, please consider eye surgery. The risk is minimal and the cost is minuscule when amortized over the life of your eyes.

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.

Apple seeds contain cyanide, not arsenic: http://www.snopes.com/food/warnings/apples.asp

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

There's no IV, but the AES key changes each time you encrypt the secret. The key is random.

Good catch. My comment was already rather long, so I didn't mention that the public key actually encrypts an AES key that encrypts the secret. A different AES key is used for each secret. Also if the secret is < 1000 bytes (I forget the exact value), it's padded with random bytes. The encrypted format is something like kz::[AES key]:[encrypted padded secret]. Both the AES key and secret bytes are base64 encoded so they don't screw up parsing or break Python string quoting/escaping.

First: I completely agree. Keeping plaintext secrets in source control is a bad idea. Encrypting them is a good idea. If you have plaintext secrets, encrypt them now using this makefile or git-crypt. Then rotate them.

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.

Can you give us the steps to reproduce? I googled around but couldn't find the bug. I also tried a few different languages and I can't get Terminal.app to crash.

Quick, get ahold of the engineers at Boeing! Tell them to switch to whatever they used on their older planes! Surely they haven't considered that idea yet!

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 know. I was just poking some fun at TextMate. TM2 was delayed by what, 6 years? One can't not joke about that.

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 see ST3 bundles its own version of Python 3.3 on all platforms. ST2 did this on Linux and Windows, and it was quite annoying. In ST2, the ssl module is broken on Linux and the select module is completely missing on Windows. (See http://sublimetext.userecho.com/topic/50801-bundle-python-ss... and http://sublimetext.userecho.com/topic/149231-include-pythons...)

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. :)

It's a very rare situation in which truncation is worse than a buffer overflow. I'd also bet that erasing the destination string is more liable to cause problems than truncating it. For example, the programmer might have pointers to locations in the destination string passed to str*cat. All of a sudden, these pointers are to garbage data.

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.

You make an excellent argument for dropping the GPL and adopting the Affero General Public License. After all, the GPL doesn't force commercial web apps to release their modified source.

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

In his bestselling 1946 book, Man's Search for Meaning, which he wrote in nine days about his experiences in the camps, Frankl concluded that the difference between those who had lived and those who had died came down to one thing: Meaning, an insight he came to early in life.

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.

The last graph amuses me: http://media.npr.org/assets/img/2013/01/22/graph_custom-3939...

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.

The probability of revival varies based on who you ask. SEM micrographs of cryopreserved mammal brain tissue show intact nanostructure. One can even see synaptic vesicles with neurotransmitters in them. Also, Alcor's cryopreservation protocol has been used to preserve and revive rabbit kidneys successfully (http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2781097/).

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'll address it, but I don't think cost is your true rejection[1]. If I was talking about a highly-experimental cancer treatment, I doubt you'd nitpick the price. Doubly-so if you had cancer. In fact, I bet you'd do your best to estimate its effectiveness.

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/

The cost is low enough today that it could be much more common. Even the most expensive set-up (Alcor whole-body, whole life insurance) is about $130/month for a healthy person in their mid 20's. With term life and neuro (head-only), you could cut that in half. Still, only a couple thousand people are signed up.

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.

Good point, but I'm not sure I agree with your second sentence. At every place I've worked at since 2008, most devs used laptops and plugged them into monitors and keyboards. I'm sure other places are different, but it makes a lot of sense to go laptop-only.

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.

Why limit yourself to a $1,000 budget? If you're writing code, that's a small percentage of your yearly income. If a more expensive laptop makes you 5% more productive, it's worth buying purely for economic reasons.

Magazine restrictions are a separate law in most states. California has an assault weapon ban which restricts features such a pistol grips, collapsible stocks, and flash hiders. They have another law restricting the possession of magazines with a capacity of more than 10 rounds. Old magazines are grandfathered in, so you can use them in legal rifles.

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.

Companies make money off life insurance, even though mortality rates tend to 100% over time. It's similar with health insurance. This works due to several factors:

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.

"...very bad style"? That's quite an overstatement. You can enable individual optimizations with gcc. Just add `-foptimize-sibling-calls` to the debug CFLAGS and you're set. Tada! Straightforward code and debug-ability.

It looks like this started around Jan 1 00:00:00 UTC 2013.

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.

There's not much room for improvement. It's a little over 5000 miles from CA to the Netherlands, so light takes about 30ms to travel that far on a vacuum. That means a 60ms round trip minimum. Light in fiber goes at 0.6-0.7c, so the fastest round-trip you could have with a straight fiber line is 80ish milliseconds.

32GB of storage satisfies 18 users? That surprises me. I have 5GB in one mailbox and I'm not much of an e-mail hoarder. Also, what do you do for backups? Do you have offsite backups? How do you search your email? How do you filter spam? What about calendars, shared contacts, and internal document storage? Do you have multi-factor auth and application-specific passwords? Google Apps has a ton of features and it's reliable. Not to mention, it's cheap. Unless your time is worth very little, setting-up and maintaining your own mail server is going to cost a lot more.

People use e-mail constantly. It's important. $50 per person per year isn't a blip on the radar. Do you know how much money you'll lose if your 18 users can't access their mail for an hour? Now consider how much time they'll spend setting up their own mail clients instead of using Gmail. Think of the increased time and frustration waiting for searches to finish. Think of the extra time they'll spend deleting spam. You're paying a lot more than $40-50 for that mail server, but the real cost is obscured from you.

It's a no-brainer: skimping on email hosting is simply not worthwhile.