My biggest problem with fbsd in the rpi is that it's really hard to cross-compile ports for arm, and compiling everything in the rpi takes a lot of time (I think it was half a day to compile tmux in the rpi A).
I've tried freeBSD in a Raspberry Pi 1, but I couldn't get any binaries precompiled for ARM :(. I would like to have an easy way to cross-compile ports from my main machine.
In the blog post it says that CNNIC issued the CA=TRUE on the basis that MCS H only use it for domains that they have registered.. Wouldn't it be better to just issue a CA cert with name constrains extensions?
Why do we have that extension if nobody uses it :( ?
Actually, this lib needs root access in the computer. It is intended to be used as a module in MIG (Mozilla InvestiGator), which is an agent that lives in servers and can receive commands.. So it is mostly the same, I think, except that the commands shouldn't return detailed information to the main server, but just yes/no answers, for example: "Is any of my servers running a vulnerable OpenSSL Version?"
You are correct: MIG is designed to prevent a rogue investigator from executing random commands on systems. We do so by filtering what agents can run through modules, and by requiring OpenPGP signatures on all actions ran.
Even if the MIG platform is compromised, agents and systems are safe, as long as the keys of authorized investigators (kept on their laptops) are not compromised.
It was easy to solve, but I'm struggling trying to get the design right, also trying to be more robust with the parsing (there are fields that can be interpreted as uint64, int64, int32, uint32, etc).
Most of the hex editors available for linux are broken, ghex for example, the "grab these 4 bytes and interpret them as float32" functionallity doesn't work at all. I don't know what people who work doing this kind of things use.
You can join the golang-challenge channel on slack which is a room for people who are going to participate in the Go Challenge - http://t.co/n6EesY9Mmv
I have a Zenbook Infinity and yes, it is good, but the battery life is too bad. On linux it lasts 3 hours or less with the OnDemand governor, whilst on windows it last 4 o 5 hours.
I don't know what to do to improve battery life :(. I regret not buying a Macbook Air for the same money instead.
Actually, I really prefer writing that in C rather than asm: You can use bitfields to define the GDT, IDT, Page Directories and so on. Doing everything is ASM is a PITA, for debugging and for readability.
(I am a teaching assistant at one of these courses and hate when students do everything in asm.. but they are allowed to do as they want, as long as it works as specified).
Maybe it messes with the random number generator.. somehow.
Awesome article, but I suspect that something is wrong. If we see Mewtwo, lvl 70, full hp, frozen solid it says that -on average- we need 6 ultra balls. That is FAR from true. I always freezed all the legendaries to capture them easier, and it took always more than 10 balls to capture them.
We can get a more useful translation than "you need approximately 6 balls on average", here's how:
The process of capturing is a Bernoulli process [0]: each time you throw the ball, there is a P chance of catching it, and it is independent of subsequent throws.
Chance of catching, given 1 ball = P
Chance of not-catching, give 1 ball = (1 - P)
Chance of not-catching, given 6 balls = (1 - P)^6
For P = 17.5%, the chance that you don't catch your Mewtwo with 6 balls is 31% (which agrees with your observation that it often took more than 6 balls).
Let's try for 10 balls: (1-0.175)^10 = 0.15 (still a 15% chance of not catching it).
It's never certain! Even with 100 balls, there's a very slim chance you won't catch it.
