We don't use that moon anyway
HN user
keybuk
[ my public key: https://keybase.io/keybuk; my proof: https://keybase.io/keybuk/sigs/WVbbDndkAvnlmmXLIrhVNdMj3Ww9cvJps7lqFXVsAXs ]
For the most part, Classic was designed by committee with many concessions to every corporate partner, retaining compatibility with their IrDA stacks, etc...
...while LE was designed by a few smart guys working together
This is about the newer LE 2M PHY, which was added for "replacing Classic" (which is 2-3M) use cases. It's not surprising that it's not as efficient as the more widely used 1M PHY.
I was the lead for Ubuntu Desktop at Canonical.
This is nonsense.
'-ize' might be preferred by Oxford, but '-ise' is preferred by Cambridge. So I think it needs no explanation which DNA would prefer.
Ubuntu Bug 255161: Openoffice can’t print on Tuesdays (launchpad.net)
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)
Depends which season of Star Trek it's from.
Early in the run it'll come across as kinda corny, but mid-way through the run it'll be a strong episode and one fans will cite as a favorite forever.
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
If I recall correctly, deleting an app on iOS only deletes its container, it leaves any shared containers behind.
Your Google credentials are likely being stored in a shared container.
I'm not sure when or even whether shared containers are garbage collected at all, it's not documented either way.
(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.
Seeing this title, I thought: "(Nuclear) Winter is Coming."
It's hosted on Linode, looking at it sternly kills it ;-)