As case law goes, that's pretty damn feeble. Case law can also be nullified by any subsequent case law, criminal law, civil law, common law or Constitutional amendment. Based on the Supreme Court's actions over the CIA kidnap case, it is possible that courts can conclude that Executive Orders can also supersede case law.
If I was a juror, I'd want to be damn sure that the precedent governing jury nullification was still the law of the land before applying it. Furthermore, jurors cannot consider elements not presented in court, which means they'd only be able to consider nullification if nullification was presented as an element in the case.
The woman also lied to the jurors, under oath. My guess is that the Quaker in the precedent did not do so, but was sincere and honest. Breaking oath is going to upset jurors if they catch on to it. And rightly so. Personally, I'd prefer it if courts were more willing to demand truth on the stand. No legal system can function without truth, because what is presented is all any judge or jury can go on.
My guess is that the RIAA also deliberately lied under oath, and it is my belief that any such lie uncovered should have resulted in the prosecution witness responsible being jailed and possibly the trial suspended until the witness recanted. (Unintentional inaccuracies are one thing. Although they are not "the whole truth and nothing but the truth", I'd call it a reasonable allowance. Deception, on the other hand, should be a no-no.) Yes, it would make trials a LOT longer - and larger trials might never finish at all - but my guess is that you'd see a dramatic drop in both malicious prosecution and bogus convictions.
I also believe that if truth were required, you'd also see far fewer cases ending up with the jury blatantly penalizing the attitude rather than the action. It's obvious enough that that's what the bulk of the fine was - a slap across the face for the lies and deception. The attitude would have already been penalized and the jury would be free to consider the case itself and not the personalities within it.
(ObTrivia: If I ran the country, it would be fair, just, civilized... and bankrupt, boring and mostly in jail or mental institutions. It is a very, very good thing that I have enough trouble running my own life to be interested in running anyone else's.)
Last I heard, Universities taught the underlying theories and underlying principles, the science behind the practices and the maths behind the science. At least, that is what happened at the University I went to. And, as Inmos mostly worked with recent graduates, I feel confident in saying that many of the better European Universities work this way.
Knowing what was common practice at the time the text books were written is useless. Books take years to write, by people who aren't usually researching at the same time, so must be drawing on older knowledge still. It can then take years more before those books begin to be picked up by Universities. Any book talking about an implementation that existed at the time of writing is talking about an implementation that probably no longer exists at the time of the course.
Theory, on the other hand, changes much more slowly. People knew of electron tunneling long before it started showing up in silicon or germanium arsonide chips. People knew the theories behind good software and hardware designs long before such designs became practical to build. (In the case of software, formal methods are still regarded as impractical in their ideal form, but it is in their ideal form that the best software will be written.) Relational database theory existed long before there existed computers nearly powerful enough to run relational databases.
The theory is the foundation on which all practical achievements can take place. Without a foundation, no stable achievement is possible. That is why a certain range of products made by a well-known company, without regard to foundational knowledge, are of such poor quality. You can't build indefinitely on sand and expect the structure to hold up.
There is no value in teaching "practical" skills at University, because what is practical will have long-since moved on and vanished into the horizon. What you need to teach is how to distinguish what is practical from what is not, how to learn what is practical today (and tomorrow), and how to develop new practices from what exists. Students should be concerned only with learning how to move forward efficiently and effectively, given whatever starting point they discover themselves as having.
Huh? I can be wrong - it does happen from time to time. Let's look at what the GPL says:
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
I would argue that (b) would allow you to physically perform source distribution from someone else's machine to the user's machine. This section only requires that you perform the distribution and be able to do so for a given length of time, it doesn't seem to say anything about who actually does the hosting. If the user is told to select link 1 (which downloads the basic source) and then select link 2 (which downloads a self-extracting, self-installing patch), then I'd consider that as a written offer to give a third party a complete machine-readable copy of the corresponding source code on a medium customarily used for software interchange.
Is this a reasonable interpretation? Well, patches and shar files are indeed customarily used for software interchange, so I don't see any argument even on the next layer up.
Is this a common interpretation? Virtually all Linux kernel projects I know of (and I track about thirty or so) provide kernel patches, NOT a patched kernel. Some (but by no means all) provide links to the vanilla kernel sources. I would argue that those who provide no link at all do indeed violate the GPL, as what is provided is not really "complete", even indirectly. However, I can't remember the last time anyone fried them for non-compliance. Can you give me an example of that ever happening? If not, it would seem I have a stricter interpretation of the GPL than many developers.
Well, a 5 second boot time and a Flash image of Linux matches the specs and description of LinuxBIOS. If that is what they are using, then there is really nothing much for them to release other than maybe some minor patches. I would consider them entirely in compliance with the GPL if they provide their own additions (in full) and how those additions are added, along with a comprehensive set of package names, versions, URLs of master sources, and so on. Actually hosting more than they wrote would seem to be unnecessary, so long as EVERYTHING is made available.
However, given that this is almost certainly just a LinuxBIOS-flased motherboard with a mini distro on whatever bytes were left over, I'd say that it should be possible to produce a comparable system on any motherboard that is capable of holding a Flash chip of the necessary size. (This will be a LOT bigger than normal, so you may hit a whole bunch of design limitations.) It should therefore be possible to sell LinuxBIOS + BIOSdistros for any motherboard out there that can handle the chip, as an upgrade.
I support ASUS' experimentation - that's good - but people need to see that it's late in coming and it's more limited than the technology supports. Motherboard companies shouldn't be permitted to move as slow as possible and drag their feet when it creates the delusion that technology is more limited than it really is. The pace needs to be upped a little - just enough to show the consumers that they've been paying top dollar for decade-old components.
If you scaled each region by population, scaled the thickness of each line by bandwidth scaled the brightness of each line by reliability, and used the three primary colours to indicate whether the line supported IPv6, MPLS or multicasting in addition to the mainstream Internet protocols, you would produce a more representative map that would better reflect actual Internet service and coverage but would also be totally unreadable and would also likely destroy the credibility of most of the major Internet-enabled nations.
The Olympic-style carbon-fibre bikes can push amazing speeds - for very short distances, and they are strong enough to do the job but nothing more. Replacing the standard plastic they combine with the carbon-fibre with this new plastic, you could probably build a marginally lighter bike that could set new records, but it still wouldn't be a bike you'd want to take out on the road. Remember, strength is NOT the same as rigidity, and the two are often in direct opposition.
Doing something is indeed the best way to learn the practice, but it's not necessarily such a good way to learn the theory. If you don't understand why something works, then knowing that it works is less useful. Theory can't be taught so well in a lab setting, but seems to be best done in a traditional lecture-hall setting. Having said that, I do agree that rote learning is a BAD mistake. Again, it substitutes replication for understanding - these are not the same thing.
Some of the oldest schools of all work along a method known as "Classical Education", in which it is argued that understanding is impossible without context, and that context requires diversity of knowledge, not specialization. It argues a few other things I don't agree with - there is no inherent superiority to Greek or Latin - however, it has been shown several times in studies that additional languages increases overall brain capacity and decreases the rate at which brain function will decay over a person's lifespan. The brain grows far larger than is normally needed and thins back the unused portions in the late teens, early 20s, according to studies. If it's made use of, maybe this will improve the capacity of the brain overall, in addition to slowing mental aging.
New technologies don't enter into the discussion except insofar as they provide an effective means of delivering information. Generally, they don't, except in lab settings when they allow people to learn what those devices can do. Computer assisted learning has been shown to be a tough problem and one not easily solved except in very isolated cases - and the most effective CAL has been in the form of rote memorization. Nobody has taken technology much beyond that point yet.
If system A has a direct connection to external stimulus B, and system A moves to a deterministic state for any given fixed value of B, for all B, then A is a direct I/O device. (Chaotic systems are non-predictable, but they are wholly deterministic. The distinction is important.)
If system A has a direct connection to external stimulus B, and system A moves to a non-deterministic state for at least one value of B, then A is a quantum device. (Quantum systems are the only physical systems in which true randomness can exist.)
If system A has no direct connection to ANY external stimulus, but is rather operating solely off an internal model which may or may not ever get updated from an external source, then A not only exists independent of whether B exists, but cannot ever establish by any test as to whether B exists. Within normal operating conditions, A can be treated as though it were in a pocket universe, independent and isolated from the universe in which any B may exist, and should therefore be regarded as an isolated system.
The brain may be an I/O device, a chaotic system, or an isolated system. Arguments have been given for each. One thing it is NOT is a modulated system. That possibility does not really exist. The moment the connection becomes indirect, then you run into the limitations of knowledge and certainty. If you cannot distinguish between modulation by an external cause and a change of state due to internal causes, then you can't ever know if the external exists at all. It might all be a figment of your imagination. You can't conduct any test to establish otherwise, as any test which is definitely not a figment of your imagination cannot alter the external and anything that can definitely alter the external cannot be provably not a figment of your imagination.
As for Linux, the inability to determine a future state is NOT the same as the future state being non-deterministic. You cannot produce a quantum OS using Turing logic. You CAN produce an isolated system, and some research into strong AI and machine reasoning goes in this direction, but it hasn't been terribly useful so far.
How many movies have you seen where the hero rescues household finances by preventing the cups from getting broken? Or builds a 200 mpg car by replacing the iron shell with plastic, preventing the total collapse of the US car industry and Western Civilization?
Let's face it, mundane (but realistic) uses aren't exciting and don't make good stories. The microwave gun that generates pain across nerve endings is discussed in terms of urban combat and riot-suppression, but in the real world, more people are probably going to end up using the device in farmland where electric fences are impractical or impossible, as a replacement for noisy bird scarers, possibly even in a very low-power form in medical diagnostics when you want to generate a very controlled stimulus to determine the location and extent of nerve damage, etc.
An ultra-light plastic would be valuable for so many things, from cutlery to possibly safer alternatives to metal for pins and plates within the human body to a replacement for aluminium in airframes to a replacement for metals (lead especially) in "unbreakable toys". Depending on thermal properties, it may have uses in ducting where you need something strong but light. Depending on exactly what is meant by "strong", it may become a replacement for steel cabling in reinforced concrete - plastics tend to be better at aging. Current plastic drains are notoriously feeble. Now, please consider that Victorian drains are only now starting to reach the end of their lifespan, and Roman-era aqueducts are still perfectly functional, so anything that lasts a mere hundred years is simply living up to what was expected of material science a hundred years ago, and we really should be looking to match or better a bunch of iron Age punks. Could this plastic offer a cost-effective way of matching some of the greatest material science achievements in history?
Programmers could be given a transparently parallel environment - compilers could optimize the method according to communication needs, for example - but auto-parallelizing compilers have made little progress in 35 years, and even if they were perfected tomorrow, there still needs to be choices for the compiler to choose between.
Now, the next question is one of whether there needs to be as many choices. There are, after all, three different threading libraries in common usage (Pth, PThreads and OpenThreads). "Next Generation" N:M threading was abandoned by IBM, but someone, somewhere, may yet revive it if there's a case in which it is effective. Oh, almost forgot. Forking is not the same as threading (you get a different pid and it occupies a different place on the scheduler). Do we really need four or five different ways to have parallel execution within a single program?
So long as they are not identical in capability and flexibility, the answer is yes. Going back to optimization - sometimes lightweight, limited capabilities are superior, but equally sometimes heavy but powerful tools are the way to go. Most often, it'll be a compromise that's best. There isn't a single library (yet) that provides true hybrid RISC/CISC capabilities, so what you want is a range of options where you can pick the characteristics you want.
What about inter-machine communication? MPI, PVM and all that? With MPI, you specify the number of nodes at runtime. With PVM, you specify it at compile time. MPI-2 sports ROMIO (parallel file I/O), but if you don't need it, it's overhead. Both assume the whole program is on all nodes in the cluster, which is great for SIMD but is actually pretty crappy for MIMD. They also assume the program can be started via a remote shell (RSH or SSH) connection on nodes, which means you have software running that serves no purpose but to start things, which is again overhead, which may be negligible in some cases but won't always be.
Another limitation of MPI and PVM is that all-to-all operations are typically carried out sequentially. If you are sending a message to a thousand nodes, you will be sending a thousand packets. Reliable multicast busses are used, but not in these message-passing libraries. In fact, message passing to multiple nodes by multicast is so effective with so little prior art, there are numerous patented implementations. This should not be the case. Programmers, particularly in the High Performance market BADLY missed the boat on that one, and clusters WILL suffer for years to come as a result of their stupidity.
There's also the reliability thing. PVM and MPI implementations aren't terribly robust - to the point that many UAV aircraft actually use CORBA-3 instead. Yes, that monstrosity. It turns out there are CORBA implementations like TAO that support high availability and/or some degree of fault tolerance. CORBA-3 also specifies a hard real-time API, so you can guarantee a message being delivered within fairly precise bounds - PVM and MPI offer no such guarantees. In fact, some MPI implementations don't even guarantee delivery (or error, in the case of not being able to deliver) at all. Trapping errors within the application itself is clearly dependent on the method of communication and you therefore have to have traps for every possible communications library you would ever want to link to.
Those who don't want the weight of CORBA but who aren't in a SIMD cluster would probably go for RPC or some other similar interface. These are still massively heavy, in comparison to most MPI or PVM implementations, they are limited to hard-coded interfaces. On the other hand, they're more robust and can move components around more freely.
Then others use use vanilla TCP, UDP, TIPC, or some other base protocol.
Do programmers need to know about all the choices? No, no more than programmers need to know assembly, but the transparency isn't there yet.
...how this will affect the genealogy DNA market. Family Tree DNA charges several hundred for Y chromosome analysis over a month or so. It wouldn't take many people wanting faster results to cover costs.
OpenGL is the name of the API, which is what I said. I also said it was the name of the reference implementation provided by SGI (which it is). A reference implementation gives you an ABI and - invariably - quirks. SGI's OpenGL code provided in X11 and on their OSS pages are a reference implementation, not a commercial implementation. Even though OpenGL does not specify an ABI - it is an API specification - it is inherent in the process of having a reference implementation that people will code to the ABI provided by that reference version so that their code can just drop in.
OpenGL is the version produced by SGI (and now by the OpenGL consortium) and is also the name of the official reference implementation. (Nobody seriously believes that a commercial vendor would use a reference implementation of anything if they could possibly avoid doing so. Reference versions are necessarily highly generic, which usually means that the code can't be efficient anywhere.) Mesa is a third-party re-implementation of OpenGL and, as far as I know, is feature-complete to whatever version of OpenGL that version of Mesa is designed to replace. Because it's a re-implementation, there's no guarantee of it being ABI-compatible in all cases, only API-compatible. If anyone exploits undocumented quirks in the official reference version, this will obviously break on any clone.
Because of the way libraries are installed in Linux and *BSD (in a very few directories), name clashes when using Mesa and OpenGL are almost inevitable. All I can suggest is compile them yourself with different prefixes, then use library paths to pick up the right library for a given application.
Not until you mess up your hair and get the lightning bolt generator working. Maniacal laughs only work right if you have messed up hair and lightning bolts. Didn't they teach you anything in Mad Scientist 00000101?
Anycast is not routed to the nearest device, anycasting is multicast to ALL devices by means of the anycast common address and the nearest one replies. Thus, it does indeed find the nearest device without any device at all having knowledge of where such devices are. No hardcoding is required. There is no single point of failure. If a server goes down, then that doesn't respond and the next nearest is the one that responds. Thus, with anycast, if you have an address, it is a working address. DHCP offers no such security or validation.
No, IPv4 does not support anycast except as a userspace layer on top of multicast, which - in the case of IPv4 - is usually disabled and is not even implemented as standard on all kernels. There is no kernelspace anycasting in IPv4 and there are no anycast-aware applications in IPv4 that I am aware of. Multicast, yes, but even that is grossly underused and underutilized. Network programmers and ISPs should feel utterly ashamed with themselves at the pathetic, tardy and haphazard use of one of the most elegant networking tools available to software engineers.
You are also incorrect about the hardcoding. Anycasting doesn't require a hardcoded address for the service. The anycast request is sent on the anycast broadcast channel and is labeled. If the device recognizes the label and no other response has been given, the device responds.
You are also incorrect about the security risk. Multicasts (and therefore anycasts) have a scope. So long as anything outside of your local scope exceeds the anycast scope, the transmissing can never reach a device outside of the boundary you have defined.
Let us say you have a hundred IP phones, all in factory default state. You pneous DHCP hits is going to more than inconvenience most servers. You'd damn-near melt them.
Of course, this isn't limited to DHCP. Traditional PXE is unicast, hard-coded and doesn't scale to more than a dozen or so nodes on a LAN for truly simultaneous connections. Anycast PXE scales as far as you like, provided you have the servers to support the clients.
Want to tell your IP phone where the call manager is? DHCP. Want to tell your Netware clients where the nearest replica server is? DHCP.
IPv6 Anycast returns the nearest server that supports the capability you want. True, you wouldn't use the router advertisement protocol, but there are major advantages to having lightweight protocols that can be added to as extra needs develop, as opposed to having one monolithic protocol that requires excessive space on the network and heavyweight processes to churn over.
Now, as far as I know, there are many schemes for correcting and detecting errors. Some, like FEC, fix infrequent, scattered errors. Others, like turbocodes, fix sizeable blocks of errors. This leads to two questions: what is the benefit in using plain CRCs any more? And since disks are block-based not streamed, wouldn't block-based error-correction be more suitable for the disk?
You're right that this is a fake. Everyone knows the photonic drive was invented in season 4 of Blake's 7 by a fugitive researcher from the Federation.
No sparks? No flames? Dudew, you should have added some pyros to the bike, even if you never intended it to move, to give people something to photograph. Same reason early computers were dressed in lights. Sheesh, talk about a missed opporutinity.
Your mission, should you choose to accept it, is to leave the basement, cross the road in broad daylight, go into the ultra-busy supermarket and buy something healthy. This message will self-destruct in 5 jiffies.
Slashdot Mirror
If I was a juror, I'd want to be damn sure that the precedent governing jury nullification was still the law of the land before applying it. Furthermore, jurors cannot consider elements not presented in court, which means they'd only be able to consider nullification if nullification was presented as an element in the case.
The woman also lied to the jurors, under oath. My guess is that the Quaker in the precedent did not do so, but was sincere and honest. Breaking oath is going to upset jurors if they catch on to it. And rightly so. Personally, I'd prefer it if courts were more willing to demand truth on the stand. No legal system can function without truth, because what is presented is all any judge or jury can go on.
My guess is that the RIAA also deliberately lied under oath, and it is my belief that any such lie uncovered should have resulted in the prosecution witness responsible being jailed and possibly the trial suspended until the witness recanted. (Unintentional inaccuracies are one thing. Although they are not "the whole truth and nothing but the truth", I'd call it a reasonable allowance. Deception, on the other hand, should be a no-no.) Yes, it would make trials a LOT longer - and larger trials might never finish at all - but my guess is that you'd see a dramatic drop in both malicious prosecution and bogus convictions.
I also believe that if truth were required, you'd also see far fewer cases ending up with the jury blatantly penalizing the attitude rather than the action. It's obvious enough that that's what the bulk of the fine was - a slap across the face for the lies and deception. The attitude would have already been penalized and the jury would be free to consider the case itself and not the personalities within it.
(ObTrivia: If I ran the country, it would be fair, just, civilized... and bankrupt, boring and mostly in jail or mental institutions. It is a very, very good thing that I have enough trouble running my own life to be interested in running anyone else's.)
Knowing what was common practice at the time the text books were written is useless. Books take years to write, by people who aren't usually researching at the same time, so must be drawing on older knowledge still. It can then take years more before those books begin to be picked up by Universities. Any book talking about an implementation that existed at the time of writing is talking about an implementation that probably no longer exists at the time of the course.
Theory, on the other hand, changes much more slowly. People knew of electron tunneling long before it started showing up in silicon or germanium arsonide chips. People knew the theories behind good software and hardware designs long before such designs became practical to build. (In the case of software, formal methods are still regarded as impractical in their ideal form, but it is in their ideal form that the best software will be written.) Relational database theory existed long before there existed computers nearly powerful enough to run relational databases.
The theory is the foundation on which all practical achievements can take place. Without a foundation, no stable achievement is possible. That is why a certain range of products made by a well-known company, without regard to foundational knowledge, are of such poor quality. You can't build indefinitely on sand and expect the structure to hold up.
There is no value in teaching "practical" skills at University, because what is practical will have long-since moved on and vanished into the horizon. What you need to teach is how to distinguish what is practical from what is not, how to learn what is practical today (and tomorrow), and how to develop new practices from what exists. Students should be concerned only with learning how to move forward efficiently and effectively, given whatever starting point they discover themselves as having.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
I would argue that (b) would allow you to physically perform source distribution from someone else's machine to the user's machine. This section only requires that you perform the distribution and be able to do so for a given length of time, it doesn't seem to say anything about who actually does the hosting. If the user is told to select link 1 (which downloads the basic source) and then select link 2 (which downloads a self-extracting, self-installing patch), then I'd consider that as a written offer to give a third party a complete machine-readable copy of the corresponding source code on a medium customarily used for software interchange.
Is this a reasonable interpretation? Well, patches and shar files are indeed customarily used for software interchange, so I don't see any argument even on the next layer up.
Is this a common interpretation? Virtually all Linux kernel projects I know of (and I track about thirty or so) provide kernel patches, NOT a patched kernel. Some (but by no means all) provide links to the vanilla kernel sources. I would argue that those who provide no link at all do indeed violate the GPL, as what is provided is not really "complete", even indirectly. However, I can't remember the last time anyone fried them for non-compliance. Can you give me an example of that ever happening? If not, it would seem I have a stricter interpretation of the GPL than many developers.
However, given that this is almost certainly just a LinuxBIOS-flased motherboard with a mini distro on whatever bytes were left over, I'd say that it should be possible to produce a comparable system on any motherboard that is capable of holding a Flash chip of the necessary size. (This will be a LOT bigger than normal, so you may hit a whole bunch of design limitations.) It should therefore be possible to sell LinuxBIOS + BIOSdistros for any motherboard out there that can handle the chip, as an upgrade.
I support ASUS' experimentation - that's good - but people need to see that it's late in coming and it's more limited than the technology supports. Motherboard companies shouldn't be permitted to move as slow as possible and drag their feet when it creates the delusion that technology is more limited than it really is. The pace needs to be upped a little - just enough to show the consumers that they've been paying top dollar for decade-old components.
The downside is that people will think it's Prince's new name.
If you scaled each region by population, scaled the thickness of each line by bandwidth scaled the brightness of each line by reliability, and used the three primary colours to indicate whether the line supported IPv6, MPLS or multicasting in addition to the mainstream Internet protocols, you would produce a more representative map that would better reflect actual Internet service and coverage but would also be totally unreadable and would also likely destroy the credibility of most of the major Internet-enabled nations.
But... but... but... Linux was written by penguins, right?
The Olympic-style carbon-fibre bikes can push amazing speeds - for very short distances, and they are strong enough to do the job but nothing more. Replacing the standard plastic they combine with the carbon-fibre with this new plastic, you could probably build a marginally lighter bike that could set new records, but it still wouldn't be a bike you'd want to take out on the road. Remember, strength is NOT the same as rigidity, and the two are often in direct opposition.
Some of the oldest schools of all work along a method known as "Classical Education", in which it is argued that understanding is impossible without context, and that context requires diversity of knowledge, not specialization. It argues a few other things I don't agree with - there is no inherent superiority to Greek or Latin - however, it has been shown several times in studies that additional languages increases overall brain capacity and decreases the rate at which brain function will decay over a person's lifespan. The brain grows far larger than is normally needed and thins back the unused portions in the late teens, early 20s, according to studies. If it's made use of, maybe this will improve the capacity of the brain overall, in addition to slowing mental aging.
New technologies don't enter into the discussion except insofar as they provide an effective means of delivering information. Generally, they don't, except in lab settings when they allow people to learn what those devices can do. Computer assisted learning has been shown to be a tough problem and one not easily solved except in very isolated cases - and the most effective CAL has been in the form of rote memorization. Nobody has taken technology much beyond that point yet.
If system A has a direct connection to external stimulus B, and system A moves to a non-deterministic state for at least one value of B, then A is a quantum device. (Quantum systems are the only physical systems in which true randomness can exist.)
If system A has no direct connection to ANY external stimulus, but is rather operating solely off an internal model which may or may not ever get updated from an external source, then A not only exists independent of whether B exists, but cannot ever establish by any test as to whether B exists. Within normal operating conditions, A can be treated as though it were in a pocket universe, independent and isolated from the universe in which any B may exist, and should therefore be regarded as an isolated system.
The brain may be an I/O device, a chaotic system, or an isolated system. Arguments have been given for each. One thing it is NOT is a modulated system. That possibility does not really exist. The moment the connection becomes indirect, then you run into the limitations of knowledge and certainty. If you cannot distinguish between modulation by an external cause and a change of state due to internal causes, then you can't ever know if the external exists at all. It might all be a figment of your imagination. You can't conduct any test to establish otherwise, as any test which is definitely not a figment of your imagination cannot alter the external and anything that can definitely alter the external cannot be provably not a figment of your imagination.
As for Linux, the inability to determine a future state is NOT the same as the future state being non-deterministic. You cannot produce a quantum OS using Turing logic. You CAN produce an isolated system, and some research into strong AI and machine reasoning goes in this direction, but it hasn't been terribly useful so far.
Let's face it, mundane (but realistic) uses aren't exciting and don't make good stories. The microwave gun that generates pain across nerve endings is discussed in terms of urban combat and riot-suppression, but in the real world, more people are probably going to end up using the device in farmland where electric fences are impractical or impossible, as a replacement for noisy bird scarers, possibly even in a very low-power form in medical diagnostics when you want to generate a very controlled stimulus to determine the location and extent of nerve damage, etc.
An ultra-light plastic would be valuable for so many things, from cutlery to possibly safer alternatives to metal for pins and plates within the human body to a replacement for aluminium in airframes to a replacement for metals (lead especially) in "unbreakable toys". Depending on thermal properties, it may have uses in ducting where you need something strong but light. Depending on exactly what is meant by "strong", it may become a replacement for steel cabling in reinforced concrete - plastics tend to be better at aging. Current plastic drains are notoriously feeble. Now, please consider that Victorian drains are only now starting to reach the end of their lifespan, and Roman-era aqueducts are still perfectly functional, so anything that lasts a mere hundred years is simply living up to what was expected of material science a hundred years ago, and we really should be looking to match or better a bunch of iron Age punks. Could this plastic offer a cost-effective way of matching some of the greatest material science achievements in history?
Now, the next question is one of whether there needs to be as many choices. There are, after all, three different threading libraries in common usage (Pth, PThreads and OpenThreads). "Next Generation" N:M threading was abandoned by IBM, but someone, somewhere, may yet revive it if there's a case in which it is effective. Oh, almost forgot. Forking is not the same as threading (you get a different pid and it occupies a different place on the scheduler). Do we really need four or five different ways to have parallel execution within a single program?
So long as they are not identical in capability and flexibility, the answer is yes. Going back to optimization - sometimes lightweight, limited capabilities are superior, but equally sometimes heavy but powerful tools are the way to go. Most often, it'll be a compromise that's best. There isn't a single library (yet) that provides true hybrid RISC/CISC capabilities, so what you want is a range of options where you can pick the characteristics you want.
What about inter-machine communication? MPI, PVM and all that? With MPI, you specify the number of nodes at runtime. With PVM, you specify it at compile time. MPI-2 sports ROMIO (parallel file I/O), but if you don't need it, it's overhead. Both assume the whole program is on all nodes in the cluster, which is great for SIMD but is actually pretty crappy for MIMD. They also assume the program can be started via a remote shell (RSH or SSH) connection on nodes, which means you have software running that serves no purpose but to start things, which is again overhead, which may be negligible in some cases but won't always be.
Another limitation of MPI and PVM is that all-to-all operations are typically carried out sequentially. If you are sending a message to a thousand nodes, you will be sending a thousand packets. Reliable multicast busses are used, but not in these message-passing libraries. In fact, message passing to multiple nodes by multicast is so effective with so little prior art, there are numerous patented implementations. This should not be the case. Programmers, particularly in the High Performance market BADLY missed the boat on that one, and clusters WILL suffer for years to come as a result of their stupidity.
There's also the reliability thing. PVM and MPI implementations aren't terribly robust - to the point that many UAV aircraft actually use CORBA-3 instead. Yes, that monstrosity. It turns out there are CORBA implementations like TAO that support high availability and/or some degree of fault tolerance. CORBA-3 also specifies a hard real-time API, so you can guarantee a message being delivered within fairly precise bounds - PVM and MPI offer no such guarantees. In fact, some MPI implementations don't even guarantee delivery (or error, in the case of not being able to deliver) at all. Trapping errors within the application itself is clearly dependent on the method of communication and you therefore have to have traps for every possible communications library you would ever want to link to.
Those who don't want the weight of CORBA but who aren't in a SIMD cluster would probably go for RPC or some other similar interface. These are still massively heavy, in comparison to most MPI or PVM implementations, they are limited to hard-coded interfaces. On the other hand, they're more robust and can move components around more freely.
Then others use use vanilla TCP, UDP, TIPC, or some other base protocol.
Do programmers need to know about all the choices? No, no more than programmers need to know assembly, but the transparency isn't there yet.
...how this will affect the genealogy DNA market. Family Tree DNA charges several hundred for Y chromosome analysis over a month or so. It wouldn't take many people wanting faster results to cover costs.
OpenGL is the name of the API, which is what I said. I also said it was the name of the reference implementation provided by SGI (which it is). A reference implementation gives you an ABI and - invariably - quirks. SGI's OpenGL code provided in X11 and on their OSS pages are a reference implementation, not a commercial implementation. Even though OpenGL does not specify an ABI - it is an API specification - it is inherent in the process of having a reference implementation that people will code to the ABI provided by that reference version so that their code can just drop in.
Because of the way libraries are installed in Linux and *BSD (in a very few directories), name clashes when using Mesa and OpenGL are almost inevitable. All I can suggest is compile them yourself with different prefixes, then use library paths to pick up the right library for a given application.
They should have used "SPARC Ninja: Real Ultimate Power".
Moderation should move into the quaternion domain. There needs to be +i xroach, +j strange analogy and +k outright bizarre.
Not until you mess up your hair and get the lightning bolt generator working. Maniacal laughs only work right if you have messed up hair and lightning bolts. Didn't they teach you anything in Mad Scientist 00000101?
No, IPv4 does not support anycast except as a userspace layer on top of multicast, which - in the case of IPv4 - is usually disabled and is not even implemented as standard on all kernels. There is no kernelspace anycasting in IPv4 and there are no anycast-aware applications in IPv4 that I am aware of. Multicast, yes, but even that is grossly underused and underutilized. Network programmers and ISPs should feel utterly ashamed with themselves at the pathetic, tardy and haphazard use of one of the most elegant networking tools available to software engineers.
You are also incorrect about the hardcoding. Anycasting doesn't require a hardcoded address for the service. The anycast request is sent on the anycast broadcast channel and is labeled. If the device recognizes the label and no other response has been given, the device responds.
You are also incorrect about the security risk. Multicasts (and therefore anycasts) have a scope. So long as anything outside of your local scope exceeds the anycast scope, the transmissing can never reach a device outside of the boundary you have defined.
Let us say you have a hundred IP phones, all in factory default state. You pneous DHCP hits is going to more than inconvenience most servers. You'd damn-near melt them.
Of course, this isn't limited to DHCP. Traditional PXE is unicast, hard-coded and doesn't scale to more than a dozen or so nodes on a LAN for truly simultaneous connections. Anycast PXE scales as far as you like, provided you have the servers to support the clients.
IPv6 Anycast returns the nearest server that supports the capability you want. True, you wouldn't use the router advertisement protocol, but there are major advantages to having lightweight protocols that can be added to as extra needs develop, as opposed to having one monolithic protocol that requires excessive space on the network and heavyweight processes to churn over.
Now, as far as I know, there are many schemes for correcting and detecting errors. Some, like FEC, fix infrequent, scattered errors. Others, like turbocodes, fix sizeable blocks of errors. This leads to two questions: what is the benefit in using plain CRCs any more? And since disks are block-based not streamed, wouldn't block-based error-correction be more suitable for the disk?
You're right that this is a fake. Everyone knows the photonic drive was invented in season 4 of Blake's 7 by a fugitive researcher from the Federation.
No sparks? No flames? Dudew, you should have added some pyros to the bike, even if you never intended it to move, to give people something to photograph. Same reason early computers were dressed in lights. Sheesh, talk about a missed opporutinity.
...lawyers bother taking on lawsuits under $10 million these days - they can't make enough money on the small claims.
Your mission, should you choose to accept it, is to leave the basement, cross the road in broad daylight, go into the ultra-busy supermarket and buy something healthy. This message will self-destruct in 5 jiffies.