If you actually do something wrong, you're likely not to be covered, for the same reason you aren't allowed to intentionally destroy your stuff for the insurance money. This means that the insurance agency wants to fight out any lawsuit, such that they either win it (and can generally recover costs from the plantiff, leaving only the hassle and the delay on the money, both of which they're set up well to deal with) or they accumulate evidence they can use if they want to refuse to pay your claim. When OSRM started out, they made it explicit that the reimbursement could only be used for legal fees and such, not for a settlement or penalty.
What would make sense would be if OSX didn't have drivers for half of the hardware in the cheap machine. If OS X works on your cheap machine, but the sound doesn't work and animation is jerky (because it's not hardware accelerated), you could get an idea of how slick the interface is without actually being able to use it for day-to-day use. Part of the reason that Apple's stuff is stable is that there's a limited set of possible hardware configurations to test, at least for the non-hotplug stuff. It would make sense that this would imply, for example, no wifi unless you've got a built-in Airport, because there's no need to support other wifi on Apple hardware.
I bet most people heard about the original schedule, heard it got cancelled, and didn't pay too much attention to the new schedule before it was definite; but then they were asleep.
We don't really have the possibility of contradiction here, due to the way the system is constructed, and there isn't "true" or "false" (the information is essentially an arbitrary sequence of bits, and you just care whether you get it or not; we're assuming a theoretical error-free transmission).
You have to look at before and after a transmission (of, say, 1(f); this will be what tells you that the lookups are spent, and must be new information). Before, you have 100(f) + 2(Lu) = X; after, you might have 103(f) or 101(f). Now, the rules of information theory say that you can't acquire more information than the content of the transmission, and exercising the lookups doesn't count as a transmission. So X must be (at least) 102(f), because of the 103(f) case. But that means that the 101(f) case resulted from a -1(f) transmission.
The oddity results from the facts that whether resolving the lookups will get you anything is nondetermined until it happens, and that resolving the lookups isn't a transmission of information.
It would make more sense, if they wanted to prevent WINE from having access, to check that you have some registry key that's not needed for anything else and only shows up with official Windows installations. Then they can just ask WINE not to use it (or not to set it to one of the Windows values) and be clear about their policy. It's a bit foolish to try to identify a WINE system by WINE's keys, which will obviously change at the whim of the WINE developers.
Most likely, they don't really care; if you've gone so far as to run WINE, you're probably not just trying to avoid paying for Windows. They're much more interested in the people who are using Windows but not paying for it.
The trick is that you can use quantum entanglement to have excess unspecified knowledge, which can be converted into specific knowledge. It's like being on a quiz show where you are given a certain number of times you can look up an answer. These bonuses have to count in your total knowledge (I know 100 facts, plus I can look up things twice). If someone tells you something, you get positive information. If you look something up, you get zero information (you trade a bonus lookup for a fact). If you look something up, and you already knew the answer, you get negative information.
Now think about it as if someone else controlled the book. They can tell you things over the phone, and they can cause answers to pop out of the book. If they waste the book on something you actually already knew, your total information goes down, so the information in the transaction is negative.
The NASA document on the subject is somewhat unclear, but it looks to me like they've been phasing out all of the CFC-11 foam, and it's unclear to me as to whether the old hand-poured foam was ever Freon-based.
Hydrogen gas is a byproduct of oil refining. Last I heard, the demand for hydrogen gas was not up to the quantity produced as a side effect of making gasoline. So the environmental costs are actually just for capturing it, cleaning it, transporting it, and chilling it, not the original step. (Also, the higher-yield process that would be used to mass-produce it is more environmentally friendly than refining and combusting it.)
The cleaning is needed because some of what gets refined out of the oil is sulfer, which comes out as hydrogen sulfide, and needs to be removed and dealt with.
Google actually bet a million-dollar company on Linux. They're a multibillion-dollar corp now because it paid off. It's different to change infrastructure once you're already a huge company, because you've got a lot of people with procedures set up that have to learn new ways of doing things.
You actually mean that Sun and MSFT have larger lunch budgets for CIOs. What Oracle wants to sell you these days is actually Oracle on Linux (because Solaris is slow and expensive and Windows comes from their main competitor).
More idiomatically: The Secret Organization - The Organization of Qa'idat al-Jihad in Europe. The word "qa'idah" ("qa'idat" in construct cases) is a neutral word meaning "base," as in "military base" (qa'idah 'askariyah) or "database" (qa'idat bayanat), and it collocates naturally and frequently with "jihad." So, al-Qa'idah is really "the Base for Waging Jihad," or "the Base" for short.
So the word for "base" is part of the expression for "database" just as it's part of other expressions, including "holy war base", which is what "The Base" idiomatically refers to these days.
Many things do have to be done "locally", but that depends on just how locally you mean. These days, local networks are reasonably common (if only so that 4 family members' computers can share a network connection), and sticking a web app on one of these computers is certainly technically feasible. The application-as-service idea is a non-starter, but there's still the possibility of having applications that a group member runs for the group.
Personally, I think that Java didn't get anywhere in this space because the standard UI library sucks so badly and it doesn't have the necessary primitives to make one that doesn't suck. AJAX has the advantage that the UI primitives are those from the web, and are at least based on a lot of experience and some success at this point. (The main useful position for Java is server-side, where its job is to write web pages to sockets, and the available primitives basically work.)
It's time consuming to ask everybody whenever you're looking for some software. If you were choosing between qmail, exim, and sendmail, it would be tricky to accurately determine their popularities without some formal method. And applying a formal method takes a lot of work, which would need to be done by everyone trying to choose a program. The point of this project is to do that for you.
The example at the end that show how he thinks you should do things are broken. While it is useful to give your variables meaningful names, it is less useful if you give the same variable different names.
For that matter, I think that, if something is a simple loop counter, it should has a one letter name like 'i', so that someone reading the code can tell at a glance whether you're doing anything unexpected. Also, it's confusing to reuse a variable for a different purpose, and dead assignments are also bad. (isAlive has the liveness of different participants at different times, and ends up with the attacker's liveness if the defender's teammates attacked or if the attacker was killed before attacking, and the defender's liveness otherwise. Also it depends on the variable being initialized silently to true; otherwise, attackers don't attack unless defenders did a preemptive strike that didn't kill them.)
Comments should reproduce design. If they reproduce code, they're redundant and likely to become inaccurate. The design, on the other hand, is useful to know, and not actually otherwise in the file. They should say what the code is supposed to do, rather than what it actually does.
Actually, driver support for desktops is getting a lot easier these days, because there's a really common motherboard chipset with all the necessary capabilities for someone who doesn't install any extra hardware.
Of course, having a program to configure the kernel for the hardware that's in it, as well as hotplug support for figuring out what unsupported device you've plugged in and building the module would be really nice, but it's a lot less necessary with the current state of the hardware world.
They've got two branches (mainline and -mm). They do parallel deployment. The problem they're having is that people stick with the old system until it goes away, and then complain about the new system not working. The change is designed to get all of the completed development into the stabilizing system at the start of the cycle, so that it will only get bugfixes during the cycle, and will actually work when it is blessed as "stable", rather than only after being "stable" for a few point releases.
There's no reason to test the patch with 2.6.13 (as opposed to 2.6.13-rc4) if you're trying to get it into 2.6.14; there's a much higher chance that something will break it between 2.6.13 and 2.6.14-rc1 than between 2.6.13-rc4 and 2.6.13, since the former is when all of the new features are getting put in, and the latter is only the last set of bug fixes during a code freeze. The point of the change is so that you're not the only person testing it in the cycle leading up to the release that includes it, because bugs will probably show up in configurations you don't have.
Of course, the right way to get a change made is to get it into -mm now (or whenever), and have it working there; then it'll get tested and accounted for in other development, and will get put in by default at the start of the cycle if there's been good feedback. Then you just have to test it in -rcs and report if it gets broken.
The reality might be however that an improved VM is needed but all the Red Hat guys are busy working on some scheduling code that really isn't as crucial.
That's fine, because an improved VM can only really be done by developers who have specialized in the VM, not the people working on scheduling code. Practically all of Linux is to the point now that you can only improve it if you have some special qualification (which may be just that you have the hardware you want a driver for, or might be a lot of experience with some subsystem, or might be experience with some architecture). For that matter, we're not seeing less work by volunteers; it's only proportionately less.
For that matter, there's not very much to do on the kernel, except for esoteric stuff (which is huge, but few volunteers are likely to be interested, because it's stuff like cash registers and supercomputers). Most of the interesting stuff for people with computers to do at this point is in userspace.
Back in my day, we didn't have these duplicate articles. We only had one story about any article, and we had to fetch it manually. With TCP! Upstream both ways! And we liked it that way!
Everybody who's presenting at SIGGRAPH is releasing their work to the community as a way to advance the state of the art, to get fame, and to seek feedback. The OSS community is not all that different, except that it is dealing in implementations rather than techniques. Looking at things this way, it should be obvious to people in the industry how OSS is useful and can coexist with proprietary software.
You don't get direct hardware access from userspace under a moderm OS regardless of the language or environment; the actual processor hides that from you without needing a virtual machine. What Java and Lisp hide from you is arbitrary access to memory in your address space, which means that the system can safely store data in your address space, you can have multiple programs that don't entirely trust each other in the same address space, and that buggy code can't screw up the program state into an incoherent state relative to the programming language model.
If they did that, they'd have to update their figures more often. This way, they can say that 45nm is 1/1333rd the size of a human hair, while 90nm is 1/1333rd the size of a different human hair.
Ask them if they'd have been able to write the these brilliant arguments that shaped the Constitution of the United States of America if the very paper they'd printed it on could have been used to strip them of their anonymity?
The paper the Federalist Papers was printed on was clearly marked with its origin, since they were printed in newspapers. The authors hand-wrote the versions they submitted, and their contacts at the papers probably knew who they were (they wouldn't have published 85 letters to the editor from anonymous sources that just arrived in the mail). Now, you could make your point in favor of giving legal protection to communication between reporters and anonymous sources, but documents have never had all that much anonymity.
The ones who can't tell the difference between virtual and actual reality aren't going to be much of a problem these days, since they'll be trying to attack people with their controllers or mice. Virtual reality, particularly currently, isn't much like actual reality with respect to human interface.
Slashdot Mirror
If you actually do something wrong, you're likely not to be covered, for the same reason you aren't allowed to intentionally destroy your stuff for the insurance money. This means that the insurance agency wants to fight out any lawsuit, such that they either win it (and can generally recover costs from the plantiff, leaving only the hassle and the delay on the money, both of which they're set up well to deal with) or they accumulate evidence they can use if they want to refuse to pay your claim. When OSRM started out, they made it explicit that the reimbursement could only be used for legal fees and such, not for a settlement or penalty.
What would make sense would be if OSX didn't have drivers for half of the hardware in the cheap machine. If OS X works on your cheap machine, but the sound doesn't work and animation is jerky (because it's not hardware accelerated), you could get an idea of how slick the interface is without actually being able to use it for day-to-day use. Part of the reason that Apple's stuff is stable is that there's a limited set of possible hardware configurations to test, at least for the non-hotplug stuff. It would make sense that this would imply, for example, no wifi unless you've got a built-in Airport, because there's no need to support other wifi on Apple hardware.
I bet most people heard about the original schedule, heard it got cancelled, and didn't pay too much attention to the new schedule before it was definite; but then they were asleep.
We don't really have the possibility of contradiction here, due to the way the system is constructed, and there isn't "true" or "false" (the information is essentially an arbitrary sequence of bits, and you just care whether you get it or not; we're assuming a theoretical error-free transmission).
You have to look at before and after a transmission (of, say, 1(f); this will be what tells you that the lookups are spent, and must be new information). Before, you have 100(f) + 2(Lu) = X; after, you might have 103(f) or 101(f). Now, the rules of information theory say that you can't acquire more information than the content of the transmission, and exercising the lookups doesn't count as a transmission. So X must be (at least) 102(f), because of the 103(f) case. But that means that the 101(f) case resulted from a -1(f) transmission.
The oddity results from the facts that whether resolving the lookups will get you anything is nondetermined until it happens, and that resolving the lookups isn't a transmission of information.
It would make more sense, if they wanted to prevent WINE from having access, to check that you have some registry key that's not needed for anything else and only shows up with official Windows installations. Then they can just ask WINE not to use it (or not to set it to one of the Windows values) and be clear about their policy. It's a bit foolish to try to identify a WINE system by WINE's keys, which will obviously change at the whim of the WINE developers.
Most likely, they don't really care; if you've gone so far as to run WINE, you're probably not just trying to avoid paying for Windows. They're much more interested in the people who are using Windows but not paying for it.
The trick is that you can use quantum entanglement to have excess unspecified knowledge, which can be converted into specific knowledge. It's like being on a quiz show where you are given a certain number of times you can look up an answer. These bonuses have to count in your total knowledge (I know 100 facts, plus I can look up things twice). If someone tells you something, you get positive information. If you look something up, you get zero information (you trade a bonus lookup for a fact). If you look something up, and you already knew the answer, you get negative information.
Now think about it as if someone else controlled the book. They can tell you things over the phone, and they can cause answers to pop out of the book. If they waste the book on something you actually already knew, your total information goes down, so the information in the transaction is negative.
The NASA document on the subject is somewhat unclear, but it looks to me like they've been phasing out all of the CFC-11 foam, and it's unclear to me as to whether the old hand-poured foam was ever Freon-based.
Hydrogen gas is a byproduct of oil refining. Last I heard, the demand for hydrogen gas was not up to the quantity produced as a side effect of making gasoline. So the environmental costs are actually just for capturing it, cleaning it, transporting it, and chilling it, not the original step. (Also, the higher-yield process that would be used to mass-produce it is more environmentally friendly than refining and combusting it.)
The cleaning is needed because some of what gets refined out of the oil is sulfer, which comes out as hydrogen sulfide, and needs to be removed and dealt with.
Google actually bet a million-dollar company on Linux. They're a multibillion-dollar corp now because it paid off. It's different to change infrastructure once you're already a huge company, because you've got a lot of people with procedures set up that have to learn new ways of doing things.
You actually mean that Sun and MSFT have larger lunch budgets for CIOs. What Oracle wants to sell you these days is actually Oracle on Linux (because Solaris is slow and expensive and Windows comes from their main competitor).
So the word for "base" is part of the expression for "database" just as it's part of other expressions, including "holy war base", which is what "The Base" idiomatically refers to these days.
Many things do have to be done "locally", but that depends on just how locally you mean. These days, local networks are reasonably common (if only so that 4 family members' computers can share a network connection), and sticking a web app on one of these computers is certainly technically feasible. The application-as-service idea is a non-starter, but there's still the possibility of having applications that a group member runs for the group.
Personally, I think that Java didn't get anywhere in this space because the standard UI library sucks so badly and it doesn't have the necessary primitives to make one that doesn't suck. AJAX has the advantage that the UI primitives are those from the web, and are at least based on a lot of experience and some success at this point. (The main useful position for Java is server-side, where its job is to write web pages to sockets, and the available primitives basically work.)
It's time consuming to ask everybody whenever you're looking for some software. If you were choosing between qmail, exim, and sendmail, it would be tricky to accurately determine their popularities without some formal method. And applying a formal method takes a lot of work, which would need to be done by everyone trying to choose a program. The point of this project is to do that for you.
The example at the end that show how he thinks you should do things are broken. While it is useful to give your variables meaningful names, it is less useful if you give the same variable different names.
For that matter, I think that, if something is a simple loop counter, it should has a one letter name like 'i', so that someone reading the code can tell at a glance whether you're doing anything unexpected. Also, it's confusing to reuse a variable for a different purpose, and dead assignments are also bad. (isAlive has the liveness of different participants at different times, and ends up with the attacker's liveness if the defender's teammates attacked or if the attacker was killed before attacking, and the defender's liveness otherwise. Also it depends on the variable being initialized silently to true; otherwise, attackers don't attack unless defenders did a preemptive strike that didn't kill them.)
Comments should reproduce design. If they reproduce code, they're redundant and likely to become inaccurate. The design, on the other hand, is useful to know, and not actually otherwise in the file. They should say what the code is supposed to do, rather than what it actually does.
Actually, driver support for desktops is getting a lot easier these days, because there's a really common motherboard chipset with all the necessary capabilities for someone who doesn't install any extra hardware.
Of course, having a program to configure the kernel for the hardware that's in it, as well as hotplug support for figuring out what unsupported device you've plugged in and building the module would be really nice, but it's a lot less necessary with the current state of the hardware world.
They've got two branches (mainline and -mm). They do parallel deployment. The problem they're having is that people stick with the old system until it goes away, and then complain about the new system not working. The change is designed to get all of the completed development into the stabilizing system at the start of the cycle, so that it will only get bugfixes during the cycle, and will actually work when it is blessed as "stable", rather than only after being "stable" for a few point releases.
There's no reason to test the patch with 2.6.13 (as opposed to 2.6.13-rc4) if you're trying to get it into 2.6.14; there's a much higher chance that something will break it between 2.6.13 and 2.6.14-rc1 than between 2.6.13-rc4 and 2.6.13, since the former is when all of the new features are getting put in, and the latter is only the last set of bug fixes during a code freeze. The point of the change is so that you're not the only person testing it in the cycle leading up to the release that includes it, because bugs will probably show up in configurations you don't have.
Of course, the right way to get a change made is to get it into -mm now (or whenever), and have it working there; then it'll get tested and accounted for in other development, and will get put in by default at the start of the cycle if there's been good feedback. Then you just have to test it in -rcs and report if it gets broken.
The reality might be however that an improved VM is needed but all the Red Hat guys are busy working on some scheduling code that really isn't as crucial.
That's fine, because an improved VM can only really be done by developers who have specialized in the VM, not the people working on scheduling code. Practically all of Linux is to the point now that you can only improve it if you have some special qualification (which may be just that you have the hardware you want a driver for, or might be a lot of experience with some subsystem, or might be experience with some architecture). For that matter, we're not seeing less work by volunteers; it's only proportionately less.
For that matter, there's not very much to do on the kernel, except for esoteric stuff (which is huge, but few volunteers are likely to be interested, because it's stuff like cash registers and supercomputers). Most of the interesting stuff for people with computers to do at this point is in userspace.
Back in my day, we didn't have these duplicate articles. We only had one story about any article, and we had to fetch it manually. With TCP! Upstream both ways! And we liked it that way!
Everybody who's presenting at SIGGRAPH is releasing their work to the community as a way to advance the state of the art, to get fame, and to seek feedback.
The OSS community is not all that different, except that it is dealing in implementations rather than techniques. Looking at things this way, it should be obvious to people in the industry how OSS is useful and can coexist with proprietary software.
You don't get direct hardware access from userspace under a moderm OS regardless of the language or environment; the actual processor hides that from you without needing a virtual machine. What Java and Lisp hide from you is arbitrary access to memory in your address space, which means that the system can safely store data in your address space, you can have multiple programs that don't entirely trust each other in the same address space, and that buggy code can't screw up the program state into an incoherent state relative to the programming language model.
You must not have been paying attention. Slashdot reported it ages ago.
If they did that, they'd have to update their figures more often. This way, they can say that 45nm is 1/1333rd the size of a human hair, while 90nm is 1/1333rd the size of a different human hair.
Ask them if they'd have been able to write the these brilliant arguments that shaped the Constitution of the United States of America if the very paper they'd printed it on could have been used to strip them of their anonymity?
The paper the Federalist Papers was printed on was clearly marked with its origin, since they were printed in newspapers. The authors hand-wrote the versions they submitted, and their contacts at the papers probably knew who they were (they wouldn't have published 85 letters to the editor from anonymous sources that just arrived in the mail). Now, you could make your point in favor of giving legal protection to communication between reporters and anonymous sources, but documents have never had all that much anonymity.
The ones who can't tell the difference between virtual and actual reality aren't going to be much of a problem these days, since they'll be trying to attack people with their controllers or mice. Virtual reality, particularly currently, isn't much like actual reality with respect to human interface.