Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:I Have To Agree With The Texas School Board (Score 1) 763

fifty to a hundred years ago, a bunch of people who knew nothing about science and not much more about Christianity made a really stupid guess, and they're too proud to admit that they guessed wrong

This! Although the process really extends way past 100 years ago, I agree that the period you mention was perhaps the most influential.

Comment Theory -- not your common one (Score 1) 763

Given that ideas only reach the status of theory if they have overwhelming evidence supporting them

Unfortunately, nobody fucking knows that, it seems. Nobody on the school board, certainly, and a whole lot of college graduates don't know that either. It's quite sad, really. People don't grok the simple fact that in reality, as opposed to common man's fantasy, science's ultimate goal is to produce theories, and making a scientific theory is a crowning achievment. I'd be pretty extra damn proud of myself if I was a scientist and had produced an accepted theory.

The common man's fantasy about what theory means is the exact opposite of the true meaning as it applies when talking about science. I'm OK with common uses of the word "theory", but one has to understand that it all changes when the subject is science, including science education. I'm thinking I'd be all for getting a sledgehammer out and pounding into some people's thick skulls until they get it :(

Comment Re:why? (Score 1) 311

It's better if those few crucial features are in a process that can be restarted without having to reboot the kernel after a panic! That's the whole point. If a console server process fails, it simply gets restarted and that's it. You get your consoles back. That's reliable software to me. The alternative would be a kernel oops or a panic. Even if a kernel keeps running after an oops, you should normally reboot at the earliest opportunity because you can't be sure without examining the oops in detail to what extent kernel's internal data structures are consistent. A panic is simply an immediate forced reboot, an oops is a reboot that's forced but may be postpone-able -- IMHO an oops is only postponeable if there's a pair of understanding eyes that can examine the oops, check where in the kernel it happened, and how safe it is to continue. Otherwise, an oops should result in an instant reboot, but preceded with as much of an orderly shutdown as possible. For the most part this means: send sigterm to database and cache processes, send sigkill to all other processes, wait for the terminated processes to shutdown within some window of opportunity, kill them after the window has passed, recursively unmount filesystems, reboot.

Comment Re:why? (Score 3, Insightful) 311

It's not a long stretch to imagine that you can start a userspace process long before all of the kernel drivers are initialized. It's basically a big waste of time that the kernel delays starting init to *after* all the drivers are initialized. It's a waste of time. The applications that depend on functionality of certain parts of the kernel should simply wait until those parts become available. That's all there's to it. Also, the drivers can be initialized in parallel. No reason for the network card driver initialization not to run in parallel with waiting for the scsi raid driver to come up. The console doesn't need any of that and can be started up as the first thing, even if it were a userspace driver. Kernel usually starts off an initrd image, that's where the console application would be. I think it'd be wonderful if the kernel went in this direction, not only for console but for all other drivers as well. The applications that need to wait for certain things can get notifications when drivers get ready.

Comment Re:why? (Score 0) 311

It's fine if the userspace console process will be less stable. It can restart without undue consequences! Fail fast, isolate failures. That's the way to reliable software. Ericsson people knew what they were doing when they were coming up with Erlang's approach to handling software failure. It's 20 years later and linux kernel people finally get the message. I applaud that.

Comment Re:why? (Score 3, Interesting) 311

What's wrong with it being in the userspace? At least if it crashes, it doesn't bring the whole kernel down. The process is relaunched by the kernel, and off you go. It's the Erlang mantra of reliable software: fail fast, in limited scope. I love it. That's why I'm a big fan of userspace drivers for all devices that are application-specific. Suppose you have a USB-based toy that has a vendor-specific functionality and isn't one of the standard USB device classes. You have an application for. It should only have a userspace driver bundled with the application. You start the app, it claims any USB devices it can handle, and goes from there. That's often how it's done on OS X, it's quite onpopular on Windows, unfortunately.

Comment Re:Why is it so bad? (Score 1) 167

That's what any web browser does. Flash does not run native code directly from untrusted sources, just as web browsers don't. Usually, the content exploits the bugs that let you run some binary code directly, but it's not because shipping native code around is how it was supposed to work. Both web browsers and flash players get executable content they have to compile to native code and run, or at least run on a bytecode machine.

Comment Re:I Got It! (Score 1) 538

For ATMs, you don't really need much besides a 4 or 5 digit PIN. It's not usable in any other context, and the devices that are authorized to submit PINs are somewhat regulated. Historical data shows that 4 digit PINs are sufficient at keeping bank losses at manageable levels, and that's that.

I think that all too often the technical solutions to people problems such as you propose don't really work, because at the source it's not really about any sort of an absolute impossibility, but about willingness of people to actually expend some effort on keeping them safe. We're talking about stuff that's fairly easy, but people will come up with all sorts of reasons why it's a hassle for them. No matter how simple and easy you make it, people will still claim it's a hassle. For an eye opener, read some technology and other stories from notalwaysright.com.

There's no need for biometrics, everyone has got their brain already. Use it or lose it.

Comment Re:Doesn't work (Score 1) 419

He didn't claim anything that was theoretically impossible at the time, even if it was an impractical device, and still is. I'll take hand-crank mechanical calculators and a bunch of ladies over a purely mechanical general-purpose computing machine, anytime. It's just not practical. For an idea as to how to properly use low tech computing devices and people, look no further than Feynman's involvement in the Manhattan Project.

Babbage didn't go through much hype or secrecy, nor did he bilk any investors out of their money for something impossible on its face... He was comparatively low key, non aggrandazing guy. This is in sharp conrast to all those "genius" zero-point-energy, antigravity, momentum-nonpreservation scammers.

Slashdot Top Deals

You are in the hall of the mountain king.