My first thought was "maybe we should back up and emphasize that resources are nouns before going further", but if you scroll up you'll see that this was actually the original question asked (how do I avoid naming them with verbs?).
2,354 karma · joined August 8, 2009
https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
The documentation recommends changing tmux's default command, but if that weirds you out, a simple alias to "reattach-to-user-namespace pbcopy" also works.
Capitalism won, try it.
I can see relearning C for copy, as it's logical and would reduce the burden of switching between normal Mac/PC applications, but having J mean copy because that key would have been C in QWERTY is just too weird. I think about lots of Emacs bindings mnemonically: C-b, C-f and friends, obviously, or C-c because that's just the "bindings having to do with this mode" key, and you see it a lot when you read documentation -- in my head, it's a letter, not a physical position. I touch-type Dvorak pretty fast, but two-finger type it very slowly, because in my brain the letters are wired to finger movements starting on the home row.
A possible reason for this is that he has an "inverted T" for cursor movement (but on the left hand, like vi, not WASD like I believe PC gamers would be used to). If your set of cursor keys is based on the physical layout of QWERTY, like vi, it doesn't translate all that well to Dvorak (vi manages to be not horrible since J and K stay next to each other, but in this proposal J and K are not on the same axis), but if they are mnemnonic, like Emacs, there's no problem.
If the idea is to fit better with what the vast majority of "normal" people expect computers to work... well, normal people use the arrow keys. Telling them an invented abstraction is better because they don't have to move their hands from home row isn't going to sell them, I think.
<script src="//goo.gl/OCK7V"></script>
People still want music. They never wanted the music industry.
If the secret police starts breaking down your door, just calmly shuffle the deck. (Don't throw it up in the air; you'd be surprised how much of the deck ordering is maintained during a game of 52-Pickup.)This is a really sad state of affairs. If Google can't guarantee that their fancy new Javascript-dependent links won't work everywhere, they should not be used as permalinks.
I really don't care about any arguments people might want to make about the visual redesign, or how to properly implement #! paths, or the extra effort involved in generating resilient URLs, or Google paying special attention to how the Android browser handles pages, or what evil things my phone company might be doing my my data stream, and how that's not their fault, or whatever. Permalinks should work. Everywhere. Period.
long_struct_name *foo = malloc(sizeof *foo);What would an honest Android-app allegory for this be? Perhaps a consumer is faced with these options:
1. An official shop, which accepts money (yay!), gives only some (boo!) of it to the artist, and offers:
a. The source code to build the app (i.e. a plastic disc that you have to rip yourself)
b. maybe, sometimes, a version of the app compiled for a 320x480 screen (acceptable lossy compressed files)
c. maybe, even fewer times, a version of the app compiled to use any screen size (lossless files, or high-quality lossy or whatever you like)
2. A dodgy (boo!) pirate site, which doesn't accept money (boo!), and offers all of the compiled versions.
Of course this is not even close to reality. No Android apps are compiled by normal end users. All paid Android apps offer 1c. Music piracy does not exist because of religious "information must be free" nuts like this article is talking about -- it exists because people's moral feeling about getting some money to the artist is not strong enough to overcome the inconvenience of 1a (or even 1b). Maybe we should conclude that the analogy has broken down.
Society does not "accept" this sort of piracy like it's a binary switch. The "morals" curve slides down, the "inconvenience" curve slides up, and at some point they pass each other. I see no reason why they can't trade places again -- if we actually try to do something about it instead of spinning clever allegories.
I suspect we need to look elsewhere to understand the motivations of app pirates (yes, I know this was not the point, but if you're going to be facetious...). The real thing is right there, for a few dollars. I've already given Google Checkout my credit card information. I cannot fathom what would make someone deal with sketchy sites (sketchy sites whose entire purpose is to install executable code on your device) to get the same thing they can just pay for. Maybe they are in fact just religious nuts.
[0] Honestly, I can't even be bothered to pirate most things these days. I'm culturally behind because filling in the gaps in what I can actually buy in FLAC would be a part-time job. If a record shop so much as rejects spaces in my credit card number I get bored and go listen to something I've already bought. This is a problem that could use some, as they say, disruptive innovation.
.vspii {
display: none !important;
}
http://en.wikipedia.org/wiki/Arbitrage
While the 4th credit card company he applies to has imperfect information about what his credit is (at that point) actually worth, it seems like all the deals are independent.
It's a difficult problem: what's better for free software? Sticking to our principles of open development even for assets, or ensuring that potential new users see a high-quality, finished product? I don't know the answer.
For many depressed people (at least myself), changing their broken neurochemistry with drugs, ECT or both is a necessary but not sufficient condition to identifying and attacking the causes of their symptoms. It's not an either-or choice, and despite lingering stereotypes that your statement seems to imply, no kind of clinical treatment (even ECT!) is intended to just numb you to those symptoms.
What always using fast-forward merges really means is that you rebase each branch onto master once it's ready to be public. Therefore, instead of resolving conflicts when the branch is merged, the commits are rewritten to avoid introducing the conflict in the first place.
Sometimes, this is really simple -- I added a line in one spot, you added another line in the same spot, you merged first, so I rewrite my commit to add my line next to yours instead of merging and resolving the conflict. Sometimes, it's not -- maybe there's not even any text-level conflict, but your feature and my feature interact in subtle and unanticipated ways and something breaks. Now, there's no "good" point in my branch to refer to, because I rewrote it on top of something where (I didn't realize) it was never really going to work. The unit test I now need couldn't have existed because it involves things that, when I was developing the branch, didn't exist.
Rebasing first is trading off when you do that work. There's more to review when the branch is ready, and there's a stronger incentive to get it right the first time. I think this may work better for the "two founders deploying from master when they feel like it" scenario -- you pay for manageability with context switches. If you have a formal QA process, I think being able to distinguish between "this branch failed QA" and "the combination of these branches failed" may be more helpful -- you can parallelize work and hack on a different private branch.
Git, thankfully, does not force us to choose one model or the other :-)