Gartner are vigorously trying to shove it up Apple's arse) is that the smartphone market is really the Android market.
That's not really true. From the report, the iOS market is around 22% of the size of the Android market. That's a much higher ratio than the size of the Mac market to the Windows market has ever been. Even that doesn't tell the whole story, because a large part of the Android market is very low-end phones, with razor-thin margins for the manufacturer and very few app sales. This is important to the sort of people reading this kind of report, because they care about what the return on investment will be from supporting a given platform. It doesn't matter that Android completely dominates in the poorer parts of Africa, India, and China to the extent that iOS is a rounding error, it matters what phones the people with money to spend on your product have.
All I can rely on from linked is junk mail.. Mikrosoptht u killed it.
That's been all you could rely on from LinkedIn for a long time before Microsoft bought it.
You are entirely correct, even though I absolutely hate how true it is. Most of getting (and much of maintaining) a job is about how much people like you, not about your competence
I disagree. When hiring, you have a limited amount of knowledge to make a decision that can be incredibly costly if you get it wrong (Joel on Software has a good article about the costs of hiring a bad employee vs the costs of hiring no one). A CV is easy to doctor (and unscrupulous recruitment agencies do this a lot). An in-person interview gives very little information for selection (though inability to answer basic technical questions provides good deselection information). If one of your employees has worked with a candidate before and can attest to the fact that they're competent, then that's an incredibly valuable piece of information. This is why your professional network matters: it's not about how much people like you, it's about whether people respect your ability enough to want to work with you again.
I love MIPS assembly.
Really? Branch delay slots (with 'unpredictable' behaviour if you put a branch in them), no complex addressing modes, weird instruction names (an unsigned add is the same as a signed add, except one will trap on overflow, because that's obviously what the difference between signed and unsigned means), special $hi and $lo registers because some instructions have an implicit destination. Half-arsed transition from a fixed-design pipeline so that some operations have hardware interlocks but some need some magic (and implementation-dependent) number of NOPs to work. Oh, and my favourite bit of MIPS, the superscalar NOP. When your ISA has a superscalar NOP, that's when you should realise that you've done something badly wrong.
In terms of programming, it's beautifully designed.
If you ever have to write ARM assembly, your head might explode if you think MIPS is beautifully designed.
The extension from 32-bit to 64-bit is pretty seamless.
The 'oh, by the way, if you don't sign-extend into the top 32 bits then you get undefined behaviour for any 32-bit arithmetic operation' thing is seamless? So any code that has to deal with 32-bit values ends up doing a left-shift by zero instruction (which makes the code totally readable - 'Hey, this looks like a nop, can we remove it?' 'no, it looks like a job, but we'll get garbage values if we remove it') at multiple points to enforce this invariant.
Even the MIPS instruction encoding is quite clean and the CPU design makes it easy for vendors to add their own interesting instructions to coprocessor 2. For example, my employer has a bunch of encryption and hashing related instructions added there. ARM does not allow you to add your own custom instructions to ARMv8, for example.
I'm guessing your employer is Cavium? Thank $DEITY that they're starting to produce decent ARMv8 chips and we can kill off support for their MIPS products in a few years. You might see this as a strength of MIPS, but to everyone else it's a massive weakness. Every MIPS vendor takes a version of GCC, hacks it up to support their extensions, and breaks support for other extensions in the meantime. They then can't get their patches upstreamed (the few that even try) and so their customers end up with an unmaintained dead-end fork. Worst ecosystem ever.
One advantage of the MIPS instruction is it very cleanly moved from 32-bits to 64 bits. With ARM that is not the case. AARCH64 is very different than 32-bit ARM.
I think that you and I have very different definitions of clean. MIPS quickly hacked on a 64-bit extension without thinking it through, AArch64 was the result of careful study of the intersection between code sequences that compilers like to generate and instructions that are efficient to implement. For example, a lot of the predication (really useful for assembly programmers, hard to implement in superscalar pipelines, hard to use for compilers) is gone, the user-addressable PC is gone (makes branch-prediction really hard on in-order pipelines) and so is store/load multiple (basically needs microcode). You keep all of the really useful bitfield manipulation instructions (no MIPS equivalent, and oh how I miss them when I have to deal with MIPS, which sadly I do on a regular basis), store and load pairs (including atomics on pairs) and so on.
Oh, and MIPSr6 is not backwards binary compatible with previous versions. All of the branch-likely opcodes were recycled as compact branch (no delay slot), you you need to patch your binaries if you want them to work.
Somebody's terminal is dropping bits. I found a pile of them over in the corner.