While meteor-spotting, more than once I've seen a triangle-shaped thing fly overhead. I thought it was a plane at first, but it was slower than that, and the lights were dimmer, and flickered some. Eventually I decided it was three birds flying in formation with the city lights reflecting off their bellies. It was kind of small (or distant); I don't recall any stars going behind it.
Did you actually see it, or just the lights at the corners? You say it was dark gray. Then you saw the ship itself, which would rule out birds.
I know how I would react. I would ignore that everyone else wasn't doing anything, let the project run over, and eventually do all their coding myself. Single person projects are so much easier than multi person projects.
I have no doubt that someone wrote these answers, or pieces of these answers, at some time in the past. But I've read several of those pieces verbatim before.
So, did he answer them with lots of cut-n-paste from a dictionary of his standard responses, or did he leave that to one of his robots? I don't know. Either way, the answers wandered a lot.
I thought students sent information to Yale, and then Yale responded by accepting or rejecting them. There's no opportunity in that transaction for Yale to give the students a PIN.
If there's a Yale form they have to fill out, then Yale could print a random PIN on every form (and require students to remember it). Hum, but what if the students forgot to copy down their PIN? Perhaps that would be an extra screening, Yale would only accept students who could keep track of your PIN?
We humans have come so far, it's difficult to put a new idea into practice anymore without making specialized contributions on top of a mountain of work of others. And it's hard to pin down where the good ideas are going to come from.
Corporations keep their mountain of work secret, so only their employees can build on top of it. Often they're even more restrictive, the only person allowed to build on top of any piece is the person the company assigns to own that piece. Open source in general, and Linux in specific, make the mountain of work public. Anyone can contribute anywhere they see fit. The pool of potentially inspired and motivated people is just so much bigger.
There's no reason to limit that to software. I hear progress in steel manufacturing follows a similar pattern. The steelmaking process is public. Whoever gets an idea finds an existing steel company and tacks it on.
The real trick, economicowise, is to allow motivated people to do what they want to do and monetarily reward them for doing it.
Well then you'd need some sort of cord attaching your shoe to the phone. Or, they could embed the phone in the sole of your shoe. Or -- here we go -- your phone could snap onto the sole of your shoe.
I was skimming "Game Theory Evolving", which walks through various hypotheses for why humans act the way they do. That's the result they came up with, that people are programmed to play tit-for-tat. I'm not sure if the initial bias was towards cooperation, but I think it was.
I recall that they found that "homo reciprocans", who does to you what you do to them, matched people's behavior best, even in one-time situations where the other guy would never get the chance to do to you what you did to them. Also found that even a small group such people could survive and prosper in a sea of selfish people by sticking together.
Another result was that people model every situation as analogous to previous situations, and they treat one-time psychological experiments as "us against them", where "them" is the researchers.
I was impressed that it could answer "What is a botmaster?". But when I referred to previous statements without giving proper nouns, it got confused. "I think about programming computers a lot" "Do you do any?" "Yeah I do a lot of any."
4. graphical resolve of conflicts - a graphical three-way diff is the only way to resolve complex conflicts
Some people like those, but there has to be the equivalent of Unix "merge" as well.
We've got Clearcase at work which has an impressive graphical merge tool. I never use it. I use Unix "merge" instead and resolve any remaining conflicts in EMACS. Two reasons.
My error rate is about 1 in 20. The graphical tool asks me about every place that either branch changed the code, but "merge" only asks me about places where both branches changed the code. Sure, sometimes the default for "merge" is wrong, but it's wrong much less often than I'd click the wrong button.
When there is an interesting conflict, I usually can't tell what to do just from the left, right, and base versions of that fragment of code. I have to look all over the file and in other files too. That's easier in EMACS.
Most people prefer the graphical merge tool. But, please keep the non-gui tools an option.
I was wondering -- should we measure years by how long it takes between spring equinoxes, or how long it takes to make one rotation about the sun? Since the earth's pole wobbles, they're different. For that matter, should days be one rotation, or the time between noons?
I tried looking it up. "Sidereal year" is one rotation. "Tropical year" is the time between equinoxes. The official calander year so far isn't either, it's 365 days except 366 every fourth year except 365 every 400th. And days seem to be times between midnights, and those keep getting adjusted with leap seconds as the earth's spin slows down. My guess is they're shooting for the tropical year, but I'm not sure.
This should drive astrologers batty. I tried looking that up too. Most western astrologers use the tropical year, which means it's seasons that really matter, not the stars. I even spotted a definition of the "Age of Aquarius": when the spring equinox starts in Aquarius. Reckoned to start about 100 to 300 years from now. Right now it happens in Pisces.
Yes it's possible to test too much. For example, if it takes 15 minutes to fix a bug but a week to run the required regression tests for touching that area of code, that's way too much. There's a tradeoff between correctness and turnaround time.
A really bad way to write a test is to take an existing test, copy it, turn on your feature in the copy, then add the copy to the existing test. Or equivalently, call the same test twice with different parameters. It doubles the running time of the test and doesn't give you significantly better coverage. 100 iterations of that gives you a test that wouldn't finish in a trillion years.
A really good way to test orthogonal features is to write a test that turns on half the features all at once. Choose the half at random when writing the test, but avoid any combination that raises an error. Then write another the same way, and another. 50 such tests will cover 99.9% of all triples of features. Much faster than 2^^#features tests, or (#features choose 3) tests. If you add a feature, add it to half the existing tests. That means the test changes over time. That's OK because they were blackbox tests to begin with.
Error cases and bug testcases are different. They're whitebox, you know what you're testing for. Those testcase can't change over time. Don't copy them (exponential growth!). Use the simplest testcases possible.
This will absolutely defeat Microsoft's claim that Windows NT/2000/XP is ready for the enterprise. Now that the major database systems vendors such as Oracle are supporting Linux, there is simply no reason not to use it. Where's the commercial clustering software for Windows? Oh, right, it's not there - nor is it planned.
Er, Oracle RAC isn't Linux specific. It runs on Windows, too.
Having bridges might be a feature, not a bug. Once you have bridges, you can rely on them to stabilized the distance between the electrodes. They'd allow some phonons to travel the wrong way, but still 99% of the surfaces won't touch.
Couldn't you just throw some grit in between the electrodes? That won't totally keep them from touching, both touch the grit, but it would keep 99.9% of the two surfaces from touching.
Yo. Licenses are code. Laws are code. They're hard to read for the same reason code is hard to read; it's because they have to completely specify something. Every seen a simple picture or graph that implemented an OS? I thought not.
It's true that laws, unlike code, can't be compiled or linted. Somebody should fix that.
It seems to me that a more immediate use is not searching bombed out buildings, but in bombing buildings. Suicide rats are much easier to come by than suicide bombers.
Er, yes. Please name some existing stations that actually do this. And are they any good?
The RIAA has been being a pain for a few years now. Musicians have been fed up with them for even longer. If open music is going to happen, it should be happening already.
I've long wanted a "x wrap z body y" construct, which is execute x y z. A variant has an errorframe built into it so that z is executed even if y throws an error. For example
saved = context;
wrap {
context = saved;
} body {
context = 0;
foo(context);
}
bar(context);
Larry Ellison loves interesting parallel hardware. He bought NCube and made Oracle run on it! Running Oracle's internal systems on Oracle in interesting configurations is a good way for Oracle to find the bugs in it. So this story doesn't imply that Linux is Oracle's most favored platform or that Sun is going away. It does mean that, once it actually happens, that any Linux-specific Oracle bugs stand a good chance of getting detected quickly and fixed.
Slashdot Mirror
While meteor-spotting, more than once I've seen a triangle-shaped thing fly overhead. I thought it was a plane at first, but it was slower than that, and the lights were dimmer, and flickered some. Eventually I decided it was three birds flying in formation with the city lights reflecting off their bellies. It was kind of small (or distant); I don't recall any stars going behind it.
Did you actually see it, or just the lights at the corners? You say it was dark gray. Then you saw the ship itself, which would rule out birds.
Didn't you mean for Good and 666?
I know how I would react. I would ignore that everyone else wasn't doing anything, let the project run over, and eventually do all their coding myself. Single person projects are so much easier than multi person projects.
I have no doubt that someone wrote these answers, or pieces of these answers, at some time in the past. But I've read several of those pieces verbatim before.
So, did he answer them with lots of cut-n-paste from a dictionary of his standard responses, or did he leave that to one of his robots? I don't know. Either way, the answers wandered a lot.
I thought students sent information to Yale, and then Yale responded by accepting or rejecting them. There's no opportunity in that transaction for Yale to give the students a PIN.
If there's a Yale form they have to fill out, then Yale could print a random PIN on every form (and require students to remember it). Hum, but what if the students forgot to copy down their PIN? Perhaps that would be an extra screening, Yale would only accept students who could keep track of your PIN?
We humans have come so far, it's difficult to put a new idea into practice anymore without making specialized contributions on top of a mountain of work of others. And it's hard to pin down where the good ideas are going to come from.
Corporations keep their mountain of work secret, so only their employees can build on top of it. Often they're even more restrictive, the only person allowed to build on top of any piece is the person the company assigns to own that piece. Open source in general, and Linux in specific, make the mountain of work public. Anyone can contribute anywhere they see fit. The pool of potentially inspired and motivated people is just so much bigger.
There's no reason to limit that to software. I hear progress in steel manufacturing follows a similar pattern. The steelmaking process is public. Whoever gets an idea finds an existing steel company and tacks it on.
The real trick, economicowise, is to allow motivated people to do what they want to do and monetarily reward them for doing it.
Internet traffic doubles every 100 days? I never heard that myth. They must have a bad marketing department.
Well then you'd need some sort of cord attaching your shoe to the phone. Or, they could embed the phone in the sole of your shoe. Or -- here we go -- your phone could snap onto the sole of your shoe.
What they need is a foot pedal. That way you could talk while charging it.
I was skimming "Game Theory Evolving", which walks through various hypotheses for why humans act the way they do. That's the result they came up with, that people are programmed to play tit-for-tat. I'm not sure if the initial bias was towards cooperation, but I think it was.
I recall that they found that "homo reciprocans", who does to you what you do to them, matched people's behavior best, even in one-time situations where the other guy would never get the chance to do to you what you did to them. Also found that even a small group such people could survive and prosper in a sea of selfish people by sticking together.
Another result was that people model every situation as analogous to previous situations, and they treat one-time psychological experiments as "us against them", where "them" is the researchers.
I was impressed that it could answer "What is a botmaster?". But when I referred to previous statements without giving proper nouns, it got confused. "I think about programming computers a lot" "Do you do any?" "Yeah I do a lot of any."
Some people like those, but there has to be the equivalent of Unix "merge" as well.
We've got Clearcase at work which has an impressive graphical merge tool. I never use it. I use Unix "merge" instead and resolve any remaining conflicts in EMACS. Two reasons.
Most people prefer the graphical merge tool. But, please keep the non-gui tools an option.
I was wondering -- should we measure years by how long it takes between spring equinoxes, or how long it takes to make one rotation about the sun? Since the earth's pole wobbles, they're different. For that matter, should days be one rotation, or the time between noons?
I tried looking it up. "Sidereal year" is one rotation. "Tropical year" is the time between equinoxes. The official calander year so far isn't either, it's 365 days except 366 every fourth year except 365 every 400th. And days seem to be times between midnights, and those keep getting adjusted with leap seconds as the earth's spin slows down. My guess is they're shooting for the tropical year, but I'm not sure.
This should drive astrologers batty. I tried looking that up too. Most western astrologers use the tropical year, which means it's seasons that really matter, not the stars. I even spotted a definition of the "Age of Aquarius": when the spring equinox starts in Aquarius. Reckoned to start about 100 to 300 years from now. Right now it happens in Pisces.
Yes it's possible to test too much. For example, if it takes 15 minutes to fix a bug but a week to run the required regression tests for touching that area of code, that's way too much. There's a tradeoff between correctness and turnaround time.
A really bad way to write a test is to take an existing test, copy it, turn on your feature in the copy, then add the copy to the existing test. Or equivalently, call the same test twice with different parameters. It doubles the running time of the test and doesn't give you significantly better coverage. 100 iterations of that gives you a test that wouldn't finish in a trillion years.
A really good way to test orthogonal features is to write a test that turns on half the features all at once. Choose the half at random when writing the test, but avoid any combination that raises an error. Then write another the same way, and another. 50 such tests will cover 99.9% of all triples of features. Much faster than 2^^#features tests, or (#features choose 3) tests. If you add a feature, add it to half the existing tests. That means the test changes over time. That's OK because they were blackbox tests to begin with.
Error cases and bug testcases are different. They're whitebox, you know what you're testing for. Those testcase can't change over time. Don't copy them (exponential growth!). Use the simplest testcases possible.
Er, Oracle RAC isn't Linux specific. It runs on Windows, too.
Having bridges might be a feature, not a bug. Once you have bridges, you can rely on them to stabilized the distance between the electrodes. They'd allow some phonons to travel the wrong way, but still 99% of the surfaces won't touch.
I recall that electrons like jumping from points more than from flat surfaces. If the surfaces of the electrodes are not flat, would that help?
Flip side, wouldn't the electrode surfaces grow stalagtites that eventually meet as bridges spanning the gap?
Couldn't you just throw some grit in between the electrodes? That won't totally keep them from touching, both touch the grit, but it would keep 99.9% of the two surfaces from touching.
Yo. Licenses are code. Laws are code. They're hard to read for the same reason code is hard to read; it's because they have to completely specify something. Every seen a simple picture or graph that implemented an OS? I thought not.
It's true that laws, unlike code, can't be compiled or linted. Somebody should fix that.
It seems to me that a more immediate use is not searching bombed out buildings, but in bombing buildings. Suicide rats are much easier to come by than suicide bombers.
Er, yes. Please name some existing stations that actually do this. And are they any good?
The RIAA has been being a pain for a few years now. Musicians have been fed up with them for even longer. If open music is going to happen, it should be happening already.
Hurrah! Brin's got it right. The goal should be for everyone to be able to find out anything, but with heavy penalties for misusing those rights.
I've long wanted a "x wrap z body y" construct, which is execute x y z. A variant has an errorframe built into it so that z is executed even if y throws an error. For example
saved = context;
wrap {
context = saved;
} body {
context = 0;
foo(context);
}
bar(context);
Larry Ellison loves interesting parallel hardware. He bought NCube and made Oracle run on it! Running Oracle's internal systems on Oracle in interesting configurations is a good way for Oracle to find the bugs in it. So this story doesn't imply that Linux is Oracle's most favored platform or that Sun is going away. It does mean that, once it actually happens, that any Linux-specific Oracle bugs stand a good chance of getting detected quickly and fixed.
Bingo. We can support billions of times the population of earth right in our own solar system. Terraforming planets is a waste of time.
I've been building simulators of Dyson swarms in recent days.