I think the most striking thing is that for outsiders (i.e. non repo members) the acceptance rates for gendered are lower by a large and significant amount compared to non-gendered, regardless of the gender on Google+.

The definition of gendered basically means including the name or photo. In other words, putting your name and/or photo as your GitHub username is significantly correlated with decreased chances of a PR being merged as an outsider.

I suspect this definition of gendered also correlates heavily with other forms of discrimination. For example, name or photo likely also reveals ethnicity or skin colour in many cases. So an alternative hypothesis is that there is racism at play in deciding which PRs people, on average, accept. This would be a significant confounding factor with gender if the gender split of Open Source contributors is different by skin colour or ethnicity (which is plausible if there are different gender roles in different nations, and obviously different percentages of skin colour / ethnicity in different nations).

To really prove this is a gender effect they could do an experiment: assign participants to submit PRs either as a gendered or non-gendered profile, and measure the results. If that is too hard, an alternative for future research might be to at least try harder to compensate for confounding effects.

I think (unless I misunderstood the paper), they only included people who had a Google+ profile with a gender specified in the study at all (this is from 2016 when Google were still trying to make Google+ a thing).

I wonder if this is social engineering along the same vein as the xz takeover? I see a few structural similarities:

• A lot of pressure being put on a maintainer for reasons that are not particularly obvious what they are all about to an external observer.
• Anonymous source other than calling themselves KA - so that it can’t be linked to them as a past contributor / it is not possible to find people who actually know the instigator. In the xz case, a whole lot of anonymous personas showed up to put the maintainer under pressure.
• A major plank of this seems to be attacking a maintainer for “Avoiding giving away authority”. In the xz attack, the attacker sought to get more access and created astroturfed pressure to achieve that ends.
• It is on a specially allocated domain with full WHOIS privacy, hosted on GitHub on an org with hidden project owners.

My advice to those attacked here is to keep up the good work on Nix and NixOS, and don’t give in to what could be social engineering trying to manipulate you into acting against the community’s interests.

Most of mine are variations of getting confused about what system / device is which:

• Had two magnetic HDDs connected as my root partitions in RAID-1. One of the drives started getting SATA errors (couldn’t write), so I powered down and disconnected what I thought was the bad disk. Reboot, lots of errors from fsck on boot up, including lots about inodes getting connected to /lost+found. I should have realised at that point that it was a bad idea to rebuild the other good drive from that one. Instead, I ended up restoring from my (fortunately very recent!) backup.
• I once typed sudo pm-suspend on my laptop because I had an important presentation coming up, and wanted to keep my battery charged. I later noticed my laptop was running low on power (so rushed to find power to charge it), and also that I needed a file from home I’d forgotten to grab. Turns out I was actually in a ssh terminal connected to my home computer that I’d accidentally suspended! This sort of thing is so common that there is a package in some distros (e.g. Debian) called molly-guard specifically to prevent that - I highly recommend it and install it now.
• I also once thought I was sending a command to a local testing VM, while wiping a database directory for re-installation. Turns out, I typed it in the wrong terminal and sent it to a dev prod environment (i.e. actively used by developers as part of their daily workflow), and we had to scramble to restore it from backup, meanwhile no one could deploy anything.

I use https://f-droid.org/packages/mattecarra.accapp/ (with a rooted phone) to keep my charge levels within 5%-85% of the manufacturer battery range.

Most manufacturers made a decision to set the range their devices will charge to based on what is less likely to fail so quickly you’ll get mad at the manufacturer, but they trade off significant battery life for slightly higher design capacity (or perhaps more likely, they see shorter battery life as a feature not a bug, as long as it doesn’t catch fire, since it will mean your phone becomes e-waste faster and you give them more money).

Battery chemistry tells us that avoiding those extremes of high and low charge (shutdown earlier on low charge in the rare event that happens, stop charging at a lower level) drastically increases battery life - it is aligned with my interests, even if not the manufacturers’.

This seems extreme for the long tail of hobbyist apps. Finding 20 testers seems like a huge commitment for an unproven app, and I’m sure it would be a hurdle many apps currently in Google Play would not have gotten across if it existed then.

I wonder if this is a deliberate attempt to shut out hobby apps from their app store for whatever reason, rather than a good faith attempt to improve app quality.

In parallel they are also forcing people to publicly attach their real name to apps (people have long had to tell Google who they are to get in the app store, but not to make it public) - which might be another thing that is no big deal for big companies, but many smaller hobbyist app devs might think twice about doxxing themselves given how hostile people are on the Internet these days and how many crazies there are out there.

more is a legitimate program (it reads a file and writes it out one page at a time), if it is the real more. It is a memory hog in that (unlike the more advanced pager less) it reads the entire file into memory.

I did an experiment to see if I could get the real more to show similar fds to you. I piped yes "" | head -n10000 >/tmp/test, then ran more < /tmp/test 2>/dev/null. Then I ran ls -l /proc/`pidof more`/fd.

Results:

lr-x------ 1 andrew andrew 64 Nov  5 14:56 0 -> /tmp/test
lrwx------ 1 andrew andrew 64 Nov  5 14:56 1 -> /dev/pts/2
l-wx------ 1 andrew andrew 64 Nov  5 14:56 2 -> /dev/null
lrwx------ 1 andrew andrew 64 Nov  5 14:56 3 -> 'anon_inode:[signalfd]'

I think this suggests your open files are probably consistent with the real more when errors are piped to /dev/null. Most likely, you were running something that called more to output something to you (or someone else logged in on a PTY) that had been written to /tmp/RG3tBlTNF8. Next time, you could find the parent of the more process, or look up what else is attached to the same PTS with the fuser command.