Or to put it another way, the "intellectual capital" argument presupposes that you aspire to become a bully yourself, and live among a society of similar bullies. There is no incentivising effect on someone who wishes to innovate without abusing the legal system to stop others from creating similar things.
There are two concepts being confused here: Git branches and what I'll call "logical" branches.
The mutable object in the Git data model known as a "branch" is really just a ref and nothing more. Traditionally it points to a commit, though it could point to a blob or tree or tag object, in which case commit-oriented commands won't work on it (while other commands which wouldn't work on commits may).
A logical branch, on the other hand, is a particular commit, its parent commit(s), their parent(s), etc.—not a sequence per se but rather a tree. The logical branch concept captures the "structure" of the branch. Logical branches are immutable, but new commits can refer back to them to create a new, larger tree.
The logical branch has no intrinsic name, but may optionally be identified extrinsically by one or more named refs, including but not limited to Git branches.
Commands which modify branches generally create a new logical branch composed of one or more new commits referencing zero or more existing commits and also update the Git branch—the ref—to point to the new commit(s). A few commands, e.g. "git reset", update only the ref without creating new commits. It is possible, though awkward, to work exclusively with nameless logical branches and never even create a Git branch referring to those commits.
Contrast this with version control systems like Bazaar where all commits actually do belong to specific named branches, with the branch name recorded in the commit object.
To follow up on this, since we may still be talking past one another, I do not believe that the software design is deficient or that the disconnect between the implementation and actual use is nearly so large as the article makes it out to be. Taking the examples one by one:
> First ask yourself what we mean when we say “is your topic branch up to date?”
Does your local ref identify the same commit as the upstream ref?
> “be sure to fetch the dev branch”
Be sure to update your remote tracking branch ref to match the corresponding upstream ref and download all related commits.
> “what branch did I do that work on?”
Which branch(es) (which refs) point to commits with trees which contain that work?
> “is that commit on the main branch or the dev branch?”
Is that commit reachable by following the parent links from the main branch ref or the dev branch ref (or both)?
> “Has that work landed on the main branch?”
Is that work present in the tree of the commit identified by the main branch ref?
And then there is the last example which isn't even talking about branches in the version-control sense but rather the much older "split path" sense.
The documentation is fine. The way people talk about branches in the context of Git is (mostly) fine. It's only the author's understanding which is at odds with the reality of what branches are in the Git ecosystem. Which could possibly be due to trying to coerce Git into the mold of other version control systems with incompatible concepts of branching.
The current holder of the domains and trademarks was elected as the custodian for a limited time (through the end of 2022). The terms of that election included an agreement to hand over custody to their eventual elected successor. But they've instead created this for-profit company and transferred it ownership of the assets.
What happens when a new custodian is elected by the community who is not affiliated with this new company? Will the company give up control of the assets as previously agreed?
Slow settlement and reversible transactions are a boon for buyers (and for fraudsters abusing chargebacks to get free stuff). For sellers they're a bit of a nightmare since you never know when money you thought you had been payed in good faith might disappear from your accounts with little or no recourse.
> Now, an L2 service could go lower but then they're taking on more risk which they'll want to be paid for and it's basically reinventing Venmo or Square Cash.
It feels like there is a subtle misunderstanding here: Credit cards are at least L2 systems, not L1. Physical cash, the foundational raw-unit-of-account layer most comparable to Bitcoin or Etherium, is the L1. Something like Venmo or Square Cash would be L3, built on top of the credit networks or electronic bank transfers which are themselves a layer of abstraction over transacting in cash.
You do fractional reserve banking with BTC the same way you do it with any other currency: You only keep enough BTC on hand to cover the projected worst-case withdrawals, and take the risk of needing to shut down or possibly declare bankruptcy in the event of a bank run. There is no "lender of last resort" to bail you out, but banks were doing fractional reserve banking long before the creation of the FDIC. It wasn't quite so extreme in the Free Banking era, of course, compared to the state today where no bank holds much more than the legally-mandated bare minimum of reserves.
Of course you also have the option of running an honest bank, one which simply holds its customers money (for a fee) without lending it out, and perhaps offering separate investment products for those who are interested with full disclosure of the risk involved should the investments fail.
It's an open secret that money "in your bank account" isn't actually in your account waiting to be withdrawn—the banks will openly acknowledge that if asked, though it's not something they like to draw attention to in their advertising or when you're opening an account—but they aren't so open about the fact that this practice comes with investment risk, including the possibility of losing any money you've deposited with them, or at least being forced to wait longer than usual to get it back because the bank is having cash-flow issues. (Which, naturally, causes even more severe cash-flow issues for the depositors.) They have the mandatory insurance, of course, but the FDIC is more of a placebo to prevent bank runs than actual protection against systemic issues affecting many banks at the same time. The FDIC can bail out any one bank easily, but if everyone wanted their deposits back there wouldn't be nearly enough to cover the banks' obligations. The only way to avoid bank failures in that scenario would be to print more money, which would drive inflation and penalize those who put their money in less risk-prone, higher-reserve banks.
> due to leaked credentials (in this case the card number + CVV + exp date)
That information is practically public already, since you have to provide it to everyone you purchase from online with your card. If you regularly buy things online with your credit or debit card it's less a matter of if the credentials will leak than when. Regular checking and savings accounts are at least as bad given the existence of Direct Debit, a system where practically anyone can take money out of any account just by knowing the routing number (public information) and account number (printed on every check).
Cryptocurrency aside, just compare that to something like PayPal, where the authorization happens directly between you and the payment processor: the merchant never gets your credentials and can't take money out of your account without your express permission. The traditional banking system has the worst security procedures; the design is reminiscent of the early days of the Internet where plaintext passwords were commonplace in protocols like rlogin, FTP, SMTP, and unencrypted HTTP, when authentication was used at all. The only thing keeping it from complete collapse is the absolute fortune they spend on statistical anti-fraud analysis, which completely coincidentally requires them to have deep insight into every transaction passing through their network. Not that they would ever think of using that immensely valuable data for their own gain, of course. Perish the thought.
In any case, Bitcoin and most other cryptocurrencies weren't built to replace credit cards, but rather to replace cash. If someone steals your cash or you somehow manage to hand it to the wrong person or simply destroy it you can't just call up the U.S. Treasury and expect them to put things right. Holding cash and transacting in cash has its downsides, and yet those same risky properties can be extremely useful if proper care is taken. Escrow and human-mediated reversible payments can be implemented on top of a system of irreversible transactions. The reverse doesn't work; you can't very well run an escrow service where the payer can reverse their payment into the escrow account without following the escrow procedures after getting the goods.
Compared to physical cash, as a digital good crypto has several advantages and a few disadvantages. In the latter category you have the obvious risk of hackers compromising the wallet; IMHO a separate, secure, hardware wallet is mandatory if you keep any significant amount of self-custodial crypto. On the flip side, however, it's not all that difficult or expensive to make your crypto more secure against would-be thieves than the gold in Fort Knox if you're willing to put in a modicum of effort, and the possibility of geographically-distributed encrypted backups makes it much harder to separate you from your money if you plan ahead a bit.
According to the 4th Amendment to the U.S. Constitution, the People have the right "to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures". That is an explicit legal right to privacy, even if it doesn't use the literal word "privacy" in the text.
> If we did some sort of perceptual hashing to each video, would it not be logical to assume we'd all be flagged?
Flagged for what, exactly? The perceptual hash would show that all three of you uploaded the same video, but not that any those uploads were infringing. Nothing should happen unless someone (either one of you, or another party) tries to claim that they're the copyright holder for that video. Which ought to require at least some hard evidence.
Ideally[0], if that were to happen, YouTube would manually investigate the claim to determine whether it was reasonable, and the parties accused of infringement would have a chance to challenge the claim or offer another reason why the uploads are not infringing, such as prior permission or fair use, before anything permanent was done. Since the video is in the public domain, the claim should be rejected and the video marked as public domain in the content database after the investigation to preempt any further false claims.
Of course investigations like this require actual work. It's always going to be easier to just take down the video—especially since they're hosting it for free. Ad revenues won't cover the cost of investigating claims, much less protracted legal fights.
[0] Ideally ideally, copyright would simply be repealed and we'd all be much better off. But short of that…
