It matters because making an offhand joke parodying a stupid person is something that we've all done. This example shows that if you make a little parody joke like that in the wrong medium, your life could permanently pivot 180 degrees for the worst.
You say that as if it were some kind of moral failing. I bought the version with ads not because I want to be specially targeted by ads, but because it was cheaper and the ads are not intrusive and don't bother me. I use my Kindle to read books, not to get shopping tips. The only reason an ad would annoy me is if it intruded on my attention while I'm reading my book. They can try to sell me pink panties while it's off for all I care. If they're not targeting correctly, that's their problem, and it is no skin off my nose.
just rewrite history for aesthetic reasons, what could go wrong?
I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing your change, how is this not a "rewrite of history for aesthetic reasons"? Do you really need to know about all the tens of little WIP commits I made because I just wanted to back up my changes before going to the bathroom? Am I not allowed to clean up a little bit before I publish all my own changes to the world?
Now if you're just talking about rewriting published history, then nobody is going to disagree with you.
I see the ability to change local history as a huge benefit. Not only can I track changes but before I publish them I can make decisions about how to make them more presentable/understandable to other developers.
Exactly this. I get all the benefits of a DVCS, pushing and pulling from my private fork, distributing development between my home and office machines, never losing changes; and then when I'm ready to publish, I can go back and rationalize my commits (many of which are "git commit -am 'oh sbt'" sorts of things) into a useful history and issue a PR for the rest of the team to code review.
It's taken me a while to come around, but you'd have to pry rebase out of my cold dead hands now.
Sadly, Git users frequently do rewrite published history, by merging branches via "git rebase" followed by a fast-forward merge (i.e. replaying the branch on top of the target), all to maintain that wonderful linear "history". And that's a bad thing because it destroys information about the context in which a change was made. (I've been baffled a few times by apparently bad commits, before realizing they were rebased and did make sense originally.)
If they're rewriting published history, it's even worse than that, because it could change history that you are currently developing on top of, requiring some more advanced git knowledge to get your local repository into a correct state.
I have not found it to happen often though, for two reasons. First, it is widely agreed upon among almost all mildly experienced to highly experienced Git users that rewriting published history is a bad thing. Second, if it becomes a problem with new Git users doing this, you can turn of non-ff updates in the public repository, thereby disallowing this to ever happen, unless you go through all the steps to delete and recreate a branch.
If you're working with your local unpublished history, then it is your responsibility to make sure they still make sense in the context of newer updates from the public repo regardless of whether you rebase or merge. I can see how it would be confusing if people failed at this. I tend to find that more confusion results from people inflating the history with loads of one-commit merge bubbles everywhere rather than just rebasing their small changes.
Version control is one of those annoying admin tasks that you have to do and what to think about as little as possible.
I disagree. Version control as a concept is inherently embedded in every software change you make as part of a team. Every time you coordinate a change with other people, you are participating in a version control task. Your VCS can either capture the inherent complexity involved or it can sit there and force you to hash out the complexities on your own before you invoke it. Either way, you will be occupied by the task of controlling versions of your code.
You don't get it. We don't necessarily want vim to live forever. We'd love for another editor to come along and eat vim's lunch. It's just that in order to do that it needs to take the lessons that vim has taught to heart.
I understand this sentiment, but is there really a way to do this without simply recreating or emulating vim? I can't really think of a way to compose complex, precise actions ("delete the next 4 lines", "undo changes on this line") purely with mouse clicks or swipes like you can with keystrokes.
Every GUI text editor requires a combination of a cursor and keystrokes to accomplish things like this, and they probably will for a very long time.
A text editor that can replace vim would definitely be very much like vim, and it would probably be modal and have very similar if not the same command set. This would be no more a 'recreation' of vim than other text editors today would be recreations of each other just because they all come with very similar actions, commands, and features.
Your theory that the Mom's Night Out movie was panned only because critics thought it wasn't "feminist" enough can just as easily be turned around to say that the Christian audiences praised it only because the movie panders to them. All the praising user reviews I've read come from a very politically motivated and reactionary viewpoint.
This is where your analogy retreats into a kind of magic that distracts from the issue. You magically assume that $1000 compensates the company, the distribution pipeline, and the store for all of the lost opportunity of a missing item. This cost varies depending on how many items there are, what space the item is taking up in the store, where the store is located, the time that the item is being sold, etc. The assumption that this is supposedly all wrapped up in a sum 1/10th of the sticker price, while at the same time trying to use the disparity between that sum and the sticker price as moral leverage for the analogy, makes the analogy seem very dishonest.
There is nothing magic about the process. There is a number that represents the replacement value of the item, and it's computable. I pulled the number $1,000 out of a hat. I don't know what Hermes' profit margin on each item is. I assume its high, in that price >> replacement cost. I use that not as moral leverage for the analogy, but because digital products have a similar situation where price >> replacement cost.
My point is that it's ridiculous to make a categorical distinction between digital and physical goods based on the premise that digital goods have a zero replacement cost while physical goods have a non-zero replacement cost. It makes it seem like as long as a producer is not out the replacement cost, then stealing a product is okay.
I'm not talking about the cost to replace the item. I'm talking about the lost opportunity to sell the item for profit to someone in the target market. You pull $1000 out of a hat, much like a rabbit, but to assume that it factors in the whole opportunity cost of an item that can be sold for ten times that begs the question of the analogy.
Think of it this way. If, during a peak holiday shopping weekend, a thousand people not in the target market descended upon a store and replaced all of the bags with their strict cost-to-eventually-replace amount, this would be a major blow to the company's expected revenue. The same scenario does not hold for digital products. A thousand people could pirate the digital product, and as long as the pirates are not in the target market (an assumption made in these analogies so far), there is no analogous loss of potential revenue.
That's temporarily one less handbag that could be sold for profit to someone in the target market.
I think the 'magic' analogy is still a bit more apt because of the difficulty of quantifying that temporary lost opportunity. Maybe it could be about using your own 3D printer to duplicate a product exactly.
The cost of the drugs was just picked up by the medical system instead of my pocketbook.
I have seen this argument before; American health care is expensive because everybody else is a slacker who can't pay. It's obviously false. US pharma companies aren't subsidizing Canadian drugs, the Canadian government is. That Canadian drug prices are lower is more a function of the broken US medical system than anything else.
i'm using it in the sense of English - its not a specialist term or a piece of jargon. i.e. I mean 'undo', 'revert', 'reverse' - unpick just feels more appropriate because its often a fiddly process if you are doing anything more than a simple revert or back-out type operation.