Aside from the arguments others have already replied to, your numbers are wrong by an order of magnitude. 280K/year comes out to 767/day on average. Yesterday 777 people died of Covid, so, roughly, it seems to be doubling the death rate at the moment (not quite true, since we shouldn't compare to average, and maybe some of these people would have died now anyway, but +100% is a closer estimate than an increase by a single digit percentage). Note that the number of deaths/day are still on an increase, and without lockdown it'd have been expected to increase exponentially for a while longer.
Of course, things get even worse when the disease is left unchecked or hospitals become overwhelmed; some tows in the Bergamo province in Italy reached daily death rates that where 6 times as high as the ones from last year in the same time period.
But if we had a large number of undetected cases in the past, then we should also have a large number of undetected cases now, contrary to the study. (Unless we already have herd immunity, but there is no data at all suggesting this.)
It seems the reason the vaccine will take so long (12-18months) to develop is because it needs to be tested for long-term safety which takes a trial with long-term monitoring. As this is essentially a sort of (active) vaccine, how do you propose ensuring it's long-term safety? It seems you'd run into essentially the same problem as with developing the vaccine.
It seems to me that the whole article describes to me an alternative way to find a vaccine . Maybe someone can enlighten me: aren't there vaccines that are simply rather harmless mutations/relatives of the virus but trigger the same immune reaction?
By doing an end run around the regulations. Actually even if you were to follow all the vaccine regulations by choice this would still be faster as it would have already been tested in human. Nature has run the trials for us.
I don't see the point of this. Nature has most certainly not established the long-term effects of this virus, seeing as it has only been spreading in humans for a short while.
Skirting the regulations is pointless, because the important thing is the intent of the regulations. If it were just a problem with the regulations, we could also just change the regulations and give the untested vaccine.
Plus, if you want to argue from a pure legal background, this approach would probably still run into trouble, as in most countries it would be highly illegal to infect people on purpose.
If we wait for the long term we will all get infected and we will all be broke. We need to think differently.
I am not arguing that we should infect people on purpose. If people chose to become infected on their own by hanging out with those infected with an attenuated strain then that is a very different legal question.
Personally I think the result would be the regulatory agency would just rush the use through based on the epidemiology data gathered in the search for the attenuated strain.
Here's what I have trouble reconciling: You say that this attenuated virus would spread automatically -- just like a virus -- and yet no one would be infected on purpose, only if people "chose to become infected on their own by hanging out with those infected with an attenuated strain".
How much agency do I have in whether I get infected or not? It seems strange to me if it depends on the genetic makeup of the virus.
If you were to deliberately go and hangout with someone you know is infected with the attenuated strain then a lot, if you catch it because your neighbour did this then none.
This discussion is really a distraction as I don’t think a “grass roots” spread would be the way any such strain would be spread. I think the regulatory agencies would look at the data collected from the natural spread and use this to approve the strain for use.
Well, in principle it does sound like a possibly "vaccine", but without the long-term testing I still don't see how we can be sure we have found this attenuated strain. Personally, I am youngish (30s) and healthy, so I would probably fall into the core group of those that "should" be infected. But given the choice, I don't think I'd do it, because even now, three months after this virus became big, there is still huge uncertainty about its lethality (even among young people), the number of severe cases (possibly causing long-term long tissue), and how this virus behaves in the long-term: how long would immunity even last? [seems unclear now]. There were also reports from China, and now South Korea, about possible reinfections or reactivations. Under these circumstances, I'd rather pass and keep to social distancing/masks etc. until a better solution comes along or the safety of an attenuated strain has actually been proven through a large scale, controlled trial.
I assume you live in the EU (or somewhere else outside the US), where it is the most natural thing to just send money from your account to another one.
This simply isn't a thing in the US, as I discovered when moving to there for a time. They use third-party apps, cheques, and wire transfers (which are expensive and seem to work via ACH, a pull type system). It's simply not possible to go into your ebanking app and transfer money to someone elses account. (With very restrictive exceptions, e.g. same bank, or maybe the bank has integrated a third party service...)
As inconceivable as the American system is in the beginning for somebody coming from the EU, I guess for many people from the US it's similarly non-obvious that a push system can (and does) exist somewhere else.
They'll forever remain on my mind for their rip-off "lifetime hosting". I paid a lot of money for it, and it was supposed to last while the company lasted. But then they were folded into Joyent and the lifetime deals discontinued (with just a little bit limited time hosting offered in compensation).
I have stayed away from them forever since, and warned everybody I could about their terrible business practices.
A typical olympic pool (assumed 50m x 25m x 2m; the depth actually isn't standarized), contains 2500m^3 of water. 1m^3 of water has a mass of 1t (in typical conditions).
So 10^6 tons of water corresponds to 400 olympic swimming pools. That's quite a lot of water (still not much compared to the volume of the oceans, of course).
> The USPTO initially rejected our application as confusingly similar to
the existing trademark on GitHub, which was filed in 2008. While one
might imagine where the "Git" in GitHub comes from, by the time we
applied to the USPTO, both marks had been widely used in parallel for
years. So we worked out an agreement with GitHub which basically says
"we are mutually OK with the other trademark existing".
> (There was another delay caused by a competing application from a
proprietary version control company that wanted to re-brand portions of
their system as "GitFocused" (not the real name, but similar in spirit).
We argued our right to the name and refused to settle; they eventually
withdrew their application).
> So GitHub is essentially outside the scope of the trademark policy, due
to the history. We also decided to explicitly grandfather some major
projects that were using similar portmanteaus, but which had generally
been good citizens of the Git ecosystem (building on Git in a useful
way, not breaking compatibility). Those include GitLab, JGit, libgit2,
and some others. The reasoning was generally that it would be a big pain
for those projects, which have established their own brands, to have to
switch names. It's hard to hold them responsible for picking a name that
violated a policy that didn't yet exist.
wow... reading the git trademark policy now, it's... surprising:
> While the original idea was to prevent people from forking the software, breaking compatibility, and still calling it Git, the policy covers several other cases.
> One is that you can't imply successorship. So you also can't fork the software, call it "Git++", and then tell everybody your implementation is the next big thing.
This seems like a massive violation of the spirit of GPL... explicitly disallowing official endorsement is one thing (since that would be lying), but you shouldn't be able to stop someone going and doing their own thing and calling it git-something.
The GPL says nothing about branding though. The GPL is about user freedom, the ability to let the user improve (and share improved version of) the software.
In general, people tend to confuse copyright/patent with branding. The former is about using, while the later is about naming. You can totally make the next git-killer, and base it on git. What you cannot do is name it "GitSomething" (regardless of whether it uses git behind the scenes), as that would be a trademark violation.
I personally think the policy makes sense, but I also understand that there might be reasonable arguments either side. But framing it as an "anti-GPL" thing seems disingenuous to me.
> In general, people tend to confuse copyright/patent with branding
I understand how trademark laws work, I'm talking about why this policy is wrong and against how OSS projects work in general. The original purpose (as stated by the policy itself) was supposedly to protect confusing forks of the same name or prevent pseudo successors, but it goes way beyond this to attack anything with git in the name.
> For example, imagine a software project which is only tangentially related to Git. It might use Git as a side effect, or might just be "Git-like" in the sense of being a distributed system with chained hashes. Let's say as an example that it does backups. We'd prefer it not call itself GitBackups. We don't endorse it, and it's just using the name to imply association that isn't there. You can come up with similar hypotheticals: GitMail that stores mailing list archives in Git, or GitWiki that uses Git as a backing store.
They reason this issue as "endorsement"... yet it's so common to have an ecosystem around a popular piece of software where project names are a derivative of the name of the core software it builds upon, I doubt anyone ever got confused or even cared much about endorsement, instead I think enforcement of this policy will just make the relationship and purpose of software built for use with git more opaque to users.
That may be so, there's probably also a whole bunch of people out there who think that Bill Gates invented the computer, it doesn't matter... it's a fools errand to try to eradicate ignorance of outsiders at the cost of disregarding any relationship that is not official and "endorsed" as invalid, i'd go as far as saying it's toxic.
Endorsement is not the only valid relationship between pieces of software, and it's definitely not the most important one. As an example of how bad this can be, git asked gitTorrent to change it's name to remove "git" - how absurd is that, git's protocols are modular, they are intended to be extended, this adds a torrent type protocol to git, it's for git... what the fuck else would you call it:
This "policy" completely disregards this as a valid relationship... why does it have to be endorsed, no one cares, they care about names that clearly communicate their purpose. gitTorrent and a thousand other extensions to git probably aren't going to be as popular as git itself, they aren't going to have enough presence that naming them something completely unique and obscure is going to be useful to users.
[edit]
I just want to say (and then I'll stop ranting), as much as this policy obviously irritates me... I love git, and so was pretty disappointed to find this, it doesn't make me love git any less, but It makes me more wary of people who "manage" open source projects.
> I guess Richard Stallman violated the "spirit of the GPL" when he made MicroGnuEmacs change their name.
No, because he asked them to remove "GNU" and It is not part of or for GNU, does not use GPL and is not a fork (it uses a combination of public domain and BSD licenses)... if he asked them to remove "Emacs" from the name then this would be the same issue - but it's not.
I am not familiar with the details of that discussion but I doubt many people would argue against me when I say it's very likely RMS was against them using GNU in the name of public domain and BSD licensed software due to significant differences in implied licensing, this is completely different reasoning to git's where it disapproves of _any_ implied relationship that is _not_ endorsed.
Also note that the focus of my comment is explicitly on the details of the significant implications to related software that is _not_ a fork or clone.
I don't think it violates the GPL, as the GPL doesn't really care about names. You still have every right to fork git, but have to call it a different name. So if you call your fork "treengler" or whatever, you'd be fine. As far as I can see, you could also still say on your website "Treengler is a fork of Git, that adds/modifies/improves... it in the following way, ...".
To me that seems to be compatible with the text as well as the spirit of the GPL. I think a similar discussion came up in the Debian project with the Firefox trademark at some point. Debian is quite picky about what it means for software to be free, and they seem to be fine with derivatives not being allowed to modify Firefox without changing the name. (At least, I think that was the end status of this discussion.)
Not against the spirit of GPL or free software at all. Governing the use of language and branding to promote software freedom is core to the movement.
The steward of git defining what does and does not have the git nature is completely in line with this. You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
> You want your own take on git? Go ahead, you explicitly have the four freedoms to do so, but don't muddy the waters by calling it git if you don't represent the project.
That was the original intent of the policy and not what I have issue with, but it goes much further than that, see my other comments for details.
Keeping this relevant: GitPub is not trying to replace git obviously.
The GPL exists to preserve the rights of downstream users. In doing so, it restricts the rights of downstream developers and distributors from restricting the rights of their users.
But we could go on and on back and forth about this. I just wanted to make sure the opposing view from yours is present in the thread near your claim.
Of course, things get even worse when the disease is left unchecked or hospitals become overwhelmed; some tows in the Bergamo province in Italy reached daily death rates that where 6 times as high as the ones from last year in the same time period.
Edit: The actual numbers for NY show a more than 2x increase so far, see here https://www.nytimes.com/interactive/2020/04/10/upshot/corona...