Taking the 171 acre figure we can compute at least the limits of what it could do.

171 acres is about 700,000 square meters. At a solar incidence of about 1 KW / square meter and an efficiency of 23% that's 161 MW peak power and an average of 4.7 sun hours per day will give about 750 MWh of usable electricity every day.

This calculation ignores shading effects and assumes that the panels will be stationary rather than tracking, you could probably easily deduct another 50% to account for those effects, so say 375 MWh give or take and 80 MW peak. Likely these figures are still very high, think of it as the maximum amount of solar power that you could extract at that location from incident sunlight without further accounting for conversion losses (solar panels produce DC, you'll need inverters if you want AC power, some data center equipment can run on 48V DC but you'd still need a conversion step for that) and so on.

I wonder how big a chunk of the total power requirements for a datacenter that size will be covered by this PV system, to be 100% effective it would have to be sized at least 6 times larger than the total power consumption of the DC, using the grid as a storage system.

WolframAlpha measures an average US household's yearly consumption at 12,000 KWh, or 32.8 KWh per day. The upper bound in the parent comment with the 50% fudge factor, 375 MWh per day, would power (375 MWh/32.8 KWh) = 11,430 households day-for-day, or 22,860 households day-for-day without the fudge factor.

(I would expect 161 nominal megawatts to produce more than 1 megawatt-hour in an hour)

High Resolution Map of KiloWatt Hours per day across the US: http://www.nrel.gov/gis/images/map_pv_national_hi-res.jpg

You can feed to, and take from the grid, but it's not a battery.

The Grid is like an open water pipe with holes in it - you can put water back in, or take water out, but you can't store water in it. The power stations are pumping in at one end, and the users are taking out all along the pipe.

Rendering web pages is actually one of the worst use cases for Amazon from a bang-for-the-buck perspective, especially when you factor in bandwidth.

When people are building 30,000 core compute clusters [1] on EC2 - presumably with zero publicly available web servers, I'd be very interested in any methodology that provides reasonable estimates of revenue based on public web servers.

http://arstechnica.com/business/news/2011/09/30000-core-clus...

http://asm.sourceforge.net/intro/hello.html

What you linked to is great, but it uses a different approach to explain the subject. That approach presents the correct thing to do, and explains some of it. The benefit of this approach is that it's short and sweet, but the downside is it's easy to miss subtle points. For example, what you linked to never explains why you have to call sys_exit. Someone reading this would know that's the right thing to do, but they may never really understand why that's so.

An alternative approach - which the posted article does - is to try the obvious but wrong thing, then explain why it fails. Fix that problem, and try the next obvious but wrong thing and keep iterating. The problem with this approach it can be a long process, particularly if you just want to know how to do something and are less interested in the why. But the benefit is that by seeing how things fail, and then seeing the fix for them, the reader can gain a deeper understanding of what's going on.

In general terms, one is more of a reference, and the other is more of a lesson. I like the try, fail, fix iteration for explaining things. I've used it many times when teaching. I find that it matches well with what we would actually do on our own, and for that reason, tends to stick with people better than simply saying "this is how to do it."

If you write a blog post about something like this at least finish the damn thing rather than to leave a bunch of obviously wrong snippets laying around to confuse whoever lands on that page.

There are plenty of good pages on introductory assembler on the web, this isn't one of those and I'm really surprised to see it this high on the homepage. Maybe it shows how much the HN crowd would like to get a little bit of insight of what actually powers their computers, the error is mine in assuming that such knowledge would be commonplace here.

That it fails at being an introduction to assembly is, I think, missing the point. It doesn't try to be. It's just trying to demystify some of the system stack.

As for HN itself, I've known for a while now that there's a pretty wide range of people here. While I think the percentage of people will almost no systems experience is more than it was a few years ago, the number wasn't zero a few years ago, either.

You sir, are really subtle with your humor.

That's like expecting Sylvester Stallone to do higher mathematics or Mother Theresa to do an arms deal for you.

Some people are what they are and their environment/audience will have to accept them as they are.

The problem lies squarely with the person that hired him, the abstract of the speeches listed should have adequately explained what they were going to get. That's exactly what that rider exists for in the first place, to avoid misunderstandings like that.

I highly doubt if RMS could even tailor his speech to the occasion, he must know it by heart by now except for the Q&A part.

What I found interesting on reading the 'rider' is that he still refers to the GNU operating system as though it is in daily use. I've yet to see a HURD based system do anything useful in production but half the world wide web seems to run on Linux these days. Of course linux is 'merely a kernel'.

But if you write free software the you also give away the right to name that software, after all, a fork is under no obligation to be named after the parent. So RMS holding on to insisting to call Linux GNU/Linux looks to be against the self-imposed freedoms.

Considering that glib, libc, gcc, emacs, the vast majority of the Unix utilities, bash, grub, autoconf, make, readline, gzip, tar, screen, wget, and Gnome are all GNU projects[0], I would say that GNU is most definitely in daily use. The Linux kernel isn't much use without the software on top of it, and it's nothing at all without the compiler that turns it into machine code.

[0] See https://www.gnu.org/software/software.html#allgnupkgs for the full list.

Linux is still useful without KDE, but the functionality provided by GNU is critical and would require a large effort to replace.

This isn't really true. You could just grab your userspace from a BSD, or Plan9Port. Clang and LLVM do well enough to replace GCC on most important architectures.

25 years later. Very few works are relevant for that long.

You could also form stacks, like KDE/GNU/Linux, or go all the way and just draw a directed graph of the major software dependencies. This isn't a serious proposal, but I would be kind of pleased if someone actually did this.

However since GNU software is the foundation on which most of the system is built you can argue that it has a much greater importance.

"Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs"

Now compare that to how many people have none of the GNU software on their systems.

It's really difficult to determine the relative importance of one software project at this level over another they reliant on each other. The Linux kernel needs GNU as much as GNU needs the kernel (at the moment anyway). You can run the OS without KDE (hence not calling it KDE/Linux).

I can see Stallman's point as he set out to create an operating system called GNU, created almost all of the parts required which were then used by someone else to create a Kernel which was then packaged up with a different name.

Personally I think you can call GNU/Linux whatever you want as the licence its released under has nothing in there saying you need to give mention to GNU in the name. If you package it up you can call it Fred for all I care and I will refer to it as Fred.

Or without the its own license, the GNU GPL.

You didn't know the real Mother Theresa, did you.

That, and he does tend to be brusk.

Technology moves so fast these days that if you don't place the bar for your product sufficiently high you won't be able to get happy customers even if you give it away.