At a certain large Canadian technology company, after having the email shut down by a Word macro virus panic, I once wrote a program that identifies attachments with a ".doc" extension that are actually ".dot" files (Word document templates that could contain macro viruses). If it was a real ".doc", it just opened the file with Word; if it was a ".dot", it put up a dialog box with big biohazard signs that said "This is a falsely labeled file! It could carry a virus or trojan horse! ARE YOU SURE YOU WANT TO OPEN IT?"
Everyone who saw it, including my boss, agreed that it solved the problem completely. However, nobody installed it, and nobody outside of my department was shown it. It was almost certainly deleted shortly after I left the company, and the vulnerability (to a few specific viruses) solved several months later by purchasing expensive anti-virus software.
Home users have an excuse: most of them are ignorant. They have a vague idea of some portion of what's on their hard drive and what's on the internet, and of the difference between an application and a document. Corporations, though, want a simple solution: money out, invulnerability to viruses in. The answers have been jumping up and biting them on the nose from any halfway decent MIS department, from security websites, from annoyed articles in the trade papers, but the managers involved want their computers to "just work", and not be bothered with having to think (or making all their employees apply common sense, which, I must admit, is about as difficult as teaching cats to march in formation).
A.K.A. Windows NT, unrelated to the other BSDs, this one stands for Blue Screen of Death.
Some people claim that MS can't produce a stable operating sytem, but winBSD is the ultimate in stability. Once you manage to boot winBSD (inexplicably, there is no official option to boot directly into it, but there are many ways to start it), it will run forever, disregarding anything short of a power outage.
Some may complain that there is no software for winBSD, but people make the same complaint about Linux, and the same answer applies: that doesn't make the OS bad. You can already enjoy such entertaining games as "Swear at the Screen" and "Ignore all Inputs". So start developing for winBSD today!
Linux is not a good environment for viruses, but it's not impervious either. Even a half-assed capabilties system would greatly improve Linux virus security.
For example, how often do you use "su; make install"? That hands over full authority to do anything. It would not be all that hard to hide, say, literal strings of Perl bytecode in a deeply recursive make, that search all *.tar.gz|*.tgz files for just such a deeply recursive make and hide itself in the ones it finds (cryptic nonsense marked with cute yet unhelpful comments is nothing new to free software; if it was obfuscated to look like a cute piece of ASCII art, it might not even need to justify its existence as part of the project). Combine this with infecting key utilities, like gcc and make, and you've got yourself an annoyingly persistent and sneaky virus.
Even though it would be more useful to have a full capabilties system, like in EROS, a good "execute with permissions + limited capabilities" utility could prevent root-mode installation infections.
For example:capsdo -cu -wnf/usr/local/bin -cwd/usr/local/lib -c "make install" meaning, run "make install" like current user (-cu), except that you can write new files (-wnf) to/usr/local/bin and create new directories to which it has full write access (-cwd) in/usr/local/lib (of course, it would require your root password to run). Not that this would be easy to write. It would have to sit between the app and the kernel, filtering actions.
Another way safety might be improved (at the admin level) is to create an "installer" group that has access to the "/usr/local" tree, and a new user in the group for each new installation; none of which gives write access for its files to any other user. A root utility could create and manage these psuedousers without bothering the admin. However, this would do nothing for holes like running SVGALIB games.
Okay, it wasn't exactly pure brute force, but it's still pretty close. A human player analyses the pattern of the pieces and considers maybe a dozen moves. Deep Blue can generate 200,000,000 board positions per second, so brute-forcing 3 moves ahead isn't remotely a problem (and is almost certainly part of its strategy). The time allowed for a move in chess is 3 minutes, enough time for the latest Deep Blue to consider 60 billion moves.
It's still a situation of having a very primitive chess player spending the human equivalent of thousands of years per move.
While shogo (Japanese chess) does not really seem a lot more complex to humans, there are a lot more options at each turn. Since the (rather sad) state of the art in chess is simple brute force algorithms (check every possible move for several turns down the road, see which one puts you in the best spot; Deep Blue did this), this means that computers aren't nearly as good at shogo as at chess.
The choice of games makes a big difference. I'm not impressed when a computer beats all humans at chess by recursing through all possible moves any more than I am by a perfect tic-tac-toe player or a calculator that is always accurate to eight decimal places in no perceptable time.
BTW, I think game AI (and silly things like chatterbots) is more aptly named than "AI as it is practiced at places like MIT". To me, an AI is a program that pretends to be human, not an algorithm that solves a certain class of problem.
"Who Wants To Be A Millionaire" is the American version of a British show. Only... nobody there ever won the big prize (the insurance company that pays the prizes is rather upset).
The shopkeepers, the miners, the staff officers, bureaucrats, and various other varieties of drudge should not be players. You don't interact with them in meaningful (i.e. non-mechanical) ways, anyhow.
It's the bounty hunters, ambitious military officers, rebel agents, etc. that are the fun roles to play, and the people you want to be unpredictable allies or opponents.
If you don't fill out the worlds with simulated normal, boring people, there is no sense of reality.
Don't worry about not meeting them, your common interests will draw you to each other.
Well, in theory it's simple. If you made it, you own it, and you can release it and re-release it under as many licences as you like, whenever you like (though of course you can't unrelease any open-source code).
However, when others modify it, they own those modifications, so in theory, if you want to base a proprietary product on an open-source product, you have to secure the permission of the author of every modification.
Here's where it gets tricky: if you can't contact (or secure the cooperation of) all the authors, you can recreate their work. You are free to read their code and use the ideas. But here the line between copying and recreation from ideas blurs.
Say you release a GPL'd program and someone fixes a for(i=0; i<limit; i++) loop to for(i=0; i<=limit; i++) and this cures a boundary condition bug. What kind of copyright hold do they have on the insertion of a single character? Should you delete the '=' and reinsert it? Would even that be legal, or would you have to express it differently? (this is the minimal example, but the issues are essentially the same for all true bug fixes)
I don't have any answers as to how this would work out in court, and I suspect nobody else does either (I'd happily be demonstrated wrong, though). Copyright was not designed to protect the formal specification of mechanisms, and doesn't really deal very well with multiple holders with dramatically different levels of contribution anyway. It certainly wasn't designed with anything like the GPL in mind. If anyone can come up with a relevant legal precedent (either from the software world or, say, when a proofreader or editor claimed copyright on fixes or other changes he made to a story), I'd be very interested.
If you want a 3-book-long lovemaking session to the planet Mars, I highly suggest Kim Stanley Robinson's _RED MARS_, _GREEN MARS_, and _BLUE MARS_. They get progressively more boring and uninspired...
Uh, gee, thanks. Do you recommend any other boring, uninspired books for me to read? I'm sensing some hostility here.
What exactly do you mean by a "lovemaking session" anyway? Oh right, that's where somebody can't keep track of how many books are in the series, so they should take all the books to Mars and screw a sand dune while reading each one, then just count the holes, conclusively proving that they're dumber than fucking dirt on Mars. (sorry, this is as bad as my posts get, I hope)
...if the general-purpose hardware wasn't so stupid. Of the millions of transistors on a modern chip, most of them are wasted in maintaining the illusion of sequential operation, while the OS writers go to considerable trouble to create the illusion of parallel operation.
Furthermore, there are the huge (in terms of transistor count) banks of flip-flops which just sit around most of the time, and the costly layers of cache all working their hardest to maintain the illusion that it is RAM. Meanwhile, software optimizers make sure to access memory sequentially to avoid upsetting this illusion, which would ruin the performance.
You can justify all this nonsense with the argument that software is written for sequential machines with RAM. It's a circular problem. If somebody would just release a cheap massively parallel system, the programmers would learn to use it efficiently.
You can make a complete processor in a few thousand transistors (as this guy has done, though he goes a bit off the deep end...), and you can add a bit (a few K) of high-speed RAM and network them easily enough to make a (dare I say it?) Beowulf cluster on a chip. Each might only run at one tenth the speed of a modern CPU, but you could have hundreds of them for the same cost, giving you bips and gflops for the price of mips.
It would also make the whole design process a lot easier and faster. One simple processor, repeated hundreds or thousands of times. Every advance in production would bring a direct and proportional improvement in performace, with a tiny added design cost. Forget special graphics or sound processors, just plug in more processor banks like you would add memory today and watch your system fly.
C'mon hardware guys, we software guys aren't that stupid! We don't need your illusion of a 386!
I hate the way Windows handles floppies. It grinds away at random times and pops up error dialogs, instead of just not considering the (diskless) drive as an option. I don't really like the Linux way of having to manually mount them, either, but I prefer it. It represents the system state without a floppy more accurately, as an absence rather than an error state.
The hardware ought to be fixed up, so it tells the OS when someone pops a floppy in, and prevents the user from ejecting the disk when it is in use (with the main button, though there should be an auxiliary mechanical button for emergency use, just like a CD-ROM).
Linux systems can be configured to automount CD-ROMs, because CD-ROM drives don't have a completely braindead design like PC floppy drives.
I agree with the curved surface rendering, and collision detection, but not the rest.
Depth of field is not appropriate for interactive games. In RL you refocus your eyes to look at different things, if you can't refocus just by controlling your eyes, you'd be half blind. It'd drive people crazy.
Integrated physics would lock the programmer into a certain physics model. Physics is not terribly CPU intense, and the demands vary a lot from game to game. Having specialized physics hardware on the video card is about as appropriate as having specialized AI hardware (IOW, it's not).
Voxels are either huge memory pigs or butt ugly. They might make nice 3d texture maps (if you're okay with fuzzy interpolation), but I wouldn't want to bother with them for whole 3d models.
Chromatics are a waste. They are so rarely useful that it would be better to special case the lighting effects when needed.
Radiosity would be nice, but it's not something you can just pipeline in (ditto for casting rays). However, there might be cheaper ways to get the same effect.
Oh, come on! That is the most childish RPG I've ever tried!
Nobody and nothing ever dies, there's nothing remotely resembling an adult plot, all the main characters are children, and it's very easy (it takes a long time, and there are a lot of little details you can learn, but it's still easy). Everything about it suggests that it was made for children.
When you digitize real world textures, laserscan objects to get surface meshes, and motion capture the animation, is it still really CG? Or just digitally altered?
A lot of human effort besides mouse/keyboard/monitor interactions went into producing these images. Simply calling them "computer generated" is like calling rotoscoped cartoons "hand-drawn animation".
...feel strangely like viewing a page of celebrity nudes? If only they had a half-dozen popups which redirect you to pages like "Emotion Engine acid-strip show!", "two female connectors coupled!", and "Brazilian Plug Pornography!"... (sigh)
(olives have MANY more calories than apples, but as that doesn't take into account digestibility, that isn't a measure of anything -real-.)
Unfortunately, there is no genuinely useful measure of value of a fruit, and all the benchtests that exist are catastrophically flawed.
Personally, I think the giant apple is an over-bloated lump of fruit. I feel that it's time that it got divided into a pile of high-calorie olives that -pretended- to be a single apple. That way, you'd get the calories of olives, with the convenience of one apple.
However, this is getting off-track. To get back to the main point, if you are going to use/need a single, simple benchmark, the calories rating is far, far superior to the weight, because at least it measures how much energy the fruit contains. A 1000 pound fruit could only have 1 calorie per pound - what use is that to anyone?
Sometimes "it's just more" is all the argument you need, when you're comparing apples to apples.
As a philosopher he's a joke. His views are not self-consistent. The whole free software thing basically comes from a pleasant time in his life when all the software he saw was software he could hack. His whole justification is basically "that was nice, let's do that." He has other rationalizations, but they are recognizable as such by the way they break down on logical examination.
If he hadn't come along, Linux would have been another free BSD variant. The people who put their work into GNU projects would have put their work into other free projects and we'd have more or less the same stuff.
All in all, I think we would have been better off without him. He's an annoying nut who makes the rest of us look crazy and is always trying to steal the spotlight and tell us how most programmers should be broke like most musicians (go read his stuff, if you think I'm making that up). We could live without the GPL, and we could certainly live without Eight Megs And Constantly Swapping!
That source code be free is not so important. It's nice, but not crucial. What is important is that standards be open. It is essential that anyone willing to invest the effort (and smart enough to manage the task) be able to build their own replacement for any one part. Secret instruction sets are wrong, patented reading mechanisms are wrong, proprietary interfaces of all types are wrong.
The problem which destroys freedom is not that we can't see the internals of others' mechanisms, but that we aren't even able to produce devices which connect to the interface visible on the surface, or to produce fully compatible replacements for these proprietary devices.
For me, the obvious example of this is the gaming console. It is absolutely unacceptable that the producers of the console have control over who produces games and peripherals for the console. Sure, you'd have to pay more for your new Nintendo toy, but you'd save the difference in the cost of games, plus you would have the freedom to be your own censor, rather than allowing Nintendo to decide what games are good for their company image, and therefore acceptable for you to play.
The importance of open interfaces should be written into all IP laws. If all interfaces are open, then proprietary and open devices can coexist and free market dynamics assert themselves over the strange positive-feedback dynamics of gatekeeper marketing strategies reinforced by outdated IP laws.
Sure, UNIX was designed for mainframes running a bunch of dumb terminals, but the average pocket calculator these days has more computing power than those old mainframes.
The overhead is simply not an issue. You can fit a useful Linux distro on a floppy and run it on a 386. This is easily small and efficient enough for a palmtop.
Linux is nice because it's free and there's lots of free software for it. Why reinvent the wheel? Instead of needing a massive promotional campaign to get developers to make stuff for it, you've already got a pile of useful software.
Slashdot Mirror
At a certain large Canadian technology company, after having the email shut down by a Word macro virus panic, I once wrote a program that identifies attachments with a ".doc" extension that are actually ".dot" files (Word document templates that could contain macro viruses). If it was a real ".doc", it just opened the file with Word; if it was a ".dot", it put up a dialog box with big biohazard signs that said "This is a falsely labeled file! It could carry a virus or trojan horse! ARE YOU SURE YOU WANT TO OPEN IT?"
Everyone who saw it, including my boss, agreed that it solved the problem completely. However, nobody installed it, and nobody outside of my department was shown it. It was almost certainly deleted shortly after I left the company, and the vulnerability (to a few specific viruses) solved several months later by purchasing expensive anti-virus software.
Home users have an excuse: most of them are ignorant. They have a vague idea of some portion of what's on their hard drive and what's on the internet, and of the difference between an application and a document. Corporations, though, want a simple solution: money out, invulnerability to viruses in. The answers have been jumping up and biting them on the nose from any halfway decent MIS department, from security websites, from annoyed articles in the trade papers, but the managers involved want their computers to "just work", and not be bothered with having to think (or making all their employees apply common sense, which, I must admit, is about as difficult as teaching cats to march in formation).
A.K.A. Windows NT, unrelated to the other BSDs, this one stands for Blue Screen of Death.
Some people claim that MS can't produce a stable operating sytem, but winBSD is the ultimate in stability. Once you manage to boot winBSD (inexplicably, there is no official option to boot directly into it, but there are many ways to start it), it will run forever, disregarding anything short of a power outage.
Some may complain that there is no software for winBSD, but people make the same complaint about Linux, and the same answer applies: that doesn't make the OS bad. You can already enjoy such entertaining games as "Swear at the Screen" and "Ignore all Inputs". So start developing for winBSD today!
I advise you to consult with your lawyer before advising anyone to consult with their lawyer.
Oh, wait, IANAL! Curses, I am doomed! doomed...
Linux is not a good environment for viruses, but it's not impervious either. Even a half-assed capabilties system would greatly improve Linux virus security.
For example, how often do you use "su; make install"? That hands over full authority to do anything. It would not be all that hard to hide, say, literal strings of Perl bytecode in a deeply recursive make, that search all *.tar.gz|*.tgz files for just such a deeply recursive make and hide itself in the ones it finds (cryptic nonsense marked with cute yet unhelpful comments is nothing new to free software; if it was obfuscated to look like a cute piece of ASCII art, it might not even need to justify its existence as part of the project). Combine this with infecting key utilities, like gcc and make, and you've got yourself an annoyingly persistent and sneaky virus.
Even though it would be more useful to have a full capabilties system, like in EROS, a good "execute with permissions + limited capabilities" utility could prevent root-mode installation infections.
For example:capsdo -cu -wnf /usr/local/bin -cwd /usr/local/lib -c "make install" /usr/local/bin and create new directories to which it has full write access (-cwd) in /usr/local/lib (of course, it would require your root password to run). Not that this would be easy to write. It would have to sit between the app and the kernel, filtering actions.
meaning, run "make install" like current user (-cu), except that you can write new files (-wnf) to
Another way safety might be improved (at the admin level) is to create an "installer" group that has access to the "/usr/local" tree, and a new user in the group for each new installation; none of which gives write access for its files to any other user. A root utility could create and manage these psuedousers without bothering the admin. However, this would do nothing for holes like running SVGALIB games.
Ladies and Gentlemen (and trolls), I give you the SpringWalker Not a bad base to build from, eh?
Heh, heh, shogo is a little different.
Okay, it wasn't exactly pure brute force, but it's still pretty close. A human player analyses the pattern of the pieces and considers maybe a dozen moves. Deep Blue can generate 200,000,000 board positions per second, so brute-forcing 3 moves ahead isn't remotely a problem (and is almost certainly part of its strategy). The time allowed for a move in chess is 3 minutes, enough time for the latest Deep Blue to consider 60 billion moves.
It's still a situation of having a very primitive chess player spending the human equivalent of thousands of years per move.
While shogo (Japanese chess) does not really seem a lot more complex to humans, there are a lot more options at each turn. Since the (rather sad) state of the art in chess is simple brute force algorithms (check every possible move for several turns down the road, see which one puts you in the best spot; Deep Blue did this), this means that computers aren't nearly as good at shogo as at chess.
The choice of games makes a big difference. I'm not impressed when a computer beats all humans at chess by recursing through all possible moves any more than I am by a perfect tic-tac-toe player or a calculator that is always accurate to eight decimal places in no perceptable time.
BTW, I think game AI (and silly things like chatterbots) is more aptly named than "AI as it is practiced at places like MIT". To me, an AI is a program that pretends to be human, not an algorithm that solves a certain class of problem.
Religion began when the first rogue met the first fool.
So it was, so it is, so it ever shall be.
"Who Wants To Be A Millionaire" is the American version of a British show. Only... nobody there ever won the big prize (the insurance company that pays the prizes is rather upset).
The shopkeepers, the miners, the staff officers, bureaucrats, and various other varieties of drudge should not be players. You don't interact with them in meaningful (i.e. non-mechanical) ways, anyhow.
It's the bounty hunters, ambitious military officers, rebel agents, etc. that are the fun roles to play, and the people you want to be unpredictable allies or opponents.
If you don't fill out the worlds with simulated normal, boring people, there is no sense of reality.
Don't worry about not meeting them, your common interests will draw you to each other.
Well, in theory it's simple. If you made it, you own it, and you can release it and re-release it under as many licences as you like, whenever you like (though of course you can't unrelease any open-source code).
However, when others modify it, they own those modifications, so in theory, if you want to base a proprietary product on an open-source product, you have to secure the permission of the author of every modification.
Here's where it gets tricky: if you can't contact (or secure the cooperation of) all the authors, you can recreate their work. You are free to read their code and use the ideas. But here the line between copying and recreation from ideas blurs.
Say you release a GPL'd program and someone fixes a for(i=0; i<limit; i++) loop to
for(i=0; i<=limit; i++) and this cures a boundary condition bug. What kind of copyright hold do they have on the insertion of a single character? Should you delete the '=' and reinsert it? Would even that be legal, or would you have to express it differently? (this is the minimal example, but the issues are essentially the same for all true bug fixes)
I don't have any answers as to how this would work out in court, and I suspect nobody else does either (I'd happily be demonstrated wrong, though). Copyright was not designed to protect the formal specification of mechanisms, and doesn't really deal very well with multiple holders with dramatically different levels of contribution anyway. It certainly wasn't designed with anything like the GPL in mind. If anyone can come up with a relevant legal precedent (either from the software world or, say, when a proofreader or editor claimed copyright on fixes or other changes he made to a story), I'd be very interested.
IANAL, TINLA
If you want a 3-book-long lovemaking session to the planet Mars, I highly suggest Kim Stanley Robinson's _RED MARS_, _GREEN MARS_, and _BLUE MARS_. They get progressively more boring and uninspired...
Uh, gee, thanks. Do you recommend any other boring, uninspired books for me to read? I'm sensing some hostility here.
What exactly do you mean by a "lovemaking session" anyway? Oh right, that's where somebody can't keep track of how many books are in the series, so they should take all the books to Mars and screw a sand dune while reading each one, then just count the holes, conclusively proving that they're dumber than fucking dirt on Mars. (sorry, this is as bad as my posts get, I hope)
He st uck a whole computer in a mouse</a>, apparently just for the hell of it. Knowing him, it probably wouldn't cost significantly more than an ordinary mouse, either.
...if the general-purpose hardware wasn't so stupid. Of the millions of transistors on a modern chip, most of them are wasted in maintaining the illusion of sequential operation, while the OS writers go to considerable trouble to create the illusion of parallel operation.
Furthermore, there are the huge (in terms of transistor count) banks of flip-flops which just sit around most of the time, and the costly layers of cache all working their hardest to maintain the illusion that it is RAM. Meanwhile, software optimizers make sure to access memory sequentially to avoid upsetting this illusion, which would ruin the performance.
You can justify all this nonsense with the argument that software is written for sequential machines with RAM. It's a circular problem. If somebody would just release a cheap massively parallel system, the programmers would learn to use it efficiently.
You can make a complete processor in a few thousand transistors (as this guy has done, though he goes a bit off the deep end...), and you can add a bit (a few K) of high-speed RAM and network them easily enough to make a (dare I say it?) Beowulf cluster on a chip. Each might only run at one tenth the speed of a modern CPU, but you could have hundreds of them for the same cost, giving you bips and gflops for the price of mips.
It would also make the whole design process a lot easier and faster. One simple processor, repeated hundreds or thousands of times. Every advance in production would bring a direct and proportional improvement in performace, with a tiny added design cost. Forget special graphics or sound processors, just plug in more processor banks like you would add memory today and watch your system fly.
C'mon hardware guys, we software guys aren't that stupid! We don't need your illusion of a 386!
I hate the way Windows handles floppies. It grinds away at random times and pops up error dialogs, instead of just not considering the (diskless) drive as an option. I don't really like the Linux way of having to manually mount them, either, but I prefer it. It represents the system state without a floppy more accurately, as an absence rather than an error state.
The hardware ought to be fixed up, so it tells the OS when someone pops a floppy in, and prevents the user from ejecting the disk when it is in use (with the main button, though there should be an auxiliary mechanical button for emergency use, just like a CD-ROM).
Linux systems can be configured to automount CD-ROMs, because CD-ROM drives don't have a completely braindead design like PC floppy drives.
I agree with the curved surface rendering, and collision detection, but not the rest.
Depth of field is not appropriate for interactive games. In RL you refocus your eyes to look at different things, if you can't refocus just by controlling your eyes, you'd be half blind. It'd drive people crazy.
Integrated physics would lock the programmer into a certain physics model. Physics is not terribly CPU intense, and the demands vary a lot from game to game. Having specialized physics hardware on the video card is about as appropriate as having specialized AI hardware (IOW, it's not).
Voxels are either huge memory pigs or butt ugly. They might make nice 3d texture maps (if you're okay with fuzzy interpolation), but I wouldn't want to bother with them for whole 3d models.
Chromatics are a waste. They are so rarely useful that it would be better to special case the lighting effects when needed.
Radiosity would be nice, but it's not something you can just pipeline in (ditto for casting rays). However, there might be cheaper ways to get the same effect.
Oh, come on! That is the most childish RPG I've ever tried!
Nobody and nothing ever dies, there's nothing remotely resembling an adult plot, all the main characters are children, and it's very easy (it takes a long time, and there are a lot of little details you can learn, but it's still easy). Everything about it suggests that it was made for children.
When you digitize real world textures, laserscan objects to get surface meshes, and motion capture the animation, is it still really CG? Or just digitally altered?
A lot of human effort besides mouse/keyboard/monitor interactions went into producing these images. Simply calling them "computer generated" is like calling rotoscoped cartoons "hand-drawn animation".
...feel strangely like viewing a page of celebrity nudes? If only they had a half-dozen popups which redirect you to pages like "Emotion Engine acid-strip show!", "two female connectors coupled!", and "Brazilian Plug Pornography!"... (sigh)
- Weight, in itself, isn't an indicator -
That was true of the old calorie ratings, too.
(olives have MANY more calories than apples, but as that doesn't take into account digestibility, that isn't a measure of anything -real-.)
Unfortunately, there is no genuinely useful measure of value of a fruit, and all the benchtests that exist are catastrophically flawed.
Personally, I think the giant apple is an over-bloated lump of fruit. I feel that it's time that it got divided into a pile of high-calorie olives that -pretended- to be a single apple. That way, you'd get the calories of olives, with the convenience of one apple.
However, this is getting off-track. To get back to the main point, if you are going to use/need a single, simple benchmark, the calories rating is far, far superior to the weight, because at least it measures how much energy the fruit contains. A 1000 pound fruit could only have 1 calorie per pound - what use is that to anyone?
Sometimes "it's just more" is all the argument you need, when you're comparing apples to apples.
As a philosopher he's a joke. His views are not self-consistent. The whole free software thing basically comes from a pleasant time in his life when all the software he saw was software he could hack. His whole justification is basically "that was nice, let's do that." He has other rationalizations, but they are recognizable as such by the way they break down on logical examination.
If he hadn't come along, Linux would have been another free BSD variant. The people who put their work into GNU projects would have put their work into other free projects and we'd have more or less the same stuff.
All in all, I think we would have been better off without him. He's an annoying nut who makes the rest of us look crazy and is always trying to steal the spotlight and tell us how most programmers should be broke like most musicians (go read his stuff, if you think I'm making that up). We could live without the GPL, and we could certainly live without Eight Megs And Constantly Swapping!
That source code be free is not so important. It's nice, but not crucial. What is important is that standards be open. It is essential that anyone willing to invest the effort (and smart enough to manage the task) be able to build their own replacement for any one part. Secret instruction sets are wrong, patented reading mechanisms are wrong, proprietary interfaces of all types are wrong.
The problem which destroys freedom is not that we can't see the internals of others' mechanisms, but that we aren't even able to produce devices which connect to the interface visible on the surface, or to produce fully compatible replacements for these proprietary devices.
For me, the obvious example of this is the gaming console. It is absolutely unacceptable that the producers of the console have control over who produces games and peripherals for the console. Sure, you'd have to pay more for your new Nintendo toy, but you'd save the difference in the cost of games, plus you would have the freedom to be your own censor, rather than allowing Nintendo to decide what games are good for their company image, and therefore acceptable for you to play.
The importance of open interfaces should be written into all IP laws. If all interfaces are open, then proprietary and open devices can coexist and free market dynamics assert themselves over the strange positive-feedback dynamics of gatekeeper marketing strategies reinforced by outdated IP laws.
...
...if the data is all zeros...
Sure, UNIX was designed for mainframes running a bunch of dumb terminals, but the average pocket calculator these days has more computing power than those old mainframes.
The overhead is simply not an issue. You can fit a useful Linux distro on a floppy and run it on a 386. This is easily small and efficient enough for a palmtop.
Linux is nice because it's free and there's lots of free software for it. Why reinvent the wheel? Instead of needing a massive promotional campaign to get developers to make stuff for it, you've already got a pile of useful software.