There isn't much Helium-3 on Earth. Most of it is Helium-4, produced through radioactive decay. Helium-3 is easy to fuse whereas Helium-4 is quite difficult.

The moon has far more, collected from the solar wind over long periods of time. Still, not exactly tons, but enough that it might be worth going there to get it.

As I understand it (which is also rather little), the "interpretation" you are talking about is just for portability. When the application starts up, it asks the driver to compile it for whatever the hardware is and then the application copies that to the video memory for execution. There are limitations around what that can do, but only because of limitations of the GPU instruction set (not sure of the current state but they historically avoided things like loops, etc, since they never wanted it to be possible to execute more than a statically-determined number of instructions for element).

If you are allowed to copy data to the card (as most software is), then you could either use the driver's compiler or just copy a pre-built binary and try running that.

There is little in terms of actual security once you are on the card. This is part of why one application can often read another's framebuffer or why an illegal instruction requires restarting the entire card (typically).

I wish I had the points to mod this up since I am also very interested in this question.

Exploits through hardware with too much access are discussed, from time to time, but I never hear what realistic impact they can have relative to whatever the current state of IOMMU is. I remember this same discussion, with the same missing data, regarding at least FireWire and Thunderbolt, over the past several years, and those don't even require physical access to the machine internals.

The best part about legislating what kinds of technology people can use is that only legal entities must abide by the law.

So, the "good companies" or "good individuals" who agree with you are now penalized by having back-doors while anyone "bad" is "free" to use solid and effective tools.

Bullet, meet foot.

This touches on an interesting idea which I wonder if anyone has built: a video distribution system built on BitTorrent. It seems like a clever way of using the network strength instead of these monolithic companies storing and sending all the data, requiring massive resources. It seems like it could work as long as you had enough nodes (especially offering the first few blocks - improve quick-start behaviour) and it would scale with popularity of the channel: a channel could just provide an RSS feed including summary data and Magnet links (essentially borrowing a page from the podcast world).

It seems like _someone_ must have built such a thing since the hard parts (BitTorrent network and Magnet queries) are already solved by the network. Is anyone aware of such a tool?

"I'm not not licking toads"

--Homer Simpson

... or that people are actually individuals and their genders are not their direct identities.

Sure, I am male but that only matters in one situation (due to my handicap of being straight) and we aren't doing that right now so I have no interest in your gender.

If you can help me work through the design of this idea without resorting to arguments relating to "where the braces will go", then I think this may be the beginning of a beautiful colleagueship.

This is very true. While new ideas can be useful (or even great - everything was new at one point), the hype of the fad leads to tunnel vision where we only talk about how they will revolutionize everything.

The problem I have seen with the power of the fads is that they often become vague and redefined by everyone to fit what they are doing. "Cloud" is a great example: is it a common execution dialect, a remote storage system, or a flexible infrastructure virtualization system? "Agile" had the same problem a few years ago when everyone was doing it, even though their implementations were about as diverse as they were without it.

The "trendy" programming languages are frustrating since they are justified as being "great" because of their abilities to solve small problems with concise (or even terse) expressions. Since few people actually deal with large systems, they don't realize that most of these languages are really only good for prototyping or other small problems and big things are still written in C, C++, or Java for very good reasons.

It is why "legacy" has come to mean "actually works".

(Sorry for the shameless plug)

Personally, I created OpenAutonomy to solve this (and other) problems in an open, federated network (here is a video I did at FSOSS 2014 talking about this space). There is no centre of the network, nor is there much of a limitation in terms of what it can actually do.

That said, most of the approaches to solving this problem focus on social networking, specifically, and there are tons of them!

The problem is figuring out a way to explain the vision to a non-technical audience and get their interest in something new/different. The problems aren't technical, they are related to communication and marketing.

I was interested in what the change-over was, which was causing the performance increase, and how old the existing system is. This information seems to be missing.

What is included actually sounds a little disappointing:
13x faster
12x as many CPUs
4x mass (3x "heavier")

I would have thought that there would be either a process win (more transistors per unit area and all that fun) or a technology win (switching to GPUs or other vector processors, for example) but it sounds like they are building something only marginally better per computational resource. I suppose that the biggest win is just in density (12x CPUs in 4x mass is pretty substantial) but I was hoping for a little more detail. Or, given the shift in focus toward power and cooling costs, what impact this change will have on the energy consumption over the old machine.

Then again, I suppose this isn't a technical publication so the headline is the closest we will get and it is more there to dazzle than explain.

That isn't an operating system flaw but a hardware flaw: loads data from device into memory and points the CPU at it.

What is actually surprising is that they don't use some kind of DRM-esque bootloader (much like you find in many phones) where it only boots an image with a matching signature.

I definitely agree with this. Building a good game requires really good ideas (the game mechanics) and really great content (artwork and writing). These days, it seems to be common to sell a shell of a game and relying on multi-player to make it worth playing. Of course, to sound savvy, you just say you "crowd-sourced" it.

Many indie games have carved out a good niche for themselves by capitalizing on exceptionally creative game mechanics, which is definitely a great thing to see.

But in a truly single-player game, you are only cheating yourself, so you are probably just reducing your own fun and value.

If you want to cheat to "accomplish" things, then I don't really see the problem. It is just a different way of "playing" the game (albeit probably a less interesting one).

Having used GCC and XLC on AIX, I can tell you that XLC is definitely the superior compiler.

The difference is less dramatic on Linux, but it is still there.

The difference between the platforms is caused by some interesting knowledge the compiler has of how the OS does some things (readable zero page being the most obvious example).

(FYI: I haven't followed the systemd saga but I have noticed this fight in a growing number of places)

This seems to be a VERY common problem in the modern computing environment: arguments are reduced to ad hominem labels of their supporters where the proponents of "new" are just "kids fascinated by the trendy at the expense of stability" or other "why maintain it when I can write something better?" inexperienced people and the proponents of "old" are just "out of touch old-timers who are afraid of the unknown" or people "only interested in their own job security".

Of course, the reality is some bits of these straw men, combined with massive doses of reality. The truth is, both sides of the argument make more sense if they are reduced to actual concerns and interests, as opposed to "us versus them" camps.

The truth is that "change for change sake" is a dangerous position and the reality is that the "legacy" moniker is slowly changing from a negative term into something which means "has worked well for a long time".
Alternatively, sometimes new ideas are beneficial since they tend to think of current realities, as opposed to sometimes-extinct realities.

This whole notion of "choosing your side" doesn't help anyone since it isn't actually a division, but a conversation/argument. Sometimes stepping forward is correct while sometimes standing still is correct and neither approach is "always correct". Maybe we would choose our next steps better if we worked together to choose them instead of all lining up in our preassigned trenches.