No kidding, I was always wondering how they got away with billing it as a screensaver. I left my PC powered on accidentally when I went on a four week trip in 2004 and came back to a 24" Sun CRT with SETI@HOME permanently burnt into the center. Screendestroyer is more like it.

With that kind of money it should be easy to keep your own private army or buy protection from a warlord.

Perhaps, but if the northern hemisphere becomes uninhabitable a billion or so people will want to migrate south. The northerners will still be the most heavily armed in the world, have a long history of manufacturing excuses for wars that are thinly disguised land grabs, and aren't going to take no for an answer.

So did I - spent time in the local woods, swam in the lakes, jumped in every muddy puddle to be seen, played out in the rain, and whatnot. I'm still allergic to cats, some detergents, and natural rubber (latex, avocado). This was in the mid 70s, and people had allergies then just like today. It's just the bar was much higher and people didn't really consider it an allergy unless they were likely to go into shock or develop serious symptoms. A little spring sniffle caused by pollen wasn't really hay fever unless it caused breathing difficulties or made your eyes puff up so bad you couldn't see. Anything else just wasn't bothered with and parents would tell their kids, "yeah it's just a little spring pollen, now go to school."

But what? There's nothing inconsistent about that - the air isn't your property to do with as you wish. It's held in common trust, so rules for its use (and abuse) is set through democratic political process.

Ah yes, that would be a pipelined design. I think that would work more efficiently than the original DDJ story's.

I think too much significance is place on the "single instruction" aspect; the DDJ design is really "single instruction format". It clearly has multiple operations, and the destination address is more or less an opcode field. So it's more accurate to describe it as a single-instruction format machine. Each operation has its own dedicated destination register which can be used as a source for operations.

All the execution units (aka co-processors in modern parlance) are still attached to a single bus, so theoretical max throughput is still one instruction per cycle. So this only makes sense if the CPs perform complex operations - like memory management, floating point, mul/div - or something of similar complexity. For the typical simple integer instruction that tends to dominate code it's no better than a microcoded processor - since now each normal instruction requires several cycles on the bus.

Compare this to a pipeline, where each step is what you'd consider a FU, but each one only needs to interface to the previous one, not counting the occasional clever bypass and special linkage. In a pipeline each FU can be fed an input in one cycle and provide an output in the next, something "FU"s (CPs actually) on a shared bus can't.

The other drawback is that anything that goes on the bus needs to implement a generic bus interface and its own internal sequencing logic. This doesn't come free. This is really just a CISC in silicon with exposed microcode, and it's pretty clear the author is thinking CISC all the way as can be witnessed by the stack operations. The typical RISC approach is to have a link register where the return address is placed on subroutine calls, so leaf functions don't have to push/pop it from the stack. Non-leaf functions start by saving the link register to the stack frame in the function prologue once space has been allocated for it.

This is a lot like MIPS. And indeed, a RISC processor is pipelined rather than microcoded. In a microcoded design it's not really feasible to execute multiple instructions in parallel. ARM strays a little from the pure pipelined model in that it offers complex instructions like stm/ldm, mainly to make it easier to program and reduce code footprint - which is understandable given is origin as a home computer CPU (for the Acorn).

I think it would be cool to take RISC one step further where a single instruction is broken into 5-7 parts (or however deep the pipeline is), which each part controlling each step in the pipeline. But the assembler exposed a very traditional RISC instruction set similar to MIPS or Sparc, with a naked pipeline model - but then does initial instruction decode and generates pipeline steps instead. So while you might write "bal $a0", meaning store PC in LR, and A0 in PC, the assembler breaks this into pipeline controls over multiple instructions. Doing so would make it easier to fill delay slots and manage hazards, allowing the assembler to optimize the pipeline. Exposing a traditional RISC ISA would make porting a toolchain relatively easy, requiring only a version of gas with a pipeline optimizer. Of course, such a processor would require a slightly different pipeline, but it's somewhat plausible the changes would be mostly simplifications to reduce complexity.

There's a whole cottage industry that helps create single shareholder-employee S corporations purely to reduce payroll taxes. It works - for now - BUT they also vastly oversell the benefits to people who are getting into deep water with limited experience. The IRS will reassess payroll taxes - and can do so at will. They look at your $40k and see how much it would cost to hire someone of a comparable ability, give you some benefit of doubt (say 5-10%), then send you a tax bill for the balance. So while you only make quarterly payments based on $40k, you may get a tax bill based on an additional $80k. $20k is what they may leave as a reasonable dividend payout. Or they could simply decide that $140k is a reasonable salary and what it would cost (including benefits and payroll taxes) to hire someone doing your job. So while you may save a little bit on taxes, it's by no means a slam dunk.

It does. You can read the software as much as you like. You just can't make copies of it - like onto a computer, without a license to do so. Just like the book. But you can sit and read the bits of the disk as much as you wish. You can even give it to your friends for them to sit and read the bits until they get mortally bored with it.

And this is the fundamental difference between a book and software: reading the book is its principal use. It is in itself not meaningful with software.

I don't understand the point you're trying to make. The Bay Bridge isn't funded by public transportation funds. Or are you claiming the bridge is funded _by_ raids on PTA funding under some vague notion that say because buses drive on it it's public transportation? But if so, wouldn't that be _good_ for the bridge - so how would that be the root cause of the eyebar crack?

Second, what gives you the idea that it's not properly funded - if that's in fact what you're claiming (your other confusing statement seems to contradict this)? Or not properly maintained? Isn't finding and promptly fixing a cracked eyebar an indicator of active maintenance? Sure the temporary patch they applied (that span is coming down in a few years, anyway) was inadequate, but that's an engineering error and not a sign of lack of maintenance? In fact, isn't the mere act of completely replacing the span a sign of maintenance?

You're just not making much sense.

You still need to pay close attention to what you're doing. If you communicate a time stamp to the targeting system using the equivalent of (double)timestamp*0.1f you will have the same error as if you added up 0.1f for each tick. It's quite easy to accidentally use this form instead of (double)timestamp/10f, because multiplication is cheaper than division, making it natural to prefer it.

With cloud computing you lease virtual servers to host YOUR software. It doesn't have to be web services, you could run DNS or host NFS servers, or your own custom Unix daemons (or WIndows Services) to do whatever you want. If you're a developer you can use it to host svn, trac, and build server. Unlike a colo it's a virtual machine instance. In a cloud you install all your stuff on an instance, then take a snapshot. You can then automatically spin up additional instances in response to load, according to your metrics of load. So if you build the right tools you could have a build server that scales dynamically - more checkins could spin up more instances to run more builds in parallel. When you lease storage you can have it shared across your instances.

Clearly, with EC2, one of the most installed software is mysql. You run it in one or more instances and put the db on S3. With Amazon offering mysql as SaaS you no longer have to deal with provisioning and sizing - it adapts to your usage. I think it sounds like a brilliant time saver and my company will take a close look at it for sure. (We run a lot of backend infrastructure on EC3.)

With SaaS you lease services not servers. Like collaboration tools, web hosting, etc. You don't know what the provider runs the software on - and don't care. You pay for the use of their software, not your own. I get the impression Amazon didn't want to get involved with SaaS for various reasons previously. (There are others who sell SaaS that's hosted on EC2, perhaps Amazon didn't want to compete with their own customers.)

You make it sound as if progress is tied to their marginalization.