HN user

keybuk

156 karma

[ my public key: https://keybase.io/keybuk; my proof: https://keybase.io/keybuk/sigs/WVbbDndkAvnlmmXLIrhVNdMj3Ww9cvJps7lqFXVsAXs ]

Posts1
Comments15
View on HN

In Swift, if cow is a reference type you all share a cow that moos whoever asks, but if cow is a value type then you all have your own copy of a cow that only moos for you.

We had a great plan somewhere around Ubuntu intrepid or jaunty that rather than have apps rewrite /etc/resolve.conf, we'd leave it as a static file and have a "nameserver dynamic" type config in there.

ie. sensible default for many people, but super easy to override

This particular undefined case is a really interesting one; it seems utterly non-obvious why it exists, until you remember one thing...

The most popular architecture today is 64-bit, with ABI specifying that the integer type is 32-bits wide.

So when faced with performing an operation on two 32-bit signed integers, on a 64-bit platform, you have to either:

1) perform the operation in 32-bit registers - if available - and even if available, usually far far far fewer in number thus massive performance & resource penalties to code

2) perform the operation in 64-bit registers, then add code to check the result, and if it would overflow in 32-bit, compute what the overflowed result would have looked like in a 32-bit register, and return that instead - again quite a performance hit

3) perform the operation in 64-bit registers, and just return the lower 32-bits, whatever that might be

The standard declined to pick a choice, which is why we have UB here.

(For unsigned integers, you can just truncate the result and it works every time, which is why the standard defines the result)

There are vulnerabilities in the "standard" LE pairing, even with MITM, that make these things possible.

Fixed with the BT LE Secure Connections key exchange, but many devices don't implement that

(I have worked as an engineer on both Ubuntu and Chrome)

One tab on chrome takes about 100MB memory, why?

It probably doesn't.

Much of that apparent memory usage is shared between all tabs, and the browser renderer process, etc. in the form of shared memory.

Quite a bit of it will be the executable code itself, which is "mapped" into memory, given an address, and allocated the full size but doesn't actually consume memory until it needs to be read from disk.

And a large part of that memory is going to be the giant white pixel buffer that you want it to draw into, which is typically mapped to a texture buffer in the GPU memory.