Follow Slashdot stories on Twitter


Forgot your password?
Slashdot Deals: Cyber Monday Sale! Courses ranging from coding to project management - all eLearning deals 25% off with coupon code "CYBERMONDAY25". ×

Comment Re:Don't Use UTC (Score 2) 143

Are you sure YOU know the difference between UTC and GMT?

It's not that UTC sounds cooler... It's what we actually use. UTC ticks based on atomic clocks and it's what's distributed through NTP. GMT (really UT) tracks Earth's rotation, doesn't have a stable second, and there are no high-precision realtime references.

Most programmers just need to know the number of seconds since Midnight, Jan 1, 1970, GMT, as God intended.

time_t doesn't count the number of absolute SI seconds since the Epoch: it assumes days are always 86400.0 seconds long, and completely ignores leap seconds... even worse, before 1972 they used sub-second leaps, so the offset isn't even an integer.

So, all told, why not refer to it as UTC since that's actually correct?

Comment Re:No kidding (Score 2) 103

The fact that you get /a/ face isn't profound, but the resulting image is interesting. It gives a good picture of the things that human vision uses to locate faces: obviously the eyes and mouth are most prominent; there's moderate contrast for the cheekbones and nose; the oval shape is only vague; the neck, ears, eyebrows, and hairline are almost entirely missing.

I expect those are already well known to vision specialists, but to me, it's an interesting analysis of the exact details which make an inanimate object become a face.

Comment Re:Power usage? (Score 4, Informative) 94

My Arduino projects don't require the power of a 32-bit processor, but do run on batteries. How much more (... or less maybe?) power is drawn by this processor?

It's reasonably close. If you check the datasheets for "Static Characteristics" / "DC Characteristics" you'll find:

The LPC1114FN28 (the ARM chip) draws 9ma @50 MHz, 6ua @deep-sleep, and 220na @power-down;
The ATMEGA168PA (typical Arduino-ish AVR) draws 4.2ma @8MHz, 0.8ua @power-save, and 0.1ua @power-down.

These numbers are just for the chips - the Arduino draws considerably more (about 40ma @idle), and you can stretch your batteries a lot by hacking it. To give a sense of scale, the power LED on an Arduino probably draws 5-10 ma just by itself.

Note that this is a "Cortex M0" profile ARM chip - M means Microcontroller, and 0 means low-end. This is a 50 MHz chip with 32K of flash and 4K of RAM. It's more powerful than an AVR, but don't expect to boot Linux on your breadboard with this thing... that's a job for the Cortex A (Application) series.


Comment Re:Hydrogen and Helium? (Score 1) 35

But doesn't the gas form part of the reaction mass? And therefore using a lighter gas would give less thrust? Eg might sulfur hexafluoride be better?

No, these are water rockets. The reaction mass is water. :)

Even if the gas was reaction mass you'd probably want a light gas. A heavy gas might have better impulse per mole or per liter, but lighter gasses will provide more impulse per gram. At some point the larger pressure vessel will add more mass than you're saving on the gas, but I'd expect the optimal gas to be closer to the hydrogen end of the spectrum. Take that with a grain of salt though because I haven't made any attempt at the math.

Comment Re:Hydrogen and Helium? (Score 2) 35

So, I'm super curious to hear what you think pressurized hydrogen or helium would provide that pressurized air would not.

1) Lower mass. Air at STP is 1.2 g/L. Hydrogen is 0.09 g/L. Looking at the contest rules the pressure vessel has to contain 20% water, so most of the volume is gas. A lighter gas lets you either use more pressure while staying under the 1500 gram limit, or have less dead weight for a given bottle/propellant quantity (whichever way you want to look at it).

2) Non-ideal gasses have different compressability. Not my field, so I can't calculate it, but it's significant enough that the rules forbid it for this reason. You have to use air.

Comment Re:From TFA: bit-exact or not? (Score 1) 174

Dithering isn't about adding noise either BTW.

"Dither is an intentionally applied form of noise used to randomize quantization error..." --

It's also unrelated to interpolation ("...a method of constructing new data points within the range of a discrete set of known data points..."). No new data points are generated - the monitor knows the exact RGB values it wants to display; instead, it's about doing the best job presenting them within the limits of the hardware.

Regardless, your original point is still correct: 6-bit panels do make meaningful use of 8-bit input. Throwing away two bits per channel will visibly degrade an image.

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

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.

No man is an island if he's on at least one mailing list.