Forgot your password?

Comment: Re:Be ready for a lot of frustration (Score 1) 170

I had a Palm IIIe and the NiMH batteries I used in it lasted roughly a week or two depending on how heavily I used the backlight. But these were the old school NiMH that would be dead after a couple of weeks even when they weren't plugged into anything. Alkaline batteries lasted a crazy long time, like a month or more. I was a pretty heavy user of the device as well, using it to read e-books on the bus every day, playing games, and taking notes.

Comment: Re:I doubt most people care (Score 1) 353

by jandrese (#47508365) Attached to: Netflix Reduces Physical-Disc Processing, Keeps Prices the Same
I have a 2 disk at a time plan with Netflix. I have my own queue and my wife has one. I run through about a disk a week, sometimes two. My wife has had the same disk for a couple of months now. It really depends what movie you have. If I get some light comedy I'll pop it in whenever and return it in a day or two. If I get some Kurosawa film I need to hunker down and pay attention so it can sit for several days before I watch it. It's a lot more commitment.

There is no way I'm going to drop the DVD plan unless it goes totally to crap. Selection wise there is just no comparison. For me the streaming is a sideshow until there is some sort of compulsory licensing system for video like we have for music. The current law gives too much power to rightsholders to ever have a good streaming service. It's a fundamental problem with the way the laws are set up.

Comment: Re:Why not? (Score 1) 382

by jandrese (#47473079) Attached to: White House Punts On Petition To Allow Tesla Direct Sales
Also the ones where he appointed people to positions without Congressional approval, because without people in the positions the government agency could not operate and Republicans didn't like those agencies and was withholding nominations to effectively cripple them.

But really, the ones that go "too far" are simply the orders that Obama has signed. The fact that he signed them makes them automatically disastrous power grabs by an out of control executive bent on total domination. They need a return to the careful and thoughtful exercise of executive power we saw under George W.

Comment: Re:This is not how you inspire confidence (Score 1) 151

by jandrese (#47473015) Attached to: LibreSSL PRNG Vulnerability Patched
Only if the master process quit after forking twice. This is not typical, since most of the time people will leave the master process around to clean up after the children to avoid zombies. It's such a strange case I think you would be hard pressed to find a real world application that behaved in a way that made it vulnerable to this exploit. I'm glad the OpenBSD guys got a patch for this, but even if they didn't I woudln't be losing much sleep over it.

Comment: Re:Shocked I am! Shocked! (Score 5, Informative) 151

by jandrese (#47470707) Attached to: LibreSSL PRNG Vulnerability Patched
That's not exactly the case, but it's close. The issue is that the SSL library has no way of knowing if the process forks other than checking the PID. If the SSL library detects a PID change, it has to reseed the RNG to avoid getting the same random values in both the parent and the child. Due to the way Unix PIDs work, you have a guarantee that the Parent and the Child will have different pids (fork() fails otherwise). However, if a grandparent forks a parent and then exits, and the parent then forks a child, there is nothing in Unix that outright prevents the child from getting the pid of the now deceased grandparent and foiling this detection so the SSL library doesn't know that a fork happened.

So it's a potential problem, but not one that likely exists in any production code. You could write test code that exploits it fairly easily by forkbombing the machine until the pid wraps before spawning the child, but in real production code it is unlikely to be an issue. Plus it was fixed.

Comment: Re:This is not how you inspire confidence (Score 4, Interesting) 151

by jandrese (#47470217) Attached to: LibreSSL PRNG Vulnerability Patched
To exploit this, you needed a program that was written like so:
1. Grandparent initializes SSL state, sends some data, then exits.
2. Parent forks a child
3. Child happens to get the same pid as the grandparent, and then uses the SSL connection.

It's a program structure that doesn't make a whole lot of sense in the real world. Maybe it has happened somewhere.

The big issue is that the original discoverer found an easily filled molehill and somehow it got reported as a world destroying volcano across the the various tech sites. A minor flaw in the first public release of the test version of a library with no production users is not "catastrophic".

"Trust me. I know what I'm doing." -- Sledge Hammer