That's interesting; I thought people would notice a dropped frame just because it would mean that one frame would be shown twice as long as any of the rest, so everything would stop for a moment and then jump forward to the right place. Of course, traditionally when a frame gets dropped, the person sees a blank frame or static or something unrelated to the scene; people don't notice these at all, because the brain is wired to ignore them (because you blink and so forth). But having a frame update dropped means you'll see the previous frame for twice as long, which appears as a change in the motions of objects, which the brain is tuned to see.
I'm not sure exactly how many frame updates you can miss without people noticing, but it's got to be a lot fewer than frames you can blank without anyone noticing, especially if it's not consistent.
If you've got a Linux machine somewhere, you could do what I do. Install screen on the machine. In your.profile, test whether it's begin run on an ssh connection not in screen, and if so, do: screen -x -S home || screen -R -S home || bash and then exit
This won't take care of graphics, but it means that you'll have the exact session always running wherever you go. If you put a webserver which serves a MindTerm SSH client on the machine, you can go to the URL and continue working from any java-enabled browser.
If you want to use applications that not everyone has, you're going to have to store or run at least some programs on the server. Running them there generally makes the most sense, since that's where your data is, although if they fetch information for immediate display from third parties, doing that from the machine you're sitting at makes sense.
So what you really want is a widget toolkit where the communication between the program and the widgets is light enough to have over a network, that you're likely to have available on any machine use want to use. I don't think there is such a thing so far with more capabilities than a color xterm, unfortunately.
You're not going to get more cortex just by getting more input. The parts of your brain that would go to processing this input would no longer be available for their original tasks. So it's not so much them getting 'lazy' as getting less of your processing power.
Of course, getting existing brain structures to re-specialialize in order to deal with this input is probably very difficult in an adult. Fortunately, we have depth perception already, so we at least have structures for the processed data.
It seems to me that this is a promising idea. The various foods we like to eat are often made in the bodies of animals, but there's no reason that the cells that do it have to be in something with a nervous system. Of course, it couldn't have evolved that way, but the reason that meat is an inefficient food source is that it tends to wander around and look for food. We've just replaced the rest of the fish's body with a vat.
If this sort of research continues, we ought to be able to build what amounts to an ecosystem with the routing between various animal organs done with pipes instead of the rest of the animals.
The performance tests that various people have run with these patches seem to show improvements in throughput on servers. The guess is that this is because the machine will respond more quickly to the completion of I/O (which is, of course, is the slow step on most applications), so it essentially arranges tasks so that the next I/O operation can get started sooner.
Of course, you'd presumably get a higher load, since you're doing your task in less time, which means that the processor is busy more of the time.
Additionally, latency is important for interactive tasks on desktop machines, because it determines how responsive the system feels under load. The user's experience is determined more by how quickly the system responds to simple requests (moving the mouse cursor, drawing menus, etc) than by the milliseconds place on more complex tasks. Furthermore, the user will instantly notice if sound or video is not handled on time.
Re:Why couldn't a SPAMMER simply...
on
ORBZ Shuts Down
·
· Score: 2
The issue isn't spammers setting up their own servers as open relays. Spammers don't set up open relays; they use other people's open relays. If the spammers were setting up the servers, they would presumably have them only relay their spam, not everyone else's.
The issue is when person A sets up their server wrong and person B sends spam through it; person A isn't responsible for the message and person B is impossible to find.
I'm using RedHat 6.2 w/fvwm2 on my work machine and a slackware-ish homebrew w/fvwm2 on my home machine. The Linux GUIs we used to have we still have. It's just that people have the choice of using more bloated things. The beauty of using open source software is that you don't have to switch to the latest UI every couple of years. If you miss the old days, you can go back. You'll probably actually get a lot more done, too.
I'm running 2.4.18 and 4.0.(3?) on my home machine, and fvwm has never run nearly as well. The only time it's stopped responding, I needed to wiggle the keyboard connector.
What do they expect if they keep increasing taxes on magnetic media? The magnetic north pole is obviously going to want to move to somewhere cheaper, like Siberia.
Why, then, can't they detect that it's a Domino server and skip the check? If the obscure bug, in this case, causes the server to crash, rather than sending the message to its destination, the server isn't an open relay (and likely not to remain open at all if a spammer tries to use it).
SMTP servers tend to give their version information when you connect to them, and, while they may refuse to say, they're unlikely to lie, and especially unlikely to be set up to say they're Domino, not have this bug, and be an open relay.
You want to measure documentation separately, because it obviously isn't used in the same way as code.
For the code, the metric you'd actually like is something like number of useful, novel expressions.
Copying a section of code doesn't add anything, because the lines aren't novel. Any changes you make to the lines do count, though. Making an existing block of code into a separate procedure adds a novel expression, and the expression is useful if you call it from multiple places (i.e., if the procedure is a useful abstraction). Calling a procedure with a new set of arguments is novel and generally useful.
Basically, you want to know how long the day's work had to be, given the pre-existing code, if it was done optimally.
If you add a penalty for making the code needlessly long, then a day spent reworking bad code to be shorter by combining common expressions, removing extraneous computation, etc, will also be considered productive.
For the documentation, it is easier to consider but harder to quantify. You are now measuring the number of correct and useful pieces of information that a person would get out of reading the commented code. The information may, of course, be obvious from the control structure, implied by the variable names, or actually in comments; since comments add to the length of the code without adding any functionality, using coding idioms that the reader will know (because they're part of the company's style guide or common throughout the code) and informative names is better than putting in comments, unless it is impossible (which is frequently the case).
Of course, it's hard to quantify "pieces of information" and hard to judge objectively what can be gotten out of a block of code, which is one reason this isn't something you can set up cvs to do each day or something.
This means that the ideal block of code, which should be counted as the most possible for a given problem, has these properties: it (or an equivalent block) has to be there in order for the project to do what it's supposed to do; it is not replicated, in whole or in part, anywhere else in the project (if it did, it would do better to call the other part); its behavior is clear from the names of the procedures, variables, and types; any common algorithms are implemented in the standard ways; and unusual algorithms are commented explicitly.
I think this metric would measure productivity effectively. Of course, it doesn't help productivity to actually try to measure it.
The one of these I am familiar with does things with heap allocation, such that heap-allocated memory is separated by buffer zones of unallocated memory. This can be very helpful for checking bounds on accesses, but it won't catch everything.
First of all, it doesn't do anything with the stack, which is laid out by the program itself (with code generated by the compiler), and the most common buffer overruns are out of stack-allocated buffers into other parts of the same stack frame.
Similarly, it won't catch overruns of buffers in structs, where the overrun goes into adjacent fields but not out of the struct.
The essential problem is that nothing at runtime is keeping track of sizes of arrays and types of values, so incorrect usage cannot be detected. This information requires checks while running entirely non-library code, so it cannot be done by changing libraries.
It would be possible to find occurences of known common mistakes in different packages automatically, and to find instances of a known error throughout a large project. There is work on doing this with the linux kernel, where a group has turned up hundreds of potentially unsafe usages (mostly DoS-type, mostly in drivers).
This particular problem is not actually a buffer overflow at all, it turns out, and is more subtle.
There are commercial programs which can find this sort of error, assuming it actually happens while running an instrumented version of the code. These programs are in the expensive commercial development tool price range (order $10k), though, and very difficult to write.
Another possibility is to build and run the program under a virtual machine which checks these things; for example, if you turn your C into Java and run it, it shouldn't throw any out-of-bounds exceptions, or it indicates that your C wasn't checking array bounds. There isn't a C virtual machine (that I know of), though.
Okay, so you now you're distributing what are essentially platform-independent binaries, under the GPL. Anyone who gets these is licensed to distribute them freely, and they're allowed to produce modified versions, such as a recommented and sensible version.
Selling GPLed software depends on the gratitude of your customers. They'll be able to get it for free, but will have some reason to prefer paying to get it from you. It seems to me that providing only useless source in this situation will generate enough ill will that, regardless of the legality of what you're doing, you won't make any money.
In this context, other people being able to modify the program is the least of your worries.
FTP is not suitable for transferring files that aren't generally available, because it's not secure. FTP isn't any stronger than HTTP with basic authentication, and encrypted wrappers for HTTP are far better deployed (so far as I can tell) than for FTP.
HTTP only sort of works for "push" transfers, but in this case, people generally want enough authorization that scp is the correct tool.
I agree that HTTP makes a lousy RPC protocol, because it's no good when you are not, in fact, transferring anything. But this doesn't mean it isn't suitable for P2P, which is only sometimes RPC and frequently fits a request-response model.
Likewise, the fact that the response will be delayed isn't a problem with HTTP. You could post a URL as a form field, and the server can do a long request, and then PUT/POST the result to that URL. You could, instead, post an email address, and have the result emailled to you when it is ready. The only issue is that the second half of the exchange has to happen with a "push", over a separate connection. But that's going to be an issue with any protocol.
The whole firewall issue is silly. Few firewalls actually look at the packet contents, so you could just do RPC over TCP on port 80 and bypass the firewalls just as well.
HTTP is designed for the pattern of an independent request/response pair. This isn't the case in a lot of situations where people try to use it, and it's always a bad fit when they try. But there are a lot of situations where people traditionally use other protocols which, as commonly practiced these days, HTTP would work fine, and is better designed than the alternatives.
Actually, ftp is a lousy protocol for transfering files. It requires a persistent connection between transfers, uses a bunch of connections anyway, isn't designed for machine-machine interaction, and doesn't have a mechanism for content type information. HTTP is a "transfer" protocol, and there's nothing in particular that relates to hypertext in it.
HTTP is fine for P2P applications, in general; it's not hard to have a program the both makes and accepts HTTP requests.
HTTP is suitable for delayed responses, although the entity expecting an eventual response will have to be running an HTTP server. Of course, if you want to get a delayed response, you'll have to have somewhere to accept an incoming connection, whether it's a mail server, an HTTP server, or some weird new MS thing.
HTTP is not suitable for is negotiation, since you can't easily go back and forth multiple times (later interactions are not sufficently tightly connected to not need to send all of the information again). Of course, this is essentially what people are trying to use it for.
The Windows UI is slow to use. Even if you know what you're doing, it requires a lot of keyboard-mouse transitions, and a lot of clicking on small areas of the screen.
Windows is also hard to develop an intuition for. I have yet to meet anyone who, when asked to use a feature they've never used before, knows where to find it. People will generally use the same features they're accustomed to using, so people can deal with Windows pretty well: they learn where a few things are, and use those. In part, the Windows UI is broken intentionally, because people will only get a new version if the new version does something that the old one didn't, and, if the new version behaved as expected, people wouldn't use any features other than the features they already knew.
Looking at it from the frame of reference of the building, you're not moving. In the frame of reference of the slope, you are moving, but not accelerating, so it doesn't matter much.
The only situation in which you'd care about position is for angular momentum, which you don't have at all, because you're not turning.
Even if it's partially about momentum, you don't have any momentum if you're not moving, either. On any actual slope, I think the center of gravity aspect of tucking is much more for stability than speed-- if your center of gravity is low, you'll be able to turn more effectively, which is necessary when you're going faster, since people don't normally ski straight down hills competitively (except for ski jump, but even there, you don't care about your speed on the ramp, but your momentum at the end). So the effect of tucking other than drag is to increase the speed that you can deal with, not the speed you can attain.
Because the way Apple does it is totally unlike what any existing applications use and what any present users know how to use. OS X is already mystifying anyone accustomed to UNIX and/or MacOS by being significantly different from either.
"Hey, if you learn this totally new and unmotivated system, it will be user-friendly" is not a solution unless you're MicroSoft or Apple and have users who are used to having the system changed on them regularly (but, admittedly, each time to something consistent).
XML is almost certainly the right solution for structured data, but is a major pain for unstructured data. If you don't have at least two levels of sections which actually need to be sections (i.e., they get repeated or items in them have different meanings than identically named items in other sections), then XML is needlessly verbose, and therefore unfriendly for humans to deal with.
I think the right choice of standards would be an outer layer of RFC822 headers (which everyone has a parser for already, and which is trivial to implement anyway), with values which may be XML documents with predefined schemas, if there are structured configuration items.
RFC822 headers have the advantage of being as compact as possible, easier to parse (although there are libraries anyway), easier to use after parsing (it's a map of keys to values, nothing complicated like a tree; compare SAX to "get(key)"), and just as standard.
It'd probably be worth putting a header on top which let you choose the character set, and it would be good to include something to say which program (or library) the file is supposed to configure, and where the help/format file is.
If keys were required to not include '=' (treated the same as ':'), and to start with a letter or number (or the line would be ignored as a comment), this would take care of many existing config files.
The ALSA interface code is unquestionably much better; one of the main reasons for ALSA was to get a saner interface. Many of the drivers are better, and there are drivers for some cards that OSS didn't support at all. However, there are also some cards with more stable OSS drivers. Are there any plans to merge the driver set, keeping the better of the overlapping drivers, and spliting the driver choice from the interface choice? The reports I've heard say that the Yamaha OSS drivers are more stable, so it would be nice to stick with them without losing the up-to-date interface.
What do you pay your ISP for? To intercept your packets. Because otherwise, they're not getting anywhere. The person at the other end of your phone call is also allowed to tap the phone line with their telephone and listen. Wiretapping laws come into play only when the person listening is not the person whose wire it is. Otherwise it would be illegal for the phone system to route your calls to the person you're calling.
Unencrypted data is like postcards with respect to expectations of privacy: it doesn't have the digital equivalent of an envelope, and the address information is not separated from the content in any meaningful way. You can therefore not expect privacy of the data from anyone who is responsible for routing.
Unencrypted data is like postcards: there's nothing keeping them from the view of anyone who happens to look other than the fact that most people aren't actually in a position to see your mail at all.
You cannot reasonably have an expectation of privacy from the post office when sending postcards, although you can assume that random other people won't see them up close.
You have some expectation of privacy sending voice over the phone because there are specific laws regarding the data on the phone network which prohibit the phone carriers from looking at the data (as opposed to the routing information, which is separate).
It is illegal for some unrelated person to sniff your packets, but perfectly fine for your ISP to look at them. Comcast is looking at the "Host" field in HTTP connections? Next you're going to tell me that the post office reads the address section of postcards.
Slashdot Mirror
That's interesting; I thought people would notice a dropped frame just because it would mean that one frame would be shown twice as long as any of the rest, so everything would stop for a moment and then jump forward to the right place. Of course, traditionally when a frame gets dropped, the person sees a blank frame or static or something unrelated to the scene; people don't notice these at all, because the brain is wired to ignore them (because you blink and so forth). But having a frame update dropped means you'll see the previous frame for twice as long, which appears as a change in the motions of objects, which the brain is tuned to see.
I'm not sure exactly how many frame updates you can miss without people noticing, but it's got to be a lot fewer than frames you can blank without anyone noticing, especially if it's not consistent.
If you've got a Linux machine somewhere, you could do what I do. Install screen on the machine. In your .profile, test whether it's begin run on an ssh connection not in screen, and if so, do: screen -x -S home || screen -R -S home || bash and then exit
This won't take care of graphics, but it means that you'll have the exact session always running wherever you go. If you put a webserver which serves a MindTerm SSH client on the machine, you can go to the URL and continue working from any java-enabled browser.
If you want to use applications that not everyone has, you're going to have to store or run at least some programs on the server. Running them there generally makes the most sense, since that's where your data is, although if they fetch information for immediate display from third parties, doing that from the machine you're sitting at makes sense.
So what you really want is a widget toolkit where the communication between the program and the widgets is light enough to have over a network, that you're likely to have available on any machine use want to use. I don't think there is such a thing so far with more capabilities than a color xterm, unfortunately.
You're not going to get more cortex just by getting more input. The parts of your brain that would go to processing this input would no longer be available for their original tasks. So it's not so much them getting 'lazy' as getting less of your processing power.
Of course, getting existing brain structures to re-specialialize in order to deal with this input is probably very difficult in an adult. Fortunately, we have depth perception already, so we at least have structures for the processed data.
It seems to me that this is a promising idea. The various foods we like to eat are often made in the bodies of animals, but there's no reason that the cells that do it have to be in something with a nervous system. Of course, it couldn't have evolved that way, but the reason that meat is an inefficient food source is that it tends to wander around and look for food. We've just replaced the rest of the fish's body with a vat.
If this sort of research continues, we ought to be able to build what amounts to an ecosystem with the routing between various animal organs done with pipes instead of the rest of the animals.
The performance tests that various people have run with these patches seem to show improvements in throughput on servers. The guess is that this is because the machine will respond more quickly to the completion of I/O (which is, of course, is the slow step on most applications), so it essentially arranges tasks so that the next I/O operation can get started sooner.
Of course, you'd presumably get a higher load, since you're doing your task in less time, which means that the processor is busy more of the time.
Additionally, latency is important for interactive tasks on desktop machines, because it determines how responsive the system feels under load. The user's experience is determined more by how quickly the system responds to simple requests (moving the mouse cursor, drawing menus, etc) than by the milliseconds place on more complex tasks. Furthermore, the user will instantly notice if sound or video is not handled on time.
The issue isn't spammers setting up their own servers as open relays. Spammers don't set up open relays; they use other people's open relays. If the spammers were setting up the servers, they would presumably have them only relay their spam, not everyone else's.
The issue is when person A sets up their server wrong and person B sends spam through it; person A isn't responsible for the message and person B is impossible to find.
I'm using RedHat 6.2 w/fvwm2 on my work machine and a slackware-ish homebrew w/fvwm2 on my home machine. The Linux GUIs we used to have we still have. It's just that people have the choice of using more bloated things. The beauty of using open source software is that you don't have to switch to the latest UI every couple of years. If you miss the old days, you can go back. You'll probably actually get a lot more done, too.
I'm running 2.4.18 and 4.0.(3?) on my home machine, and fvwm has never run nearly as well. The only time it's stopped responding, I needed to wiggle the keyboard connector.
What do they expect if they keep increasing taxes on magnetic media? The magnetic north pole is obviously going to want to move to somewhere cheaper, like Siberia.
Why, then, can't they detect that it's a Domino server and skip the check? If the obscure bug, in this case, causes the server to crash, rather than sending the message to its destination, the server isn't an open relay (and likely not to remain open at all if a spammer tries to use it).
SMTP servers tend to give their version information when you connect to them, and, while they may refuse to say, they're unlikely to lie, and especially unlikely to be set up to say they're Domino, not have this bug, and be an open relay.
You want to measure documentation separately, because it obviously isn't used in the same way as code.
For the code, the metric you'd actually like is something like number of useful, novel expressions.
Copying a section of code doesn't add anything, because the lines aren't novel. Any changes you make to the lines do count, though. Making an existing block of code into a separate procedure adds a novel expression, and the expression is useful if you call it from multiple places (i.e., if the procedure is a useful abstraction). Calling a procedure with a new set of arguments is novel and generally useful.
Basically, you want to know how long the day's work had to be, given the pre-existing code, if it was done optimally.
If you add a penalty for making the code needlessly long, then a day spent reworking bad code to be shorter by combining common expressions, removing extraneous computation, etc, will also be considered productive.
For the documentation, it is easier to consider but harder to quantify. You are now measuring the number of correct and useful pieces of information that a person would get out of reading the commented code. The information may, of course, be obvious from the control structure, implied by the variable names, or actually in comments; since comments add to the length of the code without adding any functionality, using coding idioms that the reader will know (because they're part of the company's style guide or common throughout the code) and informative names is better than putting in comments, unless it is impossible (which is frequently the case).
Of course, it's hard to quantify "pieces of information" and hard to judge objectively what can be gotten out of a block of code, which is one reason this isn't something you can set up cvs to do each day or something.
This means that the ideal block of code, which should be counted as the most possible for a given problem, has these properties: it (or an equivalent block) has to be there in order for the project to do what it's supposed to do; it is not replicated, in whole or in part, anywhere else in the project (if it did, it would do better to call the other part); its behavior is clear from the names of the procedures, variables, and types; any common algorithms are implemented in the standard ways; and unusual algorithms are commented explicitly.
I think this metric would measure productivity effectively. Of course, it doesn't help productivity to actually try to measure it.
The one of these I am familiar with does things with heap allocation, such that heap-allocated memory is separated by buffer zones of unallocated memory. This can be very helpful for checking bounds on accesses, but it won't catch everything.
First of all, it doesn't do anything with the stack, which is laid out by the program itself (with code generated by the compiler), and the most common buffer overruns are out of stack-allocated buffers into other parts of the same stack frame.
Similarly, it won't catch overruns of buffers in structs, where the overrun goes into adjacent fields but not out of the struct.
The essential problem is that nothing at runtime is keeping track of sizes of arrays and types of values, so incorrect usage cannot be detected. This information requires checks while running entirely non-library code, so it cannot be done by changing libraries.
It would be possible to find occurences of known common mistakes in different packages automatically, and to find instances of a known error throughout a large project. There is work on doing this with the linux kernel, where a group has turned up hundreds of potentially unsafe usages (mostly DoS-type, mostly in drivers).
This particular problem is not actually a buffer overflow at all, it turns out, and is more subtle.
There are commercial programs which can find this sort of error, assuming it actually happens while running an instrumented version of the code. These programs are in the expensive commercial development tool price range (order $10k), though, and very difficult to write.
Another possibility is to build and run the program under a virtual machine which checks these things; for example, if you turn your C into Java and run it, it shouldn't throw any out-of-bounds exceptions, or it indicates that your C wasn't checking array bounds. There isn't a C virtual machine (that I know of), though.
Okay, so you now you're distributing what are essentially platform-independent binaries, under the GPL. Anyone who gets these is licensed to distribute them freely, and they're allowed to produce modified versions, such as a recommented and sensible version.
Selling GPLed software depends on the gratitude of your customers. They'll be able to get it for free, but will have some reason to prefer paying to get it from you. It seems to me that providing only useless source in this situation will generate enough ill will that, regardless of the legality of what you're doing, you won't make any money.
In this context, other people being able to modify the program is the least of your worries.
Getting the network switch into the bear isn't the hard part...
FTP is not suitable for transferring files that aren't generally available, because it's not secure. FTP isn't any stronger than HTTP with basic authentication, and encrypted wrappers for HTTP are far better deployed (so far as I can tell) than for FTP.
HTTP only sort of works for "push" transfers, but in this case, people generally want enough authorization that scp is the correct tool.
I agree that HTTP makes a lousy RPC protocol, because it's no good when you are not, in fact, transferring anything. But this doesn't mean it isn't suitable for P2P, which is only sometimes RPC and frequently fits a request-response model.
Likewise, the fact that the response will be delayed isn't a problem with HTTP. You could post a URL as a form field, and the server can do a long request, and then PUT/POST the result to that URL. You could, instead, post an email address, and have the result emailled to you when it is ready. The only issue is that the second half of the exchange has to happen with a "push", over a separate connection. But that's going to be an issue with any protocol.
The whole firewall issue is silly. Few firewalls actually look at the packet contents, so you could just do RPC over TCP on port 80 and bypass the firewalls just as well.
HTTP is designed for the pattern of an independent request/response pair. This isn't the case in a lot of situations where people try to use it, and it's always a bad fit when they try. But there are a lot of situations where people traditionally use other protocols which, as commonly practiced these days, HTTP would work fine, and is better designed than the alternatives.
Actually, ftp is a lousy protocol for transfering files. It requires a persistent connection between transfers, uses a bunch of connections anyway, isn't designed for machine-machine interaction, and doesn't have a mechanism for content type information. HTTP is a "transfer" protocol, and there's nothing in particular that relates to hypertext in it.
HTTP is fine for P2P applications, in general; it's not hard to have a program the both makes and accepts HTTP requests.
HTTP is suitable for delayed responses, although the entity expecting an eventual response will have to be running an HTTP server. Of course, if you want to get a delayed response, you'll have to have somewhere to accept an incoming connection, whether it's a mail server, an HTTP server, or some weird new MS thing.
HTTP is not suitable for is negotiation, since you can't easily go back and forth multiple times (later interactions are not sufficently tightly connected to not need to send all of the information again). Of course, this is essentially what people are trying to use it for.
The Windows UI is slow to use. Even if you know what you're doing, it requires a lot of keyboard-mouse transitions, and a lot of clicking on small areas of the screen.
Windows is also hard to develop an intuition for. I have yet to meet anyone who, when asked to use a feature they've never used before, knows where to find it. People will generally use the same features they're accustomed to using, so people can deal with Windows pretty well: they learn where a few things are, and use those. In part, the Windows UI is broken intentionally, because people will only get a new version if the new version does something that the old one didn't, and, if the new version behaved as expected, people wouldn't use any features other than the features they already knew.
Looking at it from the frame of reference of the building, you're not moving. In the frame of reference of the slope, you are moving, but not accelerating, so it doesn't matter much.
The only situation in which you'd care about position is for angular momentum, which you don't have at all, because you're not turning.
Even if it's partially about momentum, you don't have any momentum if you're not moving, either. On any actual slope, I think the center of gravity aspect of tucking is much more for stability than speed-- if your center of gravity is low, you'll be able to turn more effectively, which is necessary when you're going faster, since people don't normally ski straight down hills competitively (except for ski jump, but even there, you don't care about your speed on the ramp, but your momentum at the end). So the effect of tucking other than drag is to increase the speed that you can deal with, not the speed you can attain.
Because the way Apple does it is totally unlike what any existing applications use and what any present users know how to use. OS X is already mystifying anyone accustomed to UNIX and/or MacOS by being significantly different from either.
"Hey, if you learn this totally new and unmotivated system, it will be user-friendly" is not a solution unless you're MicroSoft or Apple and have users who are used to having the system changed on them regularly (but, admittedly, each time to something consistent).
XML is almost certainly the right solution for structured data, but is a major pain for unstructured data. If you don't have at least two levels of sections which actually need to be sections (i.e., they get repeated or items in them have different meanings than identically named items in other sections), then XML is needlessly verbose, and therefore unfriendly for humans to deal with.
I think the right choice of standards would be an outer layer of RFC822 headers (which everyone has a parser for already, and which is trivial to implement anyway), with values which may be XML documents with predefined schemas, if there are structured configuration items.
RFC822 headers have the advantage of being as compact as possible, easier to parse (although there are libraries anyway), easier to use after parsing (it's a map of keys to values, nothing complicated like a tree; compare SAX to "get(key)"), and just as standard.
It'd probably be worth putting a header on top which let you choose the character set, and it would be good to include something to say which program (or library) the file is supposed to configure, and where the help/format file is.
If keys were required to not include '=' (treated the same as ':'), and to start with a letter or number (or the line would be ignored as a comment), this would take care of many existing config files.
The ALSA interface code is unquestionably much better; one of the main reasons for ALSA was to get a saner interface. Many of the drivers are better, and there are drivers for some cards that OSS didn't support at all. However, there are also some cards with more stable OSS drivers. Are there any plans to merge the driver set, keeping the better of the overlapping drivers, and spliting the driver choice from the interface choice? The reports I've heard say that the Yamaha OSS drivers are more stable, so it would be nice to stick with them without losing the up-to-date interface.
So now it's:
1. Buy the CD
2. Throw the CD away
3. Download the CD
etc...
What do you pay your ISP for? To intercept your packets. Because otherwise, they're not getting anywhere. The person at the other end of your phone call is also allowed to tap the phone line with their telephone and listen. Wiretapping laws come into play only when the person listening is not the person whose wire it is. Otherwise it would be illegal for the phone system to route your calls to the person you're calling.
Unencrypted data is like postcards with respect to expectations of privacy: it doesn't have the digital equivalent of an envelope, and the address information is not separated from the content in any meaningful way. You can therefore not expect privacy of the data from anyone who is responsible for routing.
Unencrypted data is like postcards: there's nothing keeping them from the view of anyone who happens to look other than the fact that most people aren't actually in a position to see your mail at all.
You cannot reasonably have an expectation of privacy from the post office when sending postcards, although you can assume that random other people won't see them up close.
You have some expectation of privacy sending voice over the phone because there are specific laws regarding the data on the phone network which prohibit the phone carriers from looking at the data (as opposed to the routing information, which is separate).
It is illegal for some unrelated person to sniff your packets, but perfectly fine for your ISP to look at them. Comcast is looking at the "Host" field in HTTP connections? Next you're going to tell me that the post office reads the address section of postcards.