Participating in a woman focused community is hopefully not a competition, so I don't see why the same considerations should apply.
296 karma · joined June 4, 2010
I am cis-gendered female and exhibit a lot of conversational traits typically identified as male-patterned. Does that mean I shouldn't be allowed?
Personally I love the idea of allowing trans-women into a woman focused community. Your perspective is going to be unique (and likely uniquely insightful.) You also experience the same discrimination as cis-gendered women if you aren't explicitly identifying as transgendered and may have the same needs for support and understanding related to that discrimination.
lobste.rs has a invite system where a person who invites someone may potentially be kicked if the person they invite is a problem. See https://lobste.rs/about#invitations
Organize a booth or representative at women-focused tech events like FFC or GHC, or have events/meetups for Leap members to meet face-to-face where prospective members are also invited. The invite system would make this easier to implement.
I believe the [XX]-[XX]-[XX] is:
<extended family><family>-<extended model><model>->stepping id>
Those values are all in the first few lines of output from 'cpuid'.
The [XX]->[XX] is probably [old microcode version]->[new microcode version]
If the cpuid for a processor is not listed in those release notes, I don't think there's a reason to believe the processor has received a microcode update. It might be worth comparing the microcode blob to Intel's last release in 2017-11 to confirm.
It looks to me like the microcode version can be read out from
hexdump <XX-XX-XX from .tgz> | head -n1 | cut -f4,5 -d' '
where the first field is the lower 16 bits and the second field is the upper 16 bits. I don't have any documentation to prove this assumption, it is just based on comparing the listed microcode versions to those fields in the binary blobs. But doing a straight 'diff' would probably be good enough to tell if the microcode file has changed.
Some Linux vendors like CentOS, Debian and Ubuntu may have microcode updates for processors that weren't part of this release, I'm not sure.
There's no causation shown this data. It takes two parties to be in a relationship and you have no reason to assume that it's primarily the woman making that choice.
If you want another anecdote, I've been dumped after disclosing I made more than my partner.
It sounded to me like it could have been the same problem as this person encountered: https://stackoverflow.com/questions/10560834/to-what-extent-... . Based on their data loss after a clean shutdown of mongodb in order to perform a backup, I think the only way we could have possibly saved the data is if we hibernated the system instead of doing a clean shutdown. But I don't know how well mongodb handles sudden time jumps. In general, since time jumps can be an issue, we typically perform shutdowns if a service needs to be stopped for whatever reason.
I hope you ended up with a hosted mongodb service or an MSP with an expertise specifically with mongodb, as mongo seems like it can be very tricky to administer properly if it's not the one thing you do.
You can install a custom OS. But it can be difficult to use an installer we don't provide right now because we only allow serial console access, not VNC. This means most installers won't work out of the box. Worst case you can dd an image to the disk using ssh from the rescue image.
FYI we don't do overage charges right now. For network, if we can't throttle your traffic down then we will shut your service off.
Our blog is a little misleading these days in that for downtime for individual servers, we started emailing customers directly rather than posting to the blog. This is because we want to make sure customers see the downtime notice. We also got confused responses sometimes to the blog wondering whether a given service was affected or not and if we email directly there is no such confusion.
I think our worst case downtime barring about 5 services this year has been the following:
* 0.75 hour network outage, unplanned - 2016-03-16 (gave proportional credit)
* ~2.5 unplanned downtime due to hardware failure requiring new components - 2016-04-03 (gave 15% month credit)
* 2.6 hours downtime from start of maintenance window, planned due to security upgrade - 2016-07-23 (gave proportional credit)
* 2 hours or less downtime, planned due to security upgrade - sometime around 2016-09-01 (gave proportional credit)
* 1.5 hour network outage, unplanned - 2016-09-09 (gave proportional credit)
* 1.3 hour network outage, unplanned - 2016-11-06 (gave proportional credit)
* 2.04 hours downtime from start of maintenance window, planned due to security upgrade - 2016-11-18 (gave proportional credit)
This is a total of up to 12.69 hours downtime over the year so far, assuming downtime started at the beginning of maintenance windows (it usually started after.) Of that 6.05 hours, or less than half, was unplanned.
So far this year there's been about 336 days or 8064 hours. 12.69/8064 is 99.84% uptime overall, which is significantly lower than we would like. For some servers the uptime has so far been significantly better in that there were no hardware failures, one of the security upgrades was unnecessary, and the turnaround time for the remainder of the security upgrades was much faster than for this particular server.
For this particular server, the largest downtime contributors were security upgrades and network outages in that order. For network downtime, we got around to setting up our second upstream but there's a number of single points of failure we should take care of in 2017. There is also some additional scripting we should probably do that would cut down on the network downtime a lot, such as automatically taking down BGP if connectivity beyond the first hop is lost.
For the security update downtime, I think our most realistic bet right now is to get ourselves on the latest version of Xen once it comes out. That will hopefully have a stable implementation (not a technology preview) for live patching.
gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-faad gstreamer1.0-plugins-bad-videoparsers libgstreamer-plugins-bad0.10-0 libgstreamer-plugins-bad1.0-0
I really like your idea of rotating through different groups who are statistically underrepresented (not just women.)
It is good to ask these questions because there are simply biological issues that the other sex is not going to have personal experiences with. Pregnancy and breastfeeding? I know there are considerations that someone who has not gone through these events (including women without children) are just not going to relate to.
We also can't control how people react to us in person and the assumptions that are made based on our appearance, regardless of what are personality is. You aren't going to resolve those issues without identifying what they are in the first place.
Personally I would like it if the series was "ask an engineer who is female" rather than "ask a female engineer" though.
$ host -t NS pagerduty.com
pagerduty.com name server ns-219.awsdns-27.com.
pagerduty.com name server ns-739.awsdns-28.net.
pagerduty.com name server ns-1198.awsdns-21.org.
pagerduty.com name server ns-1569.awsdns-04.co.uk.
I think I'm satisfied.
I dug and found https://www.fiala.me/pubs/papers/sc12-redmpi.pdf the title of which is "Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing."
They state that for a cray there was a double bit flip about 1x/day for 75k modules. To (probably incorrectly) extrapolate, if you have a server with 16 modules that would be equivalent to a single double failure about once every 13 years.
For example, reallocated sectors are not alerted on by default, so we added '-R 5!' to our smartd config. The full config we have is:
DEVICESCAN -a -s (L/../../6/01) -l selftest -l error -m <email> -M daily -M test -R 5!
Looking at http://vault.centos.org/6.8/updates/Source/SPackages/kernel-... it looks like RedHat backported this function but has not applied the fix.
I've used both apparmor and selinux and while it was pretty easy to figure out how to write a custom profile for apparmor, it's not easy to do the same for selinux. If a custom profile for selinux could be made as easy to write, that would help a lot.
While the risk from QEMU can largely be mitigated by running QEMU in a device model stub domain, a new mode called PVH (currently being rewritten) should theoretically be best in terms of performance, resource usage, and attack surface. See http://wiki.xen.org/wiki/Xen_Project_Software_Overview#PVH
pygrub runs in the context of the dom0 and should not be used with untrusted guests. Both grub legacy and grub2 work with PV mode now and there is no need for pygrub.