(The first being an obscure reference to a cult air disaster movie.)
Do the drones have Mind Control, and could this be the Real Reason for the recent screw-up over confusing an overgrown village airfield with a national airport?
It has been around for a while, and I've not heard anything particularly bad about it. Not heard anything exceptionally good, either. One of the problems with security is that there are so many different kinds. The flavours that seem to be popular are:
Security of the host against intrusion (eg: OpenBSD)
Security of the host against usability attacks
Security of the contents against a user (eg: Trusted Irix)
On top of that, you have several methods of ensuring that the software is correct. The methods that are popular are:
Correct bugs as they are discovered (eg: Linux)
Aggressively audit for bugs (eg: OpenBSD)
Implement the software from a correct design (eg: Gemini)
Trustix does some of the auditing of OpenBSD, I believe, which is good. However, no auditing method will ever produce provable security. It can only ever produce probable security.
Linux (and so presumably Trustix) has various role-based mandatory access control systems, which provide a vastly higher level of protection against malicious use by someone already on the system. However, none of the mechanisms I am aware of provide mandatory access controls for packets or memory allocations. I am also very unclear if they provide additional security for shared memory or shared resources (using the P9000 filing system). As far as I know, OpenMOSIX and bproc have no mandatory access control support, so if you migrate a process, the rights do NOT migrate with it. (Also, if one node in a cluster has MAC, it should be impossible for threads to migrate from that to a non-MAC node, although the reverse should work, as MAC restrictions can be added but should not be removable outside of the established mechanism for doing so.)
MAC only appears on a very limited number of *BSDs, and most of those have vanished without a trace. SecureBSD and TrustedBSD are not exactly household names, and even those seemed to be limited to the narrow range of controls that SELinux supports. AFAIK, no other of the Open Source BSDs support mandatory access controls at all.
Note: MAC clusters would be wonderful for public server farms, as they would be a lot simpler and a lot safer than any of the other popular methods used.
Trusted computing and encryption often go hand-in-hand, but driver support for either is abysmal in the kernel. The number of trusted computing accelerators supported by Linux is feeble, and there's only one (RSA) crypto chip, even though many many others exist - and there's even specs and Open Source support for them. Why publicly specced devices aren't making it into Linux is beyond me, as that is the chief complaint of Linux driver developers. The way to reinforce that specs are good is to reward those who publish them. The way to reinforce that Linux doesn't matter is to have no impact.
(A good example is the Motorola S1 chip, for which the complete manual has been online for a long long time.)
Ultimately, until an Open Source system can beat the pants off an ancient closed-source system like Gemini, we've no business calling anything we have "secure" in any absolute sense. In a relative sense, most Open Source systems are infinitely more secure than any comparable system, but that only goes so far. It's about time we bit the bullet and gatecrashed the turf that has so far been reserved for the most secure of military systems.
You'd just need a tamper-proof electronic design. EPROMs (not EEPROMs, or Flash RAM, just regular non-reprogrammable EPROMs) would be pretty good for this. You write the code onto the EPROM, burn it with a UV, and then it cannot be altered. You then solder the EPROM onto the board, so replacement by someone with access to the electronics is impossible.
No sane designer would allow anything to be loaded onto such a machine after construction time. If you need to replace the code, you should replace the motherboard entirely. That is the only guaranteed way of ensuring that the software and hardware fully match up.
Ideally, such machines should have either no Operating System at all, or have a very minimal hardware abstraction layer. OSKit would almost be overkill. The reason being that you don't want to multitask, memory management can all be static (as all structures are of fixed size and number), drivers will be minimal and linear, the system will be fixed in design, and you don't need any kind of system library.
None of this is rocket science. No, correction - a lot of rocket computers are built along similar sorts of ideas, as they need to be robust, fast, efficient and secure.
On the original computer Elite came out on, the BBC Micro, it was possible (through an ingenious piece of programming) to have the top half of the screen in a high resolution, two-colour mode, and the bottom half of the screen in a much lower, multi-colour mode. The upshot was that you had graphics that should, logically, have been impossible on a computer that small.
If a Firefox VRML Extension extends Firefox to control VRML objects, then a Slashdot Firefox Extension should extend Slashdot to control Firefox browsers.
There's some functions I'd like to see......but however good they made it, I'd be saying the same thing, so it's a pointless thing to say.:)
Seriously, oolite is a brilliant game and I wish it were better-known and better-circulated. Purely from a psychotic historical angle, I wish the coders could jury-rig Linux' framebuffers to do split-resolution screens, but that's not really so important these days.
Ah, now I wouldn't say "noble". I believe the people of the Indus Valley might qualify (no evidence of weapons or warfare amongst them) but few European cultures could qualify as "noble". Different, certainly, but noble?
The Celts are well-known for all kinds of atrocities. The Romans invented a few for their histories, but we do have evidence in the form of Lindow Man (aka "Pete Marsh") and the numerous histories of cattle raids to demonstrate these were no peaceful, idyllic folk.
The Scandinavians don't fare much better - the Danish rule of England was pretty vicious and King Canute was probably not the sanest of all men to walk the Earth. The Vikings were the Norse raiders and they plundered many countries. There is definitely evidence of them as far inland as Kiev, with some suspicion that Russia was occupied by them at one point.
The Ice Man, found in the Austrian alps, was probably left-handed and it has been theorized that this was why he was brutally attacked and killed. There is insufficient data, at this time, to do more than speculate, as we don't know enough about the Iron Age cultures at this time.
What else is known: Very ancient markers, once extremely common in Europe, have become practically extinct. There isn't enough information to infer a violent overthrow of a native population, but this is usually seen as the most likely possibility.
However, much more recent markers from immigrant Iron Age farmers are also missing in the modern population, suggesting that they were definitely not welcomed with open arms.
Currently, the existing research is scattered and piecemeal. You'll find some on the excellent Genography Project website, but other discoveries are to be found in a multitude of places. Researchers aren't organizing and collecting the data at all well. If I thought anyone other than myself would be remotely interested, I'd probably go round and collect what I could find. However, on all the DNA lists and geek web-boards I've seen, I'm the only one unhappy, suggesting that it would be a pointless exercise.
could be considered racist (as I make it pretty clear I don't believe in racism). However, is it something/.ians should be aware? To a degree. I believe/.ians should be better aware of DNA research into population migrations, as it is a fascinating piece of research on a truly gigantic (planetary!) scale. There's no other research that has ever been conducted on this kind of scale.
The Aryans were a particularly violent cult that originated somewhere around Iran (whose name derives from it). They are associated with the massacre of the peaceful citizens of the Indus Valley, placing them under a violent and cruel slavery. There, the trail stops being so clear. The religions of the Aryans never made it into mainstream Europe and DNA analysis shows a surprisingly high percent of very early DNA traces, indicating that a warlike, psychotic race like the Aryans could not have conquered any sizable part of Europe.
DNA analysis strongly indicates a widespread influence from the Nordic cultures, which are often associated with the Aryans. However, the Norse of old would have laughed at such a delusion. The Norsemen are a far more ancient lineage, which spread up through Europe in the stone age - long before the Aryans existed. Indeed, there are few in Europe whose lineage is not provably far older and far more noble.
Is this flamebait? Probably. I have little time for supremacist groups. There's nothing supreme about them, apart from their egos, and their claims are easily disprovable trash. I'd rather go to a Microsoft conference - and that's saying something. Even Discordians are more worthy of respect.
...but Slashdot did cover the cancellation at the time, there were a LOT of unhappy campers on here, and we DO know that the Slashdot Effect is feared by many an admin. I seriously doubt NASA made any decisions based on a fear of Slashdot (but it would be nice!:) - however, it may be possible that this site contributed in some way to the restoration of the mission.
Back in the days when I was an old-timer, we had to code 37 hours a day! Uphill, both ways!
Seriously, anyone who calls themselves an Old-Timer in a field that is barely over 60 years old, is either a former co-worker of Turing or Von Neumann - the only generation with any business adding the word "old" - or they don't have enough understanding of the field to qualify.
Operating Systems in general are relatively new things. MULTICS is "historic", but only in the sense that it isn't in use. It has many ideas I consider valuable today, and I wish it was easier to get hold of MULTICS code, but it is far from ancient.
The odds are fairly high, though, that most "old-timers" on Slashdot are from the Unix or even the CP/M generation. Some might even call themselves "old-timers" when they only really started with DOS 3.1 or even something as modern as Windows 3.0!
I predate CP/M - not by much - but that doesn't matter because I don't claim to be an Old-Timer. Experienced, sure. Aware, certainly. Old-timer? No. I can tell you what I saw - from the control center at Jodrel Bank's Lovell Telescope to Imperial Computer's minis at Daresbury, from dusty Forth manuals to robotics and micromice - the word was Small. Small was good. Small was in. Small made Smartware one of the best damn integrated packages of that era in computing - and it outperformed many later generation systems. Small made Acornsoft's "Elite" the hottest game ever published by any title, as a percentage of the userbase it sold to.
Not sure if PETSpeed was small & unit-based. Wouldn't surprise me. You couldn't fit much even in a 32K machine, so modules would be logical.
As for Linus -- we're talking about Torvalds, right? The one who produced Linux, probably the most modular (and therefore smallest) OS ever released on this planet? The one who gave up on monolithic maintenance because he couldn't scale, so modularized even the maintenance process? You'd use him as an illustration for monolithic design, given that he hasn't used that in Linux in God-lost-count number of years?
"If SCO wins, on anything whatsoever, we're going to plunder whatever company we can for whatever we can get. If they lose, we don't want to commit ourselves to plundering, as that could backfire. We finally confess that we goaded SCO into the lawsuit, and that we are using them to find out what is legally going to hold water without us getting burned in the process. We're only doing so, however, because if we didn't, some insider was going to rat on us to ESR."
Yes, there were some strange protocols around at the time for mail - X.400 for example. But sendmail probably doesn't support many of these. Besides, even back then, it was considered ugly to design things as monolithic programs. Truly modular designs did not appear until dynamic linking became portable/usable, but basic modularity in the form of program piping has always existed.
(Indeed, all of the original Unix tools are written as pipelined utilities. If Sendmail had been written in this manner, you would have had a few hundred executables - BUT they would have been faster, more secure, and much more flexible. Small, modular kits have always been the "accepted" Unix way of Getting Things Right. Large, monolithic lumps have always been disparaged as probably bug-ridden and Bad.)
I have no objection to the Government criminalizing the witholding of a patch for a security flaw, where that flaw could endanger national security OR could cause significant economic harm (over the country, not just for some individual). This would require a fix to exist, but be knowingly or deliberately not released (eg: to "encourage" people to update to Vista, once it is available). I can't see any sane objection to such legislation, since if the code already exists, there is no further cost in producing it. All the production cost has already been spent. Such patches would not have been QA'd properly, so would be "at own risk", but all software is "at own risk" anyway.
I have no objection - and firmly believe the Government should - mandate that ALL software used in any Government institution - regardless of where or how - should be reasonably secure against any intrusion or misuse, should have a minimum of a 99.9% uptime under heavy but situationally-plausible stress, and should be considered clean of defects when tested against industry-standard closed- and open-source security scanners.
(You don't need massive reliability and security when playing minesweeper, but you do if your computer is controlling a warship or contains highly classified data.)
Many people like to say that it would be too expensive (or even impossible) to make software defect-free. Perhaps that is true, for totally off-the-shelf, totally generic systems. I think it's nowhere near as expensive or difficult as people imagine (although it certainly isn't cheap or easy), so think it's possible to have limited lemon laws. Where such requirements go beyond desires and become actual needs - particularly where the failure to meet those needs could have major consequences - I certainly believe that it is important to sacrifice unwanted functionality to the point where what is left CAN be secured to a high standard.
(I also believe that good programming methods can eliminate most problems, so that quality design can become the cheapest, most practical option for these sorts of cases.)
That conjecture does not apply to articles which, when cast onto the numeric system of base pi, multiplied by the current diameter of the nooverse taken to the log of base e, and divided by the user ID of the first poster, has a value of 42.
The correct question is "can you do it bug-free". Remember the US Navy's "Smart Ships" that were controlled, steered and operated by computer? Remember how they used to get towed in because of divide by zero errors killing the system? (Mind you, using Windows wasn't so smart, either.)
The problem is, most software out there is hopelessly bug-ridden. Even the military stuff. I know - I helped debug some of it. Until there are enough highly competent programmers that "zero defect" can have a literal meaning, computer-controlled warships are going to be a fiasco.
(Those with LOOONG memories, old copies of Practical Computing from the 1980s, and a fondness of sci-fi might come up with another reason it's a bad idea. There were several military scenarios in the short story section, over the years, that would definitely be valid today.)
ARLA - an alternative rocket launch assist system - uses a ramjet as the second "stage" (the first stage is given as a gas cannon, but a magnetic linear accelerator would work better for manned flight). They propose a rocket on top of the ramjet, but you could easily have a scramjet on the ramjet, then a rocket on top of that.
You don't need turbines to get a ramjet to sufficient speed. A ramjet will operate at 400mph - well within the limits of a propeller engine (I believe the Rolls Royce Merlin could manage over 500 in World War II). You simply fold the propellers inwards when the ramjet hits activation speeds.
You're also assuming ramjets are solely for Earth use. Let's say you want to have a flying aircraft operate on Titan. Nice, methane atmosphere. You're extremely limited in the weight you can lug over there, so the less you carry the better. In that case, you'd have an oxygen "fuel" and use your scramjet to pull in the methane. An electrical engine would be an alternative, but you'd have trouble keeping it hot enough to function. A glider would also be good, but you've no thermals of significance.
Back on Earth, a scramjet would be valuable in the event of an emergency. There's an island off the African coast, I believe, which - when (not if) it falls into the ocean, will create a tsunami capable of wiping out the entire eastern seaboard of the Americas for several hundred miles. There simply isn't any combination of aircraft, mass transit or shipping currently in existence capable of getting more than a small percent of people to safety.
The west coast is in as much danger from faultlines, volcanoes and other disaster-causing events, but it probably isn't going to be in danger at the same time.
Thus, a simple mechanism for ferrying massive numbers of people very rapidly from coast to coast would likely eliminate most of the potential for fatalities. True, this does mean that supersonic and hypersonic aircraft will need to fly over populated areas. Oh wah. The RAF do low-level supersonic flights in populated areas all the time. Hasn't killed me ye...ughhhh..
(Seriously, I'd rather have to worry about not getting much sleep during a disaster, if on an evacuation flightpath, than getting permanent sleep if living within a hundred miles of a coastline.)
The only way to get to mach 7 efficiently is to use an assisted ramjet with hydrogen fuel. From start to finish, everything is burning hydrogen and oxygen (producing water). As 80% of the atmosphere is nitrogen, you will get nitrates forming as well, which (in the presence of water) will then convert to a very dilute nitric acid. It'll add a little to the acid rain, but far and away less than conventional jet fuels and VASTLY less than ship fuels.
(As ships spend most of their time in international waters, most ships carry fuels that would be blatantly illegal in any civilized country. Acid rain in Europe, these days, is predominantly from the shipping lanes and not from industry.)
My closest claim to fame was involvement in AMS research at Darebury Laboratory that was looking at the aluminium levels of Alzeimer sufferers. I also had very peripheral involvement in the research into the use of desfereoxamine in treating people suffering from aluminium toxicity (it can cause brittle bones, limit oxygen uptake, etc).
However, that is neither here nor there. This is about how to measure the speed of the brain and improve it.
First off, improving the brain is somewhat of a Black Art. There are many variables, some of which will depend on the individual, and I'm not about to trust the research of anyone on this subject without some damn good supporting evidence. The problem is, what constitutes good supporting evidence? It's only been in the past few years that people have discovered (through the use of fMRI) some of the underlying mechanics of phenomena they have largely been restricted to studying by reported symptoms alone.
There appears to be some correlation between Omega-3 and Omega-6 fatty acids and brain development, but nobody seems clear as to exactly what the correlation is, whether it's limited to childhood or not, how significant the effect (if any) is, etc.
With such uncertainty, and so many wild claims being made, it is hard to be anything but skeptical. I do not dispute the genuine researchers who do genuine good and who genuinely discover useful things about the mechanics of the brain. The problem is, it's hard to know who those people are. It's like listening to Art Bell's old show - you KNOW that some guests are genuinely brilliant, genuine scientists - but which ones?
Actually, that's EXACTLY what I was thinking of when I wrote that. The breakfast cereal manufacturers aren't much better, but they make fewer brands than studios make movies, so aren't quite as bad. You're absolutely right about the problem with unique identifiers and about the fact that there are now a bazillion dead domain names. It doesn't help that whilst some will use www.hedgehogthemovie.com, others will use www.hedgehog-the-movie.com. No big difference? It is if you're trying to remember it.
DNS often sucks because the databases are too big, too flat and powered by too small a system. Flat naming systems are evil and inefficient.
JANET (the Joint Academic Network) used to use X.25, which used reverse domain names, if I recall correctly. It also used HORRIBLE addressing notation. Essex University's DEC 10 (which ran the first ever massively multi-user adventure game, or rather three of them) had an address of A2206411411. (Yes, I really do remember that.)
So the idea that he started off having trouble with the Berkeley naming convention doesn't surprise me at all.
(I'd prefer a more heirarchical system, myself, where an organization can ONLY have one domain name and have all their actual addresses inside of that. It would make the namespace a lot less cluttered and would reduce trademark abuses. On the other hand, names would be a lot longer. However, if you're using a search engine, a portal or bookmarks most of the time anyway, that's no big deal.)
Slashdot Mirror
Do the drones have Mind Control, and could this be the Real Reason for the recent screw-up over confusing an overgrown village airfield with a national airport?
You must be new here, then.
On top of that, you have several methods of ensuring that the software is correct. The methods that are popular are:
Trustix does some of the auditing of OpenBSD, I believe, which is good. However, no auditing method will ever produce provable security. It can only ever produce probable security.
Linux (and so presumably Trustix) has various role-based mandatory access control systems, which provide a vastly higher level of protection against malicious use by someone already on the system. However, none of the mechanisms I am aware of provide mandatory access controls for packets or memory allocations. I am also very unclear if they provide additional security for shared memory or shared resources (using the P9000 filing system). As far as I know, OpenMOSIX and bproc have no mandatory access control support, so if you migrate a process, the rights do NOT migrate with it. (Also, if one node in a cluster has MAC, it should be impossible for threads to migrate from that to a non-MAC node, although the reverse should work, as MAC restrictions can be added but should not be removable outside of the established mechanism for doing so.)
MAC only appears on a very limited number of *BSDs, and most of those have vanished without a trace. SecureBSD and TrustedBSD are not exactly household names, and even those seemed to be limited to the narrow range of controls that SELinux supports. AFAIK, no other of the Open Source BSDs support mandatory access controls at all.
Note: MAC clusters would be wonderful for public server farms, as they would be a lot simpler and a lot safer than any of the other popular methods used.
Trusted computing and encryption often go hand-in-hand, but driver support for either is abysmal in the kernel. The number of trusted computing accelerators supported by Linux is feeble, and there's only one (RSA) crypto chip, even though many many others exist - and there's even specs and Open Source support for them. Why publicly specced devices aren't making it into Linux is beyond me, as that is the chief complaint of Linux driver developers. The way to reinforce that specs are good is to reward those who publish them. The way to reinforce that Linux doesn't matter is to have no impact.
(A good example is the Motorola S1 chip, for which the complete manual has been online for a long long time.)
Ultimately, until an Open Source system can beat the pants off an ancient closed-source system like Gemini, we've no business calling anything we have "secure" in any absolute sense. In a relative sense, most Open Source systems are infinitely more secure than any comparable system, but that only goes so far. It's about time we bit the bullet and gatecrashed the turf that has so far been reserved for the most secure of military systems.
No sane designer would allow anything to be loaded onto such a machine after construction time. If you need to replace the code, you should replace the motherboard entirely. That is the only guaranteed way of ensuring that the software and hardware fully match up.
Ideally, such machines should have either no Operating System at all, or have a very minimal hardware abstraction layer. OSKit would almost be overkill. The reason being that you don't want to multitask, memory management can all be static (as all structures are of fixed size and number), drivers will be minimal and linear, the system will be fixed in design, and you don't need any kind of system library.
None of this is rocket science. No, correction - a lot of rocket computers are built along similar sorts of ideas, as they need to be robust, fast, efficient and secure.
On the original computer Elite came out on, the BBC Micro, it was possible (through an ingenious piece of programming) to have the top half of the screen in a high resolution, two-colour mode, and the bottom half of the screen in a much lower, multi-colour mode. The upshot was that you had graphics that should, logically, have been impossible on a computer that small.
I 3 and Ubuntu's 2, then I wins by one point.
If a Firefox VRML Extension extends Firefox to control VRML objects, then a Slashdot Firefox Extension should extend Slashdot to control Firefox browsers.
Seriously, oolite is a brilliant game and I wish it were better-known and better-circulated. Purely from a psychotic historical angle, I wish the coders could jury-rig Linux' framebuffers to do split-resolution screens, but that's not really so important these days.
The Celts are well-known for all kinds of atrocities. The Romans invented a few for their histories, but we do have evidence in the form of Lindow Man (aka "Pete Marsh") and the numerous histories of cattle raids to demonstrate these were no peaceful, idyllic folk.
The Scandinavians don't fare much better - the Danish rule of England was pretty vicious and King Canute was probably not the sanest of all men to walk the Earth. The Vikings were the Norse raiders and they plundered many countries. There is definitely evidence of them as far inland as Kiev, with some suspicion that Russia was occupied by them at one point.
The Ice Man, found in the Austrian alps, was probably left-handed and it has been theorized that this was why he was brutally attacked and killed. There is insufficient data, at this time, to do more than speculate, as we don't know enough about the Iron Age cultures at this time.
What else is known: Very ancient markers, once extremely common in Europe, have become practically extinct. There isn't enough information to infer a violent overthrow of a native population, but this is usually seen as the most likely possibility.
However, much more recent markers from immigrant Iron Age farmers are also missing in the modern population, suggesting that they were definitely not welcomed with open arms.
Currently, the existing research is scattered and piecemeal. You'll find some on the excellent Genography Project website, but other discoveries are to be found in a multitude of places. Researchers aren't organizing and collecting the data at all well. If I thought anyone other than myself would be remotely interested, I'd probably go round and collect what I could find. However, on all the DNA lists and geek web-boards I've seen, I'm the only one unhappy, suggesting that it would be a pointless exercise.
could be considered racist (as I make it pretty clear I don't believe in racism). However, is it something /.ians should be aware? To a degree. I believe /.ians should be better aware of DNA research into population migrations, as it is a fascinating piece of research on a truly gigantic (planetary!) scale. There's no other research that has ever been conducted on this kind of scale.
DNA analysis strongly indicates a widespread influence from the Nordic cultures, which are often associated with the Aryans. However, the Norse of old would have laughed at such a delusion. The Norsemen are a far more ancient lineage, which spread up through Europe in the stone age - long before the Aryans existed. Indeed, there are few in Europe whose lineage is not provably far older and far more noble.
Is this flamebait? Probably. I have little time for supremacist groups. There's nothing supreme about them, apart from their egos, and their claims are easily disprovable trash. I'd rather go to a Microsoft conference - and that's saying something. Even Discordians are more worthy of respect.
...that equating Microsoft with the Imperial March is being unduly suspicious and paranoid about empires?
...but Slashdot did cover the cancellation at the time, there were a LOT of unhappy campers on here, and we DO know that the Slashdot Effect is feared by many an admin. I seriously doubt NASA made any decisions based on a fear of Slashdot (but it would be nice! :) - however, it may be possible that this site contributed in some way to the restoration of the mission.
Seriously, anyone who calls themselves an Old-Timer in a field that is barely over 60 years old, is either a former co-worker of Turing or Von Neumann - the only generation with any business adding the word "old" - or they don't have enough understanding of the field to qualify.
Operating Systems in general are relatively new things. MULTICS is "historic", but only in the sense that it isn't in use. It has many ideas I consider valuable today, and I wish it was easier to get hold of MULTICS code, but it is far from ancient.
The odds are fairly high, though, that most "old-timers" on Slashdot are from the Unix or even the CP/M generation. Some might even call themselves "old-timers" when they only really started with DOS 3.1 or even something as modern as Windows 3.0!
I predate CP/M - not by much - but that doesn't matter because I don't claim to be an Old-Timer. Experienced, sure. Aware, certainly. Old-timer? No. I can tell you what I saw - from the control center at Jodrel Bank's Lovell Telescope to Imperial Computer's minis at Daresbury, from dusty Forth manuals to robotics and micromice - the word was Small. Small was good. Small was in. Small made Smartware one of the best damn integrated packages of that era in computing - and it outperformed many later generation systems. Small made Acornsoft's "Elite" the hottest game ever published by any title, as a percentage of the userbase it sold to.
Not sure if PETSpeed was small & unit-based. Wouldn't surprise me. You couldn't fit much even in a 32K machine, so modules would be logical.
As for Linus -- we're talking about Torvalds, right? The one who produced Linux, probably the most modular (and therefore smallest) OS ever released on this planet? The one who gave up on monolithic maintenance because he couldn't scale, so modularized even the maintenance process? You'd use him as an illustration for monolithic design, given that he hasn't used that in Linux in God-lost-count number of years?
"If SCO wins, on anything whatsoever, we're going to plunder whatever company we can for whatever we can get. If they lose, we don't want to commit ourselves to plundering, as that could backfire. We finally confess that we goaded SCO into the lawsuit, and that we are using them to find out what is legally going to hold water without us getting burned in the process. We're only doing so, however, because if we didn't, some insider was going to rat on us to ESR."
(Indeed, all of the original Unix tools are written as pipelined utilities. If Sendmail had been written in this manner, you would have had a few hundred executables - BUT they would have been faster, more secure, and much more flexible. Small, modular kits have always been the "accepted" Unix way of Getting Things Right. Large, monolithic lumps have always been disparaged as probably bug-ridden and Bad.)
I have no objection - and firmly believe the Government should - mandate that ALL software used in any Government institution - regardless of where or how - should be reasonably secure against any intrusion or misuse, should have a minimum of a 99.9% uptime under heavy but situationally-plausible stress, and should be considered clean of defects when tested against industry-standard closed- and open-source security scanners.
(You don't need massive reliability and security when playing minesweeper, but you do if your computer is controlling a warship or contains highly classified data.)
Many people like to say that it would be too expensive (or even impossible) to make software defect-free. Perhaps that is true, for totally off-the-shelf, totally generic systems. I think it's nowhere near as expensive or difficult as people imagine (although it certainly isn't cheap or easy), so think it's possible to have limited lemon laws. Where such requirements go beyond desires and become actual needs - particularly where the failure to meet those needs could have major consequences - I certainly believe that it is important to sacrifice unwanted functionality to the point where what is left CAN be secured to a high standard.
(I also believe that good programming methods can eliminate most problems, so that quality design can become the cheapest, most practical option for these sorts of cases.)
That conjecture does not apply to articles which, when cast onto the numeric system of base pi, multiplied by the current diameter of the nooverse taken to the log of base e, and divided by the user ID of the first poster, has a value of 42.
The problem is, most software out there is hopelessly bug-ridden. Even the military stuff. I know - I helped debug some of it. Until there are enough highly competent programmers that "zero defect" can have a literal meaning, computer-controlled warships are going to be a fiasco.
(Those with LOOONG memories, old copies of Practical Computing from the 1980s, and a fondness of sci-fi might come up with another reason it's a bad idea. There were several military scenarios in the short story section, over the years, that would definitely be valid today.)
You don't need turbines to get a ramjet to sufficient speed. A ramjet will operate at 400mph - well within the limits of a propeller engine (I believe the Rolls Royce Merlin could manage over 500 in World War II). You simply fold the propellers inwards when the ramjet hits activation speeds.
You're also assuming ramjets are solely for Earth use. Let's say you want to have a flying aircraft operate on Titan. Nice, methane atmosphere. You're extremely limited in the weight you can lug over there, so the less you carry the better. In that case, you'd have an oxygen "fuel" and use your scramjet to pull in the methane. An electrical engine would be an alternative, but you'd have trouble keeping it hot enough to function. A glider would also be good, but you've no thermals of significance.
Back on Earth, a scramjet would be valuable in the event of an emergency. There's an island off the African coast, I believe, which - when (not if) it falls into the ocean, will create a tsunami capable of wiping out the entire eastern seaboard of the Americas for several hundred miles. There simply isn't any combination of aircraft, mass transit or shipping currently in existence capable of getting more than a small percent of people to safety.
The west coast is in as much danger from faultlines, volcanoes and other disaster-causing events, but it probably isn't going to be in danger at the same time.
Thus, a simple mechanism for ferrying massive numbers of people very rapidly from coast to coast would likely eliminate most of the potential for fatalities. True, this does mean that supersonic and hypersonic aircraft will need to fly over populated areas. Oh wah. The RAF do low-level supersonic flights in populated areas all the time. Hasn't killed me ye...ughhhh..
(Seriously, I'd rather have to worry about not getting much sleep during a disaster, if on an evacuation flightpath, than getting permanent sleep if living within a hundred miles of a coastline.)
(As ships spend most of their time in international waters, most ships carry fuels that would be blatantly illegal in any civilized country. Acid rain in Europe, these days, is predominantly from the shipping lanes and not from industry.)
However, that is neither here nor there. This is about how to measure the speed of the brain and improve it.
First off, improving the brain is somewhat of a Black Art. There are many variables, some of which will depend on the individual, and I'm not about to trust the research of anyone on this subject without some damn good supporting evidence. The problem is, what constitutes good supporting evidence? It's only been in the past few years that people have discovered (through the use of fMRI) some of the underlying mechanics of phenomena they have largely been restricted to studying by reported symptoms alone.
There appears to be some correlation between Omega-3 and Omega-6 fatty acids and brain development, but nobody seems clear as to exactly what the correlation is, whether it's limited to childhood or not, how significant the effect (if any) is, etc.
With such uncertainty, and so many wild claims being made, it is hard to be anything but skeptical. I do not dispute the genuine researchers who do genuine good and who genuinely discover useful things about the mechanics of the brain. The problem is, it's hard to know who those people are. It's like listening to Art Bell's old show - you KNOW that some guests are genuinely brilliant, genuine scientists - but which ones?
DNS often sucks because the databases are too big, too flat and powered by too small a system. Flat naming systems are evil and inefficient.
First time through, I thouht it said it had been destroyed in a Maiden concert. I always knew there was something suspect about the bass settings.
So the idea that he started off having trouble with the Berkeley naming convention doesn't surprise me at all.
(I'd prefer a more heirarchical system, myself, where an organization can ONLY have one domain name and have all their actual addresses inside of that. It would make the namespace a lot less cluttered and would reduce trademark abuses. On the other hand, names would be a lot longer. However, if you're using a search engine, a portal or bookmarks most of the time anyway, that's no big deal.)