...the cancer cells are identical. Not merely "similar", in that they're cells of cancer type X, but a direct copy of the original cancer. (The genes that are present are from a husky, if I understand the story correctly, and the markers are clear enough to be able to estimate a timeframe. This is how they know the origin, as opposed to finding said husky in a glacier somewhere.)
This story has a lot of implications that aren't necessarily obvious. First, if both dogs and marsupials can have a contageous, directly-transmissable cancer, then so can any species, through ANY mechanism that involves a transfer of cells. I wonder if blood banks are being screened for such cancers. Given the total lack of speed they showed over AIDS or vCJD, I seriously doubt they've got any serious monitoring in place for such pathogens. (Sure, it's a theoretical, but it would seem better to KEEP it a theoretical, rather than wait until it's a major problem.)
Since this was presumably two different spontaneous mutations, transmissable cancer must be capable of arising in almost any organism at almost any time. I doubt there would be many carcinogens in common between Alaska and Australia, despite them having the same first and last letters. Understanding that mechanism would seem very important, as it would seem reasonable to assume that anything that easy to start would be equally easy to stop.
Finally, for the cancer to spread in the way described, we must be talking about cells with a high degree of mobility. This can't be something attached to something, like a tumour, or it couldn't spread identically from organism to organism. It must also be fragile enough that an airborne version has not yet evolved. However, that may be merely a matter of time. I think medical labs should be putting the effort into understanding the mechanisms and the limitations of transmissable cancers, as we really don't want to be in the usual mess of playing catch-up afterwards, but don't need to do more than necessary if research shows that the limitations are barrier enough.
Netcraft reveals that the site is running Linux with Apache 1.3.37 - which was only recently updated from 1.3.36. (Based on that, my guess is that the "crash" was actually them upgrading the webserver.)
There's not a whole lot of other information. It was paid for by the "Friends of Joe Lieberman" (so he didn't even use his own funds for it), and the hosting company was The Planet Internet Services. Anyone buying the services of a company with a name that pretentious almost deserves problems. Oh, the ISP is located in Dallas, Texas. Not exactly a local vendor, then. And who -are- those mysterious Friends over in Texas, anyway...?
...but missing an important point. Every resend you do has to go through the bus, and PCI is a slug on tranquilizers. The less you go through your bus, the better. You've also got the problem of getting data to and from the card. The PCI bus is 66 MHz, the local LAN will probably be 100 Mb/s. This isn't a problem most of the time. The problem is when you have bursts of data that exceed your PCI bus speed. If your card can store-and-forward these AND deliver all the appropriate responses, then you don't have problems from packet retransmits and timeouts.
Will this be useful over a WAN? Depends. If the WAN is significantly faster then the bus, then yes. In most cases, people don't have access to a pipe of anything like 100 MB/s. In those cases, you gain nothing at all.
This device is for LAN parties, as far as I can tell. If it is designed correctly, it'll max out your system under those conditions. You'll get damn-near wire-speeds, even though the internal PC architecture can't handle data that fast.
The biggest question I have is: Why Linux? I use Linux because I'm a geek and because Linux is damn-near infinitely versatile. It supports protocols that have barely cooled down from being hot off the press. Games don't use, or need, SCTP. They might be able to benefit a little from DCCP or GAMMA, but no game in existance uses those. Network games are almost certain to use TCP/IP, and the fastest TCP/IP stack on the planet is in NetBSD.
I don't use NetBSD, though I do use some of the other *BSDs, but credit should be given where credit is due - NetBSD holds the record for TCP/IP throughput and so is the sensible system to use for an accelerator of this kind.
There is one - and only one - exception to this. That is when the hardware (DMA, etc) is designed to be controlled by multiple points. A lot of work has gone into Linux for clustering, and that's essentially what you'd have - a cluster, with the network card acting as the I/O node. You could transfer to/from memory (or other devices) directly without using the CPU at all, in that case. This has limited benefit if used trivially - the memory bandwidth is already so constricted that you've L1, L2 and sometimes L3 caches just to keep things going at all.
What you'd need to do is - provided the game is multithreaded - move the communications thread onto the network card, with the rest of the game staying on the CPU. The calls to and from the communications thread will generally be much more compact than the data to/from the socket layer, so it'll be much less bus-intensive and therefore substantially faster. This only works if there is a thread that can be firmly identified as handling communications, AND where the assumption of calls vs. sockets is valid.
No, the Black Hat wouldn't tell them about the hole. Well, not per-se. Not if there was some way of tricking Microsoft into thinking it was fixed, whilst leaving the Black Hat a back-door into everybody's systems. One way to do this would be to try and persuade Microsoft that only a subset of the values that would break security are a problem. Social engineer both the fix and the buglist. That way, if the Black Hat is ever detected, there's a good chance Microsoft will deem it a fixed bug and blame the victim, rather than investigating further.
One of the dangers in hiring or consulting Black Hats who are any good is that 99% of security is all about social engineering - both the defence and the offense. Because of this, it is utterly impossible to distinguish between someone actually securing your systems and merely persuading you they have done so. Grey Hats will have basically the same social engineering skills but are more likely to teach you what to avoid, than to use those skills against you. This is not to say that Black Hats will always work against you - that's bad for business. All you can say is that what makes someone a Black Hat as opposed to a Grey Hat is that they wouldn't be opposed to doing so, and you'll never know.
Oh yeah - I mentioned the use of social engineering in the protection of a system. The defences in any system will always be breakable with enough time and effort, so the only truly secure system is one that can socially engineer the attacker into believing that they have either already succeeded long before they really have or that there's nothing alive and listening for them to attack. Under no circumstances should obscurity be used as a substitute for social engineering. Obscurity hides what is important except to an attacker who has figured the obscurity out - which means that it can be used against the defender far more effectively than against the attacker. Social engineering hides nothing, it merely helps someone to see what they want to see. Because it hides nothing, it cannot be used against you, the worst possible case is that it'll cease to be as effective.
Ground Penetrating Radar works best in dry conditions with a uniformly-composed ground that contains no natural iron. It's also reliable only to a few feet. If you want greater depth, you need more power and you lose resolution. You also risk noise in the signal.
Non-uniform ground is a pain for two reasons. First, it creates false reflections, and secondly because GPR measures depth as a function of the time for the echo to return, the vertical scale goes to hell in a handbasket. You've no idea where things are in relation to each other, because the GPR will assume a constant speed for the radar signal, and that assumption - in such cases - is going to be false.
Water of any kind dissipates the signal, so you get less resolution, a shorter range, and all kinds of noise in the signal as the pulses could be travelling along any possible path. Not sure if there's any way you could get a naturally-occuring diffraction grating, total internal reflection, or similar, but there probably are. These would also totally fool a GPR.
GPR is also horrible to interpret. Anyone who is interested in archaeological GPR, I do have a bunch of GPR datafiles (raw and processed) which I can e-mail to anyone interested. It'll give you a good idea of just how wretched the damn thing is.
Five years ago, the popular view was that Linux was unstable and needed hacking to make it work, but I had no stability issues and never needed to hack except for the pleasure of getting the computer to do something freaky.
Today, the popular view is that Linux is highly stable and can be run out of the box by a WalMart customer, but I just had to reformat after Fedora Core 6 pre barfed after a yum update fried X totally and irretrievably. (And before someone says anything, yes I'm fully aware that running alpha-grade software is risky. That's half the fun. I burn out machines on a regular basis. It's just a little disconcerting when a highly-stable industry-standard package throws up over the disk and video card.)
...if it weren't for the fact that there are a VAST number of drivers that are not being included in distros. Madwifi covers a lot of wifi cards, for example. Then, there are drivers for "less common" hardware - WANPIPE is provided by one manufacturer for their T1 cards and there's even patches out there for the LEON architecture, the Texas Instruments OMAP architecture, nanosecond clocks, the VME bus, etc.
On that basis, I'll ask my question: Users are forever complaining about a lack of drivers, but the drivers they are often presented with are a very small subset of the Open Source drivers that exist. Is this a problem Fedora will be addressing, or will it be largely left to such drivers being absorbed into the mainstream kernel?
Library files have versioning, so multiple instances can coexist just fine in the main directory. Applications are also perfectly capable of setting LD_LIBRARY_PATH for anything local, or could even be statically compiled. Yes, that really is an option.
Hell, in the days of yore, when the IBCS module was being maintained, you could even run binaries from SCO UnixWare or Sun Solaris within Linux at native performance. How different do you need to get?
If you want to be really fancy, then any program with a sufficiently comprehensive symbol table aught to be "relinkable". For any given tuple (called function, desired library set, available library set), it will often be possible to return a fresh pointer to an existing library which will handle the call in the manner expected, and optionally a tiny conversion routine that handles differences in the API or ABI to conceal the difference. That's just a matter of building a comprehensive database of what libraries are out there and what can be used as a drop-in replacement (or at least abused as one with the right glue layer).
A universal package manager would be good. RPM is unstable when handling thousands of transactions - a not uncommon sight if you're using the development files and wait more than a day or two between yum updates - so the sooner Fedora/Red Hat dump it and write something more scalable, the better. I've been tempted to write something that's interoperable with rpm and apt, and that meets my requirements for better scalability and improved robustness, but time is not something I've had a vast amount of, of late.
Another problem is in some of the configuration stuff. Gentoo and Fedora have almost nothing in common in the/etc directory tree, which makes things a little awkward. However, I'm of the opinion that/etc is ancient technology. Some files must remain physical files (or rescue becomes impossible), but the rest could be virtualized without much trouble. What's the benefit of that? Well, you could then use a mix of Gentoo and Fedora software without having duplicate data in different files. There would be one instance of any piece of data, compilable into whatever virtual file format you liked, so applications could view said data in the form they wanted. This could help with improving compatibility with other distros, too.
Finally, there is the problem of namespace conflicts with programs. Not merely different versions of the same program, but totally different programs with the same name. To solve this, the binary directories */bin and */sbin need to be virtualized as well. Have the real programs in unique locations, then have the specific combination of desired applications mapped onto that user's view of the standard binary directories. Different users could, therefore, be running totally different programs by calling the same application name.
(This also improves security, as it means you can't merely "not run" programs for which you have no permission, they don't even exist in your userspace. It could re-use a lot of the ideas in SELinux and eliminate some of the shortcomings of it - such that it would be possible to get webservers or other complex configurations running properly, because you could visually see what is reachable from what.)
So, all in all, there's plenty of room for improvement in compatibility and there has been some backsliding at times. This isn't necessary and could be corrected at any time.
Yes, taxes should be considered. A $55,000/yr job in one place is NOT the same as a $55,000/yr job somewhere else, if the net cost to you after State taxes, County taxes (Multnomah County, OR, has its own taxes for example), -and- Sales Tax are different. Taxes are hard to figure in, because paying less on State taxes but more on Sales tax can end up far more expensive if you spend a large percentage of your income.
(This is why poor people are generally screwed with sales taxes, as they spend a much higher percentage of their income just to keep going, and therefore get taxed more heavily. Rich people generally get screwed with State taxes, as they get taxed even on the income they're saving. Being your typical left-leaning Brit, I tend to take the line that the rich can afford to get screwed a little.)
However, we've only factored in the costs here. What about the benefits? A State that has more money to play with can have better roads (so you spend LESS on expensive car maintenance), can have better schools and Universities (so you're not limited to sending the kids to some fundamentalist haven so that they're at least capable of adding correctly), can have decent public transport (saving you gas money and usually time), and can have some excellent public museums, public art galleries, etc, which gets you direct access to stuff only the world's megarich can even think of affording.
So, if taxes are spent by Government wisely (yeah, like that happens!), the net cost can end up being lower than the hidden and not-so-hidden costs of living in areas with lower taxes or no taxes at all. This does, however, require wisdom. High taxes that don't benefit anyone at all are simply a drain on the pocket.
(And, yes, I deliberately said anyone, not just you. If high taxes produce a good schooling environment, then it doesn't matter if it doesn't benefit you directly. Better educated kids will produce a better quality workforce. What does it matter if you're a richly-paid genius, if the rest of the company can't figure its way out of a paper bag and goes under? The brighter your co-workers, the more profitable the company and so the better your job security. Oh, and the better your pay.)
So, to correctly factor in the REAL cost of the taxes, you must factor in the real cost of what those taxes buy you, both directly and indirectly. Let's say your income is I, the total direct tax over the same time is T1, the total average indirect tax is T2, the total direct benefit to you because of superior infrastructure and/or superior facilities is B1, and the total indirect benefit is B2, then your actual salary S is calculated as follows: S = I + B1 + B2 - T1 - T2.
B1 and T2 are extremely hard to calculate. B2 is virtually impossible to know. However, without knowing those values, you cannot say how the real cost of living compares to your effective salary.
Is this the end of it? Uhh, no. Each State, each county, has an effective rate of inflation which is dictated by the change in the price of those goods that have a floating value across the country. Gasoline is an example of something subject to local inflation. When businesses move in, there are more people with disposable income, so prices will rise to what the market will bear and local inflation goes up. When businesses move out, there are fewer people buying, so to conserve profit margins prices must rise and local inflation goes up.
This is why you do not want to be in an area that is undergoing a boom OR a bust. It's expensive. You want an area that has a fairly stable economy and is growing at a fairly steady, gentle pace. How steady and gentle? Well, it needs to grow faster than the population, but not by very much.
You also want an area with superb social welfare. No, I don't mean people get paid for doing nothing - that's what politicians are for. I mean you want to ensure that those who are unemployed are retrained and th
Dunno if Norton AV was ever essential. I used macafee very early on. Now, some Norton software was, indeed, essential, back in the DOS days. No serious geek left home without a floppy containing the early Norton Utilties (undelete files, hex edit files or even the disk - there were some seriously useful tools). Norton Guides were pretty helpful, too. I can remember using the Guides for assembler and for DOS interrupts. They were the first practical on-line guides for DOS, because they were plugged in on a TSR, so you could actually be editing and switch to them. They were also unloadable, making them in many ways almost direct ancestors of the Linux kernel modules.
Never found Peter Norton's books to be that good, though. There were many excellent books on the PC internals, detailing the interrupts, the INT 21 functions, how to directly program the video card, "undocumented" Intel CPU instructions, etc. Norton's books were not amongst those I regard as the gems of that era.
Maybe this is a Blashsack, or a Slabshack ("Love Shack" for big iron). Now, if it's both a Slashback and a Backslash, then it could be a back-to-back slash-slash. Which, given the comments aimed pointedly at Microsoft, would make sense.
Why would you need to drop Oracle support? If the code is split from the primary codebase, a well-defined API is drawn up that allows a dynamic module to be loaded at runtime, and some sort of exception-handler is set up so that incompatiable or absent routines don't blow everything up, then you get the best of both worlds.
In this scenario, the Oracle people get to have an Oracle module that is guaranteed to run within the application for a very reasonable period of time. Well, up until the time that so many functions have changed that there are no salvagable functions in the Oracle module. But that's not going to happen overnight and it gives the Oracle afficados time to reconsider what support they want to give.
On the other hand, because the Oracle code is extracted, the primary developers don't need to give a damn if they break anything in the Oracle code. They don't have to fix the Oracle code and as the code is now compiled seperately, it doesn't break the builds.
On the third hand, by exposing an API via a pluggable module, other people who might well be interested in providing such modules would be able to do so without ripping the code apart and making major changes. Ingres would be a reasonable candidate, now that it is Open Source, as it is pretty beefy. And IBM seem to be making some serious inroads with Linux versions of DB/2 and Informix.
It is a grave error to assume everything in computing is either/or. That may be true of bits (except when they're fuzzy), but it hasn't been true of programs for some considerable time.
Nonono - the quote is quite wrong.
on
Halving Half Lives
·
· Score: -1, Offtopic
proposed technique - which involves slashing the half-life of an alpha emitter by embedding it
This should read:...which involves slashdotting the embedded alpha emitter while playing half-life...
Anyone who could design a VIC 20 has to either be criminally insane or paid off. And why DID the Commodore 64 disk drives work at about a tenth the speed of the 4040 and 8080 drives they were selling 5-7 years earlier? If that wasn't proof enough of Evil Intent, then answer me this - why has the PIC Chip never been added to the VICE emulator? I think it's because Bill Gates sacrificed a goatse and placed an Evil Curse on Commodore.
Paper votes can easily be altered. Simply make sure the ballot boxes "go missing", or in the case of the Mexican election, simply don't provide ballot papers in the areas you don't want voting.
The best solution I can think of with electronic votes is to use some form of public key encryption with an authenticating block encryption mode. One half of the keys would be provided on a TOTALLY random basis along with the voter card. The decrypting keys would be kept in a tamper-proof computer that is designed to be write-only with the sole exception of the count at the end.
The voter comes along and enters their vote. The vote is encrypted with their key. As nobody (at this point) has the decryption key, or another copy of the encryption key, it is impossible for the vote to be altered. A copy could then be printed out for backup purposes and placed in a regular ballot box.
So far, doesn't sound much different from anyone else's electronic system, right? Except that we're not tallying yet. Well, read on. The votes are collected in their encrypted form and kept in some secure system OTHER than the one doing the counting. They are then fed into the counting machine. The counting machine knows what keys are allocated to a given precinct, so tests each potential key against each vote from that precinct. Once a key is used, it is deleted.
If a vote has no valid decryption key, the vote is invalid and is rejected. This will include duplicate votes (the key has been deleted) as well as votes for which no key has ever existed. The (still encrypted) vote would then be output as a reject.
The votes are kept seperate and tallied. The output will be the tallies, the votes that comprise that tally, and the grand totals involved. The grand totals should be the same, provided the counters are working correctly.
Now, what basic checks can we perform, using this sort of system? First, let us say there is a recount. The recount would be of the votes placed into the ballot box. There should be exactly one such ballot box vote that is not spoiled or a duplicate for each and every valid vote printed by the tallying machine and the totals should match exactly. There should ALSO be exactly one spoiled or bogus ballot paper for every rejected vote, although further comparison would be impossible as the rejects are encrypted and the spoiled ballots aren't.
Ok, how do we know the software is valid? Well, we know that the vote that the user put in the ballot box matched the one they entered in the computer, and we know that there's a 1:1 between the results in the box and the results in the computer, so we know that the computer has to be producing valid data.
Then what happens when there is a discrepency? With two sources, how do we know which is the one that has the valid data and which does not? The votes are encrypted in a way that is essentially tamper-proof, the ballot boxes are not. The only way to resolve this is to make the ballot boxes reasonably tamper-proof. I'd suggest a wooden or metallic ballot box that has a lid that can be attached with spring-loaded bolts, where the only way to open the box is to cut it open. You want unique non-sequential numbers on RFID tags, to ensure that boxes don't go missing anyway.
After all that, you will have a more honest system than you do at the moment. You might even discourage those who would cheat the system from even being a part of it. However, ultimately, politicians are professional liars and the extremely rich will always be power brokers. The best system in the world can't clean up the human race, it can only clean up one very small part of the feedback loop. Which is better than nothing, but should not be assumed to be everything.
Can you answer this one for me. They're talking about using this in conjunction with chemotherapy, which is notoriously toxic to the body. However, the scorpion venom will have spectral absorbtion properties totally unlike anything in the brain, which means that if you tune a microwave to that unique frequency, it'll cook the cancer cells in the vicinity of the venom and will leave the rest of the brain completely untouched.
It would seem, at first glance, that this tagging mechanism would be ideal for treatments that can be finely targetted onto that mechanism, but that it isn't going to be nearly so effective as simply a means of weakening what's left for the chemo to get.
However, this is so blindingly obvious that, since it wasn't mentioned, there's an advantage to chemo -or- a disadvantage to my suggestion that I'm missing and is amazingly obvious to these guys. Any idea on what that might be?
I can see that a standard interface for everything would be next to impossible. HOWEVER, there are some things that could be added that would greatly improve standardization without adding significant expensive hardware and would also take some of the burden off the main processor.
OpenGL - Many graphics cards support OpenGL, but do so in different ways. That's fine. All you need is some cheap transliteration layer that converts a generic OpenGL instruction into the card-specific OpenGL instruction. They're going to be 1:1 if the standard is followed correctly.
Renderman/NURBS - Most high-end graphics software support Renderman and/or NURBS, but a lot of crunching goes on to turn this into something the graphics card supports, usually by the software itself, not even the driver. This creates massive redundancy and inconsistancy - two good indicators that this is a crappy approach.
Loadable Microcode - A number of CPUs support loadable microcode. It's used a fair bit on the Intel Pentium processor series - Freshmeat has listed several updates - and the Transmeta Crusoe was built around it. Loadable microcode could be used to accelerate functions currently in software drivers that are I/O bound, as typically commands to drivers will take less bandwidth than processed data.
Firmware - This is not the same as microcode. Microcode is loaded into the CPU or GPU snd often provides basic intermediate-level functions. Firmware is in non-volatile RAM and is usually more extensive. A card-based driver would likely be in firmware, not in microcode. Firmware is software that runs on the GPU and so can do anything you can do in software, given the instruction set provided. On Linux, you'd probably want the X client to run in firmware on the GPU rather than on the main CPU.
Graphics protocol tunneling - You should not need to care if the graphics card works over PCI, HyperTransport, Infiniband, VME, IDE or a small piece of green putty found in the armpit of an ATI card designer one midsummer morning. If there was a recognized, standard graphics communications protocol that provided all the extensibility vendors just love to abuse, it would eliminate the bus technology from graphics drivers. The driver would produce a standard packet which would be tunneled over the physical transport without having to care what that transport was.
Let's look at these in turn. First, OpenGL. OpenGL is a nice, popular 3D graphics format. Software generates the OpenGL instructions, which get turned into identical but probably different OpenGL instructions (on a 1:1 basis) in some OS library, which then gets translated into identical but almost certainly different OpenGL instructions (still on a 1:1 basis) by the graphics driver, which hands the data to the card. If the communications is not wrappered, then the OpenGL instructions sent over the bus will need to be converted into yet another different but identical set of OpenGL instructions that the GPU can actually process. There is absolutely no way on Earth that this can be an efficient mechanism. A single standard representation would be infinitely superior.
Renderman/NURBS. This is the format used by tools such as BMRT, Pixar's Renderman software, Rhino 3D, etc. We're talking ultra high-end 3D graphics with shaders to die for. In terms of CPU and I/O requirements, it's not cheap to get this stuff done at any decent level of performance. The CPU part isn't that important, as the GPU won't be able to do any better. What you will do, however, is eliminate the I/O of rendered data over a slow bus. Sending a shader or an image over would be painless, and graphics is I/O-bound, not CPU-bound.
Loadable Microcode and Firmware. These are NOT the same thing, as I've already said. But what they do allow you to do is more effectively divide the driver between what is on the CPU and what is on the GPU. You can run anything in firmware, provided the GPU has the instruction set for it. It also pr
Sarcasm in British comedy is about as useful in comedy as sticking a pencil up your nose and saying "Wibble". For example, Sir Humphrey Applebey wouldn't be caught dead being sarcastic - unless there was an excellent chance of manipulating Jim Hacker as a result. That leaves Tim Brooke-Taylor, Bill Oddie and Graeme Garden, but they're a real bunch of goodies. Oh, I forgot Kenny Everett, but then it's definitely a rap.
Black Holes are permitted non-point singularities (Kerr Ring singularities, for example). The requirement is that the singularity has infinite density. Although light cannot escape directly, Black Holes evaporate by means of virtual particles and these virtual particles contain information that has fallen into the hole, as well as mass/energy.
MECOs are constantly collapsing, so the laws of thermodynamics which compell Black Holes to evaporate do not necessarily apply to MECOs in the same way, without any requirement for evaporation of mass/energy or of information. (This is because they're not in a pseudo-stable state as they are.) It would seem to follow that MECOs must exhibit different characteristics at this level.
Even if we were to say that the two were directly comparable, MECOs would be closer to a naked singularity (ie: a Black Hole without an event horizon) and almost certainly can only be spheres or related shapes. There would be nothing comparable to a Kerr Ring singularity in nature, although if you were to produce a MECO inside of a torus, it would have no way of collapsing beyond the torroidal shape, as the quantum foam would hold it apart at a certain point.
No, we do not need a singularity at the beginning of the Universe, though for a different reason. The prevailing theory at the moment is that time is curved by gravity as well as space, so the closer you get to the point of the big bang, the greater that curvature gets. The upshot of this is that time ends up as a parabola, which means that there is no increment along the axis we normally refer to as time at the point of origin. Instead of having a discontinuity (which is all a singularity is), space/time would be wholly continuous.
This also solves another gremlin. As there is no "time zero", there is no moment of creation. This is what concerned Professor Hawking, when he was asked by the Pope not to delve into the creation of the Universe - he'd just proved that there is no moment of creation and therefore no need of a creator.
MECOs are suspended within an eruption of quantum foam, if I understand things correctly. This does relate to the early Universe, because this eruption is closely related to cosmological Inflation, only in the other direction. If MECOs exist, it means that there is a strict division between a pre-Inflationary system and a post-Inflationary system, that you can move in one direction only between these states. This would make accelerators much more interesting, as they would then be strictly prohibited from recreating conditions that existed in the pre-Inflationary universe. As soon as you get to the borders, MECO theory suggests, the pressure from the virtual particles will always keep the system from going further.
This makes the theory very testable in the laboratory. Simply push the system towards very high energy densities. If the MECO theory is correct, your ability to do so will fall off and be asymtotic to the energy density required for inflation. (Thus, although the conditions are finite, there is some sort of feedback that makes the input required to actually achieve those conditions infinite.)
If experimental science fails to yield a force with the required properties, then MECOs probably do not exist. If experimental science always yields such a force, then black holes probably do not exist.
I'd use a database modelling tool, like ERWin or Dezign for Databases. (Yes, they're both commercial - I've not seen a single good entity-relationship modelling tool that is also Open Source, although it's an obvious tool to write.)
These tools map attributes in records to other attributes in other records. They're designed to then turn these maps into SQL code, but that part isn't important here. What is important is that you can create a full relationship mapping between entities. If you then treat the direction of the relationship as showing the dependency, you can map all the dependencies in the system.
Managers like diagrams to be of a format that are familiar to them, so anything that is "better" from a technical standpoint but "less familiar" to managers from an experience standpoint is, in fact, not as good of a solution.
Slashdot Mirror
This story has a lot of implications that aren't necessarily obvious. First, if both dogs and marsupials can have a contageous, directly-transmissable cancer, then so can any species, through ANY mechanism that involves a transfer of cells. I wonder if blood banks are being screened for such cancers. Given the total lack of speed they showed over AIDS or vCJD, I seriously doubt they've got any serious monitoring in place for such pathogens. (Sure, it's a theoretical, but it would seem better to KEEP it a theoretical, rather than wait until it's a major problem.)
Since this was presumably two different spontaneous mutations, transmissable cancer must be capable of arising in almost any organism at almost any time. I doubt there would be many carcinogens in common between Alaska and Australia, despite them having the same first and last letters. Understanding that mechanism would seem very important, as it would seem reasonable to assume that anything that easy to start would be equally easy to stop.
Finally, for the cancer to spread in the way described, we must be talking about cells with a high degree of mobility. This can't be something attached to something, like a tumour, or it couldn't spread identically from organism to organism. It must also be fragile enough that an airborne version has not yet evolved. However, that may be merely a matter of time. I think medical labs should be putting the effort into understanding the mechanisms and the limitations of transmissable cancers, as we really don't want to be in the usual mess of playing catch-up afterwards, but don't need to do more than necessary if research shows that the limitations are barrier enough.
Netcraft has indeed confirmed that J.A.V.A. is no longer being interpreted.
There's not a whole lot of other information. It was paid for by the "Friends of Joe Lieberman" (so he didn't even use his own funds for it), and the hosting company was The Planet Internet Services. Anyone buying the services of a company with a name that pretentious almost deserves problems. Oh, the ISP is located in Dallas, Texas. Not exactly a local vendor, then. And who -are- those mysterious Friends over in Texas, anyway...?
Will this be useful over a WAN? Depends. If the WAN is significantly faster then the bus, then yes. In most cases, people don't have access to a pipe of anything like 100 MB/s. In those cases, you gain nothing at all.
This device is for LAN parties, as far as I can tell. If it is designed correctly, it'll max out your system under those conditions. You'll get damn-near wire-speeds, even though the internal PC architecture can't handle data that fast.
The biggest question I have is: Why Linux? I use Linux because I'm a geek and because Linux is damn-near infinitely versatile. It supports protocols that have barely cooled down from being hot off the press. Games don't use, or need, SCTP. They might be able to benefit a little from DCCP or GAMMA, but no game in existance uses those. Network games are almost certain to use TCP/IP, and the fastest TCP/IP stack on the planet is in NetBSD.
I don't use NetBSD, though I do use some of the other *BSDs, but credit should be given where credit is due - NetBSD holds the record for TCP/IP throughput and so is the sensible system to use for an accelerator of this kind.
There is one - and only one - exception to this. That is when the hardware (DMA, etc) is designed to be controlled by multiple points. A lot of work has gone into Linux for clustering, and that's essentially what you'd have - a cluster, with the network card acting as the I/O node. You could transfer to/from memory (or other devices) directly without using the CPU at all, in that case. This has limited benefit if used trivially - the memory bandwidth is already so constricted that you've L1, L2 and sometimes L3 caches just to keep things going at all.
What you'd need to do is - provided the game is multithreaded - move the communications thread onto the network card, with the rest of the game staying on the CPU. The calls to and from the communications thread will generally be much more compact than the data to/from the socket layer, so it'll be much less bus-intensive and therefore substantially faster. This only works if there is a thread that can be firmly identified as handling communications, AND where the assumption of calls vs. sockets is valid.
One of the dangers in hiring or consulting Black Hats who are any good is that 99% of security is all about social engineering - both the defence and the offense. Because of this, it is utterly impossible to distinguish between someone actually securing your systems and merely persuading you they have done so. Grey Hats will have basically the same social engineering skills but are more likely to teach you what to avoid, than to use those skills against you. This is not to say that Black Hats will always work against you - that's bad for business. All you can say is that what makes someone a Black Hat as opposed to a Grey Hat is that they wouldn't be opposed to doing so, and you'll never know.
Oh yeah - I mentioned the use of social engineering in the protection of a system. The defences in any system will always be breakable with enough time and effort, so the only truly secure system is one that can socially engineer the attacker into believing that they have either already succeeded long before they really have or that there's nothing alive and listening for them to attack. Under no circumstances should obscurity be used as a substitute for social engineering. Obscurity hides what is important except to an attacker who has figured the obscurity out - which means that it can be used against the defender far more effectively than against the attacker. Social engineering hides nothing, it merely helps someone to see what they want to see. Because it hides nothing, it cannot be used against you, the worst possible case is that it'll cease to be as effective.
Non-uniform ground is a pain for two reasons. First, it creates false reflections, and secondly because GPR measures depth as a function of the time for the echo to return, the vertical scale goes to hell in a handbasket. You've no idea where things are in relation to each other, because the GPR will assume a constant speed for the radar signal, and that assumption - in such cases - is going to be false.
Water of any kind dissipates the signal, so you get less resolution, a shorter range, and all kinds of noise in the signal as the pulses could be travelling along any possible path. Not sure if there's any way you could get a naturally-occuring diffraction grating, total internal reflection, or similar, but there probably are. These would also totally fool a GPR.
GPR is also horrible to interpret. Anyone who is interested in archaeological GPR, I do have a bunch of GPR datafiles (raw and processed) which I can e-mail to anyone interested. It'll give you a good idea of just how wretched the damn thing is.
Today, the popular view is that Linux is highly stable and can be run out of the box by a WalMart customer, but I just had to reformat after Fedora Core 6 pre barfed after a yum update fried X totally and irretrievably. (And before someone says anything, yes I'm fully aware that running alpha-grade software is risky. That's half the fun. I burn out machines on a regular basis. It's just a little disconcerting when a highly-stable industry-standard package throws up over the disk and video card.)
On that basis, I'll ask my question: Users are forever complaining about a lack of drivers, but the drivers they are often presented with are a very small subset of the Open Source drivers that exist. Is this a problem Fedora will be addressing, or will it be largely left to such drivers being absorbed into the mainstream kernel?
Hell, in the days of yore, when the IBCS module was being maintained, you could even run binaries from SCO UnixWare or Sun Solaris within Linux at native performance. How different do you need to get?
If you want to be really fancy, then any program with a sufficiently comprehensive symbol table aught to be "relinkable". For any given tuple (called function, desired library set, available library set), it will often be possible to return a fresh pointer to an existing library which will handle the call in the manner expected, and optionally a tiny conversion routine that handles differences in the API or ABI to conceal the difference. That's just a matter of building a comprehensive database of what libraries are out there and what can be used as a drop-in replacement (or at least abused as one with the right glue layer).
A universal package manager would be good. RPM is unstable when handling thousands of transactions - a not uncommon sight if you're using the development files and wait more than a day or two between yum updates - so the sooner Fedora/Red Hat dump it and write something more scalable, the better. I've been tempted to write something that's interoperable with rpm and apt, and that meets my requirements for better scalability and improved robustness, but time is not something I've had a vast amount of, of late.
Another problem is in some of the configuration stuff. Gentoo and Fedora have almost nothing in common in the
Finally, there is the problem of namespace conflicts with programs. Not merely different versions of the same program, but totally different programs with the same name. To solve this, the binary directories */bin and */sbin need to be virtualized as well. Have the real programs in unique locations, then have the specific combination of desired applications mapped onto that user's view of the standard binary directories. Different users could, therefore, be running totally different programs by calling the same application name.
(This also improves security, as it means you can't merely "not run" programs for which you have no permission, they don't even exist in your userspace. It could re-use a lot of the ideas in SELinux and eliminate some of the shortcomings of it - such that it would be possible to get webservers or other complex configurations running properly, because you could visually see what is reachable from what.)
So, all in all, there's plenty of room for improvement in compatibility and there has been some backsliding at times. This isn't necessary and could be corrected at any time.
(This is why poor people are generally screwed with sales taxes, as they spend a much higher percentage of their income just to keep going, and therefore get taxed more heavily. Rich people generally get screwed with State taxes, as they get taxed even on the income they're saving. Being your typical left-leaning Brit, I tend to take the line that the rich can afford to get screwed a little.)
However, we've only factored in the costs here. What about the benefits? A State that has more money to play with can have better roads (so you spend LESS on expensive car maintenance), can have better schools and Universities (so you're not limited to sending the kids to some fundamentalist haven so that they're at least capable of adding correctly), can have decent public transport (saving you gas money and usually time), and can have some excellent public museums, public art galleries, etc, which gets you direct access to stuff only the world's megarich can even think of affording.
So, if taxes are spent by Government wisely (yeah, like that happens!), the net cost can end up being lower than the hidden and not-so-hidden costs of living in areas with lower taxes or no taxes at all. This does, however, require wisdom. High taxes that don't benefit anyone at all are simply a drain on the pocket.
(And, yes, I deliberately said anyone, not just you. If high taxes produce a good schooling environment, then it doesn't matter if it doesn't benefit you directly. Better educated kids will produce a better quality workforce. What does it matter if you're a richly-paid genius, if the rest of the company can't figure its way out of a paper bag and goes under? The brighter your co-workers, the more profitable the company and so the better your job security. Oh, and the better your pay.)
So, to correctly factor in the REAL cost of the taxes, you must factor in the real cost of what those taxes buy you, both directly and indirectly. Let's say your income is I, the total direct tax over the same time is T1, the total average indirect tax is T2, the total direct benefit to you because of superior infrastructure and/or superior facilities is B1, and the total indirect benefit is B2, then your actual salary S is calculated as follows: S = I + B1 + B2 - T1 - T2.
B1 and T2 are extremely hard to calculate. B2 is virtually impossible to know. However, without knowing those values, you cannot say how the real cost of living compares to your effective salary.
Is this the end of it? Uhh, no. Each State, each county, has an effective rate of inflation which is dictated by the change in the price of those goods that have a floating value across the country. Gasoline is an example of something subject to local inflation. When businesses move in, there are more people with disposable income, so prices will rise to what the market will bear and local inflation goes up. When businesses move out, there are fewer people buying, so to conserve profit margins prices must rise and local inflation goes up.
This is why you do not want to be in an area that is undergoing a boom OR a bust. It's expensive. You want an area that has a fairly stable economy and is growing at a fairly steady, gentle pace. How steady and gentle? Well, it needs to grow faster than the population, but not by very much.
You also want an area with superb social welfare. No, I don't mean people get paid for doing nothing - that's what politicians are for. I mean you want to ensure that those who are unemployed are retrained and th
Never found Peter Norton's books to be that good, though. There were many excellent books on the PC internals, detailing the interrupts, the INT 21 functions, how to directly program the video card, "undocumented" Intel CPU instructions, etc. Norton's books were not amongst those I regard as the gems of that era.
Maybe this is a Blashsack, or a Slabshack ("Love Shack" for big iron). Now, if it's both a Slashback and a Backslash, then it could be a back-to-back slash-slash. Which, given the comments aimed pointedly at Microsoft, would make sense.
In this scenario, the Oracle people get to have an Oracle module that is guaranteed to run within the application for a very reasonable period of time. Well, up until the time that so many functions have changed that there are no salvagable functions in the Oracle module. But that's not going to happen overnight and it gives the Oracle afficados time to reconsider what support they want to give.
On the other hand, because the Oracle code is extracted, the primary developers don't need to give a damn if they break anything in the Oracle code. They don't have to fix the Oracle code and as the code is now compiled seperately, it doesn't break the builds.
On the third hand, by exposing an API via a pluggable module, other people who might well be interested in providing such modules would be able to do so without ripping the code apart and making major changes. Ingres would be a reasonable candidate, now that it is Open Source, as it is pretty beefy. And IBM seem to be making some serious inroads with Linux versions of DB/2 and Informix.
It is a grave error to assume everything in computing is either/or. That may be true of bits (except when they're fuzzy), but it hasn't been true of programs for some considerable time.
This should read:
Anyone who could design a VIC 20 has to either be criminally insane or paid off. And why DID the Commodore 64 disk drives work at about a tenth the speed of the 4040 and 8080 drives they were selling 5-7 years earlier? If that wasn't proof enough of Evil Intent, then answer me this - why has the PIC Chip never been added to the VICE emulator? I think it's because Bill Gates sacrificed a goatse and placed an Evil Curse on Commodore.
The best solution I can think of with electronic votes is to use some form of public key encryption with an authenticating block encryption mode. One half of the keys would be provided on a TOTALLY random basis along with the voter card. The decrypting keys would be kept in a tamper-proof computer that is designed to be write-only with the sole exception of the count at the end.
The voter comes along and enters their vote. The vote is encrypted with their key. As nobody (at this point) has the decryption key, or another copy of the encryption key, it is impossible for the vote to be altered. A copy could then be printed out for backup purposes and placed in a regular ballot box.
So far, doesn't sound much different from anyone else's electronic system, right? Except that we're not tallying yet. Well, read on. The votes are collected in their encrypted form and kept in some secure system OTHER than the one doing the counting. They are then fed into the counting machine. The counting machine knows what keys are allocated to a given precinct, so tests each potential key against each vote from that precinct. Once a key is used, it is deleted.
If a vote has no valid decryption key, the vote is invalid and is rejected. This will include duplicate votes (the key has been deleted) as well as votes for which no key has ever existed. The (still encrypted) vote would then be output as a reject.
The votes are kept seperate and tallied. The output will be the tallies, the votes that comprise that tally, and the grand totals involved. The grand totals should be the same, provided the counters are working correctly.
Now, what basic checks can we perform, using this sort of system? First, let us say there is a recount. The recount would be of the votes placed into the ballot box. There should be exactly one such ballot box vote that is not spoiled or a duplicate for each and every valid vote printed by the tallying machine and the totals should match exactly. There should ALSO be exactly one spoiled or bogus ballot paper for every rejected vote, although further comparison would be impossible as the rejects are encrypted and the spoiled ballots aren't.
Ok, how do we know the software is valid? Well, we know that the vote that the user put in the ballot box matched the one they entered in the computer, and we know that there's a 1:1 between the results in the box and the results in the computer, so we know that the computer has to be producing valid data.
Then what happens when there is a discrepency? With two sources, how do we know which is the one that has the valid data and which does not? The votes are encrypted in a way that is essentially tamper-proof, the ballot boxes are not. The only way to resolve this is to make the ballot boxes reasonably tamper-proof. I'd suggest a wooden or metallic ballot box that has a lid that can be attached with spring-loaded bolts, where the only way to open the box is to cut it open. You want unique non-sequential numbers on RFID tags, to ensure that boxes don't go missing anyway.
After all that, you will have a more honest system than you do at the moment. You might even discourage those who would cheat the system from even being a part of it. However, ultimately, politicians are professional liars and the extremely rich will always be power brokers. The best system in the world can't clean up the human race, it can only clean up one very small part of the feedback loop. Which is better than nothing, but should not be assumed to be everything.
It would seem, at first glance, that this tagging mechanism would be ideal for treatments that can be finely targetted onto that mechanism, but that it isn't going to be nearly so effective as simply a means of weakening what's left for the chemo to get.
However, this is so blindingly obvious that, since it wasn't mentioned, there's an advantage to chemo -or- a disadvantage to my suggestion that I'm missing and is amazingly obvious to these guys. Any idea on what that might be?
You can buy a single prop aircraft for almost a third of the price, a Tiger Moth for under half, or even a YAK
There was a story some time back about a button on the front that did exactly the same thing.
Let's look at these in turn. First, OpenGL. OpenGL is a nice, popular 3D graphics format. Software generates the OpenGL instructions, which get turned into identical but probably different OpenGL instructions (on a 1:1 basis) in some OS library, which then gets translated into identical but almost certainly different OpenGL instructions (still on a 1:1 basis) by the graphics driver, which hands the data to the card. If the communications is not wrappered, then the OpenGL instructions sent over the bus will need to be converted into yet another different but identical set of OpenGL instructions that the GPU can actually process. There is absolutely no way on Earth that this can be an efficient mechanism. A single standard representation would be infinitely superior.
Renderman/NURBS. This is the format used by tools such as BMRT, Pixar's Renderman software, Rhino 3D, etc. We're talking ultra high-end 3D graphics with shaders to die for. In terms of CPU and I/O requirements, it's not cheap to get this stuff done at any decent level of performance. The CPU part isn't that important, as the GPU won't be able to do any better. What you will do, however, is eliminate the I/O of rendered data over a slow bus. Sending a shader or an image over would be painless, and graphics is I/O-bound, not CPU-bound.
Loadable Microcode and Firmware. These are NOT the same thing, as I've already said. But what they do allow you to do is more effectively divide the driver between what is on the CPU and what is on the GPU. You can run anything in firmware, provided the GPU has the instruction set for it. It also pr
Sarcasm in British comedy is about as useful in comedy as sticking a pencil up your nose and saying "Wibble". For example, Sir Humphrey Applebey wouldn't be caught dead being sarcastic - unless there was an excellent chance of manipulating Jim Hacker as a result. That leaves Tim Brooke-Taylor, Bill Oddie and Graeme Garden, but they're a real bunch of goodies. Oh, I forgot Kenny Everett, but then it's definitely a rap.
MECOs are constantly collapsing, so the laws of thermodynamics which compell Black Holes to evaporate do not necessarily apply to MECOs in the same way, without any requirement for evaporation of mass/energy or of information. (This is because they're not in a pseudo-stable state as they are.) It would seem to follow that MECOs must exhibit different characteristics at this level.
Even if we were to say that the two were directly comparable, MECOs would be closer to a naked singularity (ie: a Black Hole without an event horizon) and almost certainly can only be spheres or related shapes. There would be nothing comparable to a Kerr Ring singularity in nature, although if you were to produce a MECO inside of a torus, it would have no way of collapsing beyond the torroidal shape, as the quantum foam would hold it apart at a certain point.
This also solves another gremlin. As there is no "time zero", there is no moment of creation. This is what concerned Professor Hawking, when he was asked by the Pope not to delve into the creation of the Universe - he'd just proved that there is no moment of creation and therefore no need of a creator.
MECOs are suspended within an eruption of quantum foam, if I understand things correctly. This does relate to the early Universe, because this eruption is closely related to cosmological Inflation, only in the other direction. If MECOs exist, it means that there is a strict division between a pre-Inflationary system and a post-Inflationary system, that you can move in one direction only between these states. This would make accelerators much more interesting, as they would then be strictly prohibited from recreating conditions that existed in the pre-Inflationary universe. As soon as you get to the borders, MECO theory suggests, the pressure from the virtual particles will always keep the system from going further.
This makes the theory very testable in the laboratory. Simply push the system towards very high energy densities. If the MECO theory is correct, your ability to do so will fall off and be asymtotic to the energy density required for inflation. (Thus, although the conditions are finite, there is some sort of feedback that makes the input required to actually achieve those conditions infinite.)
If experimental science fails to yield a force with the required properties, then MECOs probably do not exist. If experimental science always yields such a force, then black holes probably do not exist.
...that an eternally collapsing MECO being suspended on an eruption of quantum foam is a hearth god looking for the fire? (Shobogenzo, introduction)
These tools map attributes in records to other attributes in other records. They're designed to then turn these maps into SQL code, but that part isn't important here. What is important is that you can create a full relationship mapping between entities. If you then treat the direction of the relationship as showing the dependency, you can map all the dependencies in the system.
Managers like diagrams to be of a format that are familiar to them, so anything that is "better" from a technical standpoint but "less familiar" to managers from an experience standpoint is, in fact, not as good of a solution.