Well, at least on OS X most applications are in bundles and require no installation. You can pretty much drag them to a USB stick, wipe the system, then move them back. Heck, if you move them to another machine they'll usually work just fine, too.
Inertial navigation needs that sort of accuracy. Low-drift, high-resolution laser gyros are IIRC as good as and no better than their time bases are. Drift in reference frequency causes changes in gain...
If it was about the energy ratio, you'd be right, but the energy ratio isn't relevant. Alas, it's about momentum, and momentum scales linearly with velocity. This makes the whole thing impractical. Assuming:
- the satellite's path would intersect the asteroid path at right angle, - the satellite would embed itself in the asteroid
Then, in SI units, the velocity of the compound object is (10E9*[10E3 0] + 10E3*[0 200E3])/(10E9+10E3) = [9.9999 0.002]*1E3 m/s. The total system would gain a 2m/s motion component in the direction of the satellite's path. Since Earth is about 12.8E6 m in diameter, it'd take about 6E6 seconds to clear Earth -- that's 70 days
Of course we're ignoring the gravitational pull of Earth, so we'd really have to move the asteroid at least a few Earth diameters out. So half a year is cutting it close I'd say.
Alas, your asteroid mass could be off by a bunch of orders of magnitude. The K-T "dino killer" chondrite is estimated at 10E3m in diameter, and I presume its density is about 3ton/m^3. The volume is 5E11m^3, thus mass is 1.5E12 tons. So your mass estimation is off by 6 orders of magnitude. This makes the "clearing maneouver" take proportionally longer -- on the order of a hundred thousand years.
I'm sure a copter with enough aerodynamic efficiency to support human-powered flight will be a joy to autorotate. Autorotation is the standard helicopter failsafe: if your engines fail and you're high enough and have some forward speed, you disengage the rotor clutch and let it spin freely, "gently" getting you to to ground. In a normal helicopter a proper autorotation IIRC is only designed to be survivable, in this human-powered one it should be not only survivable but very gentle, too.
I don't know if they'll have enough structural load limits to be able to do any quick hops like that. I think that it will all have to go very, very smoothly. To a point where the pilot would be able to break something if he were to push too hard on the pedals.
I must not be getting something: how can the water "buck and knock" -- you mean the flow in the piping, due to presence of large gas bubbles? I guess it must be similar to having an air leak in a well pump. If so, two storage tanks, one in line after the other, should fix it. You would need to vent the tanks periodically of course.
If there's enough methane in the air to asphyxiate you, it must mean that you're in a facility with Ex-proof equipment and are taking proper precautions. If it's a regular household, it will blow up way before it gets to a concentration where you get any respiratory symptoms. Unless you're Amish and also happen not to have any flames around, and the humidity is like in your subterranean cold room. IOW: get a sense of scale...
If the water is only contaminated with methane, is it even a real problem? Is methane in drinking water toxic to humans? Is there enough methane in the water to pose a fire hazard when you use the water in everyday chores? I'd think that the only scenario when water gets good gas exchange with air is in the shower and in the dishwasher. Were people's dishwashers blowing up? Did anyone lose their hair and hearing due to a methane explosion while taking a shower? Methane is odorless, so it's not like anyone would be overwhelmed by the smell, and it won't magically leak out of plumbing either unless you open the tap...
Unless we're talking about using WiFi for tower-to-cantenna style paths, WiFi is pretty much insensitive to absorption in air. To a point where I bet we could easily have 95% humidity at 10 atmospheres and there'd be no noticeable effect on propagation. In satellite communications, clear air (whether humid or not) absorbs a couple dB. So whatever is done by air in a building can be neglected, even if it was an order of magnitude or two more intense. WiFi signals from antennas with low directionality (as is the case with usual access points) are lost to building materials and to free space path loss (20dB power loss per decade of increase in distance). Interference from other sources in the ISM band causes additional degradation of SNR. And that's pretty much it.
The monitors and stuff are not a problem inherent in host-based printing. Not at all. For reasons better left to be explained by marketing types, HP's Windows printing support for home printer product line sucks donkey balls. Their support on Linux and Mac doesn't come with any of the overhead.
So what you're complaining against is not host based printing per se, but broken drivers peddled by HP and others, bundled with bloatware. There's no inherent technical reason for it to be that way. And the problem is not because printer is not performant enough. The problem is bloatware. What you feel as the problem is not the rasterizer, it's everything else. Note that the same bloatware, unfortunately, comes with printers that have a built-in rasterizer, too.
As for 200MB of disk: you are not complaining about what the rasterizer is doing, merely about bloatware that came with the printer. A monochrome letter-sized page at 600dpi takes 4.2 Mbytes. At that resolution, you could stuff uncompressed bitmaps for about 45 monochrome pages in 200MB, or 12 pages worth of CMYK bitmaps.
You seem to be seriously overstating the impact of host-based printing. Obviously when you're not printing (and that's probably most of the time!), there's no overhead. And when you are printing, then the rasterizer consumes a little bit of memory and plenty of CPU, but that's transient. I would never venture as far as calling it "consuming" the computer.
I haven't personally felt it to be a problem, and I'm using a host-based printer (HP LJ P1006). It spits out about 17 pages per minute, not too shabby if you ask me. Having a CPU capable of rasterizing that fast in the printer itself would probably double its cost, so I'm not complaining. The Core2 Duo in the iMac is already paid for;)
Heck, I've used plenty of PCL-only LaserJets, and they were -- for all practical purposes -- host-rendering printers. Some of them could render scalable fonts, but that only helped if you were printing text. As soon as there were graphics involved, or output from professional typesetting/design packages, the printer was receiving a huge monochrome bitmap wrapped in a couple PCL instructions. In all recent-enough cases, though, the host CPU was much faster than the one on the printer, so it actually helped with throughput if the PC would do the rasterization.
You are probably right w.r.t. relative gas consumption.
Alas, there's still something to be said for face-to-face interaction between workers. Telecommuting only works so far.
The biggest problem I have with your viewpoint, though, is that quite often in the U.S. you have NO choice but to live in the suburbs. Living anywhere near downtown will usually imply higher crime, worse schools, and unsafe neighborhoods. Heck, even in some suburbs it's not all that great: I wouldn't mind living right next to my suburban workplace if it wasn't for the fact that the area has been declining for the last decade -- after a nearby euro-themed shopping mall closed down. It's really not a very pleasant area to live in right now, even though 20 years ago it was a very hot spot, commanding high real estate prices. So I have to live in the suburbs, but elsewhere, and waste 15 minutes each day for one-way commute. Sure it beats commuting say on the beltway in D.C. Yet having to spend 0 minutes in the car surely beats 30 minutes every day. At least we can walk to the grocery store and some restaurants.
I think that the demise of USPS points to one thing: the external interface to offices is ceasing to be paper based. The information is still transferred, but no more is it done using paper as the medium. It does not necessarily indicate that offices are going truly paperless. Some are, some aren't. The definite trend is to transport less paper between offices, and I use the term widely to include both corporate giants and each home's "office". Within the offices, though, it's hard to infer the amount of information that gets printed out. Certainly as soon as it has to leave the building, it's converted to electronic form. Maybe all they do is scan things: there must be a good reason why Xerox advertises their document scanning & management services in prime-time spots in many U.S. markets.
I'm quite happy, though, that we finally woke up to the fact that shipping paper around is just a huge waste. Think of the millions of gallons of fuel already saved by not having USPS ship as much stuff around, their workers not having to drive to work, etc.
I agree. I updated a friend's Powerbook G4 from 10.3 to 10.5 and the difference was very, very positive. She ended up with a much more responsive system. Of course it wasn't originally on 10.4, but still I don't think there was anything wrong with Leopard. I've never ever had a GSOD (gray screen of death). Didn't even know it existed until reading this thread. I've been using an iMac at home for 4+ years, and a MBP at work. The only hardware problems I had with Intel macs would not cause any screens of death: either the machine would not start up, or it would shut down hard when I didn't want it to, or a peripheral wouldn't work (optical drive in one case, built-in mic in the other).
I've been looking at some numbers and if Apple could weather approx. 2 years worth of 50% cut in net profits, they could set up to manufacture all of their equipment in the U.S. at the same cost as they do now in FoxConn factories -- maybe not in California, but definitely in the U.S. They'd need plenty of automation, of course, but that's IMHO still a better deal -- I don't see why we should, in effect, subsidize China's working class.
As for the example of cat, which IS implemented as a read followed by a write (at least on FreeBSD and Gnu), in practice, this works better than you might think, because the Linux and FreeBSD kernels may prefetch reads in anticipation that you will call read again, and isn't required to have written to disk (though it may be for other output channels) when it returns from the write syscall, it is only required that subsequent reads (that are proven to occur afterward) return the written data, in essence, the caching of the data has been moved out of userspace and into the kernel, for cases where caching is appropriate. It should be obvious why someone would not want an async_io cat if you think about the cases where you would use cat between two sockets (not files), you can't write if you haven't read anything, and you shouldn't read if there's nowhere to write to, because then you'd have to allocate memory, and stack up a read buffer (of what size?), and any fault that occured at the output would not be propagated synchronously to the input socket. If you want a cat that violates the semantics of POSIX cat, please don't call it cat.
Prefetching of course only applies to block devices. What I'd expect of cat or dd is to have enough of a buffer to prevent stalls -- to cushion latency of source and destination devices. This should work automagically, within some limits. Of course you shouldn't indefinitely read if there's nowhere to write to, but perhaps the destination is fast on average, but has latency peaks? This can be quite cheaply characterized at runtime, each and every time. Think of a tape drive. A tape drive that normally streams megabytes per second will easily stall a TCP/IP socket on a T1 link when it has to reverse the tape due to loss of streaming. So you end up with an underutilized T1 link as the network stack will not buffer much more than a second or two of data (not for me, at least). All this even though on average T1 can only push about 140kbytes/s, while the tape drive should "cope" with more than an order of magnitude more.
What you of course correctly highlight is the very sad shape of system APIs, and that includes POSIX. There's very little consistency. This is to a point where the internal kernel synchronization APIs are usually cleaner than what the userspace has to live with. On Linux and Windows, AFAIK if you have kernel code that waits for something to come over the network, or from a USB device, or from the drive, the API used to wait on "somethings" is exactly the same. In the userspace, as you point out, there's no consistency, and there's generally no joy to be had from dealing with non-blocking APIs. I claim that the bad shape of those APIs is partly responsible for the refusal of toolkit and application developers to do the right thing. In this area winapi is somewhat better than POSIX, in fact, and that's just sad.
If that's what she really said, I find it somewhat agreeable. Being "guilted into helping people" -- yes, I hate that. I think that I do quite a bit to help people out. I'd probably stop helping others real quick if someone tried to make me feel guilty about *not* doing it, though. It's hard to explain why I'd stop, but somehow I find the act of "guilting someone into something" to be repugnant. Takes all the pleasure out and ruins the day.
For this to make any financial sense for the economy as a whole, the cost of licensing the patent must be, overall, lower than the totaled cost of reinventing. Quite often the invention itself has a very low value, because the money has to be spent anyway on actually engineering it -- you know, designing the hardware and software that embodies the 'invention'. In most cases, the engineering costs overwhelm any sort of "savings" from not "reinventing".
Replacing some contributions is hard. There may be a lot of other code that is arguably a derived work. The only sure-fire way to deal with it would be to freeze the code at a point before the contribution, then do a clean-room reimplementation of everything that was added later. That may be hard to put it mildly.
The latency problem in non-networked applications is ultimately caused by poor software engineering, starting with system-provided APIs. Most of "bog standard" system libraries were designed for something entirely different than what they end up used for. The "normal" C I/O paradigm is used everywhere, yet it was really designed for batch applications, not for interactive use. The only way to do almost any filesystem and network interaction should be to submit a request, then react when the results come back, all the while being receptive to other "results" (events) coming in. Unfortunately, designing things this way requires a certain discipline and a mindset, and default APIs and "industry practices" simply don't encourage it at all.
A correctly engineered system API should not have any blocking calls apart from the "wait for events" call, it's as simple as that. It's very rare that an application is only waiting for one thing to happen. Even something as simple as a UNIX cat has two file descriptors open, and simultaneously waits for stuff to come and and for stuff to finish going out, with a buffer in-between (I'm ignoring no-copy APIs for a moment). Coding it up as a read followed by a write is, at best, wishful thinking. Of course event-based programming is something that seems like a lot of extra work, but it's just a matter of getting used to doing things the right way.
In fact, if you decide to code up your whole system in an entirely reactive way, you gain other benefits. By reactive I mean you could reduce every application thread's interface to a single processEvent(event), run-to-completion function that you implement. As it turns out, it becomes almost natural to get the guts of the processEvent() function implemented as a state machine. The state machine formalism often helps in producing better quality code, and it certainly makes it very easy to trace interaction with the outside world. Miro Samek shows a striking example: the supposedly "so simple it couldn't possibly go wrong" calculator example from old Visual Basic has several bugs that stem from its bug-prone yet commonplace design. The calculator's state is spread out in an ad-hoc manner in various variables, and the tests done on those variables in response to external UI events pretty much amount to a buggy reconstruction of a single state variable to drive a state machine.
The state machine paradigm is in somewhat stark contrast to the way a typical GUI application is designed, where you have on_fooBar methods that get invoked when fooBar event happens. In the fooBar method it's up to you to verify that the application is in the correct state to do whatever fooBar calls for. This requires forethought, and status quo indicates that it's easy to get it wrong. Perhaps that's the reason: the de-facto mode of implementing reactions to external events is so broken that it's not used for much besides the GUI. Perhaps this is why "quick" system calls are usually done in line and end up blocking the whole application, or at least one thread, and those are not free either so why waste them with blocking APIs?! Apart from perhaps querying the current time or current username, there are really no "quick" system calls. Simple things like listing a directory or getting a key's value from the registry can potentially take seconds if your drive is thrashing around due to high I/O demand, or if the network happens to be slow.
Of course the line has to be drawn somewhere, so let's assume that paging of code, libraries and heap is something we should not worry about because it cannot be helped much. At that point one realizes that indiscriminate memmapping of data files can be problematic in itself: a memory-mapped file is, after all, supposed to hide the fact that you are doing a request-response that can be either very fast or very, very slow. The latter is something you should explicitly handle, and with memmap it's at best cumbersome: you have to use some API to check if given page is av
Slashdot Mirror
Well, at least on OS X most applications are in bundles and require no installation. You can pretty much drag them to a USB stick, wipe the system, then move them back. Heck, if you move them to another machine they'll usually work just fine, too.
So, I understand that all of your software keeps itself up-to-date, Riiight.
Inertial navigation needs that sort of accuracy. Low-drift, high-resolution laser gyros are IIRC as good as and no better than their time bases are. Drift in reference frequency causes changes in gain...
Very informative. I'll run some numbers to see whether phase shifting would work in a short-term scenario (6 months advance warning).
The original press release is from January 18th 2011. Just sayin'. Of course this is a very nifty device and all that.
If it was about the energy ratio, you'd be right, but the energy ratio isn't relevant. Alas, it's about momentum, and momentum scales linearly with velocity. This makes the whole thing impractical. Assuming:
- the satellite's path would intersect the asteroid path at right angle,
- the satellite would embed itself in the asteroid
Then, in SI units, the velocity of the compound object is (10E9*[10E3 0] + 10E3*[0 200E3])/(10E9+10E3) = [9.9999 0.002]*1E3 m/s.
The total system would gain a 2m/s motion component in the direction of the satellite's path. Since Earth is about 12.8E6 m in diameter, it'd take about 6E6 seconds to clear Earth -- that's 70 days
Of course we're ignoring the gravitational pull of Earth, so we'd really have to move the asteroid at least a few Earth diameters out. So half a year is cutting it close I'd say.
Alas, your asteroid mass could be off by a bunch of orders of magnitude. The K-T "dino killer" chondrite is estimated at 10E3m in diameter, and I presume its density is about 3ton/m^3. The volume is 5E11m^3, thus mass is 1.5E12 tons. So your mass estimation is off by 6 orders of magnitude. This makes the "clearing maneouver" take proportionally longer -- on the order of a hundred thousand years.
I'm sure a copter with enough aerodynamic efficiency to support human-powered flight will be a joy to autorotate. Autorotation is the standard helicopter failsafe: if your engines fail and you're high enough and have some forward speed, you disengage the rotor clutch and let it spin freely, "gently" getting you to to ground. In a normal helicopter a proper autorotation IIRC is only designed to be survivable, in this human-powered one it should be not only survivable but very gentle, too.
I don't know if they'll have enough structural load limits to be able to do any quick hops like that. I think that it will all have to go very, very smoothly. To a point where the pilot would be able to break something if he were to push too hard on the pedals.
I must not be getting something: how can the water "buck and knock" -- you mean the flow in the piping, due to presence of large gas bubbles? I guess it must be similar to having an air leak in a well pump. If so, two storage tanks, one in line after the other, should fix it. You would need to vent the tanks periodically of course.
If there's enough methane in the air to asphyxiate you, it must mean that you're in a facility with Ex-proof equipment and are taking proper precautions. If it's a regular household, it will blow up way before it gets to a concentration where you get any respiratory symptoms. Unless you're Amish and also happen not to have any flames around, and the humidity is like in your subterranean cold room. IOW: get a sense of scale...
If the water is only contaminated with methane, is it even a real problem? Is methane in drinking water toxic to humans? Is there enough methane in the water to pose a fire hazard when you use the water in everyday chores? I'd think that the only scenario when water gets good gas exchange with air is in the shower and in the dishwasher. Were people's dishwashers blowing up? Did anyone lose their hair and hearing due to a methane explosion while taking a shower? Methane is odorless, so it's not like anyone would be overwhelmed by the smell, and it won't magically leak out of plumbing either unless you open the tap...
Unless we're talking about using WiFi for tower-to-cantenna style paths, WiFi is pretty much insensitive to absorption in air. To a point where I bet we could easily have 95% humidity at 10 atmospheres and there'd be no noticeable effect on propagation. In satellite communications, clear air (whether humid or not) absorbs a couple dB. So whatever is done by air in a building can be neglected, even if it was an order of magnitude or two more intense. WiFi signals from antennas with low directionality (as is the case with usual access points) are lost to building materials and to free space path loss (20dB power loss per decade of increase in distance). Interference from other sources in the ISM band causes additional degradation of SNR. And that's pretty much it.
This demands a "-4 depressing, quadruply so" mod.
The monitors and stuff are not a problem inherent in host-based printing. Not at all. For reasons better left to be explained by marketing types, HP's Windows printing support for home printer product line sucks donkey balls. Their support on Linux and Mac doesn't come with any of the overhead.
So what you're complaining against is not host based printing per se, but broken drivers peddled by HP and others, bundled with bloatware. There's no inherent technical reason for it to be that way. And the problem is not because printer is not performant enough. The problem is bloatware. What you feel as the problem is not the rasterizer, it's everything else. Note that the same bloatware, unfortunately, comes with printers that have a built-in rasterizer, too.
As for 200MB of disk: you are not complaining about what the rasterizer is doing, merely about bloatware that came with the printer. A monochrome letter-sized page at 600dpi takes 4.2 Mbytes. At that resolution, you could stuff uncompressed bitmaps for about 45 monochrome pages in 200MB, or 12 pages worth of CMYK bitmaps.
You seem to be seriously overstating the impact of host-based printing. Obviously when you're not printing (and that's probably most of the time!), there's no overhead. And when you are printing, then the rasterizer consumes a little bit of memory and plenty of CPU, but that's transient. I would never venture as far as calling it "consuming" the computer.
I haven't personally felt it to be a problem, and I'm using a host-based printer (HP LJ P1006). It spits out about 17 pages per minute, not too shabby if you ask me. Having a CPU capable of rasterizing that fast in the printer itself would probably double its cost, so I'm not complaining. The Core2 Duo in the iMac is already paid for ;)
Heck, I've used plenty of PCL-only LaserJets, and they were -- for all practical purposes -- host-rendering printers. Some of them could render scalable fonts, but that only helped if you were printing text. As soon as there were graphics involved, or output from professional typesetting/design packages, the printer was receiving a huge monochrome bitmap wrapped in a couple PCL instructions. In all recent-enough cases, though, the host CPU was much faster than the one on the printer, so it actually helped with throughput if the PC would do the rasterization.
You are probably right w.r.t. relative gas consumption.
Alas, there's still something to be said for face-to-face interaction between workers. Telecommuting only works so far.
The biggest problem I have with your viewpoint, though, is that quite often in the U.S. you have NO choice but to live in the suburbs. Living anywhere near downtown will usually imply higher crime, worse schools, and unsafe neighborhoods. Heck, even in some suburbs it's not all that great: I wouldn't mind living right next to my suburban workplace if it wasn't for the fact that the area has been declining for the last decade -- after a nearby euro-themed shopping mall closed down. It's really not a very pleasant area to live in right now, even though 20 years ago it was a very hot spot, commanding high real estate prices. So I have to live in the suburbs, but elsewhere, and waste 15 minutes each day for one-way commute. Sure it beats commuting say on the beltway in D.C. Yet having to spend 0 minutes in the car surely beats 30 minutes every day. At least we can walk to the grocery store and some restaurants.
I think that the demise of USPS points to one thing: the external interface to offices is ceasing to be paper based. The information is still transferred, but no more is it done using paper as the medium. It does not necessarily indicate that offices are going truly paperless. Some are, some aren't. The definite trend is to transport less paper between offices, and I use the term widely to include both corporate giants and each home's "office". Within the offices, though, it's hard to infer the amount of information that gets printed out. Certainly as soon as it has to leave the building, it's converted to electronic form. Maybe all they do is scan things: there must be a good reason why Xerox advertises their document scanning & management services in prime-time spots in many U.S. markets.
I'm quite happy, though, that we finally woke up to the fact that shipping paper around is just a huge waste. Think of the millions of gallons of fuel already saved by not having USPS ship as much stuff around, their workers not having to drive to work, etc.
I agree. I updated a friend's Powerbook G4 from 10.3 to 10.5 and the difference was very, very positive. She ended up with a much more responsive system. Of course it wasn't originally on 10.4, but still I don't think there was anything wrong with Leopard. I've never ever had a GSOD (gray screen of death). Didn't even know it existed until reading this thread. I've been using an iMac at home for 4+ years, and a MBP at work. The only hardware problems I had with Intel macs would not cause any screens of death: either the machine would not start up, or it would shut down hard when I didn't want it to, or a peripheral wouldn't work (optical drive in one case, built-in mic in the other).
If my engineering nose is worth anything, I'd say it was a classic case of bad power supply.
I've been looking at some numbers and if Apple could weather approx. 2 years worth of 50% cut in net profits, they could set up to manufacture all of their equipment in the U.S. at the same cost as they do now in FoxConn factories -- maybe not in California, but definitely in the U.S. They'd need plenty of automation, of course, but that's IMHO still a better deal -- I don't see why we should, in effect, subsidize China's working class.
As for the example of cat, which IS implemented as a read followed by a write (at least on FreeBSD and Gnu), in practice, this works better than you might think, because the Linux and FreeBSD kernels may prefetch reads in anticipation that you will call read again, and isn't required to have written to disk (though it may be for other output channels) when it returns from the write syscall, it is only required that subsequent reads (that are proven to occur afterward) return the written data, in essence, the caching of the data has been moved out of userspace and into the kernel, for cases where caching is appropriate. It should be obvious why someone would not want an async_io cat if you think about the cases where you would use cat between two sockets (not files), you can't write if you haven't read anything, and you shouldn't read if there's nowhere to write to, because then you'd have to allocate memory, and stack up a read buffer (of what size?), and any fault that occured at the output would not be propagated synchronously to the input socket. If you want a cat that violates the semantics of POSIX cat, please don't call it cat.
Prefetching of course only applies to block devices. What I'd expect of cat or dd is to have enough of a buffer to prevent stalls -- to cushion latency of source and destination devices. This should work automagically, within some limits. Of course you shouldn't indefinitely read if there's nowhere to write to, but perhaps the destination is fast on average, but has latency peaks? This can be quite cheaply characterized at runtime, each and every time. Think of a tape drive. A tape drive that normally streams megabytes per second will easily stall a TCP/IP socket on a T1 link when it has to reverse the tape due to loss of streaming. So you end up with an underutilized T1 link as the network stack will not buffer much more than a second or two of data (not for me, at least). All this even though on average T1 can only push about 140kbytes/s, while the tape drive should "cope" with more than an order of magnitude more.
What you of course correctly highlight is the very sad shape of system APIs, and that includes POSIX. There's very little consistency. This is to a point where the internal kernel synchronization APIs are usually cleaner than what the userspace has to live with. On Linux and Windows, AFAIK if you have kernel code that waits for something to come over the network, or from a USB device, or from the drive, the API used to wait on "somethings" is exactly the same. In the userspace, as you point out, there's no consistency, and there's generally no joy to be had from dealing with non-blocking APIs. I claim that the bad shape of those APIs is partly responsible for the refusal of toolkit and application developers to do the right thing. In this area winapi is somewhat better than POSIX, in fact, and that's just sad.
If that's what she really said, I find it somewhat agreeable. Being "guilted into helping people" -- yes, I hate that. I think that I do quite a bit to help people out. I'd probably stop helping others real quick if someone tried to make me feel guilty about *not* doing it, though. It's hard to explain why I'd stop, but somehow I find the act of "guilting someone into something" to be repugnant. Takes all the pleasure out and ruins the day.
For this to make any financial sense for the economy as a whole, the cost of licensing the patent must be, overall, lower than the totaled cost of reinventing. Quite often the invention itself has a very low value, because the money has to be spent anyway on actually engineering it -- you know, designing the hardware and software that embodies the 'invention'. In most cases, the engineering costs overwhelm any sort of "savings" from not "reinventing".
Replacing some contributions is hard. There may be a lot of other code that is arguably a derived work. The only sure-fire way to deal with it would be to freeze the code at a point before the contribution, then do a clean-room reimplementation of everything that was added later. That may be hard to put it mildly.
The latency problem in non-networked applications is ultimately caused by poor software engineering, starting with system-provided APIs. Most of "bog standard" system libraries were designed for something entirely different than what they end up used for. The "normal" C I/O paradigm is used everywhere, yet it was really designed for batch applications, not for interactive use. The only way to do almost any filesystem and network interaction should be to submit a request, then react when the results come back, all the while being receptive to other "results" (events) coming in. Unfortunately, designing things this way requires a certain discipline and a mindset, and default APIs and "industry practices" simply don't encourage it at all.
A correctly engineered system API should not have any blocking calls apart from the "wait for events" call, it's as simple as that. It's very rare that an application is only waiting for one thing to happen. Even something as simple as a UNIX cat has two file descriptors open, and simultaneously waits for stuff to come and and for stuff to finish going out, with a buffer in-between (I'm ignoring no-copy APIs for a moment). Coding it up as a read followed by a write is, at best, wishful thinking. Of course event-based programming is something that seems like a lot of extra work, but it's just a matter of getting used to doing things the right way.
In fact, if you decide to code up your whole system in an entirely reactive way, you gain other benefits. By reactive I mean you could reduce every application thread's interface to a single processEvent(event), run-to-completion function that you implement. As it turns out, it becomes almost natural to get the guts of the processEvent() function implemented as a state machine. The state machine formalism often helps in producing better quality code, and it certainly makes it very easy to trace interaction with the outside world. Miro Samek shows a striking example: the supposedly "so simple it couldn't possibly go wrong" calculator example from old Visual Basic has several bugs that stem from its bug-prone yet commonplace design. The calculator's state is spread out in an ad-hoc manner in various variables, and the tests done on those variables in response to external UI events pretty much amount to a buggy reconstruction of a single state variable to drive a state machine.
The state machine paradigm is in somewhat stark contrast to the way a typical GUI application is designed, where you have on_fooBar methods that get invoked when fooBar event happens. In the fooBar method it's up to you to verify that the application is in the correct state to do whatever fooBar calls for. This requires forethought, and status quo indicates that it's easy to get it wrong. Perhaps that's the reason: the de-facto mode of implementing reactions to external events is so broken that it's not used for much besides the GUI. Perhaps this is why "quick" system calls are usually done in line and end up blocking the whole application, or at least one thread, and those are not free either so why waste them with blocking APIs?! Apart from perhaps querying the current time or current username, there are really no "quick" system calls. Simple things like listing a directory or getting a key's value from the registry can potentially take seconds if your drive is thrashing around due to high I/O demand, or if the network happens to be slow.
Of course the line has to be drawn somewhere, so let's assume that paging of code, libraries and heap is something we should not worry about because it cannot be helped much. At that point one realizes that indiscriminate memmapping of data files can be problematic in itself: a memory-mapped file is, after all, supposed to hide the fact that you are doing a request-response that can be either very fast or very, very slow. The latter is something you should explicitly handle, and with memmap it's at best cumbersome: you have to use some API to check if given page is av