I'd probably add the use of Tripwire or something similar to detect malware or other evidence of intrusions, and disable all unused services and processes. This will improve performance, reduce memory footprint, increase stability, increase security and mow the lawn. If you're into kernel building, remove unnecessary kernel options and specify your hardware rather than using generic options. If network loads may be a problem, you might want to investigate patches like Web100, if it'll work with the distro version of the kernel. Swap space should be 2.5-3 times the size of RAM for a server and/tmp should probably be on an isolated partition. I'd probably put/var/log on an isolated partition too. If you're paranoid, put a proxy server in the company's DMZ network (there is a DMZ network, right?) and only permit connections to (and from) the server via the proxy. Then put a honeypot on the proxy that traps all services and IP ports you've disabled on the server.
Taxpayers aren't necessarily good at taking a long-term view. Yes, the investment should benefit the taxpayer (investing in infrastructure, decent education - things that build up the society over the long-term) but should probably not go into the taxpayer's pockets. The recent US "tax refund" was no such thing, since everyone knew damn well the money would end up in the hands of merchants almost immediately. Most likely, the populace got nothing of any worth out of the deal - the amounts involved were far too trivial and Americans work on a debt culture not a saving culture. Pure bread and circuses. All illusions to make people feel better, without giving them anything worth feeling better about.
On the other hand, the sum total of cash was quite considerable. Had the same total amount been spent on, oh, debugging the US educational system, or getting Amtrak some more rolling stock, people may not have experienced the same peak level of happiness, but a whole lot more people would have had actual value added to their lives.
I know, I make a lousy American. Blame the British in me. But blame or credit, it is indisputable that Governments have the resources to invest in things that will have a longer-term benefit to many, individuals (barring the super-rich) barely have the resources to invest in things that will have any meaningful (ie: not bread and circuses) impact on even themselves. They certainly can't affect anything beyond the tiniest of microcosms in the macrocosm of an entire nation. That's why, tens of thousands of years ago, they figured out how to organize collectively to do such stuff.
Investments doesn't mean or imply liquid capital they can actually spend. In fact, I'd argue that sane Government should have almost all of its money tied and locked-up in investments of one kind or another, as Governments can afford to invest on a timeframe and magnitude that corporations do not (and in the modern world probably cannot). I wouldn't call it "hidden" or even inappropriate. Paying lawyers on matters that should be clear eminent domain is, however, highly inappropriate. Lawyers don't get the work done and are only good for stalling. Sure, the local authorities might win a year or two down the road. That's a two year delay in productive work and a two year delay in any small business or home business (Red Hat started as a home business) getting decent fiber access. Two years in which taxpayer's money does nothing but make a few fat cats fatter and a few entrepreneurs thinner. THAT is NOT what Government is for.
In this case, you are not only correct in the way intended but also in the way the typo implies (unregulated corporations act like the old-style feudal Lords in their Manors).
I have the excuse I wrote part of the code for one of the LHC's predecessors. In this case, the grid software is very generic. ShibGrid doesn't care if it's securing a particle accelerator or a wide-area distributed MMORPG, but I bet you anything that if WoW was a part of the Grid Gaming consortium, ShibGrid would be more audited than OpenBSD by more anal coders than Theo ever thought of being. There may be only one LHC, but anybody can run a Globus module through a static code checker and fix "obvious" coding errors.
True, the LHC has limited staff and can't check every patch people send to them. But the same problem is faced by OpenBSD, Linux, X.Org, the GCC developers, and a thousand and one other mega-coding projects. They seem to solve the problem without too much strain, so what do they do that the LHC guys aren't? I don't have to be a genius to solve the LHC's security issues, I merely have to know where the geniuses are and see what they do different.
Also true, the size of the code base makes the idea of bug-free code laughable. The middleware alone is HUGE. However, that's deceptive. There's a fascinating paper on Trusted Software. Not "trustworthy", "Trusted". As in A1 Orange Book Trusted. The paper basically states that buggy software is not the issue. So long as you have a small, tightly-written security kernel within key components, where that security kernel can be proven correct, bugs elsewhere can never pose a security risk. They can do lots of other nasty things, but they can never compromise the security of the system.
As the paper in question (which I've linked to previously, on the issue of security) is written by one of those aforementioned geniuses, and as this is something those geniuses do differently, it follows that this is a factor in what makes the difference between secure software and insecure software. MPI, a common message-passing system, usually uses RSH to start applications across a cluster or grid. Since MPI is generally not going to have any means of providing passwords, this means you're looking at.rhosts files, which means you've a wide-open security hole right there. And, yes, having worked at such facilities I can tell you that they often don't use SSH or a Kerberos-hardened RSH, just the vanilla form that no sane person would use in a million years. (This goes to show that, yes, scientists truly are mad.)
Open Source should have meant that a few thousand eyeballs scoured that code over the years between being written and being used. However, those few thousand eyeballs can't see code that nobody is told about. I discovered the source to the various projects by scouring CERN's network and digging deep through nests of links and obscure references. The Yahoo group for discussing grid computing has barely been used in the past year, and none of it for this. If there are any records for these projects on Freshmeat, it's because I added them. The project summaries are vague, where they're given at all. This simply isn't an acceptable way of distributing information. Their brief notices on minor pages away from the real information are about as useful as a house demolition order being posted in a basement with no stairs or lights.
If you think there's bugs in the security, you are able to fix it. That's the brilliant thing about Open Source. We don't have to just complain, we can actually send them the necessary patches. Now, the lack of publicity regarding the source is a concern. If Arthur Dent found getting the demolition plans for his house was bad, the notices regarding what software is available and where from are even worse.
They've had TWENTY YEARS to circulate the designs, prototypes and implementations. Yes, there are fewer software engineers interested in high-energy physics than there are software engineers into bomb-proofing OpenBSD, but if you don't tell any of them what's out there, it wouldn't matter if it was one coder or a million. You can't fix what you don't know exists to fix.
These control systems are mission-critical. The particle stream can't do "extensive" damage, but it can write-off the magnets, and those are multi-million-dollar toys. It could also shut down the accelerator for years, if a hacker goes drilling holes in the mountainside. (The hole would be small, but politicians aren't interested in paying for high-energy landscaping, and CERN isn't infinitely rich.)
Ignoring for a moment that the front-line defenses should have kept intruders out (though I'll bet that they're not using IPSec VPNs, they've got firewall holes for rsh and rlogin, and use.hosts files everywhere), the bulk of grid-enabled software these days can use Kerberos V or SAML 2.0 for security. They're probably not doing anything remotely that's time-critical so an in-line active intrusion detection and countermeasures system (there's plenty of them) could have been installed. Those cost a damn sight less than the detector array.
Since they were worried about someone getting onto an internal network, they must also believe that shell access was possible, so this isn't simply a matter of someone being able to ping a machine or SNMP query a server. This was a case of CERN violating some very serious standard protocols for ensuring code safety and system safety.
The "open secret" mentality, though, is probably the most dangerous part, though. By making the source available but not telling anyone, it is most available to those of malicious intent. Obscurity is not security, guys! That includes obscuring your announcements, it's not confined to merely obscuring the code itself. If you're going to release source (which is a Good Thing), you want to broadcast that fact to as WIDE an audience as possible. (In fact, if it's network-related, WIDE would be a good place to start announcing.) Get ALL the eyes you possibly can onto that code, for a comprehensive, rigorous audit. And if you're worried you can't get enough eyes, use static code checkers and test harnesses. Bet you anything none of the coders for the LHC have been using such resources beyond a superficial level, if at all.
All in all, I am impressed by the fact that the code is out there, and can be fixed, but I am NOT impressed with the secrecy mentality that created this utterly unnecessary security fiasco. If I'd wanted my tax money to go into security holes, I'd have paid Group Four to build the LHC. I want INTELLIGENT people to be doing the work.
I'd not design buildings using a stack-of-boxes template. It's not particularly strong, although it is incredibly cheap. I'd be looking more to the designs nature often uses for very strong designs - spirals, helical designs, backbones, etc. A central "backbone" (based on a spiral column) that is large enough to support the weight of the building hanging off it would seem to have several benefits:
a) If supports melt, the risk of a cascading failure is greatly reduced - and even if that did happen, such a collapse should be greatly slowed down.
b) A spiral staircase is self-supporting. Ideally, the blocks would also be locked in place by design, so that blockage of the escape route is much less likely.
c) You can add more limited "backbone" spiral columns in the design, to provide additional structural support. Ideally, you have such spiral columns at different places on different floors, dispersing any collapse and preventing a cascading effect.
It would also have three disadvantages:
a) Developers throughout the US would go bankrupt (actually, would that be a disadvantage...?)
b) Floorspace becomes horribly expensive and would be of indeterminate, inconsistant shape
c) The entire USian mindset of uniformity and conformity in business would be utterly destroyed, causing widespread panic amongst interior decorators and shoppers everywhere
Locating such a system logically: You do a sweep using OS fingerprinting to look for known router fingerprints on an unknown IP. You do a BING (bandwidth ping) or PCHAR (open-source Pathchar) and look for a segment that has LAN-like bandwidth characteristics but "should" be on a WAN segment, or WAN-like bandwidth characteristics but "should" be on an LAN.
Locating such a device physically: You are best off finding the "last mile" drop-point from the ISP (they will have it on record) and then trace back from the drop-point. You CAN use nanosecond clocks and use timings to determine the cable distance from the drop-point to the device, but that only gives you a maximum radius to search, as you don't know how coiled the cable is.
Personally, I'd love it if there was a facility somewhere with a small army of software engineers whose jobs were to formally verify (where possible) or unit-test (in all other cases) every function of every major project in Linux, and to fix those functions to operate within specification. It wouldn't fix all problems, integration creates as many bugs as the individual units, but if you could halve the number of bugs, the primary developers could focus on architectural defects rather than implementational defects.
What would it take to do this? For just the Linux kernel, GCC and GLibc suites and X11, you'd need about 20,000 full-time mathematically-oriented software engineers, to be able to get the code as clean as possible and keep it that way, within a year. If you rolled them over onto other software, you could have Gnome, KDE and ROX pretty much sewn up the following year, maybe two.
So, we can get Linux reasonably (not perfectly, just reasonably) bug-free, for about 6 billion dollars. Personally, I would regard that as an extremely worthwhile investment. The DoD has done studies that have shown troops have illicitly spent about that on women of ill repute using Government credit cards, in the past 15 years. (That has resulted in some going to military prison, but I doubt that got any of the money back.) A national bug-hunt might not be as much "fun", but a lot more people will enjoy the results.
This, however, is somewhat unlikely. Equally unlikely, however, is the ALSA module ever getting many problems ironed out. The range of hardware is too great, the information available is too limited, the number of developers is too small, the complexity of ALSA is too vast and the spaghetti monster of a configuration module is too convoluted.
ALSA is probably unmaintainable in the long-term and does not appear sustainable in the short-term. It's good, but it's just not providing the resources people need. If it was, you'd not need heavy-weight pluggable supercharged V10 engines just to run the mixing desks.
Well, no guarantee as to when I'll get round to it, but I'm thinking of doing exactly that, putting them into.deb packages built for Ubuntu and seeing what happens.
...but it certainly is done. The projects I've found that do much the same thing are NOT being run by kids in their basement, but serious, large-scale research centers that need to do wide-area RAID.
CERN (and their collaborators) use fully Open Source grid software. I've added a few of the more interesting projects to Freshmeat. Before we get all cynical, let's exploit the hell out of what they've made available.
A friend of mine routinely has 400+ tabs open. Assigning them randomly every 20 is going to make the internal logic look like spaghetti. There are extremely few browsers capable of users with such a browsing pattern and if they switch to process tables for tabs, that number is rapidly going to fall. Given my own browsing habits, if I had a monitor large enough to make navigation practical, I'd probably be using somewhere into the hundreds of tabs, and frankly I don't want Linux' process tables to only show browser entries, obscuring everything else. I happen to like "top" showing me ONE entry for the browser. It means there is room for other stuff.
The Open Library project has barely any users, let alone book contributors or code contributors, and that isn't even restricted to something as special-interest as textbooks. If they can't get the open model to work for the written word, I doubt Virginia (not known as a bastion of openness or science) is going to have any impact worthy of the name. I hope I'm wrong, but I won't hold my breath.
Now these guys have an idea for openness that looks far more interesting. Grids of Beowulfs of games. I can see that succeeding. (Can you imagine a MMORG that's also in the Top500 list? Or a planet-wide FPS? Can you imagine a LAN Party where the "server" is spread over the entire LAN - all that extra power available for tougher, more sophisticated games?) I'm willing to bet that more students at more Universities would be willing to be involved in a world-wide game engine than any number of textbook projects.
Bear in mind that Y chromosomes are actually defective X chromosomes. From a purely mechanical sense, this means the system is not functioning according to what might be called "specification" (no implication of a specifier intended). Nonetheless, this defect is extremely valuable.
Prions alter nearby proteins to the same set of folds, giving you the ability to build a consistant structure out of a random set of proteins. It is possible that early pre-life exploited this, as a tesselating structure has a lot of advantages. True cells may therefore be a defective version of such a pre-cellular structure.
(Experiments on creating life from scratch have been based on using minerals like sulpher and molecules like fatty acids, and that may well have been the absolutely first step, but a spongy prion structure seems a logical next step, as DNA/RNA can create proteins not fatty acids, which means you've support for growth, and a sponge structure is good for trapping the raw materials.)
Evolution NEVER works in giant leaps. That is not how systems change. Ergo, as viruses are fairly complex molecules that can perform assisted self-replication, there must be simpler systems that perform even more primitive forms of self-replication, stretching right the way back to organic building-block material that cannot self-replicate at all. It seems to me that prions - which are organic molecules with crystal-like properties - are a necessary and fundamental step from "inert" proteins that sit there and do nothing at all. They are not the only step. DNA and RNA must have evolved independently and externally of the "cell" structure we see today. But prions and their ability to alter structure around them would seem to be absolutely a fundamental, key step to moving towards a cell body where the component proteins must tessellate. Prions are geometry-defining proteins and must have played some role in this process.
Does that make prions "living"? Maybe. I think that no matter how you define "life", there will be a grey area between living and non-living. The spectrum is near-enough continuous and therefore wherever you draw the line, the step immediately over that line will not be obviously distinct.
Except for extremely generalized categorization, I do not think the concepts of "living" and "non-living" will hold out for much longer. They are not scientifically meaningful, offer up no verifiable hypothesis independent of the data used to draw up the definitions, and are essentially a religious viewpoint that has been extended into a legal framework. But to science, these terms mean nothing. Only life over a certain level of complexity can alter its own environment as per Lovelock's Gaia Hypothesis, which is the most generic and universal of all biosystem models. Primitive first-step free-floating DNA couldn't alter conditions as he describes, that doesn't become possible until after the first true cell, which post-dates the origin of measurable life by perhaps quarter of a billion years, and therefore the true origin of life by longer still.
This reminds me of the argument of whether a machine can think, with some arguing that of course machines cannot think, they do not have an organic brain. That may be a requirement for a specific class of thinking (and that's unproven), but clearly if you go back far enough, there is some precursor to that specific type of thinking that does NOT have such a requirement and is computable. But is it then still thinking? I say the question is flawed and assumes an arbitrary dividing line exists that has a scientifically valid definition and objective purpose. No such line exists, except in the minds of those who believe that mind is a spiritual thing that should not be sullied with the physical.
Many lines are important. But many are not, and interfere with critical thinking. If you do not wish your thoughts turned into a self-inflicted slurry, banish those lines from your mental processes. Only accept divisions that serve a useful purpose in a scientific sense. All others are illusions, generated by an irrational need to be "better than" something else. If you have that great a need to be better than a rock, you will find greater benefit from re-examining your needs than from labeling the rock.
Slashdot Mirror
I'd probably add the use of Tripwire or something similar to detect malware or other evidence of intrusions, and disable all unused services and processes. This will improve performance, reduce memory footprint, increase stability, increase security and mow the lawn. If you're into kernel building, remove unnecessary kernel options and specify your hardware rather than using generic options. If network loads may be a problem, you might want to investigate patches like Web100, if it'll work with the distro version of the kernel. Swap space should be 2.5-3 times the size of RAM for a server and /tmp should probably be on an isolated partition. I'd probably put /var/log on an isolated partition too. If you're paranoid, put a proxy server in the company's DMZ network (there is a DMZ network, right?) and only permit connections to (and from) the server via the proxy. Then put a honeypot on the proxy that traps all services and IP ports you've disabled on the server.
Taxpayers aren't necessarily good at taking a long-term view. Yes, the investment should benefit the taxpayer (investing in infrastructure, decent education - things that build up the society over the long-term) but should probably not go into the taxpayer's pockets. The recent US "tax refund" was no such thing, since everyone knew damn well the money would end up in the hands of merchants almost immediately. Most likely, the populace got nothing of any worth out of the deal - the amounts involved were far too trivial and Americans work on a debt culture not a saving culture. Pure bread and circuses. All illusions to make people feel better, without giving them anything worth feeling better about.
On the other hand, the sum total of cash was quite considerable. Had the same total amount been spent on, oh, debugging the US educational system, or getting Amtrak some more rolling stock, people may not have experienced the same peak level of happiness, but a whole lot more people would have had actual value added to their lives.
I know, I make a lousy American. Blame the British in me. But blame or credit, it is indisputable that Governments have the resources to invest in things that will have a longer-term benefit to many, individuals (barring the super-rich) barely have the resources to invest in things that will have any meaningful (ie: not bread and circuses) impact on even themselves. They certainly can't affect anything beyond the tiniest of microcosms in the macrocosm of an entire nation. That's why, tens of thousands of years ago, they figured out how to organize collectively to do such stuff.
Investments doesn't mean or imply liquid capital they can actually spend. In fact, I'd argue that sane Government should have almost all of its money tied and locked-up in investments of one kind or another, as Governments can afford to invest on a timeframe and magnitude that corporations do not (and in the modern world probably cannot). I wouldn't call it "hidden" or even inappropriate. Paying lawyers on matters that should be clear eminent domain is, however, highly inappropriate. Lawyers don't get the work done and are only good for stalling. Sure, the local authorities might win a year or two down the road. That's a two year delay in productive work and a two year delay in any small business or home business (Red Hat started as a home business) getting decent fiber access. Two years in which taxpayer's money does nothing but make a few fat cats fatter and a few entrepreneurs thinner. THAT is NOT what Government is for.
In this case, you are not only correct in the way intended but also in the way the typo implies (unregulated corporations act like the old-style feudal Lords in their Manors).
CERN use OS/X?
I have the excuse I wrote part of the code for one of the LHC's predecessors. In this case, the grid software is very generic. ShibGrid doesn't care if it's securing a particle accelerator or a wide-area distributed MMORPG, but I bet you anything that if WoW was a part of the Grid Gaming consortium, ShibGrid would be more audited than OpenBSD by more anal coders than Theo ever thought of being. There may be only one LHC, but anybody can run a Globus module through a static code checker and fix "obvious" coding errors.
True, the LHC has limited staff and can't check every patch people send to them. But the same problem is faced by OpenBSD, Linux, X.Org, the GCC developers, and a thousand and one other mega-coding projects. They seem to solve the problem without too much strain, so what do they do that the LHC guys aren't? I don't have to be a genius to solve the LHC's security issues, I merely have to know where the geniuses are and see what they do different.
Also true, the size of the code base makes the idea of bug-free code laughable. The middleware alone is HUGE. However, that's deceptive. There's a fascinating paper on Trusted Software. Not "trustworthy", "Trusted". As in A1 Orange Book Trusted. The paper basically states that buggy software is not the issue. So long as you have a small, tightly-written security kernel within key components, where that security kernel can be proven correct, bugs elsewhere can never pose a security risk. They can do lots of other nasty things, but they can never compromise the security of the system.
As the paper in question (which I've linked to previously, on the issue of security) is written by one of those aforementioned geniuses, and as this is something those geniuses do differently, it follows that this is a factor in what makes the difference between secure software and insecure software. MPI, a common message-passing system, usually uses RSH to start applications across a cluster or grid. Since MPI is generally not going to have any means of providing passwords, this means you're looking at .rhosts files, which means you've a wide-open security hole right there. And, yes, having worked at such facilities I can tell you that they often don't use SSH or a Kerberos-hardened RSH, just the vanilla form that no sane person would use in a million years. (This goes to show that, yes, scientists truly are mad.)
What you need is the 100 tesla refrigerator magnet for the 12,500 tonne refrigerator. (It'd reduce car pollution within a ten mile radius...)
Open Source should have meant that a few thousand eyeballs scoured that code over the years between being written and being used. However, those few thousand eyeballs can't see code that nobody is told about. I discovered the source to the various projects by scouring CERN's network and digging deep through nests of links and obscure references. The Yahoo group for discussing grid computing has barely been used in the past year, and none of it for this. If there are any records for these projects on Freshmeat, it's because I added them. The project summaries are vague, where they're given at all. This simply isn't an acceptable way of distributing information. Their brief notices on minor pages away from the real information are about as useful as a house demolition order being posted in a basement with no stairs or lights.
If you think there's bugs in the security, you are able to fix it. That's the brilliant thing about Open Source. We don't have to just complain, we can actually send them the necessary patches. Now, the lack of publicity regarding the source is a concern. If Arthur Dent found getting the demolition plans for his house was bad, the notices regarding what software is available and where from are even worse.
They've had TWENTY YEARS to circulate the designs, prototypes and implementations. Yes, there are fewer software engineers interested in high-energy physics than there are software engineers into bomb-proofing OpenBSD, but if you don't tell any of them what's out there, it wouldn't matter if it was one coder or a million. You can't fix what you don't know exists to fix.
These control systems are mission-critical. The particle stream can't do "extensive" damage, but it can write-off the magnets, and those are multi-million-dollar toys. It could also shut down the accelerator for years, if a hacker goes drilling holes in the mountainside. (The hole would be small, but politicians aren't interested in paying for high-energy landscaping, and CERN isn't infinitely rich.)
Ignoring for a moment that the front-line defenses should have kept intruders out (though I'll bet that they're not using IPSec VPNs, they've got firewall holes for rsh and rlogin, and use .hosts files everywhere), the bulk of grid-enabled software these days can use Kerberos V or SAML 2.0 for security. They're probably not doing anything remotely that's time-critical so an in-line active intrusion detection and countermeasures system (there's plenty of them) could have been installed. Those cost a damn sight less than the detector array.
Since they were worried about someone getting onto an internal network, they must also believe that shell access was possible, so this isn't simply a matter of someone being able to ping a machine or SNMP query a server. This was a case of CERN violating some very serious standard protocols for ensuring code safety and system safety.
The "open secret" mentality, though, is probably the most dangerous part, though. By making the source available but not telling anyone, it is most available to those of malicious intent. Obscurity is not security, guys! That includes obscuring your announcements, it's not confined to merely obscuring the code itself. If you're going to release source (which is a Good Thing), you want to broadcast that fact to as WIDE an audience as possible. (In fact, if it's network-related, WIDE would be a good place to start announcing.) Get ALL the eyes you possibly can onto that code, for a comprehensive, rigorous audit. And if you're worried you can't get enough eyes, use static code checkers and test harnesses. Bet you anything none of the coders for the LHC have been using such resources beyond a superficial level, if at all.
All in all, I am impressed by the fact that the code is out there, and can be fixed, but I am NOT impressed with the secrecy mentality that created this utterly unnecessary security fiasco. If I'd wanted my tax money to go into security holes, I'd have paid Group Four to build the LHC. I want INTELLIGENT people to be doing the work.
I'd not design buildings using a stack-of-boxes template. It's not particularly strong, although it is incredibly cheap. I'd be looking more to the designs nature often uses for very strong designs - spirals, helical designs, backbones, etc. A central "backbone" (based on a spiral column) that is large enough to support the weight of the building hanging off it would seem to have several benefits:
a) If supports melt, the risk of a cascading failure is greatly reduced - and even if that did happen, such a collapse should be greatly slowed down.
b) A spiral staircase is self-supporting. Ideally, the blocks would also be locked in place by design, so that blockage of the escape route is much less likely.
c) You can add more limited "backbone" spiral columns in the design, to provide additional structural support. Ideally, you have such spiral columns at different places on different floors, dispersing any collapse and preventing a cascading effect.
It would also have three disadvantages:
a) Developers throughout the US would go bankrupt (actually, would that be a disadvantage...?)
b) Floorspace becomes horribly expensive and would be of indeterminate, inconsistant shape
c) The entire USian mindset of uniformity and conformity in business would be utterly destroyed, causing widespread panic amongst interior decorators and shoppers everywhere
Locating such a system logically: You do a sweep using OS fingerprinting to look for known router fingerprints on an unknown IP. You do a BING (bandwidth ping) or PCHAR (open-source Pathchar) and look for a segment that has LAN-like bandwidth characteristics but "should" be on a WAN segment, or WAN-like bandwidth characteristics but "should" be on an LAN.
Locating such a device physically: You are best off finding the "last mile" drop-point from the ISP (they will have it on record) and then trace back from the drop-point. You CAN use nanosecond clocks and use timings to determine the cable distance from the drop-point to the device, but that only gives you a maximum radius to search, as you don't know how coiled the cable is.
Personally, I'd love it if there was a facility somewhere with a small army of software engineers whose jobs were to formally verify (where possible) or unit-test (in all other cases) every function of every major project in Linux, and to fix those functions to operate within specification. It wouldn't fix all problems, integration creates as many bugs as the individual units, but if you could halve the number of bugs, the primary developers could focus on architectural defects rather than implementational defects.
What would it take to do this? For just the Linux kernel, GCC and GLibc suites and X11, you'd need about 20,000 full-time mathematically-oriented software engineers, to be able to get the code as clean as possible and keep it that way, within a year. If you rolled them over onto other software, you could have Gnome, KDE and ROX pretty much sewn up the following year, maybe two.
So, we can get Linux reasonably (not perfectly, just reasonably) bug-free, for about 6 billion dollars. Personally, I would regard that as an extremely worthwhile investment. The DoD has done studies that have shown troops have illicitly spent about that on women of ill repute using Government credit cards, in the past 15 years. (That has resulted in some going to military prison, but I doubt that got any of the money back.) A national bug-hunt might not be as much "fun", but a lot more people will enjoy the results.
This, however, is somewhat unlikely. Equally unlikely, however, is the ALSA module ever getting many problems ironed out. The range of hardware is too great, the information available is too limited, the number of developers is too small, the complexity of ALSA is too vast and the spaghetti monster of a configuration module is too convoluted.
ALSA is probably unmaintainable in the long-term and does not appear sustainable in the short-term. It's good, but it's just not providing the resources people need. If it was, you'd not need heavy-weight pluggable supercharged V10 engines just to run the mixing desks.
I'm sorry, but even Bill Gates doesn't have the money to get Enlightenment even to the next full release.
Well, they were technically guns. See the story Slashdot ran on the Emacs vs. Vi paintball game.
Well, no guarantee as to when I'll get round to it, but I'm thinking of doing exactly that, putting them into .deb packages built for Ubuntu and seeing what happens.
Try again....
Fix the iRods link. Bah.
...but it certainly is done. The projects I've found that do much the same thing are NOT being run by kids in their basement, but serious, large-scale research centers that need to do wide-area RAID.
dCache
iRods
OPeNDAP
PVFS
TPIE
CERN (and their collaborators) use fully Open Source grid software. I've added a few of the more interesting projects to Freshmeat. Before we get all cynical, let's exploit the hell out of what they've made available.
A friend of mine routinely has 400+ tabs open. Assigning them randomly every 20 is going to make the internal logic look like spaghetti. There are extremely few browsers capable of users with such a browsing pattern and if they switch to process tables for tabs, that number is rapidly going to fall. Given my own browsing habits, if I had a monitor large enough to make navigation practical, I'd probably be using somewhere into the hundreds of tabs, and frankly I don't want Linux' process tables to only show browser entries, obscuring everything else. I happen to like "top" showing me ONE entry for the browser. It means there is room for other stuff.
...she's oked the website to continue, it's not the lexicon she has killed but the Horcrux in the physical book, thus saving Ginny.
The Open Library project has barely any users, let alone book contributors or code contributors, and that isn't even restricted to something as special-interest as textbooks. If they can't get the open model to work for the written word, I doubt Virginia (not known as a bastion of openness or science) is going to have any impact worthy of the name. I hope I'm wrong, but I won't hold my breath.
Now these guys have an idea for openness that looks far more interesting. Grids of Beowulfs of games. I can see that succeeding. (Can you imagine a MMORG that's also in the Top500 list? Or a planet-wide FPS? Can you imagine a LAN Party where the "server" is spread over the entire LAN - all that extra power available for tougher, more sophisticated games?) I'm willing to bet that more students at more Universities would be willing to be involved in a world-wide game engine than any number of textbook projects.
Bear in mind that Y chromosomes are actually defective X chromosomes. From a purely mechanical sense, this means the system is not functioning according to what might be called "specification" (no implication of a specifier intended). Nonetheless, this defect is extremely valuable.
Prions alter nearby proteins to the same set of folds, giving you the ability to build a consistant structure out of a random set of proteins. It is possible that early pre-life exploited this, as a tesselating structure has a lot of advantages. True cells may therefore be a defective version of such a pre-cellular structure.
(Experiments on creating life from scratch have been based on using minerals like sulpher and molecules like fatty acids, and that may well have been the absolutely first step, but a spongy prion structure seems a logical next step, as DNA/RNA can create proteins not fatty acids, which means you've support for growth, and a sponge structure is good for trapping the raw materials.)
Noting? Nothing?! Have you seen the photos linked to from the summary? They've opened the damn Stargate! And you call that nothing?! Yeesh!
Evolution NEVER works in giant leaps. That is not how systems change. Ergo, as viruses are fairly complex molecules that can perform assisted self-replication, there must be simpler systems that perform even more primitive forms of self-replication, stretching right the way back to organic building-block material that cannot self-replicate at all. It seems to me that prions - which are organic molecules with crystal-like properties - are a necessary and fundamental step from "inert" proteins that sit there and do nothing at all. They are not the only step. DNA and RNA must have evolved independently and externally of the "cell" structure we see today. But prions and their ability to alter structure around them would seem to be absolutely a fundamental, key step to moving towards a cell body where the component proteins must tessellate. Prions are geometry-defining proteins and must have played some role in this process.
Does that make prions "living"? Maybe. I think that no matter how you define "life", there will be a grey area between living and non-living. The spectrum is near-enough continuous and therefore wherever you draw the line, the step immediately over that line will not be obviously distinct.
Except for extremely generalized categorization, I do not think the concepts of "living" and "non-living" will hold out for much longer. They are not scientifically meaningful, offer up no verifiable hypothesis independent of the data used to draw up the definitions, and are essentially a religious viewpoint that has been extended into a legal framework. But to science, these terms mean nothing. Only life over a certain level of complexity can alter its own environment as per Lovelock's Gaia Hypothesis, which is the most generic and universal of all biosystem models. Primitive first-step free-floating DNA couldn't alter conditions as he describes, that doesn't become possible until after the first true cell, which post-dates the origin of measurable life by perhaps quarter of a billion years, and therefore the true origin of life by longer still.
This reminds me of the argument of whether a machine can think, with some arguing that of course machines cannot think, they do not have an organic brain. That may be a requirement for a specific class of thinking (and that's unproven), but clearly if you go back far enough, there is some precursor to that specific type of thinking that does NOT have such a requirement and is computable. But is it then still thinking? I say the question is flawed and assumes an arbitrary dividing line exists that has a scientifically valid definition and objective purpose. No such line exists, except in the minds of those who believe that mind is a spiritual thing that should not be sullied with the physical.
Many lines are important. But many are not, and interfere with critical thinking. If you do not wish your thoughts turned into a self-inflicted slurry, banish those lines from your mental processes. Only accept divisions that serve a useful purpose in a scientific sense. All others are illusions, generated by an irrational need to be "better than" something else. If you have that great a need to be better than a rock, you will find greater benefit from re-examining your needs than from labeling the rock.