Incredibly L take.
macOS keyboard commands are great for working in the terminal since system shortcuts use a different key and don't interfere with control codes
Many of the keyboard commands are configurable in settings, complete with switching cmd and ctrl keys around.
Or you can get used in a week or two when switching, this is what I did years ago and now for me Win/Linux is confusing and find the location of the command key more ergonomic on a Mac.
agree. I guess it's a force of habit, but I am so used to the cmd+<whatever> (specially copy & paste) shortcuts, that I configured them into my linux desktop to behave the same way
Being limited to just control and alt definitely cuts down on the options. Conversely, having MacOS command key act as “super” in Emacs opens up some possibilities.
Super key for most keybinds is much nicer than windows in my opinion, where it is entirely wasted on opening the start menu. On Linux it gains a few functions based on the desktop environment but not much.
The use of the Windows key extends far beyond the start menu. Builtin functions include window management, invoking programs on the taskbar, locking the computer, invoking Explorer and Settings, invoking and controlling accessibility functions like Magnifier. The Microsoft Power Toys add a lot of functions using the Windows key by default as well, like screen snipping, screen OCR, color picking, enhanced clipboard, and many more.
My problem is that I don’t use the majority of these functions at all. Command I can use for almost everything no matter how frequent or infrequent. It also replaces most “ctrl+shift” binds which is a great plus for me.
Having a key reserved for OS level actions means you can create your own shortcuts and macros based on it without fear of it conflicting with each app shortcuts.
Since operating systems also don't change often nowadays there is also seldomly any conflicts when a new system shortcut is added.
I also love good old Meta + left click/right click drag for moving and resizing windows in linux.
You totally can, I used Karabiner-Elements to switch command (behaves like ctrl), option (behaves like alt) and control (behaves ~ like super and like control in terminal) to their usual positions. (You could do this even with bare system settings but iirc they could not switch around differently the left and right keys.)
Then I set up a few shortcuts that were different on macOS I actually used, plus a port of a Linux keyboard layout (I think the US layout mostly matches but I use a national one which differs in the AltGr layer). Surprisingly configurable for an Apple product.
Absolutely. I went through great lengths to install Asahi on my work M1, only to have most things not work (RTFM). So when one is forced to use MacOS, may it round corners in hell, for work…
As someone that switches between MacOS (dayjob) and Linux (my own PCs) workstations daily - I wish I could do the opposite for Linux. MacOS keyboard shortcuts are just way more intuitive to me, and they are way more consistent across applications.
> Nice. But it deters people like me who aren't totally confident in sending reports, trading false positives for false negatives
There's no such thing as a reasonable "false positive" on a security report. There is such a thing as a false positive on a bug report. (A real bug, that happens to have no security impact, is still a true positive, just without a security risk)
If you can make it crash, or behave incorrectly, or have some repeatable, weird behavior; but you have no idea how you could exploit that for an articulable advantage, or access to the system you shouldn't have. What you have is a bug, not a security issue. You can, and should submit a bug report.
Then, critically; "if you waste our time" seems to be an important part of the statement.
If you don't know, you suspect it's a security bug because you shouldn't be able to do this, and it is leaking information that you think is suspicious, and you can easily demonstrate that you can make it happen on demand. And you report that bug, and make it easy for them to understand and either confirm the security, or reject because [reason]. You haven't wasted anyone's time and this wouldn't apply to your bug.
> it deters people like me who aren't totally confident in sending reports
This is by design, you shouldn't be submitting reports on anything less than certainty. It's not the maintainers responsibility to prove out your idea. It's yours, and when you're sure, reproduceable, and documented it, then you can submit it.
The real problem here is that this is now the only way the maintainer/reporter can reasonably work.
Proving out a security vulnerability from beginning to end is often very difficult for someone who isn't a domain expert or hasn't seen the code. Many times I've been reasonably confident that an issue was exploitable but unable to prove it, and a 10s interaction with the maintainer was enough to uncover something serious.
Exhausting these report channels is making this unfeasible. But the number of issues that will go undetected, that would have been detected with minimal collaboration between the reporter and the maintainer, is going to be high.
It would be more straightforward to remove the permutations and just display the combinations and the symmetry between heads and tails. And solve it analytically Eg:
if p is the probability that the NPC is correct
P(A|AAAA) = p^4
P(A|BBBB) = (1-p)^4
Anyway, the apparent strangeness of the tie case comes from the fact that the binomial PMF is symmetric with respect to n (the number of participants) and n-k.
PMF = (n choose k) * p^k * (1-p)^(n-k)
So when k = n/2, the symmetry means that the likelihood is identical under p and 1-p, so we're not gaining any information. This is a really good illustration of that; interesting post! (edit: apparently i suck at formatting)
reply