Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Re:Solar Roadway Bull$it (Score 1) 405

Dave's argument starts with real-world numbers regarding solar insolation and PV conversion efficiency to establish a baseline. The exact details of a specific implementation won't change the broad conclusion that the energy balance alone, even if you take out the gee-whiz features of the Solar Freakin' Roadways design such as LEDs and networking, doesn't make sense.

When you add all the other stuff on top, it only gets worse.

Fundamental issues: Only so much sun hits the earth, and PV cells only convert a certain fraction to usable energy. When you mount them flat on the ground, you reduce their efficiency further because they're not perpendicular to the incoming light. When you put them under thick enough glass to support real physical loads such as cars and trucks, you lose even more. And when you distribute them over a large area, transmission losses become a Big Deal.

I'm personally skeptical you could build solar panels that would withstand actual vehicle traffic, at least the way we build roads here in the US. Real world roads aren't flat, and they change shape over time as they wear and as the road bed settles and degrades. But real world glass isn't very plastic, and won't conform to a changing surface. It's more likely to crack and break into many pieces. Likewise for the PV cells under it. You'd have to put some beefy steel plates under these to guarantee a sufficiently flat mounting surface to support the load-bearing glass.

Comment Doesn't this just affect Chrome? (Score 1) 136

Seems like this should just affect Chrome / Chromium and anything derived from those, as it's an implementation issue in the V8 JavaScript interpreter. (V8 is the name for the engine in Chrome.)

That is, it's not a JavaScript / ECMAScript bug in the standard (as implied by the headline), but rather a bug in one company's implementation.

Compare/contrast with the comically bad PRNG enshrined in the C standard itself:

static unsigned long int next = 1;
int rand(void) // RAND_MAX assumed to be 32767
next = next * 1103515245 + 12345;
return (unsigned int)(next/65536) % 32768;

Thankfully, though, this is just an example, and not required by the standard. But, many simple C compilers use that implementation. It's got plenty of problems, such as always alternating between even and odd values. If the last value was odd, the next value is even....

Comment Set *top* box? (Score 1) 153

So... does anyone actually put a set top box on top of their TV set these days? Once upon a time, TVs were deep enough front-to-back to support this; these days, most aren't.

Or is this a term that was once accurate, but will never be accurate again, like "dialing" a phone? It's been a long time since phones had dials, unless they're being purposefully retro.

Comment Re:Hurd.. why? (Score 1) 129

He reused the MINIX filesystem layout, and initially hosted builds on MINIX, but to my knowledge he never directly incorporated code from MINIX. Some have claimed that, but no claim has ever stuck, especially given that Andrew Tanenbaum himself agrees that Linux didn't annex any MINIX code directly.

It appears Wikipedia's account jibes with my memory.

Comment Re:Timestamps (Score 1) 129

I can't tell if you're trying to be humorous.

The rationale given is: "The kernel now keeps timestamps relative to the system boot time. Among other things this fixes bogus uptime readings if the system time is altered."

Presumably, this means the internal timestamps Hurd uses are now all monotonically increasing, regardless of any changes to the system time. Obviously, there's a relationship between the internal timestamp and what POSIX calls time_t (and related such datatypes). As I read it, they've decoupled the notion of system time (ie. something that resembles what you'd read from a clock, representing time and date as humans understand it, and subject to humans or network time daemons messing with that setting) from the internal timestamps it uses for computing the relative passage of time, such as 'uptime', network timeouts, etc.

Comment Wire, not write (Score 5, Informative) 129

According to the release:

The kernel now allows non-privileged users to wire a small amount of memory.

This is not a typo. Wiring memory means pinning it in memory so it cannot be paged out. This is potentially important both for security and real-time applications. On the security front, memory containing keys and passwords should be wired to prevent it going to disk. On the real-time front, if you can fit your working set in wired memory, you can be guaranteed you won't suffer a paging fault while you stay within that working set.

In Linux / POSIX systems, this is what mlock accomplishes.

Being able to write to memory, in contrast, isn't particularly noteworthy. You've been able to do that since pretty much the beginning...

Comment Re:Not a huge surprise (Score 2) 208

I'd expect it to be a very minor effect. I'm not aware of anyone getting worried about this.

Got it. With everything else you've explained, that makes sense.

A related effect is convergent evolution. Say two species of bacteria each colonize high temperature environment. Then certain mutations which are favoured in high temperature will likely occur in both of them. When we compare their DNA, this can make it look like they are more closely related than they really are.

Ah, that also makes sense.

I thank you again for the informative responses. You've expertly escorted me up to (or possibly even well past) the edge of my competency. :-) I've certainly enjoyed the trip.

It's truly a fascinating topic, but for me to really get much more out of it, I think I need to do some homework to learn more about what's already known. There's only so much a generically analytic mind can do w/out learning what's already known in the field.

Thanks again.

Slashdot Top Deals

I have a very small mind and must live with it. -- E. Dijkstra