If they're actually using an embedded distribution, it's not too unlikely that it doesn't have the usual GNU software on it at all. They could go with newlib, busybox, and dash, and not include a native build environment, and it would be hard to argue that it's a GNU system at all. GNU stuff in that layer is really nice for interactive use, but if your scripts are all POSIX and you don't expect people to work on the system from inside, you can cut out a huge amount of space that goes to making things that won't matter nice.
Apple cares more about high margins than market share in computers. There's no way that corporate purchasing is going to be sold on high-margin items by a vendor, because the things a vendor can offer aren't going to be sufficiently compelling in a marketing blurb to overcome the fact that the price is out of line. On the other hand, Apple can sell well to individuals based on getting people to like products that aren't available from other companies regardless of price. And individual employees at companies influence how the company spends its per-employee overhead (does the company buy nicer chairs? new cubicles? better snacks? macs?). This means that Apple is in a position where companies will be looking for the most cost-effective way for them to acquire Macs. Apple could put together a whole corporate program and send an account rep to companies that are considering buying from Apple, but all that would do is give the company somebody to negotiate a better deal with. Apple actually does better to ignore the company and leave it no choice but to go to the Apple Store and buy from people or computers that don't negotiate but just charge what the price tag says.
I think the only thing that Apple would want to change is that corporate IT is afraid of getting support and repair calls they don't know how to handle. To a certain extent, this isn't a problem so long as employees only get Macs if they ask for them, because Apple puts a lot of effort into motivated individual users being able to take care of their Macs without a help desk. But they'll probably want to streamline the process of selling out-of-warranty repairs in large numbers for the same owner. And they may want to work on getting corporate IT workers to buy Macs as their home computers.
I think the interviewer wasn't asking the right questions. His answer was for why you can't replace a GPU with an N-core CPU, not why you wouldn't put a GPU on the same die with your CPUs. I think his answers in general imply that it's more likely that people will want GPU cores that aren't attached to graphics output at all in the future, in addition to the usual hardware that connects to a monitor. I wouldn't be surprised if it became common to have a processor chip with 4 CPU cores and 2 GPU cores, and also have a graphics card with another GPU or 2 in addition to video output.
He is right that having a 16-core CPU won't do a number of common tasks efficiently, compared to a single massively-SIMD core.
It requires that you have 4G of RAM on a 32-bit kernel without PAE and have enabled sparsemem. Yes, despite having more physical memory installed than the size of the address space, you think your memory is sparse. Probably nobody ever configured the kernel like this until Ingo was doing random configurations (for testing) on a high-end machine.
Sure, it's a bug, and was a mess to debug, but it turned out that probably nobody would have ever had a problem with this in practice. But they didn't know that until they'd debugged it, and they didn't want to leave a weird memory corruption bug they didn't understand, even if they'd only seen it in a strange configuration, because it could have turned out to happen on other configurations less frequently. And they put in a bunch of infrastructure to test this, too.
Why shouldn't there be a lag between when your decision is fixed and when you know you've made it? This fits perfectly with the idea that you propose an option to yourself and then spend some time trying to think of any flaws with it. And if you do think of some flaw, you won't instantly choose a different option; you'll consider that one for some time. In any case, you'll generally not finalize anything until you've spent some time with that as the most favored option, so it's not too surprising that they can pick that out before you commit.
It's like taking a test. You think of yourself as finishing the test when you turn it in. But the answers you will turn in are on the paper since before you started checking them over. You can predict with high accuracy what answers people will give long before they consider themselves done just by reading what they've written. The only new thing here is that we can read people's answers when the answers are in their heads.
Actually, the only claim where the math actually works out is that, if you're given a choice between two options, you'll pick the one you prefer very slightly, but if you have a choice between three objects, you'll pick each one in proportion to how much you like it. In order for the chance of picking the same one twice to be 2/3 based on the same math as the Monty Hall situation, it has to be that the bias in pairwise choices is total. If the bias in this situation is less than total, the chance is less that 2/3.
The Monty Hall problem would work out very differently if it went as follows: you pick a door. Monty opens a different door, picked arbitrarily (and sometimes this reveals the car). Then you have the option of switching to the other unopened door. In this case, it doesn't matter what you do: 1/3 of the time, it's behind the door you started with, 1/3 of the time it's behind the you you could switch to, and 1/3 of the time Monty reveals the car and you aren't allowed to switch to it.
Similarly, if your bias is very slight, you'll pick the same M&M twice very slightly more than 50% of the time. So if bias is the reason for the 2/3 result of picking the same M&M, we're left with the mystery of why the large bias is undetectable.
Now it is a consistent explanation that, given a pairwise choice, you'll respond with a large bias, but given three options, you'll have no bias. Likewise, it's possible that you have a strong bias that drifts around, such that, in two trial in order, your bias is the same, but if you get lots of chances to choose, you'll change your favorite around such that it balances out.
But the math doesn't support the idea that there's no effect here, just the potential for some alternative claims as to what the effect is.
Sure, if you want to predict ovulation slightly better than chance in large samples with no systematic bias. But other factors (including, for example, what impression the person wants you to get) have a larger effect that gets averaged out in studies. Clothes will tell you whether a woman is ovulating, but they're no more likely to get you the right answer than asking her; either way, you'll only get the right answer if she doesn't have a particular answer she wants you to get, or if you average across a large number of trials.
The problem with making drivers bulletproof is that the hardware is inherently privileged and the interaction between the drivers and the hardware isn't documented. If the driver does some wrong things, the hardware will lock the PCI bus and there's nothing the OS (or the processor) can do. If the driver does other wrong thing, the hardware will DMA into the wrong place which ignored memory protection. And the kernel doesn't know how to validate the driver's bus transactions to prevent these. Having drivers in user mode makes it less easy to BSOD the machine, but doesn't prevent other problems.
You're thinking of microsaccades rather than saccades (which are larger scale jumps from one point of focus to a different point of focus). Microsaccades are probably actually actively helpful in precise eye tracking, because they end at the target of fixation, and therefore pick out the relevant spot within the area that the focus drifts within.
If they don't play by the rules, Google complains to the FCC, and also makes an offer on having the FCC turn over the spectrum to Google. I doubt the FCC would resist too much being able to get away with selling the same thing twice. So long as there are competitors who would buy the spectrum if the FCC had it back, the terms of the agreement are meaningful, because it's in other people's interest for Verizon's deal to fall through, especially after they've already paid their money.
Who cares about spying if you don't do anything wrong?
The people whose personal information gets stolen off of improperly secured FBI computers. People dating former spouses of FBI agents. It's not really an issue of the information that "the FBI" has and can use for prosecution of crimes; it's an issue of the information that FBI agents will encounter and not forget when they go home, and the FBI director who can blackmail anybody anywhere with legal but embarrassing information.
It's obviously because people don't eat whale but people hunt them that they have breed whale-cows. That way, the whalers can hunt whale-cows for food. And then they can be all snooty for insisting on free-range whale-cow beef. Incidentally, this is in no way a scheme to appease Godzilla so he doesn't have to come ashore when he feels like land mammals for dinner.
Good thing desktop users are unlikely to install a new non-distro kernel between February 28th, when Linus posted that, and March 4th, when he looked more carefully at what ndiswrapper is doing and determined that it's not re-exporting functions to non-GPL code, but rather using them to implement an API that's not a derived work of the kernel. Linus saying something dumb on a Thursday afternoon which he corrects on a Tuesday shouldn't be news on Wednesday, especially as it's a discussion about a kernel that hasn't been released yet, won't be for a couple of weeks, and probably won't be provided by distributions for a couple of months.
The point of time zones (including DST) is that you can find out the local current GMT offset, and you'll know what hours to expect local businesses to be open. Sure, I could guess that the bank will be open 13:00 to 21:00 UTC (14:00 to 22:00 UTC during the winter), but if I went to Chicago, branches of the same bank will be open from 14:00 to 21:00 (15:00 to 22:00 in the winter), and I'd have to remember what business hours are there, instead of having a device that conveniently maps those business hours to the same business hours we use at home.
Furthermore, in California in the winter, people working desk jobs would be leaving work on a different date than they arrived. If you were told you needed to get something in by closing time on Wednesday, you would have to figure out if you had to get it in before the closing time which is on Wednesday (UTC) or by when the business closes after opening on Wednesday (which may be the end of the Wednesday work day, but is on Thursday).
Like it or not, there's a lot of things that are common to events that happen at noon of the time zone they happen in. If you find out something was stolen at 13:50 UTC, and you don't know where it happened, you don't know if this was a bold daylight robbery or a thief in the night. If you know it happened at 4:50 am local time somewhere, you have a better idea of what the event was like, even without knowing where it was. The fact that, in other places, businesses were open and people were around isn't very helpful.
Gasoline-powered generators, of course. Fixed location electricity production is more efficient and cleaner than internal combustion engines, and easier to maintain effectively than devices that people drive all over the place, start and stop all the time, fail to monitor, and beat up. Even with the loss due to converting the energy twice, provided you've got some better storage than we've got now, it's more efficient, and it's cleaner in any case, since the step that generates emissions is all in one place and can have large and heavy filtering equipment without reducing performance (because it's not being dragged around). And there's supply and distribution in place for more than enough gasoline to power all of the electric cars that would replace gasoline cars (obviously, since the system as a whole is more efficient and uses the same energy source); furthermore, it would be easy to switch generation methods when other sources are cheaper than gasoline.
The main flaw with switching from gasoline to gasoline-generated electricity is the lower energy density of electricity storage, which is what this article is about addressing. Beyond that, there's a certain cost to installing generators at gas stations. And there's the issue that electrics (and hybrids) have tons of low-end torque, which means that you go 0 to 3 before you realize you've touched the accelerator.
If your employees are good, they'll tend to know other people who are good (from previous jobs, school, socially, or outside projects). If they know you want to hire people, and they like the company, they'll refer these people. People of the level you're talking about will generally be able to find jobs by way of their contacts of this sort, and will generally not want to talk to recruiters, HR people, or headhunters (all of whom are normally scary non-geeks).
The electrical grid is a really tricky system. You've got generators putting in energy at a bunch of points. And the whole thing is AC, which means that, if you look at any particular point, you see the voltage (and current) going in a sine wave. If you drive the system at the correct phase, you're supplying power; if you're slow by 1/120 second, you're turning twice your capacity into waste heat, and you start blowing up substations. Furthermore, since electricity moves at a finite speed along the wires, you can't just have a really good clock and have everybody agree; the difference in phase you need depends on the distance between the power plants along the wires. The solution is to have the power plant measure the phase of the lines they're on, and generate with a matching phase.
Now, if something goes wrong somewhere down the lines, the power plant may not be able to get a good read of the phase. At that point, you just shut down the power plant, shut down the substations (so there isn't customer load on the lines), get the switching stations fixed, start the power plant up again in phase, and reconnect the customers. It's only if the switching stations are really destroyed that they'd actually run a power plant for local customers disconnected from the national grid, and they'd have to shut it down again in order to rejoin the grid.
What happened today is actually how it's supposed to work in case of an equipment failure: a regional blackout, some time to repair the malfunctioning equipment or swap in replacements, and then restoring power. When the grid doesn't handle the failure correctly, power lines melt down and power company manholes and buildings blow up and service isn't restored for days to some customers.
Using vmsplice() in ordinary applications should improve system performance under load when appropriate (when you send full pages of generated data to a network connection, the kernel won't have to copy the pages, it can DMA straight to the NIC, saving work and cache space). So it's quite possible that distros would ship binaries that use vmsplice() if their default kernels support it, and it would be a performance hit to disable it. I don't know if any significant programs actually use vmsplice() yet, but it wouldn't be surprising.
Assuming you want it to be purely open source (and not sell proprietary licenses to it, like MySQL, for example), just ask them to license it to you under the GPL or BSD license. Either of these gives you, as licensee (it doesn't matter that you wrote the original code) the rights that you want, and they're well-understood documents. If they can't understand those licenses, they really have no business licensing their software to customers. And if they're not okay with licensing the software to you under those terms, they won't be okay with any document that effectively allows you to get that license to the software (and may also transfer copyright).
As far as whether you should try to get the copyright, having this company own the copyrights and only license it to you under the GPL and then have you work on it and only license your changes under the GPL means that nobody can change the license, since neither of those two copyright holders are likely to agree on a change. This can be preferable for end users over having a single copyright holder who could legally take future versions closed-source.
The main thing about email is that you can send it without publishing your presence, and you can send it to people who aren't online at the time. So it's a little more involved than the non-threaded chat mode, mostly in that the recipient's account needs a feature for holding messages (implemented by the recipient's server).
As far as I know, MIT hasn't given any information to the RIAA. The RIAA sent them a bunch of documents to pass on the users of particular addresses, and MIT did so without telling the RIAA who they passes the documents on to. This actually seems like the thing that MIT could do that could hurt the RIAA the worst, since it means that people are receiving these letters who the RIAA hasn't gotten any sort of background information on. It's only a matter of time before the RIAA accidentally threatens somebody they really shouldn't threaten if they send threatening letters blind like that. If MIT refused to pass on the letters, the RIAA would subpoena records, and likely find out who they were dealing with before they'd done anything objectionable, and they'd probably just forget about anyone who didn't look like a good prospect.
Currently, the top item for buying MySQL is a $599 software package that you need some suitable machine to run it. When they've rearranged things, I bet the top item will be a $2000 server comprised of the $599 software, a $1200 Sun server, and everything already set up. This is a more compelling offering in terms of a business getting froom purchase to actually using it, so they'll probably have more sales than MySQL did before. It gives a compelling benefit over using a no-cost version of MySQL, since it's all put together. It means that the machine is all one supplier, so there's no support people pointing fingers, meaning more effective support for the cost. And it's new sales of computer hardware, because people would currently never think to buy a Solaris server from Sun to run MySQL on.
Between all of those factors, I could see owning MySQL being worth $1b to Sun, even if MySQL's value in general is much lower. And, given Sun's flaky reputation in the Open Source world, I could understand MySQL refusing any lower offer.
On the other hand, I expect to see only a third of Sun's increase in income due to ownership of MySQL to come from getting the money when people buy MySQL products, and much more to come from an increase in Sun's income from existing products.
"I have a dream that my four children will one day run on a system where they will not be judged by the ID of their group but by the locks that they hold."
Slashdot Mirror
If they're actually using an embedded distribution, it's not too unlikely that it doesn't have the usual GNU software on it at all. They could go with newlib, busybox, and dash, and not include a native build environment, and it would be hard to argue that it's a GNU system at all. GNU stuff in that layer is really nice for interactive use, but if your scripts are all POSIX and you don't expect people to work on the system from inside, you can cut out a huge amount of space that goes to making things that won't matter nice.
Actually, it was sent to the mailing list that OpenSSL's README says to send patches to. They just seem not to have looked at it.
Apple cares more about high margins than market share in computers. There's no way that corporate purchasing is going to be sold on high-margin items by a vendor, because the things a vendor can offer aren't going to be sufficiently compelling in a marketing blurb to overcome the fact that the price is out of line. On the other hand, Apple can sell well to individuals based on getting people to like products that aren't available from other companies regardless of price. And individual employees at companies influence how the company spends its per-employee overhead (does the company buy nicer chairs? new cubicles? better snacks? macs?). This means that Apple is in a position where companies will be looking for the most cost-effective way for them to acquire Macs. Apple could put together a whole corporate program and send an account rep to companies that are considering buying from Apple, but all that would do is give the company somebody to negotiate a better deal with. Apple actually does better to ignore the company and leave it no choice but to go to the Apple Store and buy from people or computers that don't negotiate but just charge what the price tag says.
I think the only thing that Apple would want to change is that corporate IT is afraid of getting support and repair calls they don't know how to handle. To a certain extent, this isn't a problem so long as employees only get Macs if they ask for them, because Apple puts a lot of effort into motivated individual users being able to take care of their Macs without a help desk. But they'll probably want to streamline the process of selling out-of-warranty repairs in large numbers for the same owner. And they may want to work on getting corporate IT workers to buy Macs as their home computers.
I think the interviewer wasn't asking the right questions. His answer was for why you can't replace a GPU with an N-core CPU, not why you wouldn't put a GPU on the same die with your CPUs. I think his answers in general imply that it's more likely that people will want GPU cores that aren't attached to graphics output at all in the future, in addition to the usual hardware that connects to a monitor. I wouldn't be surprised if it became common to have a processor chip with 4 CPU cores and 2 GPU cores, and also have a graphics card with another GPU or 2 in addition to video output.
He is right that having a 16-core CPU won't do a number of common tasks efficiently, compared to a single massively-SIMD core.
It requires that you have 4G of RAM on a 32-bit kernel without PAE and have enabled sparsemem. Yes, despite having more physical memory installed than the size of the address space, you think your memory is sparse. Probably nobody ever configured the kernel like this until Ingo was doing random configurations (for testing) on a high-end machine.
Sure, it's a bug, and was a mess to debug, but it turned out that probably nobody would have ever had a problem with this in practice. But they didn't know that until they'd debugged it, and they didn't want to leave a weird memory corruption bug they didn't understand, even if they'd only seen it in a strange configuration, because it could have turned out to happen on other configurations less frequently. And they put in a bunch of infrastructure to test this, too.
Why shouldn't there be a lag between when your decision is fixed and when you know you've made it? This fits perfectly with the idea that you propose an option to yourself and then spend some time trying to think of any flaws with it. And if you do think of some flaw, you won't instantly choose a different option; you'll consider that one for some time. In any case, you'll generally not finalize anything until you've spent some time with that as the most favored option, so it's not too surprising that they can pick that out before you commit.
It's like taking a test. You think of yourself as finishing the test when you turn it in. But the answers you will turn in are on the paper since before you started checking them over. You can predict with high accuracy what answers people will give long before they consider themselves done just by reading what they've written. The only new thing here is that we can read people's answers when the answers are in their heads.
Actually, the only claim where the math actually works out is that, if you're given a choice between two options, you'll pick the one you prefer very slightly, but if you have a choice between three objects, you'll pick each one in proportion to how much you like it. In order for the chance of picking the same one twice to be 2/3 based on the same math as the Monty Hall situation, it has to be that the bias in pairwise choices is total. If the bias in this situation is less than total, the chance is less that 2/3.
The Monty Hall problem would work out very differently if it went as follows: you pick a door. Monty opens a different door, picked arbitrarily (and sometimes this reveals the car). Then you have the option of switching to the other unopened door. In this case, it doesn't matter what you do: 1/3 of the time, it's behind the door you started with, 1/3 of the time it's behind the you you could switch to, and 1/3 of the time Monty reveals the car and you aren't allowed to switch to it.
Similarly, if your bias is very slight, you'll pick the same M&M twice very slightly more than 50% of the time. So if bias is the reason for the 2/3 result of picking the same M&M, we're left with the mystery of why the large bias is undetectable.
Now it is a consistent explanation that, given a pairwise choice, you'll respond with a large bias, but given three options, you'll have no bias. Likewise, it's possible that you have a strong bias that drifts around, such that, in two trial in order, your bias is the same, but if you get lots of chances to choose, you'll change your favorite around such that it balances out.
But the math doesn't support the idea that there's no effect here, just the potential for some alternative claims as to what the effect is.
Sure, if you want to predict ovulation slightly better than chance in large samples with no systematic bias. But other factors (including, for example, what impression the person wants you to get) have a larger effect that gets averaged out in studies. Clothes will tell you whether a woman is ovulating, but they're no more likely to get you the right answer than asking her; either way, you'll only get the right answer if she doesn't have a particular answer she wants you to get, or if you average across a large number of trials.
The problem with making drivers bulletproof is that the hardware is inherently privileged and the interaction between the drivers and the hardware isn't documented. If the driver does some wrong things, the hardware will lock the PCI bus and there's nothing the OS (or the processor) can do. If the driver does other wrong thing, the hardware will DMA into the wrong place which ignored memory protection. And the kernel doesn't know how to validate the driver's bus transactions to prevent these. Having drivers in user mode makes it less easy to BSOD the machine, but doesn't prevent other problems.
You're thinking of microsaccades rather than saccades (which are larger scale jumps from one point of focus to a different point of focus). Microsaccades are probably actually actively helpful in precise eye tracking, because they end at the target of fixation, and therefore pick out the relevant spot within the area that the focus drifts within.
If they don't play by the rules, Google complains to the FCC, and also makes an offer on having the FCC turn over the spectrum to Google. I doubt the FCC would resist too much being able to get away with selling the same thing twice. So long as there are competitors who would buy the spectrum if the FCC had it back, the terms of the agreement are meaningful, because it's in other people's interest for Verizon's deal to fall through, especially after they've already paid their money.
Who cares about spying if you don't do anything wrong?
The people whose personal information gets stolen off of improperly secured FBI computers. People dating former spouses of FBI agents. It's not really an issue of the information that "the FBI" has and can use for prosecution of crimes; it's an issue of the information that FBI agents will encounter and not forget when they go home, and the FBI director who can blackmail anybody anywhere with legal but embarrassing information.
It's obviously because people don't eat whale but people hunt them that they have breed whale-cows. That way, the whalers can hunt whale-cows for food. And then they can be all snooty for insisting on free-range whale-cow beef. Incidentally, this is in no way a scheme to appease Godzilla so he doesn't have to come ashore when he feels like land mammals for dinner.
People make fun of the TSA for this, but it's only a matter of time before somebody mounts an Air on a pole and starts wielding it as a battle axe.
Good thing desktop users are unlikely to install a new non-distro kernel between February 28th, when Linus posted that, and March 4th, when he looked more carefully at what ndiswrapper is doing and determined that it's not re-exporting functions to non-GPL code, but rather using them to implement an API that's not a derived work of the kernel. Linus saying something dumb on a Thursday afternoon which he corrects on a Tuesday shouldn't be news on Wednesday, especially as it's a discussion about a kernel that hasn't been released yet, won't be for a couple of weeks, and probably won't be provided by distributions for a couple of months.
The point of time zones (including DST) is that you can find out the local current GMT offset, and you'll know what hours to expect local businesses to be open. Sure, I could guess that the bank will be open 13:00 to 21:00 UTC (14:00 to 22:00 UTC during the winter), but if I went to Chicago, branches of the same bank will be open from 14:00 to 21:00 (15:00 to 22:00 in the winter), and I'd have to remember what business hours are there, instead of having a device that conveniently maps those business hours to the same business hours we use at home.
Furthermore, in California in the winter, people working desk jobs would be leaving work on a different date than they arrived. If you were told you needed to get something in by closing time on Wednesday, you would have to figure out if you had to get it in before the closing time which is on Wednesday (UTC) or by when the business closes after opening on Wednesday (which may be the end of the Wednesday work day, but is on Thursday).
Like it or not, there's a lot of things that are common to events that happen at noon of the time zone they happen in. If you find out something was stolen at 13:50 UTC, and you don't know where it happened, you don't know if this was a bold daylight robbery or a thief in the night. If you know it happened at 4:50 am local time somewhere, you have a better idea of what the event was like, even without knowing where it was. The fact that, in other places, businesses were open and people were around isn't very helpful.
Gasoline-powered generators, of course. Fixed location electricity production is more efficient and cleaner than internal combustion engines, and easier to maintain effectively than devices that people drive all over the place, start and stop all the time, fail to monitor, and beat up. Even with the loss due to converting the energy twice, provided you've got some better storage than we've got now, it's more efficient, and it's cleaner in any case, since the step that generates emissions is all in one place and can have large and heavy filtering equipment without reducing performance (because it's not being dragged around). And there's supply and distribution in place for more than enough gasoline to power all of the electric cars that would replace gasoline cars (obviously, since the system as a whole is more efficient and uses the same energy source); furthermore, it would be easy to switch generation methods when other sources are cheaper than gasoline.
The main flaw with switching from gasoline to gasoline-generated electricity is the lower energy density of electricity storage, which is what this article is about addressing. Beyond that, there's a certain cost to installing generators at gas stations. And there's the issue that electrics (and hybrids) have tons of low-end torque, which means that you go 0 to 3 before you realize you've touched the accelerator.
If your employees are good, they'll tend to know other people who are good (from previous jobs, school, socially, or outside projects). If they know you want to hire people, and they like the company, they'll refer these people. People of the level you're talking about will generally be able to find jobs by way of their contacts of this sort, and will generally not want to talk to recruiters, HR people, or headhunters (all of whom are normally scary non-geeks).
The electrical grid is a really tricky system. You've got generators putting in energy at a bunch of points. And the whole thing is AC, which means that, if you look at any particular point, you see the voltage (and current) going in a sine wave. If you drive the system at the correct phase, you're supplying power; if you're slow by 1/120 second, you're turning twice your capacity into waste heat, and you start blowing up substations. Furthermore, since electricity moves at a finite speed along the wires, you can't just have a really good clock and have everybody agree; the difference in phase you need depends on the distance between the power plants along the wires. The solution is to have the power plant measure the phase of the lines they're on, and generate with a matching phase.
Now, if something goes wrong somewhere down the lines, the power plant may not be able to get a good read of the phase. At that point, you just shut down the power plant, shut down the substations (so there isn't customer load on the lines), get the switching stations fixed, start the power plant up again in phase, and reconnect the customers. It's only if the switching stations are really destroyed that they'd actually run a power plant for local customers disconnected from the national grid, and they'd have to shut it down again in order to rejoin the grid.
What happened today is actually how it's supposed to work in case of an equipment failure: a regional blackout, some time to repair the malfunctioning equipment or swap in replacements, and then restoring power. When the grid doesn't handle the failure correctly, power lines melt down and power company manholes and buildings blow up and service isn't restored for days to some customers.
Using vmsplice() in ordinary applications should improve system performance under load when appropriate (when you send full pages of generated data to a network connection, the kernel won't have to copy the pages, it can DMA straight to the NIC, saving work and cache space). So it's quite possible that distros would ship binaries that use vmsplice() if their default kernels support it, and it would be a performance hit to disable it. I don't know if any significant programs actually use vmsplice() yet, but it wouldn't be surprising.
Assuming you want it to be purely open source (and not sell proprietary licenses to it, like MySQL, for example), just ask them to license it to you under the GPL or BSD license. Either of these gives you, as licensee (it doesn't matter that you wrote the original code) the rights that you want, and they're well-understood documents. If they can't understand those licenses, they really have no business licensing their software to customers. And if they're not okay with licensing the software to you under those terms, they won't be okay with any document that effectively allows you to get that license to the software (and may also transfer copyright).
As far as whether you should try to get the copyright, having this company own the copyrights and only license it to you under the GPL and then have you work on it and only license your changes under the GPL means that nobody can change the license, since neither of those two copyright holders are likely to agree on a change. This can be preferable for end users over having a single copyright holder who could legally take future versions closed-source.
The main thing about email is that you can send it without publishing your presence, and you can send it to people who aren't online at the time. So it's a little more involved than the non-threaded chat mode, mostly in that the recipient's account needs a feature for holding messages (implemented by the recipient's server).
As far as I know, MIT hasn't given any information to the RIAA. The RIAA sent them a bunch of documents to pass on the users of particular addresses, and MIT did so without telling the RIAA who they passes the documents on to. This actually seems like the thing that MIT could do that could hurt the RIAA the worst, since it means that people are receiving these letters who the RIAA hasn't gotten any sort of background information on. It's only a matter of time before the RIAA accidentally threatens somebody they really shouldn't threaten if they send threatening letters blind like that. If MIT refused to pass on the letters, the RIAA would subpoena records, and likely find out who they were dealing with before they'd done anything objectionable, and they'd probably just forget about anyone who didn't look like a good prospect.
Currently, the top item for buying MySQL is a $599 software package that you need some suitable machine to run it. When they've rearranged things, I bet the top item will be a $2000 server comprised of the $599 software, a $1200 Sun server, and everything already set up. This is a more compelling offering in terms of a business getting froom purchase to actually using it, so they'll probably have more sales than MySQL did before. It gives a compelling benefit over using a no-cost version of MySQL, since it's all put together. It means that the machine is all one supplier, so there's no support people pointing fingers, meaning more effective support for the cost. And it's new sales of computer hardware, because people would currently never think to buy a Solaris server from Sun to run MySQL on.
Between all of those factors, I could see owning MySQL being worth $1b to Sun, even if MySQL's value in general is much lower. And, given Sun's flaky reputation in the Open Source world, I could understand MySQL refusing any lower offer.
On the other hand, I expect to see only a third of Sun's increase in income due to ownership of MySQL to come from getting the money when people buy MySQL products, and much more to come from an increase in Sun's income from existing products.
"I have a dream that my four children will one day run on a system where they will not be judged by the ID of their group but by the locks that they hold."