WHile that ma be true, it's equally true that the balance between adding more manpower for depth of content, and for vamping up the game engine to add even more of the snazzy 100fps foobar-shaded surface-bump-mapped depth-perception-enhanced mtion-blurred 3 1/2 D-effects which the technogamer magazines rave on and on about, is too often skewed in favor of the latter.
Then again, I'm probably the wrong guy to talk at all here, since the only gaming I do is in multiuser text-only MUDs. No graphics...
There's no way I want to visually scan 17 Megs of source to make sure there's nothing fishy.
Enough people habitually do exactly that. Maybe not the whole kernel source, but the patches.
It's also a matter of attitude. IMHO, the average person skillful enough to spot a security problem in the Linux kernel will report it to somebody who can fix it (if they don't do it themselves).
The average person who spots a new problem in Windo*s, on the other hand, will probably write an exploit for it.
You can go over its design to understand its theoretical limits. (Note the missing apostropes...:-/)
"Tacoma Narrows", 1940-11-07. In other words, no you can't, except in simple cases.
The same thing applies to software. The good thing is, with software you can do a whole bunch of tests much more easily than with a complicated physical structure, or a medical problem for that matter. Extreme Programming, while somewhat extreme:-), has some things to say about this topic.
Simple reason: Those beasts are mass-produced. They make one master and then physically bake+burn-or-whatever a few thousand 100% identical copies from it. Making the master is the only expensive part of this process.
They could use CD-RWs instead, but burning them takes too long, which would eat into profits even faster than the cost of the CD-RWs.
We definitely need graphical network monitoring tools.
Ethereal. Easy to use, graphical. Why RH doesn't include it is anybody's guess -- but it's easy to install it yourself, I just did it from CVS in ten minutes.
The whole thing was brought over wholesale from NetBSD.
NOT. Please don't spread this nonsense.
There once was a port of the NetBSD stack from Linux (I should know -- I did it), but it was a gross hack, and none of it ever ended up in any official kernel.
I'm using sockets. Named pipes are unidirectional, so I'd have to set up a second pipe for the return traffic.
Anyway, any sensible operating system should have identical performance for unix-domain sockets and named pipes.
The reason you haven't heard of OpenTrader is probably that there hasn't been any announcement yet.;-) We'll have to finish at least one module that actually does any real-world trading, or nobody will take the thing seriously. For reasons of pure arbitrariness, that module will probably be one that talks to Datek.
You might as well say that not everyone runs stdlib.
Not everybody does, right. Or even stdio. Ever looked at qmail source code?
To go back on topic: for my current project (OpenTrader -- no code yet, but getting close), I've gone the multiple-process way, for debuggability. It's much easier to trace whatever is happening with a hung or runaway background process without all those pesky X events getting in the way...
The hardware is closed. I can understand that decision. Hell, if I made expensive hardware which operates in an electronically noisy environment, I won't risk additional warranty problems with people fiddling around inside -- there are too many people out there who think they know what they're doing. The software is open enough for me.
That's fun, but I'd rather see an ARM system. Much less power consumption, and there already are a bunch of Linux systems that use it, like the Empeg car radio.
Re:This also violates 2nd Law of Thermo
on
Darwin's Radio
·
· Score: 1
Forget it. To recap, their machine rotates some gas (eg, air), pushes a piston into the partial vacuum at the center (presumably), then slows it down, and retracts the piston, thereby cooling the gas (pushing the piston in is less work than getting it out again). They conveniently ignore the fact that even if one ignores the friction between the gas molecules, which they'll not be able to do, slowing down the gas is going to be more work than speeding it up. Therefore the Second Law still holds. Too bad for the shareholders...
Slashdot Mirror
WHile that ma be true, it's equally true that the balance between adding more manpower for depth of content, and for vamping up the game engine to add even more of the snazzy 100fps foobar-shaded surface-bump-mapped depth-perception-enhanced mtion-blurred 3 1/2 D-effects which the technogamer magazines rave on and on about, is too often skewed in favor of the latter.
Then again, I'm probably the wrong guy to talk at all here, since the only gaming I do is in multiuser text-only MUDs. No graphics...
Enough people habitually do exactly that. Maybe not the whole kernel source, but the patches.
It's also a matter of attitude. IMHO, the average person skillful enough to spot a security problem in the Linux kernel will report it to somebody who can fix it (if they don't do it themselves).
The average person who spots a new problem in Windo*s, on the other hand, will probably write an exploit for it.
"Tacoma Narrows", 1940-11-07. In other words, no you can't, except in simple cases.
The same thing applies to software. The good thing is, with software you can do a whole bunch of tests much more easily than with a complicated physical structure, or a medical problem for that matter. Extreme Programming, while somewhat extreme :-), has some things to say about this topic.
Simple reason: Those beasts are mass-produced. They make one master and then physically bake+burn-or-whatever a few thousand 100% identical copies from it. Making the master is the only expensive part of this process.
They could use CD-RWs instead, but burning them takes too long, which would eat into profits even faster than the cost of the CD-RWs.
Ethereal. Easy to use, graphical. Why RH doesn't include it is anybody's guess -- but it's easy to install it yourself, I just did it from CVS in ten minutes.
The whole thing was brought over wholesale from NetBSD.
NOT. Please don't spread this nonsense.
There once was a port of the NetBSD stack from Linux (I should know -- I did it), but it was a gross hack, and none of it ever ended up in any official kernel.
Anyway, any sensible operating system should have identical performance for unix-domain sockets and named pipes.
The reason you haven't heard of OpenTrader is probably that there hasn't been any announcement yet. ;-) We'll have to finish at least one module that actually does any real-world trading, or nobody will take the thing seriously. For reasons of pure arbitrariness, that module will probably be one that talks to Datek.
Not everybody does, right. Or even stdio. Ever looked at qmail source code?
To go back on topic: for my current project (OpenTrader -- no code yet, but getting close), I've gone the multiple-process way, for debuggability. It's much easier to trace whatever is happening with a hung or runaway background process without all those pesky X events getting in the way...
The hardware is closed. I can understand that decision. Hell, if I made expensive hardware which operates in an electronically noisy environment, I won't risk additional warranty problems with people fiddling around inside -- there are too many people out there who think they know what they're doing. The software is open enough for me.
That's fun, but I'd rather see an ARM system. Much less power consumption, and there already are a bunch of Linux systems that use it, like the Empeg car radio.
Forget it. To recap, their machine rotates some gas (eg, air), pushes a piston into the partial vacuum at the center (presumably), then slows it down, and retracts the piston, thereby cooling the gas (pushing the piston in is less work than getting it out again). They conveniently ignore the fact that even if one ignores the friction between the gas molecules, which they'll not be able to do, slowing down the gas is going to be more work than speeding it up. Therefore the Second Law still holds. Too bad for the shareholders...
Yeah, and then they turn around and use 0L instead of NULL everywhere.
No thanks; personally, I'd rather use GTK+/Gnome, at least that one can be easily used with other languages than C++.