AngryParsley

Joined 17 years ago

Karma

2,886

Submissions

493

Member since

Sep 14

This account is obolete. Since I can't change my username, I created a new account. See https://news.ycombinator.com/user?id=ggreer for new activity.

My name is Geoff. I write code. I live in San Francisco.

I co-founded https://floobits.com/

Floobits is a real-time collaborative editor (like Etherpad), but with plugins for popular text editors. It's still very much a work in progress.

Personal site: http://geoff.greer.fm/

GitHub: https://github.com/ggreer/

View on Hacker News

Recent submissions

Comment · 13 years ago

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

Comment · 13 years ago

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.

Comment · 13 years ago

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.

Comment · 13 years ago

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.

Comment · 13 years ago

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

Comment · 13 years ago

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.

Comment · 13 years ago

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

Comment · 13 years ago

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

Comment · 13 years ago

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.

Comment · 13 years ago

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

kz_decrypt did exactly what you'd think: given an encrypted string and a private key, return the decrypted string. The private key was only on production servers, so the risk of leaking a secret was minimal. The public key was in source control, so anyone could encrypt a secret. For debugging or testing, one could also replace the call to kz_decrypt with a plaintext string. I wish the code had been released. It was only 100 lines or so.

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.

Comment · 13 years ago

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.

Comment · 13 years ago

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.

Comment · 13 years ago

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

Comment · 13 years ago

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'

Except for a few well-documented edge cases, a properly-built Python behaves the same on OS X, Linux, and Windows. I really hope Jon Skinner gets better at building Python. Dealing with these random platform-specific issues is very frustrating.

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

Comment · 13 years ago

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.