Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Note: You can take 10% off all Slashdot Deals with coupon code "slashdot10off." ×

Comment Probably 15.0 kW, not 150 (Score 1) 100

They're claiming this enough to power 10 households, which would be 15 kW per house... Someone clearly dropped a decimal or doesn't understand units. 15.0kW or 150kWh/d is plausible. Math or GTFO:

Google used ((862 heliostats) * (6 m**2 / heliostat)) to generate 890 kWe. Source

890kWe / 5172 m**2 =~ 172 watts per square meter.

Helio100 is using ((100 heliostats) * (2.2 m**2 / heliostat)) == 220 m**2. Assuming it's really 15.0 kWe, that comes out to 68 watts per square meter. The difference can easily be because Google optimized more for large-scale and efficiency instead of installation cost, whereas Helio100 optimized for smaller scale and minimum labor.

Comment Re:Drone It (Score 4, Interesting) 843

The idea was better stuff, quicker and cheaper. It turned out - like some of the lessons Boeing learned with the 787 - that agile development may work great at Facebook but it's a train wreck when applied to aerospace, military systems and gigantic procurements. Oops.

One of the basic ideas of agile dev is to get a partially-working system in the field ASAP. Doing so lets you figure out much sooner (10% into a project) that the design requirements are wrong, and that you need to rethink what you're doing. In this case, the loop wasn't closed - there were plenty of early signs that it was going wrong, but the project just kept going forward without reevaluating the basic requirements (VTOL being the most obvious case).

I don't think that means agile dev won't work for aerospace generally. It's more an indication that the organizations involved (governments and military contractors) are too heavy to handle an agile process: imagine trying to go back to congress once a month to get the requirements updated based on dev feedback. Smaller, independent companies like SpaceX can manage a much faster, cheaper cycle on the space side, and I think it's possible for a new military aero supplier to do the same.

There were also plenty of f***ups in assumptions the program made that were only really recognizable in hindsight, like the fact that trying to mesh the Marines' requirement for a V/STOL aircraft with the traditional designs for the Air Force and Navy hobbled the plane's performance for all three constituencies.

That wasn't only seen in hindsight. It's obvious that adding complicated, heavy components to something that's supposed to be fast and reliable is going to create problems. It was more of a "let's see how well we can apply modern materials and design to make this work" kind of thing... Initial tests showed it was possible, but a bit further into the program it was clear that it was still too much of a tradeoff to be worthwhile.

Comment Re:Full Disclosure can be found on oss-security... (Score 1) 399

Here's the exploit:

curl -A "() { :; }; /usr/bin/touch /tmp/vulnerable"

User-Agent is copied to HTTP_USER_AGENT with no munging.

For DHCP, dhclient calls several hooks (which are usually bash scripts) when events happen. It needs to pass some information like the new domain name. Passing them via the command line creates another set of problems, so they pass them via the environment. For better or worse, it's a common convention.

Comment Re:Ingredients for water? (Score 2) 190

By RTFA I discovered that "This water is not in a form familiar to us—it is not liquid, ice or vapor. This fourth form is water trapped inside the molecular structure of the minerals in the mantle rock. The weight of 250 miles of solid rock creates such high pressure, along with temperatures above 2,000 degrees Fahrenheit, that a water molecule splits to form a hydroxyl radical (OH), which can be bound into a mineral's crystal structure."

Comment Re:Test and launch are the same, it is GREAT! (Score 4, Informative) 125

RTLS, TAL and AOA all relied on the main engines. If all three SSMEs failed they would have ditched it in the Atlantic. The scenarios aren't really comparable - they had a lot more fuel to work with but also a much heavier vehicle to return.

RTLS is easier for the Falon 9. After separation the stage 1 assembly is quite light: it has shed the payload, second stage, and most importantly, most of its own fuel; the remainder is about 5% of the original mass. It can therefore make a pretty quick burn to reverse its course.

They have some real numbers over here: http://forum.nasaspaceflight.c... .

Comment Re:Yea, because glassholes will have learned (Score 1) 363

What do you think a Glass user can do that a phone user can't?

They can walk around maybe recording at any time. Someone who points a phone at me for a moment probably took a photo. Someone who points it at me continuously is probably taking a video. Either action is conspicuous which means that I can choose to leave, or I can confront them if they're doing it inappropriately.

Camera etiquette has been refined for a hundred years. Glass upsets the balance because it doesn't provide those visual cues. People who don't want to be recorded therefore presume it's not recording but feel uneasy because they're not sure, or they assume the worst and confront the wearer.

I'm actually quite enthusiastic about it as a technology, but the couple times I've encountered them in the wild I've fallen into the "uneasy because I don't know if I'm being recorded" group. I'd like to have one, but I'd cover the lens with a piece of tape most of the time.

Comment Re:Subjects suck. (Score 5, Informative) 65

It's a high-level interface to LXC (similar to Solaris Containers, or FreeBSD Jails). If you're not familiar with those, think of it as a combination of:
  chroot (virtualized filesystem root)
  git (version control where a hash-id guarantees an exact environment)
  virtual machines (virtualized networking, process tables)
  make (you make a config file describing an image to start from, then all the things to do to set up your application / build environment / whatever)

If you are building a complex product you can write a short Dockerfile which will:
  Start with 8dbd9e392a96 - a bare-bones Ubuntu 12.04 image
  apt-get install git gcc make libc6-dev

You now have a completely reproducible build machine - Docker builds it and gives you back a hashref. You run it with the right arguments (basically: a path to where your source code is, plus a command to run) and it builds your project reliably (you always have a clean container exactly the way it was when you built it) and quickly (unlike a snapshotted VM there's no need to boot it - in a split second the container comes up and it's running your makefile). More importantly, everyone else working on your project can clone that tag and get /exactly/ your environment, and two years from now people won't be scratching their heads trying to reproduce the build server.

Now let's say you're shipping your product - you're a web company, so you have to package it up for the operations guys to deploy. It used to be you would give a long list of dependencies (unreliable, and kind of a pain for the user); more recently you'd ship a VM image (big, resource-heavy, but at least it escapes dependency hell); with Docker you build an image, publish it on an internal server and give the hashref to the ops guys. They clone it (moderate-sized, resource-friendly) and they get your app with everything required to run it correctly exactly the way QA was running it.

As it's being run they can periodically checkpoint the filesystem state, much like snapshotting a VM. If something goes wrong it's easy to roll back and start up the previous version.

It's a young project and there are still some rough edges, but the benefits are significant. I think in a few years doing builds without a container will be looked at the same way as coding without source control.

Comment Re:Stop (Score 3, Informative) 349

It's OpenDNS's fault. They return a bogus A record instead of NXDOMAIN:

$ dig +noall +comments +answer @
-- Got answer:
-- -HEADER- opcode: QUERY, status: NXDOMAIN, id: 48729
-- flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

$ dig +noall +comments +answer @
-- Got answer:
-- -HEADER- opcode: QUERY, status: NOERROR, id: 31301
-- flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


Comment Re:bad trip to the power of infinity? (Score 2) 221

I've had very few bad "trips" but I can't imagine how bad it could be if you know you are dying.

Knowing you're dying can be a bad trip, no drugs required. Someone who's looped their fear until their soul is crushed isn't in much danger - they've already hit bottom.

Knowing you're going to die is a terrible burden, but it presents you the opportunity to choose the last memories your friends and family will have of you. They can remember you living your last weeks in fear and dying terrified, or you spending some time recalling the good times, and perhaps forgiving some of the bad ones. That's all the control you have left of your legacy, and you don't have much time to take advantage of it.

LSD, especially low* doses with someone to help guide can sometimes give people a new perspective. If they can relax their fixation on the fact that their time is up they may see the bigger picture - that we're all mortal, that life is a cycle, and that this is just a part of it. It may give you the opportunity to make your peace with the world. And if not, you're dead anyway. So why not?

* There's adequate margin between free-association, preconception-questioning levels and moon-howling-naked.

The more cordial the buyer's secretary, the greater the odds that the competition already has the order.