mjw1007

> Apple/ARM platform development will continue downstream. If I feel like sending some patches upstream in the future myself for whatever subtree I may, or I may not.

I suppose it's possible that that could turn out well.

The situation with Apple hardware feels a bit like the early days of Linux (including the fast pace of development). There was a time when if you wanted broad hardware support it was better to run an Alan Cox kernel than a Linus kernel. And the whole point of git was to have a system that didn't require one central blessed tree.

> after a quick look at the SMART stats, everything appeared normal. Later, though, the reader did a more thorough Field Accessible Reliability Metrics (FARM) test and discovered [that it wasn't]

I had a look at how to run these FARM tests, and it seems I want smartctl 7.4 (which is too new for Debian stable but available in backports).

Probably not.

Letsencrypt don't provide a way to tell them "I'm not using this certificate any more", so they send out so many false-positive warnings that they're likely to drown out any signal.

Every time I move a service to a machine using a different letsencrypt account, or add a domain to a certificate, I get an unactionable warning email.

The part which describes the circumstances where she's seen an unstructured group work is interesting.

In particular, this condition

> Its function is very narrow and very specific, like putting on a conference or putting out a newspaper. It is the task that basically structures the group. The task determines what needs to be done and when it needs to be done. It provides a guide by which people can judge their actions and make plans for future activity.

is a good match for many free software projects.

That's one of four conditions she thinks are necessary. The other three are interesting too.

So don't have a default. Have securerandom() and insecurerandom() and make the programmer choose.

That has the advantage of avoiding problems in a generation's time: if most platforms moved to random() being secure, it would be excusable if young programmers started assuming that would be the case on older platform too.

One of the first prosecutions under the UK computer misuse act (R v Bedworth in 1991), ended up as effectively a jury nullification.

IIRC the judge explicitly told the jury that the offered defence wasn't valid as a matter of law, but they acquitted him anyway.

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.

[1]: https://foundation.rust-lang.org/policies/logo-policy-and-me...

Note that part is unchanged from the current trademark policy here: https://foundation.rust-lang.org/policies/logo-policy-and-me...

(Except the current policy says "Distributing" rather than "Publicly distributing".)

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) »).

I disbelieve that starting a lawsuit against Oracle because their software didn't work as it was supposed to would ever end well.

Do you know of any examples of that happening?

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.

https://wiki.ubuntu.com/ZeroConfPolicySpec https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/019...

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.)

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.

Yes. For example, I've seen #5 in non-"geek" circles and I haven't seen it in "geek" circles.

But surely DEF CON know that isn't true, because Dmitry evidently provided them with the firmware after the "stop work" order to EE (otherwise it couldn't have included the easter egg).

The early days of setuptools/easy_install (around 2004) were interesting. The way I remember it, the main developer had a clear "don't ask for permission, just build what you think is best and put it out there" approach.

That avoids the problems you can get where everything gets discussed to death and nothing actually gets written, but the downside was that the project spent a long time in an uneasy situation where it didn't have complete official buy-in but was popular enough that it would have been hard to push an alternative.

There were a couple of questionable early design decisions that didn't help.

Looking at the example near the bottom of the page, they seem to be making the common mistake of thinking that if I want 16px text turning into 32px, then I also want 24px text turning into 48px.

I really really don't. I'm already much shorter of screen space than the designer planned for, and huge headings make that much worse.

If I understand correctly, in principle there isn't an asymmetry based on point of view, only on time.

If the New Yorker had been able to publish their story in the days immediately following the trial, it wouldn't have been blocked.

Though the New Yorker story itself does contain claims that more recently there has been an asymmetry based on point of view, at least in some cases of self-censorship.

It's very hard to argue that a story like this is really getting in the way of the integrity of the legal system.

I don't know whether the problem is that the judge doesn't have the discretion to lift reporting restrictions in this case, or that the judge is failing to exercise that discretion.

But it's very silly that there was a window after the original case where reporting was allowed (and therefore a great was deal written based on the decision that she was guilty, with as much prejudice to a future jury as you like), and then they closed the window again ahead of the new case.

I don't think they have any desire to control what you see, because you're not going to be on the jury in her next trial.

This isn't being done "in the name of" stopping disinformation.

It's being done "in the name of" not prejudicing a future jury.

Right.

If the categories were things like "using search as the most convenient way to find a well-known website", "entering a term that's likely to appear in a news headline", and "asking a fully-formed question", I'd find the claim that this is about ways to make a better "browser experience" more convincing.

Improving this is the subject of RFC #3621 [1], which appeared today.

[1]: https://github.com/Darksonn/rfcs/blob/derive-smart-pointer/t...

Liability for paying amounts of money is not at all the same thing as blame.

There is no law of conservation of blame. Why would there be?

Maybe not untenable.

If everything is done carefully enough with reproducible builds, I think using a binary whose hash can be checked shouldn't be a great extension of trust.

You could have multiple independent autobuilders verifying that particular source does indeed generate a binary with the claimed hash.

The fact that the protocol has changed over time is itself a problem.

It isn't reasonable to expect everyone maintaining a daemon to keep track of additions.

When was "today" when that was written?