Does that power come from a power grid, or from solar? Who makes the semiconductors for the solar panels, and the chips in the printer? How much did they cost and how did you pay for them? How long does it take you to make an item like, say, a bucket?

If the robots aren't up to repairing each other, and unless that someone is me, I will need to pay them. What should I pay them with - 3D printed goods that they can make themselves?

Just as the world's bio-diesel needs can not be met from recycled takeaway fryer oil, the "pick up other people's discarded stuff to feed my 3D printer" model is just as unscalable. Scattered, cottage industry is not the same as keeping the world running using only waste stuff.

Look, I think that 3D printing is nifty, and recycling stuff is awesome, and using things that people don't want is great - I'm one of those people that hardly ever buys anything technological until it goes on closeout sale - but it's a big stretch to claim that owning a magic printing machine and an R2-D2 to fix it will allow people to survive in a future where their labour has little selling proposition, let alone a unique selling proposition. What I want to understand is how owning some robot buddies lets you either live decently while sitting completely apart from the post-singularity economy, or participate meaningfully in it, when everything that you can do could be done by anyone else with the same gadgets.

If you have that machine, and the means to power, maintain, and keep it fed with the necessary materials, you'll be doing super fine. A few assumptions there.

Until AIs get the right to enter into contracts and own property, there will always be a role for a small number of humans to own all the stuff. They will of course be first to get access to anti-aging and life extension technologies, and Andrew Carnegie's idea that "the man who dies rich dies disgraced" will be less of an incentive to philanthropy once that moment of disgrace is pushed back into the indefinite future.

Just as computers do most repetitive, regular information work now, robots are going to do more and more manual work which can easily be systematized. What will be left will be ad hoc, messy, fiddly stuff, or face-to-face contact. In other words, there will always be plenty of crappy jobs in the service industries.

Okay, I'm happy with daylight savings for the six months around summer here, but for 2/3rds of the year in the USA??? What earthly justification was given for making DST last so long?

Yes. I was overjoyed when Spring DST was changed to more or less mirror Autumn DST (1st Sunday in October, here in the south-eastern part of Australia (35 degrees south). It used to come in almost a month later, and I used to get pretty tired of waking up at 5am for weeks on end.

That said, having slept in a room with no curtains in Stockholm a week before midsummer (when it never gets *totally* dark), I'd guess that DST for Swedes is, to be plain, like pissing into the wind. Wake up at 5am or 4am, what's the difference?

"If you were plowing a field, which would you rather use: Two strong oxen or 1024 chickens?" - Seymour Cray.

The devil is in the details. SPARC has lots of registers, very true. But it needs more user-accessible registers, because its address modes are simpler, and you need to do more address computations in registers. Register windows were like a fully associative cache for a few levels of your call stack... but then you have to save more stuff when you do a context switch, and I suspect they were part of why Sun was late to doing full out-of-order execution in their SPARC implementations.

I was a big fan of the early RISC chips, because that architectural style was bringing forth implementations which got much better bang per CPU transistor than other commercial chips at the time. That lead was eroded seriously by Intel with the Pentium Pro - certainly in terms of bang per buck - which was embarrassing for people who wanted to point out some inherent "elegance" or other timeless quality of RISC that was its great advantage. Whatever that counted for, Intel's designs and better process technology could more or less match with ugly old x86.

The time when you could play Top Trumps with computer architecture specs is really over. Decisions that were clear winners at a particular time, in terms of process technology, memory bandwidths, and compiler quality, can turn out not to be as optimal when the market, or what is cost-effective to produce, changes over time.

The T series SPARC chips came out of work done by Kunle Olukotun at Afara Websystems and then brought in-house by Sun. They represented a great point-in-time improvement for high parallelism, cache-unfriendly, integer server loads over what was under development inside Sun at the same time, especially when cost and power were taken into account. Some of those decisions in the T1 got revised for the T2 - one FPU for the whole chip turned into one FPU per core, for instance - but the per-die core count got halved for the T4, so again the Top Trumps viewpoint doesn't really illustrate whether one processor is better than another.

Bottom line is, does it run the stuff you want to run, for a good TCO?

Yeah, do not buy old Sun hardware thinking that you can get any useful support from third parties, or pick up a cheap support contract suitable for a sysadmin's home box or a dev workstation... or even download firmware for a device that is not covered by your current support contract. That sort of thing went away by or shortly after the time that Oracle bought Sun.

Oracle doesn't really care about ISV support for SPARC, and they probably like it if their big Oracle/SPARC sales included a hefty dose of high margin professional services to cover the customer's inexperience with the hardware platform, so why do they need ordinary people using SPARC anyway?

"You actually don't need to be open-minded about Oracle. You are wasting the openness of your mind..." - Bryan Cantrill, Fork Yeah!

The funny thing being that the complainer apparently wanted to spend their life writing assembly code. :-)

It's like big-endian versus little-endian memory organisation: on the one hand, you have a data format that makes it a bit easier to read raw hex dumps of main memory, but does your head in whenever you want actually write something useful (like, picking out the nth significant byte from a multibyte data type), while little-endian looks ugly on paper, but makes writing code to do multiple precision stuff simpler - the bit with significance 2^n is in the byte at [baseaddr + (n>>3)], no matter *what* length the full data type is... and the debugger will helpfully display that ugly little-endian piece of memory properly for you should you need to see it.

John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.

He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]

The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as:
- no variable-length string comparison/move instructions
- accesses to multibyte data are aligned so they can't cross page boundaries
- load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.

The more complex the exception handling requirements, the more you pay to implement those, either with more hardware, [which can imply more cost, or more power, or longer cycle time], or by giving up opportunities for parallelism because the exceptions get too hard to handle with many operations in flight. Even if an exception is rare compared to the common case, the implementation has to be able to handle it correctly...

It would be interesting to know how long each of these colliding files was... funny how we all *know* that for nontrivial hash inputs there are many many possible colliding inputs, but over time we tend to slide into "let's just compare hashes to find identical data; collisions are so rare - after all, we haven't seen any!"

Part of BMW's response FTFA:
"A vital point to acknowledge here is that there is no such thing as the ‘unstealable’ car, as Ron Cliff knows well. If a criminal decides they want your car, they will find a way to take it. Our job is to make it as difficult as possible."

Apparently, that means making it take three minutes, instead of, say, two and a half. Dare we dream one day of the car that can resist theft for... four minutes?

Anyone who thinks that tinnitus adds anything to life is kidding themselves. Constant ringing in your ears, worse with stress or fatigue.

I have much accumulated damage to my body, but my highest priority for improvement would be my hearing. I don't mind wearing a splint for the rest of my life to save my teeth from finally wearing to the point of mechanical failure, but I hate having tinnitus and high frequency hearing loss.

Look after your diet, people - your small blood vessels in your middle ear can get constricted with fatty crap just like your big arteries around your heart can. Reduced blood supply => increased oxidative stress => less robust neurons in your ears => increased risk of hearing loss after noise exposure.

...holding patents on:
- FM Synthesis (John Chowning at CCRMA)
- PageRank (a certain Larry Page and Sergei Brin)

Yamaha licensed the FM synthesis patents, and later waveguide synthesis patents, that stemmed from work at CCRMA, part of Stanford.
Google holds an exclusive license to the PageRank patent.

Stanford certainly doesn't sell musical instruments or search engine services, so does that make them patent trolls? Maybe Stanford hasn't ever had to sue any other companies to enforce their rights on these patents, but that could simply be down to people knowing not to mess with an institution backed by that kind of intellectual and financial firepower. Having made considerable profit from these patents, do you think it likely that Stanford would lie down and let some company use these patents without licensing them?

Thanks very much for this quote! I have been saying basically the same thing, albeit less eloquently, for years, but never came across this quote.

Maybe advanced magic prevents MPEG-4 compression artifacts from being just as annoying as MPEG-2 compression artifacts, but it would seem shortsighted to devalue what is supposed to be the premium movie viewing experience (digital projectors, in a cinema) by using consumer grade compression. I see enough melty faces on standard definition DVB-T broadcasts that I remain skeptical about the invisibility of MPEG-4 compression, especially when the result is blown up to huge proportions and the film has lots of special effects. I am not going to a cinema to look at blocky crap where the compression algorithm ran out of bits for the breaking waves or rushing water or full-on special effects.

Anyway, all of that P- and B-frame stuff is just to get the bit rate down to the point where a movie fits on a nice, cheap-to-produce piece of optical media sold to individual households. The economic equation is totally different for the media that is used to exhibit a film to (hopefully!) many people, and it's not like making a physical print and shipping it around was very cheap either.