zZorgz

An attacker would need the private key to update the signature in the app cast. It's possible the devs store their private key on the server, although that would be silly.

Although that doesn't discount the recent MITM vulnerability Sparkle had and if transmission is still using an old version of the framework.

This is really bad but there are two good security defenses that came out of that forum thread (which is better than not having them at all).

1. Apple revoked the certificate already. Thus people that have gatekeeper on are safer.

2. Sparkle (for auto updater) denied the malware infected update. Thus downloading from the main website is not necessarily safer, even with the recent mitm sparkle vulnerability.

Apple's code signing actually has this and it's on by default. Don't ask me why it didn't help with their installers, though..

True. Originally yes. If I were them I'd look into changing their logo but alas.

Nitpick: I just don't like seeing the name written out butchered, but it's Wine not WINE (and the latter looks a lot worse IMO)

Better to alter the user defaults key SUFeedURL for an app than break its code signature by altering its info.plist file. Sparkle looks at the user defaults first anyway. Aside it's still not bullet proof because an app can override the feed URL programmatically. Another idea is just replacing the Sparkle framework inside an app with the latest version.

Just to note: if the copy action brings up a dialog requesting what language to pick, then the menu item's name should end with an ellipsis character, as according to Apple's UI guidelines.

Holding command is pretty much the equivalent.

So I took out all the "__unsafe_unretained"'s I inserted and indeed, with optimizations enabled in my release mode, the calls were removed. However, my no-optimization debug build is unbearably unusable like this so I cannot justify making this change.

Good question actually... It was a few years ago; I know I was eyeing through my code using Instruments but I'm not sure if I profiled with optimizations on. I'll have to look back at my code to see if it'd make an impact with them on. Although having your debug build suffer significantly could be a valid concern.

ARC can add automatic calls when not needed (just to be safe). When converting from manual management to ARC for one of my projects I had to resolve performance issues found in tight loops where it inserted unneeded retain/releases.

I'm somewhat convinced the only reason other layouts are easier to learn touch typing is because most keyboards are in qwerty. Learning to type well is still hard. In fact if you typed well already and decided to switch layouts I believe you'll have a much easier time than a newbie.

I learned Colemak earlier this year. After I reached my old qwerty speed I re-learned how to type in Qwerty. As such I can now type in both layouts at my original speed. Typing in qwerty is really not bad; good enough that I don't really recommend others to change layouts or learn another one. I am also convinced an opinion stating that qwerty is terrible coming from someone who still can't type in it well and naturally is somewhat biased.