> I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.

At this point you just require every compound infix expression to be parenthesised, the terseness isn't worth the inconsistency. Especially as, as others have noted, these operations are only associative when working in some classes (notably not necessarily when dealing with floats).

And then you do automatic parens insertion in the LSP, so you write

    a - b - c

and when you save the lsp fixed it up to

    (a - b) - c

Non-mixed always goes strictly left to right, regardless of the operator, which I haven't seen anywhere near as much struggling with.

But yes, I personally parenthesize `a-b-c` explicitly, because it's not worth it for me to read and wonder if parenthesizing order matters later. Costs less than a second to write, saves a second or ten each time I read it - that's an excellent tradeoff imo, and is a trivial pattern to follow.

(Associative operators are fine, obviously)

Didn't you just suffer from the same trap the parent was trying to avoid?

Nice: https://tutorial.ponylang.io/expressions/ops#precedence

Yeah that's pretty much exactly what I do by hand. I should really give Pony a try some time... there's a lot of stuff in it that I like.

These standards are that way because older languages (specifically C and C++) have unspecified evaluation orders for arguments, so multiple argument expressions with conflicting side-effects are non-portable.

Here the expressions are pure, OoE has nothing whatsoever to do with the issue.

Everyone's got a list of people they're proud to have worked with, you're on mine.

Or in other words, the response is well-coordinated so cperciva's bragging is justified, isn't it?

He was talking about managing disclosure and patch flow, and you're just taking it as an opportunity to dunk on him.

I think cperciva may have been a touch overenthusiastic, but surely this is in fact proving his point? His claim was, as you note before trying to ignore it, about coordination. When one of the recent Linux LPEs broke, the fix wasn't in distro packages yet; there was a vulnerability that users couldn't practically do anything about. This is an LPE that is fixed in the binaries that have already shipped. If I was playing cheerleader, this is exactly the case I'd use to argue that FreeBSD being a single unified system is a win and that its approach to handing security problems is very on top of things.

Its like rain on your wedding day - not actually ironic, just unfortunate.

A not-insignificant chunk of the userbase of the various BSDs is there because they were turned off of Linux after controversial things like Gnome 3, systemd being shoved down users' throats despite being a broken mess, wayland (though nobody was as arrogant about wayland as Poettering was about systemd), etc.

All that to say, the BSD userbase as a sizeable subset that are there for countercultural reasons, rather than technical. These are the people who buy into, say, OpenBSD's vaunted security reputation, or believe that "linux bad because reasons", so you're always going to get people in here bragging, because "not using linux" has become part of their identity.

I run a mix of FreeBSD and Linux on my personal devices. The ground truth is that FreeBSD is yet another unix-like OS written in C, and thus not immune from the types of bugs that stem from that lineage. None of the BSD distros are materially more secure or better than a properly-configured and patched Linux.

Anyone relying on a 30+ year old monolith kernel written in C to not have some exploitable LPEs lurking should stay in basket weaving and out of sysadmin.

Why can't they? Upgrading and rebooting is kinda the standard response for most security issues. So I would expect something like Ansible's playbooks for this exact scenario. You might also have it setup as a staggered rollout.

What prevents it?

I don't think so? It's a buffer overflow in the system call.

[dead]

> I'm not sure how or what you're counting.

The recent two. FailCopy and DirtyFrag and FreeBSD with Execve.

2 - Linux 1 - FreeBSD.

Of course, all OS have had past-time exploits. Three now have made the news.

Local privilege escalation is largely irrelevant on Windows because basically no one uses it in a multi-user system, and application sandboxing is effectively nonexistent.

You talk as if Windows is the only OS that has red teams attacking the system when clearly that isn’t even remotely true.