From what I can tell, the only actual change is that the current rule says "two" instead of "two or one" in the last part about what happens if some Commissioners are disqualified with respect to a matter.
Sounds like the old Steven Wright joke about having a switch in his apartment that didn't do anything, he kept turning it on and off and nothing happened. Then a guy in France called him and said, "Cut it out."
The condensate (water vapor that gets condensed out of the air in the process of generating the electricity) has to go somewhere; if it's not properly handled, yes, I would expect mold.
More like Mission: Impossible. Replete with a mini-doco about how Tom Cruise literally for reals skydove out of the Blackbird without a chute and landed on the enemy rocket in one take.
Sure, and then have it break again the next time upstream pushes a change. Or have something else break because upstream doesn't care about breaking things that I'm relying on.
The only way to "fix" this from a source code perspective would be to fork Neovim.
It's worth pointing out that vim is not "another program" as far as Neovim is concerned. It's an earlier version of the same program. Neovim is a fork of vim, not a totally different editor that happens to share part of a name.
It absolutely is another program, I can tell this because it has a different name. To run it I type "nvim" instead of "vim". I use different config files to control its behavior. I install a different package on my system when I want to use it on a new computer.
There is a flip side to this - is vim encrypting this data it keeps forever? If I delete something I consider sensitive, I might unwittingly be recording that presumed-deleted piece of data to my user profile somewhere to be deleted never.
How could you possibly encrypt it in a way that holds water? Any attacker who cares enough to get your undo file can also get your undo keys, unless you want to wire a whole system of undo-now-requires-password-auth-with-MFA
It's a feature most software doesn't even have, and it is off-by-default. If you rely on your undo history to store "important data", you are doing something horribly wrong - to the level of storing your critical emails in the Trash folder.
Persistent undo exists to recover from an accidental write-and-quit mid-session nuking some stuff you really didn't intend to delete. If you care about its contents beyond a handful of hours, you either need to adopt proper version management, or start making backups.
Reading the PR the change was needed because the old undofile format was fundamentally broken. They considered making an undofile-upgrade mechanism, but it would've caused more issues that it would've solved. In other words: stuck between a rock and a hard place.
A duty of care also means occasionally having to break things to make it better, or else you end up being stuck with spacebar heating[0] forever. As a user it does suck, but that's the price you have to pay for using actively-developed software.
> Persistent undo exists to recover from an accidental write-and-quit mid-session nuking some stuff you really didn't intend to delete.
That's one use case, sure, but not the only possible one.
> Reading the PR the change was needed because the old undofile format was fundamentally broken.
That's a good reason to have a new undo file that's completely separate from the old one, and use the new one instead, and tell users "Hey, whatever undo information you had in your old undo file isn't accessible any more through neovim, you'll have to use vim if you need to get to it."
It's not a good reason for just deleting the old undo file with no warning. All the new version needs to do is ignore it, not nuke it.
User data shouldn't be silently deleted just because you think they aren't worthy enough. Especially when the name of the feature, persistent undo, and the docs explicitly promise that the edit history will be preserved.
That's completely false and also irrelevant to the point I made. Even if true, it doesn't justify deleting user data in direct conflict with what the docs say.
This gift comes with the following clauses listed plainly in the license file:
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
It's genuinely mind-blowing to me that software can do something obviously bad, someone can point it out, and then someone will link to the license file to say they have the right to do it.
That's such an obvious category mistake that I'm not sure how to respond. It almost feels like a bad-faith interpretation of Wichary's original point.
Right. It is weird that this has to be explained, but let's make it clear: in the Before Times, probably anytime up to at least the late '00s, probably approximately no-one in or around free or open source software would have endorsed the idea that the legal disclaimers completely free even the most mainstream, self-publicising, broad-userbase open source projects from any moral or ethical obligation to have even the slightest concern to ensure that their software doesn't hurt or betray its non-paying users, even in the most harmful ways. And if one of the many and often vocal FOSS opponents of the time had started claiming that this is what open-source developers really believe they'd have rightly been seen as having veered off into the lunatic fringe. And that's because it's a, frankly, bonkers idea which is radically detached from normal human understanding of the social and moral role and obligations of volunteers, voluntary organisations, charitable givers or gift-givers. And also because it's a wildly counterproductive idea to put out there if you're hoping to increase FOSS adoption.
That does leave the question of why this idea has started to take off more recently. Part of the answer is certainly that Rich Hickey, disgracefully, set the ball rolling in this direction, and that many others have welcomed it as one weird trick and one pat answer for all the worsening problems of developer burnout. Unfortunately it seems hard to dismiss the idea that it's also social breakdown driven by a broader trend, as over time we move further and further from the pre-'60s "neurotic society" of people obsessed with duty and social conformity (often with oppressive or destructive results, to be sure) into the "psychopathic society" in which even people who don't themselves merit a Cluster B diagnosis have internalised narcissistic and psychopathic attitudes.
Equally mindblowing that folks feel someone hacking on open source software has an obligation to do anything the way they feel it needs to be done when the whole point is that anyone gets to do more or less what they want with the code.
They get to do more or less what they want with the software, and others get to say more or less what they want about that. What's wrong with deciding they've crossed a line, being bothered by that, and warning others? Nobody's trying to get the law involved, or maliciously retaliate against them, or anything like that.
I think you are objecting to OP’s “duty of care” wording which could be interpreted as suggesting a legal obligation. Nobody in this thread is really arguing that open source developers have a legal obligation to do this and to not do that. We are just saying they should do this and should not do that.
"Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE."
Unclear? The fact that it's part of a license does not make it a legal-system-only warning.
The software might eat your dog, and feed your homework. Run it at your own risk, and be prepared to submit patches or fork it to make it behave the way one prefers.
This is one of the most exhausting (and frankly, exhausted) recurring arguments that comes up over and over again on HN.
Some bit of open source software does something bad or unwanted which causes people point out that it shouldn't do that bad thing. In this case, not even "the authors of this software should be held liable for the software doing the bad thing", just, "Hey, the right thing to do would be to update the software to not do the bad thing."
Why does this always lead a zillion people to come out of the woodwork to point at licenses and warnings or whatever? Like, yes, there's a warning. Your software having a warning doesn't mean people can't criticize you and your software for doing bad thing. Your software license does not give you immunity from criticism or from people saying you should change your software.
No, you don't have to change the software. Yes, other people are within their rights to fork the software themselves. But they can also point out that they told you that your software was doing the bad thing and you didn't fix it or change it, and that as a result they don't like you or your software or both — whatever. Nothing at all wrong with that.
I actually think you framed it really well. No parties involved have any particular obligations to each other. Nor should there be expectations otherwise without support. It sucks to lose data, everyone knows that, and no one wants it. And identifying things which can be improved is important. I stop at expecting someone else to do something because I want them to. I might hope they would, and try to convince them.
The software might eat your dog, and feed your homework
Sure, and when it does we can say “this piece of shit ate my dog, and the authors of the software have no concept of a duty of care to their users”. And no amount of “well, axually…” is going to make any difference. I have a hard believing someone is copy-pasting a license file in good faith in response.
Most open source software is written by individuals who aren't paid for the effort, and are solving their own problems. Presuming that they feel an obligation to the folks who download and use their work for free seems... bold.
If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.
> If my neighbor mows my lawn for free, I'm not going to complain about his workmanship. If I want the job done a particular way, the solution is to do it myself, or pay someone to do it the way I like.
I think this is a decent analogy, but it works better the other way. If my neighbour offers to mow my lawn, I accept, and then he destroys the flower bed adjacent to the lawn, I will be upset, and I will have every right to complain about what he did. If he reacts by blithely dismissing my concern, then I certainly have the right (and arguably the obligation) to warn others that they should think twice about accepting his offers of gardening assistance.
Some expectations reasonably go without saying; "don't destroy my flower bed when mowing my lawn" is one, and IMO "don't destroy my data without a clear warning and a chance to back out" is another, though of course we might disagree about exactly where this does and doesn't apply.
Suppose that you build a childrens' slide in your front garden. You put up a big sign saying "Consider using my slide! https://neovim.io/ Here are several wonderful things about it. It's free for everyone!" in your yard. Underneath in smaller letters you add "[No liability]". You also put up noticeboard ads for your free kids' slide in neighbourhood shopping malls https://launchpad.net/ubuntu/+source/neovimhttps://wiki.archlinux.org/title/Neovim . Unfortunately, when you built the slide, you left sharp metal edges and corners sticking far up on the inside, reaching into the path of the user. No reasonably competent and diligent metalworker or slide-maker would have failed to notice these major flaws or failed to understand the serious danger they represented. Several neighbourhood children use the slide and receive serious gashes to the legs, arms or face, and have to go to the hospital. Even assuming that your no-liability small print somehow had you free and clear legally, do you believe that your behaviour would have been ethically and morally above all criticism? Do you think that "should have read the small print!" or "can't I build what I like in my own front yard?!" would have you covered? Do you think that your family and friends would agree?
If my neighbor mows my lawn and ruins my whole garden, I'd definitely complain. (And if I were in the neighbor's shoes, I'd feel awful about it and try to fix things.)
If my neighbor mows my lawn for free, and in the process mows my flower garden down, things change a bit though don't they. That is a closer analogy. In that case I am going to complain, and maybe also tell everybody he's careless and not to let him near their lawns.
There's a long literary tradition of representing contracts as a tool of villainy. Signing them is generally treated as a Faustian bargain.
This is a great example of why. Most humans have a sense, deep down, that contracts often exist to bridge the gulf between the ethically defensible and the legally defensible.
It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."
It's true that contracts with liability limitation clauses like this are an absolute necessity in this day and age. But there's also a non-legal principle of mutual respect that is absolutely necessary to a healthy open source community.
> It's hard to imagine that any sane person who is just looking to use a popular editor would read some broad limitation of liability language like the above, and interpret it to mean, "By the way, we intend to quietly delete certain files created by a competing fork of this project whenever we find them."
Forks of projects trodding all over each others files is one of the more common problems that has happened, historically. Prior to the major efforts around freedesktop.org around configuration standardization, it was quite common. It'd be one of the first things I looked for when switching to a fork.
I’m not saying it doesn’t happen. I’m saying it shouldn’t be defended as good. It’s a defect. And in this particular incarnation it’s a defect that directly clashes with fundamental Free Software principles such as personal digital sovereignty.
I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons. How many people would defend Microsoft if a new Office version automatically and quietly stripped edit history from documents that were originally created by other versions? Would we be hunting for limited liability clauses in their EULA to defend the design decision?
> I also suspect that few people actually believe it’s ok and these legalistic defenses are more about circling the wagons.
For me it's more about healthy boundaries and expectations. If I'm somehow paying for a project's development, I have higher expectations. If I'm not, I understand that I've chosen the dev/test track and there will be bugs and issues. The developer may choose to run off in an odd direction coughGnome3cough and my only recourse is to fork or hope someone else does. Disagreements as to how things should work happen pretty often.
I'm not defending anything or anyone. Just describing the system as it exists.
According to TFA, it was completely intentional that they deleted someone’s data that had been created with a different program. Otherwise they would have acknowledged it was a bug. I do not know if this is true, only that it is what TFA claims.
It’s not great that Neovim destroyed/replaced files that aren’t clearly under its purview. They should have probably also made the consideration that a lot of Neovim users are going to be migrating from Vim.
Maybe if they’re making their own persistent undo standard, use different file naming conventions.
That said, as a fork of Vim, maybe the Neovim authors are at least partially reasonable in assuming that you’re not running multiple forks of Vim that could then potentially conflict with each other. It just sucks that they never really thought of a migration path for this particular feature.
Holdovers from showing the case (function in the sentence) of pronouns with inflection, which has mostly vanished from English, but not completely. The "mostly" just means we get extra confusion from different cases having ended up with the same form (as in the two different meanings of "her" below).
"It was him -> it was her" -- both are direct objects (at least as you're using them here--once upon a time the correct English would have been "it was he -> it was she", since the verb "to be" is not a transitive verb, but that seems to have gone out of fashion).
"It is his -> it is hers" -- both are possessives, but they're not directly modifying anything (they refer to "it", but the verb is in between).
"It is his thing -> it is her thing" -- both are possessives, but now they are functioning as direct modifiers of "thing", which is a different usage.
I don't know if there is a fully specified algorithm for determining these things, and even if you got one that worked in English, I don't think it would map very easily to any other language, because English is such a hodgepodge of things cherry picked from various languages over the centuries.
reply