Isn’t the copyright specifically for the recordings/streams the league produces? I don’t actually know if it’s illegal to offer a stream using your own camera. Almost certainly against stadium rules, but as you said, they shouldn’t be able to claim copyright in that case.
“History is written by the victors.” - what I immediately thought of.
Heh,
how about forcing LaLiga to show evidence about damages? Because surely everyone who pirated their content would have paid if free streams weren’t available, right guys???
If you want the magic explained, here’s a start: https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch
Huh, really? I thought there were slightly more women than men, but maybe that depends on the economies etc.
As for your second point, yes, exactly. They don’t reproduce. So it doesn’t matter if many men get one wife each, or if a few men get many wives each, the number of pregnancies won’t change, and the number of pregnancy-related deaths won’t change either. So (again), I don’t see how polygyny helps in this situation.
Edit: This first point was wrong, but the second point still stands.
Polygyny wouldn’t solve the aforementioned problem if we suppose that the birth rate of men and women is roughly the same. If one man has many wives, some of whom even die, then several other men won’t have any wives.
Huh, TIL.
Regarding your edit, that amount wasn’t the cumulated cost of whatever Limewire were distributing, that would be idiotic indeed; rather the RIAA tried to call for a ruling that somehow those guys were causing $150,000 in damages - per instance. Now the article unfortunately doesn’t state how they possibly tried to justify that number, and I can’t be bothered to research that myself. Another thing that would interest me is how the plaintiff expected them to pay with almost every dollar on Earth.
So while I don’t think this had anything to do with “lost sales”, I do agree with the possible fines and damage calculations not being fit for any sort of realistic purpose at all.
Sorry, I mistakenly assumed you were talking about disk storage - sure, if you’re designing your own solution, definitely use tags! Although the ones Gmail uses aren’t really portable in my experience, so you’re forced to use their mail client. That, however, is pretty much unavoidable if you’re putting a new spin on established protocols like they’re doing - maybe those changes will get picked up by other clients, maybe they won’t, who knows?
That’s true, but since we’re stuck with the file/folder system for all intents and purposes, you should be able to replicate that behaviour by making those tags part of the filenames (like rent_lease_landlordX.pdf) and searching for (parts of) filenames instead. But yes, a dedicated system would of course be preferable.
Why not just use soft links instead?
There are two different things mentioned here, which I feel I need to clarify:
First, what you said about merging / creating a PR with broken tests. Absolutely you shouldn’t do that, because you should only merge once the feature is finished. If a test doesn’t work, then either it’s testing for the wrong aspect and should be rewritten, or the functionality doesn’t work 100% yet, so the feature isn’t ready to get merged. Even if you’re waiting for some other feature to get ready, because you need to integrate it or something, you’re still waiting, so the feature isn’t ready.
At the same time, the OP’s point about tests being supposed to fail at first isn’t too far off the mark either, because that’s precisely how TDD works. If you’re applying that philosophy (which I personally condone), then that’s exactly what you do: Write the test first, checking for expected behaviour (which is taken from the specification), which will obviously fail, and only then write the code implementing that behaviour.
But, even then, that failing test should be contained to e.g. the feature branch you’re working on, never going in a PR while it’s still failing.
Once that feature has been merged, then yes, the test should never fail again, because that indicates a new change having sabotaged some area of that feature. Even if the new feature is considered “essential” or “high priority” while the old feature is not, ignoring the failure is one of the easiest ways to build up technical debt, so you should damn well fix that now.