Notices by Matthew Miller (mattdm@hachyderm.io)

@killyourfm

Oh, wow, yeah. Right to 1997 or so.

@vkc

Most cars these days do pretty much exactly this.

@killyourfm @Linux4Everyone @nextcloud

Or maybe https://forgejo.org/docs/latest/user/project/ but I haven't actually used that.

@mcc

There is a new `--update none` option to get the old noclobber behavior, if you want it.

tbh I'm surprised 1) they made what could be a breaking change and 2) to my knowledge there has been no "you broke my scripts" outcry. Although probably the second can be found if I look hard enough.

Also, apparently posix only specifies -i and -f. Because, sure.

@mcc

Update to (at least) coreutils 9.2, or use a distro which provides that.

With that version, mv -n will print an error and return 1 if a file is skipped. (Previously, it just printed nothing to indicate it was doing nothing. Insert Drake meme here.)

@mcc

IMHO good for the coreutils maintainers for making some of this stuff make more sense after all of these years.

But I'll wait for the "they hate Unix!" crowd to show up.

@ljrk @mcc

Also this explains the `mv -n` silence when I tested on RHEL 7. :)

@ljrk @mcc

Haven't tested, but I believe that's been fixed since 2015. From the release notes for 8.30 (2018):

``` 'mv -n A B' no longer suffers from a race condition that can
overwrite a simultaneously-created B. This bug fix requires
platform support for the renameat2 or renameatx_np syscalls, found
in recent Linux and macOS kernels. As a side effect, 'mv -n A A'
now silently does nothing if A exists.
[bug introduced with coreutils-7.1]
```

@ljrk @mcc

Meanwhile on LWN... https://lwn.net/SubscriberLink/979524/f93c7f46307f3415/

@ljrk @mcc

Anyway, everything is terrible.

*switches to plan9*

@mcc

It seems like one of those things where it's going to happen *to* you without any permission — the only "opt out" you have is to not get benefit from it yourself. Like how you can "opt out" of TSA biometrics.

@gordonmessmer Anyway, as far as open core companies go, Gitlab is probably the gold standard. https://handbook.gitlab.com/handbook/company/stewardship/ is pretty solid, really.

@gordonmessmer

Too far outside of RH core competencies to be successful, I think. But, we should have spun it off into its own company ten years ago.

Gitlab's source-available proprietary model for "open core" is _worse_ than keeping that code secret, because it serves to poison community implementation of similar features.

@clacke @shanecurcuru

And I don't think all upstream projects use that exact definition consistently.

@clacke @shanecurcuru

Thanks — it makes sense using those definitions. (It isn't the definitions we use in Fedora.)

@shanecurcuru

Also: "adds contributors to become maintainers" doesn't make sense to me. Can you explain what that means and how it relates to governance?

And: a nonprofit foundation could own a brand and use and license it in a non-open way (and indeed, this is common — see Mozilla and LibreOffice). Conversely, a for-profit corporation or government entity could own a brand but have some form of open licensing or governance.

@shanecurcuru

"Apache" is another prominent example of non-open trademark control by a non-profit foundation.

@shanecurcuru

It's not *bad* — it's just not _open_.
https://apache.org/foundation/marks/faq/#products

(See also the "iceweasel" thing.)

@shanecurcuru

> Trademarks can't really be open the same way code is, but they can be managed for the public good, not for profit.

That's exactly my point. I don't think that's related to openness _per se_.

Also, I think that it is possible for entities other than non-profit to mange trademarks in this way.