Part of the problem is the way that policies like this one are written.
They're saying things like "may not do that" and "cannot be used unless ...", when what they really mean is "we're not granting any special permission to do that", and "cannot be used unless ..., in cases where your local trademark law says you need our permission".
It's not entirely a new thing for Rust, at any rate. The current trademark policy [1] is very similar:
> Using the Rust trademarks (even in modified form) for social events like meetups, tutorials, and the like is allowed for events that are free to attend.
JavaScript method call notation is arguably a ternary operator, or a candidate for the "Near Misses" list (because « foo.bar(x) » isn't the same as « var meth = foo.bar; meth(x) »).
Not technically ternary because the number of arguments is variable, but definitely an interesting case.
`a.b(c)` is actually a bit of a degenerate case because `b` must be an identifier, it cannot be an arbitrary expression, which seems to disqualify it as a true operator. But actually `a.b` is just syntactic sugar for `a["b"]` and you can view []() as an operator, so you can write nonsense like:
I remember Ubuntu's decision to abandon its original "no open ports in the default install" policy for the sake of zeroconf/mdns was controversial at the time.
I think the biggest weakness of github issues is that the main content it shows when you visit an issue page is the original report.
That's very often unhelpful because:
- it's likely that the actual problem wasn't understood at that point (it's likely to be describing a symptom, rather than a bug)
- it's quite possible the original reporter wasn't very good at writing bug reports
- issues often remain open after the main underlying problem is fixed, because there's some small remaining part that's unsettled.
I'd much prefer it if the topmost part of the page was reserved for a space, maintained by whoever's responsible for dealing with the issue, describing the current understanding of the problem and the current status.
Then the orignal report and further discussion could be laid out under that as at present.
It's possible to get roughly this now, by repeatedly editing the initial message. But the UX isn't ideal, and more importantly it isn't culturally expected.
(Of course this isn't a github-specific problem. But github are in a better position than most to offer a fix.)
GitHub issues have edit history now IIRC, so the maintainer can just edit the ticket in these cases, and still have the original text available under the "edited" submenu.
Issues are a mess because they get used like bulletin boards for any random brain fart anyone has, despite Issue Templates trying to plead otherwise.
IMO the way to fix this is to gestate all issues in Discussions. Then, when a clear and agreed resolution is hammered out there, a maintainer creates an Issue (or just does a PR) referencing that Discussion. This would have the side effect of encouraging people to contribute to projects more when they can clearly see what needs picking up.
The nice thing about this is that, with filesystem permissions on one end and a check for SCM_CREDENTIALS or SO_PEERCRED on the other, you can effectively get user-based access control working between two machines.
I think this is the one remaining advantage of ssh tunnels over using a VPN.
NB if you're doing this sort of thing, you probably want to add `StreamLocalBindUnlink yes` to the ssh options.
mosh is for interactive sessions, to keep them working when the connection is flaky.
autossh is for keeping unattended ssh tunnels alive, if the connection is flaky or one end is only intermittently available. So for using tunnels for the sort of thing you might otherwise use a VPN for.
They're saying things like "may not do that" and "cannot be used unless ...", when what they really mean is "we're not granting any special permission to do that", and "cannot be used unless ..., in cases where your local trademark law says you need our permission".
reply