But in my book going extinct falls in the cateory of "having difficulty reproducing". Given that we have vastly more evidence of hobbit-like humanoids yet still aren't sure if they existed as a species or an illness, it seems we're inferring a lot from three jaws and the tooth fairy's collection. Oh, and we only rule the world because early humans found the cheat codes.
Blackii has been in the list of megafauna for a long time, along with a wide range of other fascinating beasties. I do strongly recommend that Slashdotters look through the finds that have been made. They are truly fascinating.
It is vitally important to add that virtually nothing has been found of G. Blackii - bits of jaw, teeth, etc. No complete skeleton is known to exist, we don't even have a complete skull. All estimates on size are based on ratios that are known to (roughly) hold true for all primates and so presumably held true for G. Blackii. We do not know this to be the case and I would personally prefer researchers to be looking for more finds than looking for more publicity. Otherwise, when something of real importance is discovered, nobody is going to take it seriously. Why should they, when so much hype has been stirred up over the dating of a bunch of teeth?
The people at the Psychic Hotline had better not need a phone line. Oh, yeah, that's right - they closed down, due to unforseen circumstances. Hmmm.
Seriously, you are correct. Virtually all of market research is done within targetted areas with a self-selecting group (which means you're not even remotely using a random, representative sample), uses extremely poor questions (which means you'll induce bias) and - strangely enough - they never mention confidence limits, variance/standard deviation, distribution or indeed anything that can tell you if their results mean anything at all. They give you a number that, in and of itself, says precisely nothing without a LOT of supporting information.
(Statistics is like paint. It doesn't work so well with thin air.)
There are MANY undeciphered languages. I only know of a very tiny handful - Etruscan, Indus/Harappa script, Rongo Rongo, Linear A, the mysterious Phaistos Disk, Pictish, Vina / Old European, Proto-Elamite and Old Elamite. I firmlyt believe all of these are computationally solvable (with the possible exception of the infamous disk, they are definitely not One Time Pads) and some of the cracked languages HAVE been solved on computer.
The latter, methinks, is worthy of a good Slashdot story. The former - if anyone would be interested - might be doable using massively distributed computing, the same way that SETI@Home and Distributed.Net are. Not everything is going to be solved by philologists and linguists and even when it is, it is because they eventually saw patterns they recognized. Pattern recognition is something computers are good at and so computers should be extremely useful tools (at the least) for such decipherments.
IANAL, but my understanding is that defamation in Britain cannot occur if a reasonable person would have come to the same conclusion (I believe this is usually used by newspapers printing dodgy stories about TV celebrities caught in awkward situations).
Also, it can't be defamation if the person has no good name to lose. In addition to those two, I believe that the defense of "truth" also holds up if there is any other reasonable grounds for believing that the claims are indeed true.
Having said all of that, Britain has no "right" of free speech (and I'm not sure that that's all that bad) and therefore freedom of speech can NOT be used as part of any kind of defense. Unless you're on Speaker's Corner, then you can say what you like - that corner is totally protected from any and all laws governing speech in England.
Canadian laws are, in many ways, very similar to Britain, so I'd assume the libel/slander laws would be based on the same governing principle - reasonableness and truth first, protection of the individual second, all other rights and obligations third.
The biggest difference I see is that the Americas have nothing comparable to the EU's Court of Human Rights, which can overturn national legal decisions or even national laws, when the EU has compelling evidence that such decisions or laws violate EU or international mandates on human rights, or when they have compelling evidence that the decision/law was in conflict with the broader needs of society.
(Britain has fallen foul of the EU's Court of Human Rights on many occasions. It is by no means a perfect country, it is flawed in many respects - as, indeed, is the EU itself. Frankly, though, I can think of little in the Americas which would lead me to believe they're any better and a lot that convinces me they're infinitely worse in many areas.)
Will be some of the BBC TV series of the 70s and 80s, which mixed film and videotape pretty randomly. (Blake's 7 is a great example of this.) There, you'll get scenes flicking between resolutions, when they're remapped onto high-definition formats. They're going to need to do some interesting interpolation to synthesize an even level of resolution if such programs are to be remotely viewable - assuming they've not destroyed all the original negatives.
(The BBC is notorious for destroying original prints, for assorted reasons. First it was that they didn't think anyone wanted to watch black-and-white stuff any more. Later on, they got rid of a lot of stuff they'd converted to digital media, although it is questionable as to whether the technology of the time was capable of digitizing at modern HDTV resolutions. It certainly wasn't capable of the resolutions of modern computers or 60" LCD displays.)
It's not bad for Nintendo to keep an eye on the money, but the patents (AFAIK) refer to the hardware (which Nintendo makes nothing from, today) not to the software (which Nintendo MIGHT make money off). The software is still covered by copyright, so the patent stuff is a non-issue there. The hardware is NOT covered by copyright, so the copyright stuff should be a non-issue there.
Producing a binary-compatiable console that is hardware-compatiable to the NES should (by anything remotely approaching fair and civilized rights) be legal, especially as Nintendo would still be making money off all the things they still make money from. However, the US is dubious on both counts, so don't count on it.
There's been a lot of work on improving the threading under Unix variants. M:N threading models, zero-copy where data structures are identical, etc. It is entirely possible, if not probable, that some cases of threading will actually be faster under some u*ix-like OS' than Windows. Because there has also been a lot of work on security models under u*ix-like OS' (role-based memory encapsulation, etc) which are inherently slooooow, there will certainly be u*ix-like OS' which are slower at starting new processes under those OS' (where you will have maximal security checks) than Windows.
In other words, write the benchtest for the sorts of sub-category of cases that side with you, and you can make any benchmarks show what you want them to show. That's one reason they should always be viewed with a pinch of salt and a dash of vinegar, then served in newspaper.
SELinux is in the kernel and one popular distribution at least (Fedora Core) has SELinux-enabled utilities and configuration files as standard, so anyone using that will be using it whether they know what it is or not.
Having said that, there are some good arguments that GRSecurity and some of the other Linux-hardening patches offer better role-based security than SELinux, due to potential limitations of the Linux Security Modules infrastructure. Those seriously interested in hardening Linux would be very well-advised to look through what is available. Having said that, BEWARE FUD! There's lots of claims and counter-claims, and nothing seems to have earned more rigid, fundamentalist stances than computer security.
There are checks for Common Criteria level 3 for Linux, but none for level 4 (which I believe RHEL is now certified to, or was it SuSE?) and there is a lot of contention as to whether these checks actually do anything useful. Are role-based memory locks and network locks actually useful? It would severely limit the security mechanisms you could use, so if you needed some other criteria as well, you might be stuck. POSIX ACLs or Trustees or do you need ACLs at all with role-based mechanisms?
Then there's the password file. Shadow is limited in the number of hashing algorithms it'll support and it may be vulnerable to rainbow dictionary cracks. The mainstream implementation does not support any unbroken hashing algorithms, which may pose other problems - though that is hard to prove. PAM is notoriously fragile, raising questions as to whether it can be considered safe or whether it should be redone. It is also unclear, especially if you use role-based computing, that the full username list should be exposed to all users. It may be more correct for the password and shadow files (if used) to be virtual, where the entries "present" depend on the user viewing the file. But that would add complexity (a BIG no-no in security) and latency.
Not all security options even exist for Linux, though it is unclear why. No Orange Book B-class patches exist for Linux, to the best of my knowledge, the best I've ever seen are just partial implementations. Very little encryption hardware is supported - far more specs have been published than have been coded to, and far more chips exist than specs. I won't even get into the limited security of e-mail clients and servers. How long have PGP and GnuPG been around??? X.400 may not be popular, but it is good on the security angle - so how many clients or servers exist for Linux???
All in all, this is an area the GOOD security guy will be doing a LOT of research in, no matter how much they know. And then, because nobody is an expert in everything and even fewer are experts in security, the REALLY GOOD security guy will not limit themselves to what they can know or understand. The REALLY REALLY GOOD security guys won't even limit themselves to what others can know or understand*.
*Ok, that's worded more for effect than accuracy. The accurate version would be that they are interested in solutions that make unauthorized access within the expected lifetime of the data and/or system highly unlikely at best - or, in the few cases you can do this, actually impossible. (You cannot break a one-time pad without the key, for example.) This is usually done by looking for "really hard problems" and hoping nobody comes up with a really easy solution. (A "really hard problem" is one that either cannot be solved in a determinate timeframe - such as NP-complete problems - or that cannot be solved, on average, in the timeframe you care about - which accounts for 99% of all popular strategies used in encryption.)
It will not only bury Sony, but also the DMCA (which actually prohibits you from de-installing the DRM code or even detecting that it's there) and will possibly cripple the credibility of the RIAA, who have been the main driving-force for DRM and the DMCA.
Peer-to-peer routing is interesting with IPv6. The usual rules apply - the most specific prefix is always used first on routing decisions (and, because of the nature of IPv6 addressing, you should never get two addresses with the same prefix anyway) and if it stopped there, you'd be right. The router tables would be a mess.
The topology helps, as the IPv6 backbone developers have realized you can't have a horrible design and expect it to work.
The problem is not with customers of a peered network (as their prefix MUST match that of the peered network), but with peers of peers, where prefixes may differ. Because you have more levels of peering, the problem is theoretically reduced (as lower levels MUST share a common prefix and are - generally - not permitted to peer between branches in the hierarchy) but that is more human policy than technology.
There is some confusion with regards IPv6 and backbone connections. IPv6 was originally designed NOT to support default routes. The::0 route was not actually prohibited, it was however considered undesirable. Later on, this was relaxed and is now pretty standard. There have also been many changes in routing protocols - originally, transparency was the watch-word and Telebit came up with a nice protocol that hid layers. BGP4+ and Protocol Independent BGP became the standards, however, and that's what we live with today.
So how does all this help? It helps because details are kept hidden as far as possible. IPv4 is bad on routing, because the layout is crap, too much is visible and has to be learned, multiple specific routes may need to be learned for a given prefix, corporations buy large blocks of addresses then share them with multiple sites using different providers, etc. IPv6 doesn't permit a lot of that and policies agreed upon don't allow the rest.
In the end, routing requires that you know every possible route you need to follow to get to where you want to go, in the most general form you can store it. There's no escaping from that. The trick is to ensure that absolutely everything is (more or less) equally general and no specific exceptions are needed. It is the exceptions that are the killer, not the rules.
Is that for every bit in the key, you double the search time. 56 bits takes a 512-node computer about 2 days. (Well, that's the record set by the EFF, with their DES decrypter.) 57 bits would take 4 days. 128 bits (the length of AES) would take more than the lifetime of the Universe. Then, if you double the number of algorithms it could be - assuming you don't know - then you again double the time it would take.
The "rainbow" method is to have an absolutely gigantic dictionary of passwords people could use to protect their encryption keys, on the basis it'll be easier to break that than the key itself. Always go after the weakest link, not the strongest. Even then, the combined power of all three of Britain's regional computing centres PLUS Britain's national computing centre would be inadequate to break passwords of significant length and strength - assuming the password hash is trivial.
(If you're using a 512-bit hash to store the password, using 16-character passwords, only through an S/Key-type OTP interface, your rainbow dictionary cracker is well and truly buggered.)
Because IPv6 is strictly heirarchical, you need to maintain one address for each downstream router and default for upstream. This gives you a memory requirement of about 2-4K for normal usage. Assuming a LOT of mobile users, you might need another 2-4K for redirections.
Because the MAC is used as the last 48 bits of the address, an end user would own a suffix, rather than an address. Because IPv6 is a protocol based on inheritance from the prior prefix, there would be almost no genuine "end user". Which is fine. IPv6 has 128 bit addressing, so you've 80 bits for the prefix, of which the first byte or two designates a lot of type of address information. As I understand the address allocation procedure, the upstream port gets one byte and the downstream gets one byte. This gives you a maximum of four levels of Internet provider, on this addressing scheme - basically one more than the A/B/C network classes of IPv4. If it's one byte total per ISP, then you've a maximum of eight levels.
In either case, given the current architecture (which assumes three layers), you're guaranteed that "end users" could be provided with quite large blocks of addresses if you so wished. I'm not sure this is currently done, but it could be. On the original 6Bone, I had a 60-bit block I could sub-allocate, which was fun. Power!
That one's relatively easy. Certain electrical and/or magnetic fields are known to cause hallucinations and minor brain storms. There are, in fact, devices you can buy to INDUCE these effects, though purportedly for the effect of listening to God. It seems likely that borderline cases where someone has an extremely low seizure threshold (and therefore extremely susceptible to such effects) AND in an area with an extremely HIGH level of EMR at the right frequency (or strong enough magnetic fields) would benefit from some form of Faraday Cage.
Since Government bleeding-edge scientific laboratories do often muck about with very powerful magnetic fields, and since lithium (an early mood stabilizer used by bipolar folk - who are disproportionately found in arts and bleeding-edge sciences) is well-known to reduce a person's seizure threshold, and since bipolar people are also well-known for being a source of conspiracy theories when in a manic state, it would not surprise me if the belief actually had historic events involving off-kilter scientists using metal sheielding and finding it helped them. (This doesn't mean this actually happened, I merely wouldn't be surprised if it had.)
Alternatively, in the 60s, the US Government actually had a psychic warfare division that did indeed indulge in the notion of mind control. Given that they also experimented a lot with LSD and other drugs well-known for causing delusions and paranoia, it would also not surprise me if - somewhere down the line - those who became deluded under the drugs experimentation were also involved (or learned of) the mind-control work and started their own research into how to stay safe.
If you combine these two potential sources together, you end up with the notion of the Government trying to control people's minds, people apparently being controlled, and apparently able to fend off that control with metal screening. Again, this is not a provable history, it is merely one of a (very large) number of possible ways you could create such a conspiracy theory.
I will offer one other basis for believing that this is the sequence of events - another poster mentioned "aliens" and "demons" - both of which are now believed to be seizure-related hallucinations in many cases. It would seem very UNlikely that a very similar myth is NOT seizure related. However, to get from the hallucinations caused by seizures to the specifics of the conspiracy theory and the proposed remedy, you would need some non-zero percent of the seizures to be triggered by the environment AND something that could be interpreted as the Government working in that field - however slight the similarity. What I've offered is one way to get both of these factors.
In general, you probably also want to check the IPv6 Information Page, which lists many IPv6 websites, FTP sites and even IRC sites not already listed. (Almost all the above sites are also IPv6-reachable.) This totally trashes the idea that there is NOBODY on IPv6, which is good because it is a delusion which prevents people from using IPv6.
I've used numerous IPv6 tunnels and will shortly be getting native IPv6 from my provider at home, so I cry "bullshit" to those who say it can't be done. Setting up an IPv6 tunnel through a broker requires knowing your public IP address and your MAC address, then running a simple script to set up the IPv6-over-IPv4 connection. It's all of a couple of minutes work, maximum. I dare those who say IPv6 isn't being used to actually set up such a tunnel, use IPv6, THEN come back and tell the rest of us why what they just did was so impossible.
Security: IPv6 mandates IPSec (which encrypts ALL streams, ALL of the time, so contextual information can't be used for cracking as it can with SSH or SSL streams, which are generally only used for specific segments of a transaction).
Authentication: X.509 within IPSec and the use of Extended Authentication protocols in IPv6 guarantee that all endpoints are who they say they are.
Fragmented Packets: Firewalls don't handle fragmented packets well, as there is no header to check for later fragments. Fragmenting and re-assembly also adds latency. IPv6 defines per-connection MTUs, guaranteeing ALL packets are the largest supported between any two endpoints without fragmentation.
Latency: IPv6 headers don't have as many entries and are heirarchical, which makes routing much faster and much simpler. The lack of fragmentation and the presence of auto-MTU also helps.
Multicasting: IPv6 mandates multicasting and has a decent range of addresses for it.
Anycasting: IPv6 mandates service location and resource location abilities, which means no more hunting for printers, routers, DNS servers, SMTP servers, POP/IMAP servers...
Autoconfiguration: IPv6 uses autoconfiguration for routing and addressing as a standard, in a manner (almost) guaranteed to be free of conflicts and absolutely guaranteed to be fully scalable.
Mobility: IPv6 mandates the ability for nodes or even entire networks to be totally mobile (ie: switch upstream routers without losing connectivity or existing connections) with upstream optimization of routing.
Advanced Headers: IPv6 allows an arbritary number of extended headers to be attached to packets, with controlled responses for unknown extended headers.
High Availability: IPv4's High Availability mechanisms require a lot of fancy manoevering, because the MAC address (used by switches) and the IP address (used by remote systems) are dissociated and ALL parties to a type of data have to agree on the failover for it to work. Hotswapping is extremely difficult and even hot standby is hard enough to be uncommon. IPv6 strongly couples MAC and IP addresses, both for autoconfiguration and mobility, allowing instantaneous, lossless failover with very minimal complexity or overhead and no patent problem.
Tunneling: There is no agreed method of tunneling in IPv4 and the de-facto method (GRE) is detested by many network admins. IPv6-over-IPv6 is to be a universal standard.
Clusters: Infiniband cooperates well with IPv6, making it possible for nodes within a cluster to directly access IP-based resources. Infiniband requires capabilities that are not guaranteed present in IPv4 stacks or IPv4 networks (such as multicasting) which means Infiniband cannot reliably treat IPv4 networks as extensions.
Reachability: IPv6 can reach all IPv4 nodes, with only trivial conversion to make allowance for the different header structure and the lack of intelligence in IPv4 networks, so any client-only machine or network could be converted tomorrow without anyone noticing. Small numbers of IPv6 machines can be exposed to IPv4, making it possible to have DMZ servers on an IPv6 network visible to IPv4, so any server could be converted tomorrow without anyone noticing. The backbone could be left as long as you like. Because IPv6-over-IPv4 is also defined, if both servers and clients are IPv6 then the backbone could be ignored forever without significant impact.
All told, I'm not convinced that there are that many people who genuinely have "no reason" to shift to the new system. All I am convinced of, so far, is that there are plenty of people who have absolutely no reasons at all but plenty of excuses. Let's look at something, here. Say Comcast converted its entire cable network to IPv6, would you care or even notice? Probably not. Their routers hide their network from your computers, so your computers wouldn't see the difference. It would be
In some countries (such as Britain) there is no law of trespass. There is a law against breaking and entering, there is a law against causing damage and there are numerous privacy laws, but if you aren't causing a problem then your ancient (pre-enclosures act) rights cannot be abbridged. Further, if there is a traditional, ancient right-of-way through your land, then you have absolutely no rights whatsoever to block, divert or otherwise interfere with that right-of-way. You may own the land on paper, but the land owns itself in many ways, in the eyes of the law.
Furthermore, in most (if not all) countries, "land ownership" does NOT include mineral rights (which are arguably a significant part of the land) and can often be overruled or dismissed by the Government should they decide they can make better use of the land (5th Amenndment in the USA includes this provision, I believe). As such, it is not really ownership and can - at best - be called borrowing from the State.
There are countries in which private ownership of any kind simply isn't recognized at all. Everything is communal. Such societies don't seem to be any less rights-respecting than any other. Indeed, the USA - which has more codified rights than almost any other country - has one of the worst records of any country for actually honoring what is codified. Indeed, not only is it not honored, even when the courts rule against it, the US Government doesn't always respect those decisions. (The Sioux won in the Supreme Court to have the Black Hills revert to them - that was something like 40 or 50 years ago and the US Government is still refusing to honor the ruling.) Even when it does respect them, it has the power to replace any judge that rules against them (as threatened by DeLay over the Terri Schaivo case) which does damage any semblance of independence or impartiality.
I do believe there are Natural Rights. I believe there is a Natural Right for any individual to be seen for oneself, that there is a Natural Right for any individual to improve their quality of life, that there is a Natural Right for any individual to hold to any beliefs they so choose, that there is a Natural Right for any individual or group to privacy and that there is a Natural Right for any individual or group to maximise potential and minimise harm.
Most of these are what Republicans and Libertarians would consider obnoxiously socialist. The only way to maximise potential is to maximise the flow of information and to guarantee the practicalities of learning that information in a manner that is useful and usable. In other words, maximal quality education and minimal restraint on learning. In practice, if you're from a poor family in a poor area in the US, the only way to learn is to be good at sports or be in the military. Oh, and be male. Poor females in the US are left to rot, regardless. The only way to be good at sports in the US seems to be to take dangerous (and eventually lethal) drugs. Brain damage and other sporting injuries are pretty common. The US military is routinely accused of fraudulant claims in recruitment efforts, violent abuse (sometimes lethal) against recruits and persecution of non-Christians. Rape of females in the US military also appears to be a common complaint - and rarely investigated.
Rights - Natural or otherwise - are only meaningful if enforcable. This is one reason the original version of the Magna Carta stipulated the right to seize (by force, if necessary) judicially-awarded compensation or enforce judicially-awarded rulings against the Government (in that case, the king). In other words, nobody - absolutely nobody - was above the law, and nobody could use executive priviledges to abuse the law or anything else. Name me one country that has such a provision today. (No, the US impeachment procedure doesn't count. The current Congress wouldn't impeach Bush if he was caught red-handed in an act of treason, and the population at large has no impeachment rights. The UK's vote of no co
For something like that - especially as it is single-user - I would say SQLite would be far more useful to you. Postgres is better where you've thousands of users and/or tables and/or horribly complex connections - it scales in those directions wonderfully.
For the sort of work you're doing, SQLite would seem to be the best choice, as it has the stuff you want and doesn't have any of the overhead of the stuff you don't want.
A very simple rule of thumb is to look at the number of variables - whether that is the number of relationships, the number of users, the number of tables, etc, but NOT the number of records - that's not really a variable in the same sense.
If the largest number is single-digit, then SQLite will out-perform anything else. If you're between double digits and triple digits, MySQL is so far ahead of the rest that it's not funny. Quadruple digits upwards, you're needing sterner stuff and you're looking at Postgres or (for massively complex databases) Ingres.
Developing Portable Code, without buying a book
on
Write Portable Code
·
· Score: 3, Informative
First, split your code into four distinct modules. These modules need to be "black box" - ie: none of them can know the internals of the others. The first module should contain the internals of your code. The stuff that actually does the hard work, but doesn't try to do any I/O of any kind. It is also the only one you absolutely need to have.
The second module deals with all the user interface stuff and nothing else. Any event handling is done in this module and nowhere else. That way, the rest of your code doesn't need to worry about what type of execution model is being used. It'll just work as you would expect. If there is no user interface, you don't need this module.
To make the UI truly portable is hard. No specific capability is guaranteed. eg: GUIs don't guarantee a text console, and text consoles don't guarantee a GUI. My advice would be to split the module into two sub-modules. The first sub-module handles what you want to do, but contains nothing specific on how. For example, it might be filled with commands for selecting fonts, drawing lines, etc. However, it would not contain any calls to an underlying system. It should assume some abstract, theoretical, idealized user interface.
The second sub-module (which may be a third-party library and not something you need to program at all) would then convert these commands into actual interface calls. If you're writing this yourself, I'd suggest starting with interfaces that are already fairly portable (eg: Qt, Gtk+, Ascii Art Library) where possible. If you can't, then you'll need to write alternative versions for different types of interface. But at least it's all in one place and squished down to the routine level, not entire screens.
The third sub-module (again, third-party if available) would do the same as above but for file I/O. Again, the upper levels should make no assumptions at all. "Anything is possible in the next half hour", as Gerry Anderson would say. The lower levels then convert the "ideal" into what the system can actually do. Here, there are at least some standards. Use them. But then write special case code for platforms that can do better. Portable need not mean sub-optimal, it merely means sub-optimal (but guaranteed to work) until tuned.
The fourth would do the same for networking. There is absolutely no reason why an application should know if you're using sockets, MPI message passing, IPv4, IPv6, DECNet or a guy waving two flags. At the application level, data comes in and goes out. The other end should be of no consequence, and the method of getting there should matter even less. High level networking should be abstract connections, using some sort of token to identify which connection is being referred to. There needs to be a middle layer here, to turn the abstract connection into a real networking protocol. The lowest level then handles the network calls required.
You need the three layers, because you've two levels of abstraction (the network protocol and the network hardware) and therefore you need two levels of reification to turn the abstract into something usable. As network protocols can work over multiple mechanisms, the protocols are resolved first and the mechanisms second.
Coding styles for ALL abstract components AND the first module should emphasize portability. There should be nothing system-specific there, so you should be able to use the absolutely vanilla ANSI specification of a language (where one exists). For C, if you want to cover ancient or obscure systems as well, you should duplicate all function declarations and external declarations, using a #ifdef to distinguish between ANSI C and K&R. There are probably other languages you need to support multiple variants of, just keep the areas where you need to have compile-time or interpret-time selection kept to a minimum.
The low-level routines are only going to work on a limited range of systems, no matter what. Therefore, anything valid for that subset is fair
The German Federal Government is short on cash, I know, but resorting to funding the "Agency for Information Technology Security" by winning RSA contests? Besides, if they're so up on IT security, why didn't they just cheat by logging onto RSA's computers?
There's the Connector layer, sysfs and fuse. The userspace-in-kernel patches also help. These allow binary-only drivers in userspace with significant kernel access.
For graphics, GGI and KGI would allow direct binary-only drivers to be written that applications can use, again without modifying the kernel.
Not sure whether you could make any use of the ABI/IBCS work for drivers, but they certainly allow "foreign" binaries to run under Linux, without anything foreign being put in the kernel itself.
In other words, a binary-only driver layer would seem unnecessary, given alternatives and mechanisms that already exist. It may be useful in some cases, but I can't see how it would be essential.
You could also use Xen as a reverse microkernel. Have foreign drivers in a "driver-only" mini OS, running as a parallel kernel. Then all Linux would need would be a way to call the other OS across Xen - and that need not be binary-only/closed-source. Companies interested in binary-only Linux work might even jointly fund development of such a capability.
The problem is not with the kernel, or even with the kernel developers. The problem is that corporations have unofficial choices rather than something they can put the blame on if their coding is crap. Officially sanctioned solutions are always preferred when being able to blame someone else is important.
Slashdot Mirror
...requires vast quantities of sodium flouride. That is the primary market for salt mines, now that people are wary of it in food.
But in my book going extinct falls in the cateory of "having difficulty reproducing". Given that we have vastly more evidence of hobbit-like humanoids yet still aren't sure if they existed as a species or an illness, it seems we're inferring a lot from three jaws and the tooth fairy's collection. Oh, and we only rule the world because early humans found the cheat codes.
They've found Monkey? Any idea if Pigsy or Sandy were nearby? Oh, and there should also be a pink cloud. There's gotta be a pink cloud.
It is vitally important to add that virtually nothing has been found of G. Blackii - bits of jaw, teeth, etc. No complete skeleton is known to exist, we don't even have a complete skull. All estimates on size are based on ratios that are known to (roughly) hold true for all primates and so presumably held true for G. Blackii. We do not know this to be the case and I would personally prefer researchers to be looking for more finds than looking for more publicity. Otherwise, when something of real importance is discovered, nobody is going to take it seriously. Why should they, when so much hype has been stirred up over the dating of a bunch of teeth?
Seriously, you are correct. Virtually all of market research is done within targetted areas with a self-selecting group (which means you're not even remotely using a random, representative sample), uses extremely poor questions (which means you'll induce bias) and - strangely enough - they never mention confidence limits, variance/standard deviation, distribution or indeed anything that can tell you if their results mean anything at all. They give you a number that, in and of itself, says precisely nothing without a LOT of supporting information.
(Statistics is like paint. It doesn't work so well with thin air.)
The latter, methinks, is worthy of a good Slashdot story. The former - if anyone would be interested - might be doable using massively distributed computing, the same way that SETI@Home and Distributed.Net are. Not everything is going to be solved by philologists and linguists and even when it is, it is because they eventually saw patterns they recognized. Pattern recognition is something computers are good at and so computers should be extremely useful tools (at the least) for such decipherments.
Also, it can't be defamation if the person has no good name to lose. In addition to those two, I believe that the defense of "truth" also holds up if there is any other reasonable grounds for believing that the claims are indeed true.
Having said all of that, Britain has no "right" of free speech (and I'm not sure that that's all that bad) and therefore freedom of speech can NOT be used as part of any kind of defense. Unless you're on Speaker's Corner, then you can say what you like - that corner is totally protected from any and all laws governing speech in England.
Canadian laws are, in many ways, very similar to Britain, so I'd assume the libel/slander laws would be based on the same governing principle - reasonableness and truth first, protection of the individual second, all other rights and obligations third.
The biggest difference I see is that the Americas have nothing comparable to the EU's Court of Human Rights, which can overturn national legal decisions or even national laws, when the EU has compelling evidence that such decisions or laws violate EU or international mandates on human rights, or when they have compelling evidence that the decision/law was in conflict with the broader needs of society.
(Britain has fallen foul of the EU's Court of Human Rights on many occasions. It is by no means a perfect country, it is flawed in many respects - as, indeed, is the EU itself. Frankly, though, I can think of little in the Americas which would lead me to believe they're any better and a lot that convinces me they're infinitely worse in many areas.)
(The BBC is notorious for destroying original prints, for assorted reasons. First it was that they didn't think anyone wanted to watch black-and-white stuff any more. Later on, they got rid of a lot of stuff they'd converted to digital media, although it is questionable as to whether the technology of the time was capable of digitizing at modern HDTV resolutions. It certainly wasn't capable of the resolutions of modern computers or 60" LCD displays.)
Producing a binary-compatiable console that is hardware-compatiable to the NES should (by anything remotely approaching fair and civilized rights) be legal, especially as Nintendo would still be making money off all the things they still make money from. However, the US is dubious on both counts, so don't count on it.
In other words, write the benchtest for the sorts of sub-category of cases that side with you, and you can make any benchmarks show what you want them to show. That's one reason they should always be viewed with a pinch of salt and a dash of vinegar, then served in newspaper.
Having said that, there are some good arguments that GRSecurity and some of the other Linux-hardening patches offer better role-based security than SELinux, due to potential limitations of the Linux Security Modules infrastructure. Those seriously interested in hardening Linux would be very well-advised to look through what is available. Having said that, BEWARE FUD! There's lots of claims and counter-claims, and nothing seems to have earned more rigid, fundamentalist stances than computer security.
There are checks for Common Criteria level 3 for Linux, but none for level 4 (which I believe RHEL is now certified to, or was it SuSE?) and there is a lot of contention as to whether these checks actually do anything useful. Are role-based memory locks and network locks actually useful? It would severely limit the security mechanisms you could use, so if you needed some other criteria as well, you might be stuck. POSIX ACLs or Trustees or do you need ACLs at all with role-based mechanisms?
Then there's the password file. Shadow is limited in the number of hashing algorithms it'll support and it may be vulnerable to rainbow dictionary cracks. The mainstream implementation does not support any unbroken hashing algorithms, which may pose other problems - though that is hard to prove. PAM is notoriously fragile, raising questions as to whether it can be considered safe or whether it should be redone. It is also unclear, especially if you use role-based computing, that the full username list should be exposed to all users. It may be more correct for the password and shadow files (if used) to be virtual, where the entries "present" depend on the user viewing the file. But that would add complexity (a BIG no-no in security) and latency.
Not all security options even exist for Linux, though it is unclear why. No Orange Book B-class patches exist for Linux, to the best of my knowledge, the best I've ever seen are just partial implementations. Very little encryption hardware is supported - far more specs have been published than have been coded to, and far more chips exist than specs. I won't even get into the limited security of e-mail clients and servers. How long have PGP and GnuPG been around??? X.400 may not be popular, but it is good on the security angle - so how many clients or servers exist for Linux???
All in all, this is an area the GOOD security guy will be doing a LOT of research in, no matter how much they know. And then, because nobody is an expert in everything and even fewer are experts in security, the REALLY GOOD security guy will not limit themselves to what they can know or understand. The REALLY REALLY GOOD security guys won't even limit themselves to what others can know or understand*.
*Ok, that's worded more for effect than accuracy. The accurate version would be that they are interested in solutions that make unauthorized access within the expected lifetime of the data and/or system highly unlikely at best - or, in the few cases you can do this, actually impossible. (You cannot break a one-time pad without the key, for example.) This is usually done by looking for "really hard problems" and hoping nobody comes up with a really easy solution. (A "really hard problem" is one that either cannot be solved in a determinate timeframe - such as NP-complete problems - or that cannot be solved, on average, in the timeframe you care about - which accounts for 99% of all popular strategies used in encryption.)
It will not only bury Sony, but also the DMCA (which actually prohibits you from de-installing the DRM code or even detecting that it's there) and will possibly cripple the credibility of the RIAA, who have been the main driving-force for DRM and the DMCA.
The topology helps, as the IPv6 backbone developers have realized you can't have a horrible design and expect it to work.
The problem is not with customers of a peered network (as their prefix MUST match that of the peered network), but with peers of peers, where prefixes may differ. Because you have more levels of peering, the problem is theoretically reduced (as lower levels MUST share a common prefix and are - generally - not permitted to peer between branches in the hierarchy) but that is more human policy than technology.
There is some confusion with regards IPv6 and backbone connections. IPv6 was originally designed NOT to support default routes. The
So how does all this help? It helps because details are kept hidden as far as possible. IPv4 is bad on routing, because the layout is crap, too much is visible and has to be learned, multiple specific routes may need to be learned for a given prefix, corporations buy large blocks of addresses then share them with multiple sites using different providers, etc. IPv6 doesn't permit a lot of that and policies agreed upon don't allow the rest.
In the end, routing requires that you know every possible route you need to follow to get to where you want to go, in the most general form you can store it. There's no escaping from that. The trick is to ensure that absolutely everything is (more or less) equally general and no specific exceptions are needed. It is the exceptions that are the killer, not the rules.
The "rainbow" method is to have an absolutely gigantic dictionary of passwords people could use to protect their encryption keys, on the basis it'll be easier to break that than the key itself. Always go after the weakest link, not the strongest. Even then, the combined power of all three of Britain's regional computing centres PLUS Britain's national computing centre would be inadequate to break passwords of significant length and strength - assuming the password hash is trivial.
(If you're using a 512-bit hash to store the password, using 16-character passwords, only through an S/Key-type OTP interface, your rainbow dictionary cracker is well and truly buggered.)
I dunno - Sting might be really good at maths.
Because IPv6 is strictly heirarchical, you need to maintain one address for each downstream router and default for upstream. This gives you a memory requirement of about 2-4K for normal usage. Assuming a LOT of mobile users, you might need another 2-4K for redirections.
In either case, given the current architecture (which assumes three layers), you're guaranteed that "end users" could be provided with quite large blocks of addresses if you so wished. I'm not sure this is currently done, but it could be. On the original 6Bone, I had a 60-bit block I could sub-allocate, which was fun. Power!
Since Government bleeding-edge scientific laboratories do often muck about with very powerful magnetic fields, and since lithium (an early mood stabilizer used by bipolar folk - who are disproportionately found in arts and bleeding-edge sciences) is well-known to reduce a person's seizure threshold, and since bipolar people are also well-known for being a source of conspiracy theories when in a manic state, it would not surprise me if the belief actually had historic events involving off-kilter scientists using metal sheielding and finding it helped them. (This doesn't mean this actually happened, I merely wouldn't be surprised if it had.)
Alternatively, in the 60s, the US Government actually had a psychic warfare division that did indeed indulge in the notion of mind control. Given that they also experimented a lot with LSD and other drugs well-known for causing delusions and paranoia, it would also not surprise me if - somewhere down the line - those who became deluded under the drugs experimentation were also involved (or learned of) the mind-control work and started their own research into how to stay safe.
If you combine these two potential sources together, you end up with the notion of the Government trying to control people's minds, people apparently being controlled, and apparently able to fend off that control with metal screening. Again, this is not a provable history, it is merely one of a (very large) number of possible ways you could create such a conspiracy theory.
I will offer one other basis for believing that this is the sequence of events - another poster mentioned "aliens" and "demons" - both of which are now believed to be seizure-related hallucinations in many cases. It would seem very UNlikely that a very similar myth is NOT seizure related. However, to get from the hallucinations caused by seizures to the specifics of the conspiracy theory and the proposed remedy, you would need some non-zero percent of the seizures to be triggered by the environment AND something that could be interpreted as the Government working in that field - however slight the similarity. What I've offered is one way to get both of these factors.
For those in Japan, I suggest checking out IPv6 Promotion Council, WIDE, Internet Initiative Japan and the BSD folks over at KAME.
In general, you probably also want to check the IPv6 Information Page, which lists many IPv6 websites, FTP sites and even IRC sites not already listed. (Almost all the above sites are also IPv6-reachable.) This totally trashes the idea that there is NOBODY on IPv6, which is good because it is a delusion which prevents people from using IPv6.
I've used numerous IPv6 tunnels and will shortly be getting native IPv6 from my provider at home, so I cry "bullshit" to those who say it can't be done. Setting up an IPv6 tunnel through a broker requires knowing your public IP address and your MAC address, then running a simple script to set up the IPv6-over-IPv4 connection. It's all of a couple of minutes work, maximum. I dare those who say IPv6 isn't being used to actually set up such a tunnel, use IPv6, THEN come back and tell the rest of us why what they just did was so impossible.
All told, I'm not convinced that there are that many people who genuinely have "no reason" to shift to the new system. All I am convinced of, so far, is that there are plenty of people who have absolutely no reasons at all but plenty of excuses. Let's look at something, here. Say Comcast converted its entire cable network to IPv6, would you care or even notice? Probably not. Their routers hide their network from your computers, so your computers wouldn't see the difference. It would be
Furthermore, in most (if not all) countries, "land ownership" does NOT include mineral rights (which are arguably a significant part of the land) and can often be overruled or dismissed by the Government should they decide they can make better use of the land (5th Amenndment in the USA includes this provision, I believe). As such, it is not really ownership and can - at best - be called borrowing from the State.
There are countries in which private ownership of any kind simply isn't recognized at all. Everything is communal. Such societies don't seem to be any less rights-respecting than any other. Indeed, the USA - which has more codified rights than almost any other country - has one of the worst records of any country for actually honoring what is codified. Indeed, not only is it not honored, even when the courts rule against it, the US Government doesn't always respect those decisions. (The Sioux won in the Supreme Court to have the Black Hills revert to them - that was something like 40 or 50 years ago and the US Government is still refusing to honor the ruling.) Even when it does respect them, it has the power to replace any judge that rules against them (as threatened by DeLay over the Terri Schaivo case) which does damage any semblance of independence or impartiality.
I do believe there are Natural Rights. I believe there is a Natural Right for any individual to be seen for oneself, that there is a Natural Right for any individual to improve their quality of life, that there is a Natural Right for any individual to hold to any beliefs they so choose, that there is a Natural Right for any individual or group to privacy and that there is a Natural Right for any individual or group to maximise potential and minimise harm.
Most of these are what Republicans and Libertarians would consider obnoxiously socialist. The only way to maximise potential is to maximise the flow of information and to guarantee the practicalities of learning that information in a manner that is useful and usable. In other words, maximal quality education and minimal restraint on learning. In practice, if you're from a poor family in a poor area in the US, the only way to learn is to be good at sports or be in the military. Oh, and be male. Poor females in the US are left to rot, regardless. The only way to be good at sports in the US seems to be to take dangerous (and eventually lethal) drugs. Brain damage and other sporting injuries are pretty common. The US military is routinely accused of fraudulant claims in recruitment efforts, violent abuse (sometimes lethal) against recruits and persecution of non-Christians. Rape of females in the US military also appears to be a common complaint - and rarely investigated.
Rights - Natural or otherwise - are only meaningful if enforcable. This is one reason the original version of the Magna Carta stipulated the right to seize (by force, if necessary) judicially-awarded compensation or enforce judicially-awarded rulings against the Government (in that case, the king). In other words, nobody - absolutely nobody - was above the law, and nobody could use executive priviledges to abuse the law or anything else. Name me one country that has such a provision today. (No, the US impeachment procedure doesn't count. The current Congress wouldn't impeach Bush if he was caught red-handed in an act of treason, and the population at large has no impeachment rights. The UK's vote of no co
For the sort of work you're doing, SQLite would seem to be the best choice, as it has the stuff you want and doesn't have any of the overhead of the stuff you don't want.
A very simple rule of thumb is to look at the number of variables - whether that is the number of relationships, the number of users, the number of tables, etc, but NOT the number of records - that's not really a variable in the same sense.
If the largest number is single-digit, then SQLite will out-perform anything else. If you're between double digits and triple digits, MySQL is so far ahead of the rest that it's not funny. Quadruple digits upwards, you're needing sterner stuff and you're looking at Postgres or (for massively complex databases) Ingres.
The second module deals with all the user interface stuff and nothing else. Any event handling is done in this module and nowhere else. That way, the rest of your code doesn't need to worry about what type of execution model is being used. It'll just work as you would expect. If there is no user interface, you don't need this module.
To make the UI truly portable is hard. No specific capability is guaranteed. eg: GUIs don't guarantee a text console, and text consoles don't guarantee a GUI. My advice would be to split the module into two sub-modules. The first sub-module handles what you want to do, but contains nothing specific on how. For example, it might be filled with commands for selecting fonts, drawing lines, etc. However, it would not contain any calls to an underlying system. It should assume some abstract, theoretical, idealized user interface.
The second sub-module (which may be a third-party library and not something you need to program at all) would then convert these commands into actual interface calls. If you're writing this yourself, I'd suggest starting with interfaces that are already fairly portable (eg: Qt, Gtk+, Ascii Art Library) where possible. If you can't, then you'll need to write alternative versions for different types of interface. But at least it's all in one place and squished down to the routine level, not entire screens.
The third sub-module (again, third-party if available) would do the same as above but for file I/O. Again, the upper levels should make no assumptions at all. "Anything is possible in the next half hour", as Gerry Anderson would say. The lower levels then convert the "ideal" into what the system can actually do. Here, there are at least some standards. Use them. But then write special case code for platforms that can do better. Portable need not mean sub-optimal, it merely means sub-optimal (but guaranteed to work) until tuned.
The fourth would do the same for networking. There is absolutely no reason why an application should know if you're using sockets, MPI message passing, IPv4, IPv6, DECNet or a guy waving two flags. At the application level, data comes in and goes out. The other end should be of no consequence, and the method of getting there should matter even less. High level networking should be abstract connections, using some sort of token to identify which connection is being referred to. There needs to be a middle layer here, to turn the abstract connection into a real networking protocol. The lowest level then handles the network calls required.
You need the three layers, because you've two levels of abstraction (the network protocol and the network hardware) and therefore you need two levels of reification to turn the abstract into something usable. As network protocols can work over multiple mechanisms, the protocols are resolved first and the mechanisms second.
Coding styles for ALL abstract components AND the first module should emphasize portability. There should be nothing system-specific there, so you should be able to use the absolutely vanilla ANSI specification of a language (where one exists). For C, if you want to cover ancient or obscure systems as well, you should duplicate all function declarations and external declarations, using a #ifdef to distinguish between ANSI C and K&R. There are probably other languages you need to support multiple variants of, just keep the areas where you need to have compile-time or interpret-time selection kept to a minimum.
The low-level routines are only going to work on a limited range of systems, no matter what. Therefore, anything valid for that subset is fair
The German Federal Government is short on cash, I know, but resorting to funding the "Agency for Information Technology Security" by winning RSA contests? Besides, if they're so up on IT security, why didn't they just cheat by logging onto RSA's computers?
For graphics, GGI and KGI would allow direct binary-only drivers to be written that applications can use, again without modifying the kernel.
Not sure whether you could make any use of the ABI/IBCS work for drivers, but they certainly allow "foreign" binaries to run under Linux, without anything foreign being put in the kernel itself.
In other words, a binary-only driver layer would seem unnecessary, given alternatives and mechanisms that already exist. It may be useful in some cases, but I can't see how it would be essential.
You could also use Xen as a reverse microkernel. Have foreign drivers in a "driver-only" mini OS, running as a parallel kernel. Then all Linux would need would be a way to call the other OS across Xen - and that need not be binary-only/closed-source. Companies interested in binary-only Linux work might even jointly fund development of such a capability.
The problem is not with the kernel, or even with the kernel developers. The problem is that corporations have unofficial choices rather than something they can put the blame on if their coding is crap. Officially sanctioned solutions are always preferred when being able to blame someone else is important.