Around 2005, Nokia had a shiny new kernel (Symbian EKA2), designed from scratch to scale to future mobile systems with a good security model, clean abstractions, and power management built in at all layers. It was still hampered, however, by userspace APIs that were designed for a far more memory-constrained environment. Their solution to this involved multiple phases. Their first part was to try to replace the kernel with Linux. This did not go well. They then had no idea how to design a new set of userland APIs, so they set up multiple teams internally competing. These teams were very good at sabotaging each other, but not so good at bringing a usable product to market.

Elop came in when Nokia had failed to produce anything to compete with the iPhone or even with a moderately decent Android handset. He managed to persuade Microsoft to buy Nokia for what now turns out to be a significant multiple of their real value. Of all the companies that benefitted from this, Microsoft was pretty low down the list.

Half true. If you want to ship Android, it's free: go to AOSP, download, tweak to your device, ship. If, on the other hand, you want the Google Play store, then you have to pay Google, agree to ship other Google apps in the default firmware install, and agree not to ship competing apps in a few categories in the default install.

A lot of that is marketing. It's far more a brand problem than a design culture. In terms of usability, I'd place Windows Phone a little bit ahead of iOS at the moment (which surprised me a lot, because Windows is a UI clusterfuck on the desktop, OS X is worse than it was but still in a completely different league to Windows 8.1 - I've not tried Windows 10 yet). Possibly MS moved all of their competent HCI people to the mobile team, or possibly management doesn't care as much about mobile so doesn't insist on multiple layers of design by committee. No one who's used Windows on the desktop would go out of their way to buy a Microsoft product though.

Symbian EKA2 was a great kernel design for mobile (and still does security and power management better than Linux), but a lot of the Symbian userspace APIs were designed at a time where 1MB of RAM was a lot, 4MB was huge. When 64MB was entry level, they were really showing their age: saving 1MB at the cost of a big increase in developer effort wasn't worth it. Nokia needed to provide a modern API and a clean migration path. They provided neither and they set up groups within the company competing to provide both and actively sabotaging each other. Maemo/Meego is an example of this: Switching from GTK to Qt shortly after launching the product doesn't instil developer confidence.

Windows Phone actually made sense for Nokia: they needed a software stack that let them differentiate themselves (and no one else seemed to be using WP) and they had managed to set up their corporate structure in such a way that it was impossible for them to develop it themselves. Some of their apps were really nice (their maps app, which was just bought by a consortium of German car makers was a lot better than the Apple or Google offerings, for example).

longjmp from a signal handler to normal code is undefined behaviour anyway - there are lots of things that can break it (signal stacks are one). God created ucontext (unfortunately, while drunk) for a reason.

Please don't. The advice in that book (or, that chapter, at least) is great, if you're targeting a 486 with VGA graphics and a compiler from around 1995. Some of the advice is still good, but it's interleaved with advice that will result in much slower code (though the advice to always profile first may save you there!) and so it would be very hard to read that book without already understanding optimisation and come away more informed.

The worst bug I had to fix recently was in some hand-written assembly where the immediate in a store and a load overflowed and the assembler silently truncated it. I read the code multiple times and it was only when I traced the execution and looked at the disassembly that it became clear that the assembly and disassembly didn't show the same thing. This caused crashes, but it was in context switch code, so it only happened in processes that happened to use those particular registers and often quite a long way after returning to the process.

That's not debugging a compiler bug, that's step one in producing a reduced test case, which is step one in debugging a compiler bug. It's also starting from the easiest kind of compiler bug to fix (ones where it causes a crash at all, and within that category, ones where the crash and the miscompilation are in the same place).

The order of parameter evaluation is one that bites a lot of people because most compilers do it the expected way. When you're walking an AST to emit some intermediate representation, you're going to traverse the parameter nodes either left-to-right or right-to-left and most compiler IRs don't make it easy to express the idea that these can happen in any order depending on what later optimisations want. If they have side effects that generate dependencies between them (as these do) then they're likely to remain in the order of the AST walker. Most compilers will walk left-to-right (because a surprising amount of code breaks if they don't), but a few will do it the other way.

To understand why this is in the spec, you have to understand the calling conventions. Pascal used a stack-based IR (p-code) and had a left-to-right order for parameter evaluation, which meant that the first parameter was evaluated and then pushed onto the stack, so the last parameter would be at the top of the stack. The natural thing when compiling Pascal (as opposed to interpreting the p-code) was to use the same calling convention, with parameters pushed onto the call stack left to right. Unfortunately, C can't do this and support variadic functions (not: some implementations wanted to do this, which is why the C spec says that variadic and non-variadic functions are allowed to use completely different calling conventions), because if the last variadic argument is the top of the stack then there's no way to find the non-variadic arguments unless you also do something like push the number / size of variadic arguments onto the stack.

This meant that C implementations tended to push parameters onto the stack right to left. This is less of an issue now that modern architectures have enough registers for most function arguments, but is still an issue on i386. Because of the order of the calling convention, it's more efficient on some architectures to evaluate arguments right to left. Some compilers that are heavily performance-focussed (GPU and DSP ones in particular, where they don't have a large body of legacy code that they need to support) will do this, because it reduces register pressure (evaluate the rightmost argument using some temporaries, push it to the stack, move onto the next, reusing all of those temporary registers).

It's called copy elision and it is part of the C++ spec. The spec specifically says that compilers may (but are not required to) implement it, meaning that the compiler is completely free to do different things within the abstract machine at different optimisation levels. It's definitely a bug, but unfortunately it's a bug in the C++ standard. Any sane spec would either require the compiler to implement it or prohibit it - either would be fine (with C++11, prohibiting it would make sense as returning an r-value reference and doing move construction ought to give the same benefit).

Another compiler guy here: Some compiler bugs are not that difficult to debug if you have a reduced test case that triggers the issue. Most are caused by subtle interactions of assumptions in different optimisations and so go away with very small changes to the code and are horrible to debug (and involve starring at the before and after parts for each step in the pipeline to find out exactly where the incorrect code was introduced, which is often not where the bug is, so then backtracking to find what produced the code that contained the invalid assumption that was then exploited later).

My day job involves a research OS, a research compiler, and research hardware. When something breaks and we can narrow it down to just two possibilities out of an OS bug, a compiler bug or a hardware bug, it's a good day...

No they don't, because they are pictograms with very specific visual appearances. Such things don't belong in a character set, because things in a character set are characters. Glyphs (visual presentation of characters) live in fonts and each font designer is free to represent them differently, as long as they're recognisable. If every font has to represent things in the same way, then they don't belong in a character set, they belong in a set of standard images.

The other issue with this kind of cruft is collation. The unicode collation algorithm is insanely complex (and often a bottleneck for databases that need to keep strings sorted). Different locales sort things in different orders and most have well-defined rules for things that are characters. The rules for how you sort a dog-poop emoji relative to a GHS hazard pictogram, relative to a roman letter are... what?

Being a character implies a bunch of other stuff such as different graphical representations (fonts) for the same semantic symbol and a collation ordering. This doesn't make sense for a load of stuff that's now in unicode. If these are meant to be glyphs with well-defined visual representations, then they don't belong in a font with their representation dependent on the font designer's whim. If they're not characters used in any language, then what are the collation rules for them? What order do dog-poop and contains-gluten sort, and how does this vary between locales?

I'm not totally convinced by this. The poorer you are, the less likely you are to own your own house. That makes moving a lot cheaper (selling a house is expensive, changing rented accommodation is inconvenient but not nearly as expensive).

It's easy to retreat to a True Scotsman argument, but when it comes to political and economic systems there are very few examples of any ideology being completely applied. Not capitalism, not communism, not socialism. Most countries have a blend of several parts of different ideas. Claiming that the Union of Soviet Socialist Republics is a shining example of socialism is about as accurate as claiming that the Democratic Republic of Congo is a shining example of a democratic republic. They may have the word in their name, but that's about it. Even the USA makes more use of Marxist ideas than the USSR did for most of its existence.