Apple pops up a notification (more annoying than Microsoft actually) that says "install these patches now or later?", and you have to click and open up before you can even see what you're clicking "now" or "later" for. Then it turns out it's just something stupid like itunes. So I ignore it. Then a few days later it repeats. Then a few days after that. And so on. It's basically the apple store window, even though I have zero software anywhere on or in the vicinity of the mac that even saw that store. So yes, I am indeed crawling under that sink to see what shit the plumber left there.

At least be glad microsoft isn't merging their updates and patches with their store.

The thing is that most of those stability patches are no such thing. They are for cards you don't have on your computer, for a product you don't use, and in some cases have nothing to do with stability but instead added new features.

When you click for more details it tells you to visit a web page. Then on that web page, full of long boilerplating, there is some description. Useful description, but it takes you enough time that to follow that patch for every update is a tedious chore. It would indeed help if the patch description said something more useful than "stability pach" or the name was something other than "KB11878723".

I think the rationale is that either the interns it would take to do this minimal work are costing too much, or they want customers to blindly install everything shoved at them.

Nonsense. Consumer protection is probably worth only 1% of a game's price. Unless the company is putting out games where most of the customers are going to complain about it.

I'm utterly baffled that EA has any customers left.

I've seen even less annoying protections. And games with no DRM or copy protection (they're not the same thing). With steam you gotta wait for steam itself to update, then mandatory updates to the game before first launch. Some games also have subsequent mandatory updates, very annoying to say the least (and when you find out what these important changes are you find out they were trivial fixes for some video card you don't even have). Some other games require you to register outside of steam to get the add-ons you paid for (seriously what the hell is wrong with bioware). Then every time you play you have to waaaait for steam to launch first.

Meanwhile GOG gives you DRM free games, and allows refunds, and sells the same title cheaper than Steam. You can give your games away, loan them out, play them without asking for permission, mod them up all you want, revert to older versions, etc.

Some of what you say is true. Register allocation was simple in RISC, but most of the competing CISC machines also had very orthagonal registers as well (PDP and VAX were the classic CISC machines, x86 isn't even in the picture yet). Also some CISC machines were adding instructions that compilers had trouble using, often because the compilers had to fit in a small amount of memory.

However many RISC machines required much more advanced compilers if you wanted optimization. I think for basic compilation RISC is very straight forward, but to try to make that actually efficient code then the compiler is much more difficult. Basic compilation for CISC was very easy at the time (many had orthagonal registers and convenient instructions). The difference is in how well the unoptimized code ran. Memory was very expensive at the time and not always slower than registers, so the push on CISC compilers was to squeeze the space and make instructions do more (not counting things like super computers which were really fore-runners of RISC).

Much of the later complexity didn't exist in the late 70s. Many machines didn't have pipelining, there weren't instruction queues for loops, only one ALU, external memory wasn't always slower than CPU registers, etc. However by freeing up space on the CPU with RISC this opened up the way to add more advanced features in cheaper CPUs and thus the new need to have advanced compiler technology even on basic workstations and minicomputers. Also RAM got very cheap but also got a lot slower relative to the CPU which also drove more change in CPU and compiler goals.

Or just 50 cents worth of common sense.

That's the thing with water too. There's a water table in many places, and if you dig and find water chances are if you move 100 feet in any direction and dig you'll find water too. Other times the dowsers instinctively head to where water is most likely, stream beds, depressions in the earth, etc. Where dowsing fails though is in a blind test, they absolutely do not find water reliably in closed opaque barrels where neither tester nor testee know which has water.

RISC came out when Intel was only doing tiny microchips, the RISC market was not competing with it. One of the advantages of CISC at the time was indeed that it was easy to implement, because you just build the micro architecture most of the rest was microcoding the instructions and putting that into ROM. If you needed to add a couple new instructions for the next release to stay competitive, it could be done very quickly (and you could patch your computers on the fly to get the new instructions too).

Yes, simplicity of design was important, but the simplicity was to free up chip resources to use elsewhere, not to make it easier for humans to design it.

I dont' see it. The ARM Thumb instruction set is vastly more simple and regular than even the 286 instruction set. Thumb is already a reduced instruction set. There are no special purpose string instructions, it has general purpose registers that can be used as anything whereas 286 has only special purpose registers (AX is only accumulator, BX is the only base register, CX is the only register for counting instructions, etc). Yes, SP and PC are special purpose, but that's true of all the early RISC machines too. I don't see anything in Thumb I would call CISC-like.

ARM is RISC through and through. Though it complicates it somewhat with multiple simple instruction sets. Basic ARM ISA is all 32-bit instructions only, very much RISC from every angle you look at it, every bit as pure as MIPS. ARM Thumb ISA is 16-bit instructions only, and the machine translation from Thumb to ARM is very simple, just a fraction of the chip. Thumb2 gets slightly more complex allowing both 16 and 32 bit instructions intermixed, but again it's not that complicated. It's just RISC like all around. Some exceptions with the PC-relative indexing perhaps, but all instructions are orthagonal, you can decode the machine code by hand, all instructions take the same amount of time to execute (not true on some multiplies/divides on some models, which was also true for classic RISC), decoding is a tiny fraction of the chip being used.

MIPS isn't a dinosaur, they still develop and advance it and it's still being sold new for use in new products.

RISC was not supposed to be a religion, which is what it seems to have turned into. No one should even ben arguing the point today because modern chips are so different from when the term 'RISC' was new. The whole premise behind RISC is being used extensively in modern CISC machines. The problem with trying to keep a RISC vs CISC debate alive is that is harms the education of the students.

RISC is primarily at its core about eliminated complex infrastructure where you can and reusing the resources for things that really can improve performance. Remember thay when RISC was first being used that the primary CISC machine at the time was the VAX (x86 still being a toy). The VAX operated primarily with a micro-architecture with the instructions implemeted in microcode. It had some amazingly complicated instructions, including one for helping compute polynomials. RISC researchers wanted to reuse those transistors for other purposes: more registers, more cache, pipelining, etc.

In fact, RISC was already well underway before 'RISC' was coined as a term. Many of the super computers and super-minis of the day already used similar techniques. One of the tradeoffs to overcome was the ease of programming in assembler versus performance, another tradeoff was memory space versus performance. Much of the complexity in CISC machines was also to support the high level architecture: paging systems, memory protection, IO subsystems, which is one major reason why the VAX was designed the way it was. Compare to the microship CPUs at the time; RAM was expensive so they also were primarily CISC in order to squeeze the most out of each instruction.

At the time the machinery necessary to support the instruction decoding was a significant part of the typical CPU design, so shrinking that gave you a big win. Today this is no longer true, the decoding and micro-architecture on Intel chips is essentially a trivial fraction, they even have on-chip caches with more static RAM than an early 80s era CISC decoder.

However it may not be true everywhere. We still have small embedded and low power chips where this stuff does matter. ARM7TDMI is a popular chip which relies on RISC in order to keep everything simple and small, no space for caches or instruction queues, so having a simple instruction decoder is a big win in keeping it simple and low power. Most of the small low power chips today for embedded use are clearly RISC derived for that reason, PIC, AVR, etc. The article here is talking about the big beefy desktop systems, which are just a fraction of CPUs being used.

The issue I had was when they brought the Weeping Angels back for another episode and ruined the whole thing.

Half Life 1 is a good choice, better than HL2 in every way, and more of a classic.