If they used Microsoft's own code, it couldn't but suck. It would cost way more than a billion dollars to write good code. Then what? We already have a Free operating system, and we don't need another.
These results tell you nothing about Google, or Yahoo, or MSN. They speak volumes about Bear Stearns, ComScore Networks, and WebSideStory.
The announcements mean that ComScore has managed to score marketing dollars that WebSideStory hasn't (yet?). Bear Stearns promoting obviously flawed stats means they're involved, too, at one end or the other. (Did they buy the stats from CS, or did CS or its patron buy the promotion from BS?) Now we know in the future to ignore ComScore and Bear Stearns announcements, and suspect anybody they are seen to associate with.
WebSideStory's case is more complicated. Are they promoting their measurement service, or are they trying to provoke Yahoo and MS to pay them to pipe down or (for just a little more) change their tune? The PR business is more scummy than people like us can even imagine.
When I think of Mauritius I think first, last, and only of a hypertrophied flightless pigeon, sadly extinct since the seventeenth century, known as the dodo.
There's one stuffed at the Harvard Museum of Natural History, from which new specimens might be cloned someday soon. I doubt they will make much use of wireless internet service, though, even if they find their way to their ancestral home. They're even dumber than your average slashdot moderator; while equipped to peck, hunting is probably beyond them.
...those methods do nothing for you if the software is designed to simply record HTTP POST and SMTP operations
It doesn't matter if they log POST and SMTP packets. What matters is whether replaying them lets them authenticate again. If you have done it right, they won't. If you haven't done it right, surely that's your problem.
Once you've authenticated and got a terminal window, you just
run mutt. Or, your web-based authentication proxy logs you into your mail-reader web page. Whatever. None of this stuff works very well if you're in a "secure facility", but it should be fine for your average paranoid-country internet cafe. (If they really want in, they can always torture you.)
...remind me how bring your own copy of ssh is going to stop a keylogger?
A keylogger only records keystrokes. If your copy of ssh reads a key from your USB gadget and uses it to authenticate, there are no keystrokes to log. If you delete the keys you used after you use them, it doesn't matter if they copied them.
For most of us, and most places, just bringing a LiveCD to boot from suffices.
Don't worry about hardware keyloggers. They cost more than software loggers, so they won't be there. Cops and spooks break in to install them on dissidents' machines; they are probably very rare otherwise.
Just bring along an Ubuntu LiveCD, and boot from it.
If you can't do that, and you can arrange to produce your own web site, have web-page javascript password-entry scheme that uses just the mouse, unrepeatably. (That is, each time the page is (re-)loaded the buttons appear in different places on the screen.)
Or, bring along a USB key with a pile of temporary-use private
keys in it, and a copy of ssh configured to use only those
key files. Be sure to delete the corresponding public key
after each use. Even if they log keystrokes they won't copy the entire contents of every USB key plugged in; and it doesn't matter so much if they do, anyway.
"the testsuite is sacrosanct - no one breaks the test suite."
The test suite is already broken, and a plethora of reports saying how are lodged in bugzilla. You're already deciding that one bug is worse than another. Instead of looking consciously at the relative impact, though, you're applying an automatic rule that depends only on the age of the test. You would equally well decide automatically according to the day of the week.
Sacrosanct rules don't make for sound reasoning. It's easy to see why regressions are a big deal for businesses -- it's embarrassing to the management. Business rules need not control development processes in Free Software. Anyway, once the port maintainer fixes any regressions before release, they didn't exist, for embarrassment purposes.
Nobody said it's good to "randomly break code". Most usually it's already been broken, and somebody's trying to fix it. Fixes for logged bugs aren't "theoretical improvements".
Releases are "full of bugs" now. (Have you looked at bugzilla lately?) In part this is because you have discarded the fixes offered, and driven away the people with time and skill to provide them.
Nobody, also, said compilers should be released for your target with platform bugs. Whoever's responsible for that target port should fix them before releasing, without making mainline developers back out patches.
You're asserting, without support, that new (platform-limited) breakage of an old test is somehow enormously worse than existing breakage of new tests. Enormously worse, here, means that you'd rather have dozens of the latter bugs than one of the former.
There's no guarantee you can "compile KDE", either way, with an unreleased compiler. Your odds get better with fewer total bugs -- regardless of how old are the tests the remaining bugs break. Furthermore, since the bugs remaining are platform- only bugs, they're easier to identify and fix without breaking some other platform. Better, the people responsible for fixing them before release are the most qualified to do it, and likely are obliged to do it as part of their day job.
Do you have some objective reason to think that old tests are inherently way, way more important than new tests, or that platform tests are way more important than core tests?
... it puts the burden of fixing it upon you. But as a result, you avoid that vicious flipping where every new release tends to break some feature of the previous one.
No. Every new release does break features of the previous one. You're failing to prevent that. You cannot prevent that, no matter how peremptory you get, unless you just prevent all changes of any kind. The features that get broken are ones you don't have tests for, yet. You can never have tests for more than an infinitesimally small fraction of the features delivered.
The only real difference you make is that fixes are impeded, many are lost, and the burden of making your oddball platform work is placed on the people least qualified and least interested in making it work, and most burdened already. Meanwhile guardians of that oddball platform can just sit around rejecting fixes without supplying any of their own.
How many people could be making really substantial contributions, but find that satisfying David Edelsohn's proprietary test apparatus is just too much bother? Do even the users of the AIX port benefit from that? It means that they get only a tiny fraction of the otherwise-available platform- independent improvements, in each release. If, instead, they had the opportunity to provide fixes for bits of platform breakage they cared about, they would get the best of both.
This conclusion is unavoidable once you discount the accidental historical sequence in which tests were added to the test suite. A change that fails a later-entered test is not better than a change that fails an older test. If you have any scruples, you compare them straight across: which one has more impact?
If a change fixes the bug you introduced, accidentally, that affects all platforms and all users, it certainly is inherently better than leaving in your bug, even if it breaks some obscure test on some obscure platform. Reverse the time sequence, or make them simultaneous. If you get a different answer, you're not reasoning clearly.
It worked before. now with your patch it doesn't - ergo, your patch broke it.
Let's get this straight. There was no test for the bug my patch fixes, but it used to work, and then you broke it, on all platforms. Somebody reports the bug, and even adds a test case to prove it. I fix the bug, and send a patch. This patch makes the new test pass on all platforms. But because it fails some older (maybe proprietary) test on one target, none of the other platforms get the fix.
That's what is meant by "holding hostage". It doesn't ensure non-deteriorating quality. It just ensures that for new bugs and regressions (what we call "deteriorating quality") where there was no test already in place, the fixes are discriminated against.
Petrovsk got that bug the same time I did, and probably lots more of the same sort. He wants them all fixed just as much as I do. Rejecting fixes for all those bugs (or making it too hard for them to be fixed) doesn't do him any good. What would do him some good would be for the porting team for his platform to do their job and fix the platform-specific bugs they're uniquely qualified to fix, and stop impeding fixes for the rest.
The net effect would be lots more fixes, and the work better distributed -- i.e., fast-increasing quality.
...an automated regression testing system. After that, every applied patch would have to go through this ordeal to ensure that it doesn't break the compiler.
In other words, something on AIX breaks, and my patch gets rejected. I don't know how to work around some sucky AIX bug, and don't have time to learn. My patch fixed a real bug, maybe even on all platforms. It gets dropped on the floor just because IBM hasn't been obliged to maintain their own damn port.
It's rather rare that the code needs to be executed on actual hardware to expose a bug in a proposed patch.
And when off-target testing does expose a problem (not necessarily a bug) in the proposed patch? Should it just be rejected? How is the patch author expected to know enough to fix it? In the essay he points to IBM, with depressing frequency, getting already- accepted patches backed out because they broke something (or even just caused existing breakage to be revealed) in an on-target only test.
I'm all for making it easier for people who have put in the time figuring out how to fix something to get that fix in. I'm all for expecting people who actually care about things that break in obscure targets to fix them. Pride is enough to get me to write reasonably portable code, but it's not enough to get me to study AIX specific object-code debug annotation formats.
There are people who are paid to know that stuff. They should be earning their keep.
Perhaps if they are unable to actually produce a cross compiler then they should stop pretending they do.
It's one thing to produce a cross compiler, another thing to run tests on the cross target, and a third to figure out how to work around bugs in the cross target's native linker and debugger. Some people are paid to do that last. I'm not. If my patch happens to tickle one of those bugs, whose job should it be to track down why, and propose an alternive patch? Somebody who is paid to grovel around in proprietary linkers, or me? If it's me, then how?
I have lots and lots of other things to keep busy with. If it's too much work getting a bug fix in, maybe I'll just figure out a local workaround.
With a project as big and important as GCC, you'd think they'd have a server for each platform set up for all their developers to play with.
So, everybody who fixes something that (incidentally) affects emission of debug annotations in Gcc has to learn all the idiot formats used in AIX, Solaris, Tru64, PE, and what-have-you just because FSF happens to have those machines? Yes, somebody on the project might know intimate object-file format details about any of those. It's unreasonable to expect everybody to learn them all before a patch may be accepted.
The FSF has those machines for doing builds, not for random strangers to poke around in. Suppose your patch does break some obscure AIX test. What are you supposed to do about it? Hire IBM Global Services to figure out why, and fix it, so you can submit it again?
Of course the headline Slashdot reported is not what he said. Uli is abrupt, but he is practical, and not stupid. He's not always right, but when he's wrong he's interestingly wrong. If you think he's arguing for something stupid, you aren't paying attention.
What he said was *not* that Glibc, or Gcc, and whatnot shouldn't be ported to AIX, m68k, and whatever. What he said was that he does not care to *maintain* those ports, and should not be expected to. IBM (or IBM's customers) can certainly afford to maintain a port for AIX. Let them. Likewise, all those embedded-system houses dependent on m68k targets are welcome to step up and supply their own patches to keep their ports working.
If a patch to mainline breaks the AIX port, it's the job of the AIX maintainers to figure out how to fix the patch, not him, and not whoever contributed the patch (but has no access to AIX targets).
He's not even saying he would reject patches needed to support minority targets. Whoever's maintaining the m68k port doesn't need to maintain a fork. They are entirely welcome to send along whatever patches they need installed. They need only be sure their patches don't break any supported targets. This certainly makes more work for users of less popular targets, but it spreads the work around, instead of piling it up on those doing mainline development. The mainline maintainers have plenty else to worry about.
At a building entrance, you wouldn't see it; it's no different from a camera, not something you have to go through. But it's true that Europe, as a rule, is being more sensible.
In the U.S., building managements install access controls to get lower insurance premiums. What controls the insurance companies? They claim to be driven by court damage awards -- if somebody got shot in that building because there was no attempt to keep guns out, the building management is made responsible, and the insurance company pays. If they made some token attempt to keep the guns out, they are off the hook.
In practice, insurance companies excuse themselves from covering all manner of mishap, so enforcing access controls is a deliberate choice they made. It's possible they just saw an opportunity to hike premiums on all the buildings they cover, until something gets put in, or permanently for the ones that don't. If juries were to refuse to hold buildings responsible for guns coming in, it might not happen, but they could just as easily be anticipating the juries. If building managements weren't afraid of the same juries, they might refuse to pay the extra premium.
What controls the juries? The U.S. is a managed population -- the majority depend on mass media for their opinions, and the American mass media (like the Italian) are controlled by a few plutocrats. Juries are a mirror of the more idle part of the population, thus even more dependent on mass media. They do as they're told.
While we're being sensible (see parent posting) we might as well point out, in response to the original article, that these things are already in use in the lobbies of buildings. Nobody gets to protest that. As privacy invasion goes, airports are the least of our worries. At least there you know it's going on.
What do you think that guard is looking at on the screen behind the counter, a soap opera?
The upshot is that (1) the rootkits will close the holes they use, (2) the vulnerable machines will be tucked behind firewalls, infected via the web and e-mail, and (3) the bad guys can send bad e-mail to victims, but the honeymonkeys can't.
Here's hoping the new version is written in a language that doesn't cripple it.
Cell networks don't. The goons catch one person, look at who his machine connects to, look at that one, and the next, and map out the whole network. Users don't even know they're helping out, the goons can just look at upstream router traffic.
The only way to have more or less anonymous usage without betraying your colleagues is to piggyback traffic on broadcast data -- such as irc, like the spam robots, or, better, web sites. The traffic should look just like (non-SSL) HTTP, like somebody websurfing, with the data encoded in odd places, such as varying the whitespace found in HTML of pages taken from other sites. (It could be encoded purely in the page, by normalizing the spacing before encoding into it; or only extractable by comparison with the original text.)
Furthermore, it should prefer to connect to hosts in other
countries, to break the trace path. The node posting the data should post it to a different IP address than any of the other nodes get it from; they should get it from a variety of addresses. Each text should be encoded into a different page each time it's sent.
Socially, it needs to be something people can be proud of patching into their web servers -- like an underground railroad -- so that there may be a very large population of
foreign web servers running the host side and replicating
files among themselves. (Maybe they can restrict
delivery to clients in certain countries.) And, of course,
it needs to have a small footprint, so it doesn't interfere with normal operation of the web server.
Directories invite abuse. Better, just arrange that every client gets everything posted more or less recently, and knows which it has seen before so it will know not to accept those again. Clients only see traffic on channels they monitor, like leaf usenet feeds. Some would be for discussion, others for posting documents.
Wouldn't agree with experiment? What experiment? Last I heard nobody had managed to think of any way to test any aspect of string theory in (any existing) lab.
All Greene had to say about the value of the coupling constant he was on about was that everybody hoped it was small, because otherwise the approximations everybody is using would be way off; and that the closer it was to 1, the less like any of the current formulations the final string theory would be.
Might this experiment be expected actually to nail down a coupling constant (or two)?
Brian Greene, in two whole books, never answered the question: is there any reason beyond wishful thinking to believe that the coupling constant isn't exactly 1?
Brian Greene in two whole books never answered the question: is there any reason, beyond wishful thinking, to believe that the coupling constant isn't exactly 1?
12 moons, 12 signs. They'd better be careful not to find any more.
Does it strike anybody else as strange how close together their orbits are, considering how far out they are? It suggests to me a single body that was broken up by a just- barely- sufficient blow.
Slashdot Mirror
If they used Microsoft's own code, it couldn't but suck. It would cost way more than a billion dollars to write good code. Then what? We already have a Free operating system, and we don't need another.
The announcements mean that ComScore has managed to score marketing dollars that WebSideStory hasn't (yet?). Bear Stearns promoting obviously flawed stats means they're involved, too, at one end or the other. (Did they buy the stats from CS, or did CS or its patron buy the promotion from BS?) Now we know in the future to ignore ComScore and Bear Stearns announcements, and suspect anybody they are seen to associate with.
WebSideStory's case is more complicated. Are they promoting their measurement service, or are they trying to provoke Yahoo and MS to pay them to pipe down or (for just a little more) change their tune? The PR business is more scummy than people like us can even imagine.
When I think of Mauritius I think first, last, and only of a hypertrophied flightless pigeon, sadly extinct since the seventeenth century, known as the dodo.
There's one stuffed at the Harvard Museum of Natural History, from which new specimens might be cloned someday soon. I doubt they will make much use of wireless internet service, though, even if they find their way to their ancestral home. They're even dumber than your average slashdot moderator; while equipped to peck, hunting is probably beyond them.
It doesn't matter if they log POST and SMTP packets. What matters is whether replaying them lets them authenticate again. If you have done it right, they won't. If you haven't done it right, surely that's your problem.
Once you've authenticated and got a terminal window, you just run mutt. Or, your web-based authentication proxy logs you into your mail-reader web page. Whatever. None of this stuff works very well if you're in a "secure facility", but it should be fine for your average paranoid-country internet cafe. (If they really want in, they can always torture you.)
A keylogger only records keystrokes. If your copy of ssh reads a key from your USB gadget and uses it to authenticate, there are no keystrokes to log. If you delete the keys you used after you use them, it doesn't matter if they copied them.
For most of us, and most places, just bringing a LiveCD to boot from suffices.
Don't worry about hardware keyloggers. They cost more than software loggers, so they won't be there. Cops and spooks break in to install them on dissidents' machines; they are probably very rare otherwise. Just bring along an Ubuntu LiveCD, and boot from it. If you can't do that, and you can arrange to produce your own web site, have web-page javascript password-entry scheme that uses just the mouse, unrepeatably. (That is, each time the page is (re-)loaded the buttons appear in different places on the screen.) Or, bring along a USB key with a pile of temporary-use private keys in it, and a copy of ssh configured to use only those key files. Be sure to delete the corresponding public key after each use. Even if they log keystrokes they won't copy the entire contents of every USB key plugged in; and it doesn't matter so much if they do, anyway.
The test suite is already broken, and a plethora of reports saying how are lodged in bugzilla. You're already deciding that one bug is worse than another. Instead of looking consciously at the relative impact, though, you're applying an automatic rule that depends only on the age of the test. You would equally well decide automatically according to the day of the week.
Sacrosanct rules don't make for sound reasoning. It's easy to see why regressions are a big deal for businesses -- it's embarrassing to the management. Business rules need not control development processes in Free Software. Anyway, once the port maintainer fixes any regressions before release, they didn't exist, for embarrassment purposes.
Nobody, also, said compilers should be released for your target with platform bugs. Whoever's responsible for that target port should fix them before releasing, without making mainline developers back out patches.
You're asserting, without support, that new (platform-limited) breakage of an old test is somehow enormously worse than existing breakage of new tests. Enormously worse, here, means that you'd rather have dozens of the latter bugs than one of the former.
There's no guarantee you can "compile KDE", either way, with an unreleased compiler. Your odds get better with fewer total bugs -- regardless of how old are the tests the remaining bugs break. Furthermore, since the bugs remaining are platform- only bugs, they're easier to identify and fix without breaking some other platform. Better, the people responsible for fixing them before release are the most qualified to do it, and likely are obliged to do it as part of their day job.
Do you have some objective reason to think that old tests are inherently way, way more important than new tests, or that platform tests are way more important than core tests?
No. Every new release does break features of the previous one. You're failing to prevent that. You cannot prevent that, no matter how peremptory you get, unless you just prevent all changes of any kind. The features that get broken are ones you don't have tests for, yet. You can never have tests for more than an infinitesimally small fraction of the features delivered.
The only real difference you make is that fixes are impeded, many are lost, and the burden of making your oddball platform work is placed on the people least qualified and least interested in making it work, and most burdened already. Meanwhile guardians of that oddball platform can just sit around rejecting fixes without supplying any of their own.
How many people could be making really substantial contributions, but find that satisfying David Edelsohn's proprietary test apparatus is just too much bother? Do even the users of the AIX port benefit from that? It means that they get only a tiny fraction of the otherwise-available platform- independent improvements, in each release. If, instead, they had the opportunity to provide fixes for bits of platform breakage they cared about, they would get the best of both.
This conclusion is unavoidable once you discount the accidental historical sequence in which tests were added to the test suite. A change that fails a later-entered test is not better than a change that fails an older test. If you have any scruples, you compare them straight across: which one has more impact?
If a change fixes the bug you introduced, accidentally, that affects all platforms and all users, it certainly is inherently better than leaving in your bug, even if it breaks some obscure test on some obscure platform. Reverse the time sequence, or make them simultaneous. If you get a different answer, you're not reasoning clearly.
Let's get this straight. There was no test for the bug my patch fixes, but it used to work, and then you broke it, on all platforms. Somebody reports the bug, and even adds a test case to prove it. I fix the bug, and send a patch. This patch makes the new test pass on all platforms. But because it fails some older (maybe proprietary) test on one target, none of the other platforms get the fix.
That's what is meant by "holding hostage". It doesn't ensure non-deteriorating quality. It just ensures that for new bugs and regressions (what we call "deteriorating quality") where there was no test already in place, the fixes are discriminated against.
Petrovsk got that bug the same time I did, and probably lots more of the same sort. He wants them all fixed just as much as I do. Rejecting fixes for all those bugs (or making it too hard for them to be fixed) doesn't do him any good. What would do him some good would be for the porting team for his platform to do their job and fix the platform-specific bugs they're uniquely qualified to fix, and stop impeding fixes for the rest.
The net effect would be lots more fixes, and the work better distributed -- i.e., fast-increasing quality.
In other words, something on AIX breaks, and my patch gets rejected. I don't know how to work around some sucky AIX bug, and don't have time to learn. My patch fixed a real bug, maybe even on all platforms. It gets dropped on the floor just because IBM hasn't been obliged to maintain their own damn port.
And when off-target testing does expose a problem (not necessarily a bug) in the proposed patch? Should it just be rejected? How is the patch author expected to know enough to fix it? In the essay he points to IBM, with depressing frequency, getting already- accepted patches backed out because they broke something (or even just caused existing breakage to be revealed) in an on-target only test.
I'm all for making it easier for people who have put in the time figuring out how to fix something to get that fix in. I'm all for expecting people who actually care about things that break in obscure targets to fix them. Pride is enough to get me to write reasonably portable code, but it's not enough to get me to study AIX specific object-code debug annotation formats.
There are people who are paid to know that stuff. They should be earning their keep.
It's one thing to produce a cross compiler, another thing to run tests on the cross target, and a third to figure out how to work around bugs in the cross target's native linker and debugger. Some people are paid to do that last. I'm not. If my patch happens to tickle one of those bugs, whose job should it be to track down why, and propose an alternive patch? Somebody who is paid to grovel around in proprietary linkers, or me? If it's me, then how?
I have lots and lots of other things to keep busy with. If it's too much work getting a bug fix in, maybe I'll just figure out a local workaround.
Then why are people who only have Intel/AMD boxes expected to do 99% of the work?
So, everybody who fixes something that (incidentally) affects emission of debug annotations in Gcc has to learn all the idiot formats used in AIX, Solaris, Tru64, PE, and what-have-you just because FSF happens to have those machines? Yes, somebody on the project might know intimate object-file format details about any of those. It's unreasonable to expect everybody to learn them all before a patch may be accepted.
The FSF has those machines for doing builds, not for random strangers to poke around in. Suppose your patch does break some obscure AIX test. What are you supposed to do about it? Hire IBM Global Services to figure out why, and fix it, so you can submit it again?
Of course the headline Slashdot reported is not what he said. Uli is abrupt, but he is practical, and not stupid. He's not always right, but when he's wrong he's interestingly wrong. If you think he's arguing for something stupid, you aren't paying attention.
What he said was *not* that Glibc, or Gcc, and whatnot shouldn't be ported to AIX, m68k, and whatever. What he said was that he does not care to *maintain* those ports, and should not be expected to. IBM (or IBM's customers) can certainly afford to maintain a port for AIX. Let them. Likewise, all those embedded-system houses dependent on m68k targets are welcome to step up and supply their own patches to keep their ports working.
If a patch to mainline breaks the AIX port, it's the job of the AIX maintainers to figure out how to fix the patch, not him, and not whoever contributed the patch (but has no access to AIX targets).
He's not even saying he would reject patches needed to support minority targets. Whoever's maintaining the m68k port doesn't need to maintain a fork. They are entirely welcome to send along whatever patches they need installed. They need only be sure their patches don't break any supported targets. This certainly makes more work for users of less popular targets, but it spreads the work around, instead of piling it up on those doing mainline development. The mainline maintainers have plenty else to worry about.
Gamer's Desiderata
At a building entrance, you wouldn't see it; it's no different from a camera, not something you have to go through. But it's true that Europe, as a rule, is being more sensible.
In the U.S., building managements install access controls to get lower insurance premiums. What controls the insurance companies? They claim to be driven by court damage awards -- if somebody got shot in that building because there was no attempt to keep guns out, the building management is made responsible, and the insurance company pays. If they made some token attempt to keep the guns out, they are off the hook.
In practice, insurance companies excuse themselves from covering all manner of mishap, so enforcing access controls is a deliberate choice they made. It's possible they just saw an opportunity to hike premiums on all the buildings they cover, until something gets put in, or permanently for the ones that don't. If juries were to refuse to hold buildings responsible for guns coming in, it might not happen, but they could just as easily be anticipating the juries. If building managements weren't afraid of the same juries, they might refuse to pay the extra premium.
What controls the juries? The U.S. is a managed population -- the majority depend on mass media for their opinions, and the American mass media (like the Italian) are controlled by a few plutocrats. Juries are a mirror of the more idle part of the population, thus even more dependent on mass media. They do as they're told.
What do you think that guard is looking at on the screen behind the counter, a soap opera?
A Modest Proposal, or not
The upshot is that (1) the rootkits will close the holes they use, (2) the vulnerable machines will be tucked behind firewalls, infected via the web and e-mail, and (3) the bad guys can send bad e-mail to victims, but the honeymonkeys can't.
Cell networks don't. The goons catch one person, look at who his machine connects to, look at that one, and the next, and map out the whole network. Users don't even know they're helping out, the goons can just look at upstream router traffic.
The only way to have more or less anonymous usage without betraying your colleagues is to piggyback traffic on broadcast data -- such as irc, like the spam robots, or, better, web sites. The traffic should look just like (non-SSL) HTTP, like somebody websurfing, with the data encoded in odd places, such as varying the whitespace found in HTML of pages taken from other sites. (It could be encoded purely in the page, by normalizing the spacing before encoding into it; or only extractable by comparison with the original text.)
Furthermore, it should prefer to connect to hosts in other countries, to break the trace path. The node posting the data should post it to a different IP address than any of the other nodes get it from; they should get it from a variety of addresses. Each text should be encoded into a different page each time it's sent.
Socially, it needs to be something people can be proud of patching into their web servers -- like an underground railroad -- so that there may be a very large population of foreign web servers running the host side and replicating files among themselves. (Maybe they can restrict delivery to clients in certain countries.) And, of course, it needs to have a small footprint, so it doesn't interfere with normal operation of the web server.
Directories invite abuse. Better, just arrange that every client gets everything posted more or less recently, and knows which it has seen before so it will know not to accept those again. Clients only see traffic on channels they monitor, like leaf usenet feeds. Some would be for discussion, others for posting documents.
Wouldn't agree with experiment? What experiment? Last I heard nobody had managed to think of any way to test any aspect of string theory in (any existing) lab.
All Greene had to say about the value of the coupling constant he was on about was that everybody hoped it was small, because otherwise the approximations everybody is using would be way off; and that the closer it was to 1, the less like any of the current formulations the final string theory would be.
Might this experiment be expected actually to nail down a coupling constant (or two)?
Brian Greene, in two whole books, never answered the question: is there any reason beyond wishful thinking to believe that the coupling constant isn't exactly 1?
Brian Greene in two whole books never answered the question: is there any reason, beyond wishful thinking, to believe that the coupling constant isn't exactly 1?
12 moons, 12 signs. They'd better be careful not to find any more.
Does it strike anybody else as strange how close together
their orbits are, considering how far out they are? It suggests to me a single body that was broken up by a just- barely- sufficient blow.