Every photon arriving at Hubble from so far off
has been coursing across the universe for billions
of years, and passing through billions of
light-years of stuff.
Is there any reason to think those photons have not
been changed by the experience? Might not many or
most of the phenomena we attribute to "the early
universe" be simple artifacts of the unimaginably
long path the light took getting to us?
The reasonable baseline hypothesis (absent
religious bias) is that the universe far away
and long ago should be much like the
universe nearby, today. Claims that it was
fundamentally different should be treated as
extraordinary, requiring extraordinary evidence.
Such claims deserve special attention to processes
that may produce artifacts.
John Dean (Nixon's White House counsel) revealed
that the true definition of a "strict
constructionist" judge, as quoted by
current Chief Justice Rehnquist, is "one who
favors criminal prosecutors over criminal
defendants, and civil rights defendants over civil
rights plaintiffs". He should know, he is one.
In other words, all the rhetoric about
preserving the constitution is a cynical
smokescreen. For lots more, do a search on Google
for "strict constructionist definition John Dean
Rehnquist appointment".
Antonin Scalia is no friend of civil rights, or of
anything but the favor of the rich or
well-connected. People who have been fooled are
in good company, but there's no excuse any more.
The truth is out.
If it doesn't play Ogg files, what good is it?
Surely no sensible person is still ripping
to MP3 any more?
Before giving a thumbs up to an MP3 player, these
days, it should already play Ogg files, or you
should have a commitment from the manufacturer that
they will have an Ogg decoder upgrade by some
specific date. It's not as if it would cost them
anything.
There's only one remedy I'd like to see: take them
at their word when they say they don't want any
government interference in their business. More
precisely: declare a five-year vacation on any
enforcement of Microsoft's contracts and copyrights. That is, for five years any civil
case brought by MS in a U.S. court bearing on
copyright or contract performance is
automatically dismissed. (Of course others would
still be able to sue MS.)
No administration, no loopholes.
The real question is, when do we start trying MS
executives for perjury?
Bruce Schneier pointed out that Rijndael
was less secure than it could have been because
it specified fewer rounds than he thought it
should. I seem to recall that a plausible attack
on an only slightly reduced-round variant was
presented.
Points for whoever can produce the explanation
why the apparent weakness doesn't matter, and why
we shouldn't be jimmying our Rijndaels to do a few
more rounds, and calling the variant "RWS" (for
Rijndael With Suspenders) or something.
Remember that it was the suspenders added to MD4
to make MD5 that made the cracking of MD4
something other than a disaster.
By incidental, I meant that you could replace the
Debian installer with anything (including
one lifted from another distro) and it would still
unquestionably be Debian. Likewise, you could drop
in a BSD or Hurd kernel, and it would still be
Debian.
That's not to say the installer (or the kernel) are not necessary and important. Rather, if the
installer is all that at distinguishes the
distribution, that's one sorry excuse for a distribution.
The installer is incidental. Debian users run
it once, and never again.
What makes
the difference in a distro is the set of
policies and procedures that make the distro
something recognizable. If those are
comprehensive, enforced, and automated enough,
it becomes possible to trust the distro from
release to release.
The infrastructure of the Debian distro has
flowered as the "apt-get" tool and its related
GUI applications (gnome-apt, aptitude, deity).
Apt-get makes a Debian system far easier to
maintain, and keep up to date and secure, than
any other. Debian policies and package tools
make it possible to use safely. Apt-get without
all the infrastructure beneath would be too
dangerous to trust.
I used to sell ASUS 7400s as Linux Laptops Ltd. (I'm using one now; it's lasted longer than I
expect a laptop to last, about 2-3 years).
What most people don't realize is that there are
only a few manufacturers of laptops. Taiwan has
four. Japan has a few (e.g. Toshiba)
and in the U.S. there's just IBM. When you buy
a brand-name laptop (Compaq, Dell, what have you),
it's manufactured by one of those, generally one
in Taiwan. You probably would not recognize the
manufactuers' names, other than ASUS.
Dell ships laptops from at least two of them,
and the quality varies accordingly. Also, Dell
specifies some of their own, cheaper, parts (e.g.
keyboards) which is why they fail so often.
What makes the difference between a well-made
laptop and a lemon is partly the design standards,
and partly the QA attitude of the buyer (not you,
the importer). If they don't like having to
handle returns, they will insist on getting
quality merchandise from the manufacturer.
There's nothing that can't be made less well for
less money, and laptops offer a zillion shortcuts.
Taiwanese companies are nothing if not
accommodating to their large customers
*ahem* Dell *ahem* who want lower quality for
lower cost.
My ASUS 7400s were imported by Chembook. ChemUSA
did a pretty good job, and would deliver without
an O/S (no MS tax).
Some laptop makers (e.g. Mitac) are really in some
other business (e.g. military contracting), and
make laptops just to have something for a favored
nephew to do, or in order to get volume discounts
on the parts they also use for other stuff.
To me the most interesting result was that both
systems came out just about equal. I doubt there
is much room left to squeeze out more performance,
so competition will have to be based on other
factors.
Your message is consistent, effective, and helpful. However, one
remark you often repeat is being used to justify harmful practices,
and even harmful legislation. It plays into the hands of Microsoft
and those like them.
In your ZDnet article you wrote, "the sheer complexity of modern software
and networks means that vulnerabilities, lots of vulnerabilities, are
inevitable." Microsoft's Scott Culp had written, "all non-trivial
software contains bugs." The difference between the two statements is
probably too subtle for most of your readers. As you say, almost all
software vendors do very shoddy work, and most large systems are riddled
with holes. Still, the step from "almost all" to "all" is much larger
than it might seem.
From Counterpane's business perspective, the distinction probably makes
no difference; Counterpane must accept its customers' software deployment
choices. From the standpoint of a judge or legislator, though, it makes
all the difference in the world. If reliable software really cannot be
written, then Microsoft and its ilk must be forgiven their sloppiness
at the outset; it would be wrong to hold them to an impossible standard.
If in fact reliable software can be written, then such ilk are negligent
in failing to produce it.
This is not an academic point. It affects your argument, and Microsoft's.
If a software system will always be full of holes no matter how many
patches are applied, publicizing holes just makes it harder for network
administrators to keep up. It is the availability of reliable alternatives
that cinches the full disclosure argument: users can get off the patch
treadmill by switching to software that's not buggy. The extra work
done to ensure reliability pays off when users switch, or needn't. Full
disclosure punishes the sloppy (and their customers) and rewards the
careful (and their customers).
It doesn't take many examples of truly reliable software to make the
point, in principle. How many bugs remain in Donald Knuth's TeX?
In Dan Bernstein's qmail? These were not billion-dollar efforts.
Once it's demonstrated that reliability is possible, getting it becomes
a matter of economics. Microsoft, rather than saying reliable software
is impossible, is forced to admit instead (forty billion dollars in the
bank notwithstanding) that they simply cannot afford to write reliable
software, or that their customers don't want it, or, more plausibly,
that they just can't be bothered to write any, customers be damned.
Instead of promoting a destructive fatalism about the software components
we rely on, you would do better to say simply that current economic
conditions lead most organizations to deploy systems known to be full
of vulnerabilities. Leave open the possibility that slightly different
circumstances would allow for a reliable infrastructure. Reliability
is no substitute for effective response, but it just might be what it
takes to make effective response possible.
I see post after post reporting gleefully that
people now can just pop off the power, believing
that journaling will save their data from harm.
It's not true.
If you have only SCSI disks, it may be true,
if your disks are from a very reputable
manufacturer. (They are few, and charge more.)
If you have IDE disks, it is almost certainly
false. IDE disks report data successfully
written to disk when it is still only in
on-board RAM buffers. Even when told not to,
they often do it anyway. (Lying results in
better benchmark scores.)
If you have IDE disks, journaling will help
protect you against various lockups and crashes,
but if the disk is active when the power goes
out, all bets are off. If you think you didn't
lose data, maybe you got lucky, or maybe you
just haven't noticed your losses yet.
The reason IDE disks are cheaper than SCSI is
that the people who buy IDE disks have much,
much lower quality standards. To compete,
the manufacturers are forced to deliver lower
quality. If you care about reliability, buy
SCSI (or fiber-channel, or...).
If you use IDE, watch that power switch, and
keep current backups. If you maintain
critical data, invest in a UPS. Journaling is
not a substitute for a UPS, it's just a time
saver.
Anybody who's read "The Last Place on Earth"
has read a litany of Scott's idiocies. His
expedition might have survived any dozen of
them, but piled one on upon another, survival
could have resulted only from extreme luck.
Taking such risks himself was just foolishness.
Imposing them on his men was gross negligence.
It was treason, too, because he dragged good
Navy men down with him.
They didn't die of extreme cold: they died of
scurvy. It had been known for a century how
to prevent it, but he couldn't be bothered.
He took *ponies* with him to haul sledges; he
couldn't be bothered to learn how to handle dogs,
or bring along anybody who could. They froze.
He took skis
but didn't use them, because they didn't ever bother to try them until after they got there.
He had the first Sno-cats, and left behind the
mechanic just for spite, so he couldn't fix them
when they broke. He dropped one through the ice
because he was bored waiting for it to solidify.
He didn't seal his
fuel cans properly, and it mostly leaked away,
although it had been known for a century how to
do it and why. I could go on and on.
The compelling practical argument, summarized
here and here,
goes like this:
Suppose you are using some Free Software in your business. You find a bug or discover you
need a new feature, so you take care of it (or hire it done) yourself. Then you have what you
need, and you don't really have to do anything else.
However, a new version of the program will soon be released. You must decide whether you
want to use the new version, and if so you must integrate your changes into it. This happens
each time a new version comes out. If you were to send in your changes and get them
integrated into the mainline code, each new version would already have your changes.
As long as you keep your changes private, nobody else is using them. Once your changes get
integrated into the mainline code, other people start using them, and improving them. As a
result, each new release of the program not only has your changes integrated, it may have
improvements on your changes.
Thus, publishing your changes (1) cuts your own workload and (2) attracts free assistance
from others with similar needs.
The process doesn't depend on altruism or a sense of community, although many people are
also motivated that way. It doesn't depend on people working to establish a reputation,
although many are. It doesn't depend on proprietary alternatives being intolerably
restricted, expensive, or buggy, although they often are.
As I understand it, practical fusion reactor were
proposed decades ago, and ignored for what
amount to political reasons.
All the money is still spent on "thermal"
fusion, where the product is high-speed neutrons
that must be captured and turned into heat, at
great expense and producing enormous amounts of
radioactive waste material.
A reaction that produces, instead, charged
particles moving at high speed can yield power
by directly extracting the kinetic energy of
the particles with an electromagnetic field.
The disadvantage of this approach is that there
is no need for multi-billion-dollar reactors
facilities, so the contractors who work on fusion
see no payoff in developing it.
Whenever you see a fusion project based on neutron
emission, you know it's just more of the same old
boondoggle.
1. I was often
mystified by Mr. Garbus's questioning of witnesses. He seemed to ask a lot of meaningless
questions, and seemed to have a very hard time
expressing some of them.
Mr. Garbus is no dummy. What was he up to?
2. It was clear, reading the transcripts, that
Judge Kaplan understood more clearly what the
trial was about than the plaintiffs did (and
sometimes better than the defendants did), and,
more to the point, far better than was expressed
in his final decision. None of his evident
understanding seems to have leaked into his final
decision; it reads like it was written by someone
who wasn't there.
According to Bob Baldwin, one reason we see a lot of Blowfish and not much of Twofish and other AES candidates is that Blowfish (like DES and 3DES) works on 8-byte blocks, where the AES candidates work on 16-byte blocks.
Crypto infrastructure is designed to allow different ciphers to be plugged in, but changing block size is more work. If you want to just drop in a cipher without changing anything else, you generally have to pick one that operates on the same size blocks.
I used to sell Thinkpads running Debian GNU/Linux under the Linux Laptops Ltd. brand.
JWZ is right: they are buggy as hell. IBM documents the bugs candidly as "Considerations" in their manual, so they happen in Windows too. Thus, the answer to JWZ's question is, "No, it will be just as buggy under Linux as under Windows."
Incidentally, the IBM laptop drives were the least reliable of any I handled. I never had a Toshiba or Hitachi drive fail, but lost two IBM drives during burn-in.
The BIOS access problem, though, has been mostly solved by Thomas Hood's "tpctl" program. IBM, uniquely, has provided a protected-mode interface to the BIOS so that you can reconfigure BIOS modes without shutting down Linux. Furthermore, IBM's PS2 program runs under DOS, so you still don't need Windows even for the things tpctl doesn't do.
I did get suspend/resume mostly working... on some models you have to unplug from the power main before popping out a network card. Also, you have to have all your programs close the sound devices first, or you won't get sound again until you cycle power. (Rebooting isn't enough!) Thus, the "esd" sound mixer daemon component of Enlightenment, or the equivalent in Gnome, messes up the hardware on suspend. It is useless to try to run APM event scripts: IBM's BIOS doesn't deliver the events, at least on the 600. (The 570 seemed to do better.)
I suspect the buggy BIOS is because they don't really have actual I/O devices; they are all simulated by the DSP gadget that also does the modem. The whole mess is probably so complicated they dare not touch it for fear of breaking something else too. At least, each model has a different set of bugs, and they never get fixed, year after year.
Why do people not complain more? Maybe because very few buy it with their own money, and maybe because most who have them are managers and don't really use them, or spent so much they feel they *must* have got their money's worth; or are embarrassed not to have done their homework. Your guess is as good as mine.
Slashdot Mirror
Is there any reason to think those photons have not been changed by the experience? Might not many or most of the phenomena we attribute to "the early universe" be simple artifacts of the unimaginably long path the light took getting to us?
The reasonable baseline hypothesis (absent religious bias) is that the universe far away and long ago should be much like the universe nearby, today. Claims that it was fundamentally different should be treated as extraordinary, requiring extraordinary evidence. Such claims deserve special attention to processes that may produce artifacts.
In other words, all the rhetoric about preserving the constitution is a cynical smokescreen. For lots more, do a search on Google for "strict constructionist definition John Dean Rehnquist appointment".
Antonin Scalia is no friend of civil rights, or of anything but the favor of the rich or well-connected. People who have been fooled are in good company, but there's no excuse any more. The truth is out.
Before giving a thumbs up to an MP3 player, these days, it should already play Ogg files, or you should have a commitment from the manufacturer that they will have an Ogg decoder upgrade by some specific date. It's not as if it would cost them anything.
No administration, no loopholes.
The real question is, when do we start trying MS executives for perjury?
Points for whoever can produce the explanation why the apparent weakness doesn't matter, and why we shouldn't be jimmying our Rijndaels to do a few more rounds, and calling the variant "RWS" (for Rijndael With Suspenders) or something.
Remember that it was the suspenders added to MD4 to make MD5 that made the cracking of MD4 something other than a disaster.
That's not to say the installer (or the kernel) are not necessary and important. Rather, if the installer is all that at distinguishes the distribution, that's one sorry excuse for a distribution.
What makes the difference in a distro is the set of policies and procedures that make the distro something recognizable. If those are comprehensive, enforced, and automated enough, it becomes possible to trust the distro from release to release.
The infrastructure of the Debian distro has flowered as the "apt-get" tool and its related GUI applications (gnome-apt, aptitude, deity). Apt-get makes a Debian system far easier to maintain, and keep up to date and secure, than any other. Debian policies and package tools make it possible to use safely. Apt-get without all the infrastructure beneath would be too dangerous to trust.
For more detail on the topic, see the Advogato posting.
What most people don't realize is that there are only a few manufacturers of laptops. Taiwan has four. Japan has a few (e.g. Toshiba) and in the U.S. there's just IBM. When you buy a brand-name laptop (Compaq, Dell, what have you), it's manufactured by one of those, generally one in Taiwan. You probably would not recognize the manufactuers' names, other than ASUS.
Dell ships laptops from at least two of them, and the quality varies accordingly. Also, Dell specifies some of their own, cheaper, parts (e.g. keyboards) which is why they fail so often.
What makes the difference between a well-made laptop and a lemon is partly the design standards, and partly the QA attitude of the buyer (not you, the importer). If they don't like having to handle returns, they will insist on getting quality merchandise from the manufacturer.
There's nothing that can't be made less well for less money, and laptops offer a zillion shortcuts. Taiwanese companies are nothing if not accommodating to their large customers *ahem* Dell *ahem* who want lower quality for lower cost.
My ASUS 7400s were imported by Chembook. ChemUSA did a pretty good job, and would deliver without an O/S (no MS tax).
Some laptop makers (e.g. Mitac) are really in some other business (e.g. military contracting), and make laptops just to have something for a favored nephew to do, or in order to get volume discounts on the parts they also use for other stuff.
This is good.
Bruce,
Your message is consistent, effective, and helpful. However, one remark you often repeat is being used to justify harmful practices, and even harmful legislation. It plays into the hands of Microsoft and those like them.
In your ZDnet article you wrote, "the sheer complexity of modern software and networks means that vulnerabilities, lots of vulnerabilities, are inevitable." Microsoft's Scott Culp had written, "all non-trivial software contains bugs." The difference between the two statements is probably too subtle for most of your readers. As you say, almost all software vendors do very shoddy work, and most large systems are riddled with holes. Still, the step from "almost all" to "all" is much larger than it might seem.
From Counterpane's business perspective, the distinction probably makes no difference; Counterpane must accept its customers' software deployment choices. From the standpoint of a judge or legislator, though, it makes all the difference in the world. If reliable software really cannot be written, then Microsoft and its ilk must be forgiven their sloppiness at the outset; it would be wrong to hold them to an impossible standard. If in fact reliable software can be written, then such ilk are negligent in failing to produce it.
This is not an academic point. It affects your argument, and Microsoft's. If a software system will always be full of holes no matter how many patches are applied, publicizing holes just makes it harder for network administrators to keep up. It is the availability of reliable alternatives that cinches the full disclosure argument: users can get off the patch treadmill by switching to software that's not buggy. The extra work done to ensure reliability pays off when users switch, or needn't. Full disclosure punishes the sloppy (and their customers) and rewards the careful (and their customers).
It doesn't take many examples of truly reliable software to make the point, in principle. How many bugs remain in Donald Knuth's TeX? In Dan Bernstein's qmail? These were not billion-dollar efforts.
Once it's demonstrated that reliability is possible, getting it becomes a matter of economics. Microsoft, rather than saying reliable software is impossible, is forced to admit instead (forty billion dollars in the bank notwithstanding) that they simply cannot afford to write reliable software, or that their customers don't want it, or, more plausibly, that they just can't be bothered to write any, customers be damned.
Instead of promoting a destructive fatalism about the software components we rely on, you would do better to say simply that current economic conditions lead most organizations to deploy systems known to be full of vulnerabilities. Leave open the possibility that slightly different circumstances would allow for a reliable infrastructure. Reliability is no substitute for effective response, but it just might be what it takes to make effective response possible.
Nathan Myers
ncm at cantrip dot org
It's not true.
If you have only SCSI disks, it may be true, if your disks are from a very reputable manufacturer. (They are few, and charge more.)
If you have IDE disks, it is almost certainly false. IDE disks report data successfully written to disk when it is still only in on-board RAM buffers. Even when told not to, they often do it anyway. (Lying results in better benchmark scores.)
If you have IDE disks, journaling will help protect you against various lockups and crashes, but if the disk is active when the power goes out, all bets are off. If you think you didn't lose data, maybe you got lucky, or maybe you just haven't noticed your losses yet.
The reason IDE disks are cheaper than SCSI is that the people who buy IDE disks have much, much lower quality standards. To compete, the manufacturers are forced to deliver lower quality. If you care about reliability, buy SCSI (or fiber-channel, or ...).
If you use IDE, watch that power switch, and keep current backups. If you maintain critical data, invest in a UPS. Journaling is not a substitute for a UPS, it's just a time saver.
Taking such risks himself was just foolishness. Imposing them on his men was gross negligence. It was treason, too, because he dragged good Navy men down with him.
They didn't die of extreme cold: they died of scurvy. It had been known for a century how to prevent it, but he couldn't be bothered.
He took *ponies* with him to haul sledges; he couldn't be bothered to learn how to handle dogs, or bring along anybody who could. They froze.
He took skis but didn't use them, because they didn't ever bother to try them until after they got there.
He had the first Sno-cats, and left behind the mechanic just for spite, so he couldn't fix them when they broke. He dropped one through the ice because he was bored waiting for it to solidify.
He didn't seal his fuel cans properly, and it mostly leaked away, although it had been known for a century how to do it and why. I could go on and on.
It seems (as of this writing) that the Slashdot Effect has overwhelmed even Sun's mighty web server. Hmph.
All the money is still spent on "thermal" fusion, where the product is high-speed neutrons that must be captured and turned into heat, at great expense and producing enormous amounts of radioactive waste material.
A reaction that produces, instead, charged particles moving at high speed can yield power by directly extracting the kinetic energy of the particles with an electromagnetic field.
The disadvantage of this approach is that there is no need for multi-billion-dollar reactors facilities, so the contractors who work on fusion see no payoff in developing it.
Whenever you see a fusion project based on neutron emission, you know it's just more of the same old boondoggle.
1. I was often mystified by Mr. Garbus's questioning of witnesses. He seemed to ask a lot of meaningless questions, and seemed to have a very hard time expressing some of them.
Mr. Garbus is no dummy. What was he up to?
2. It was clear, reading the transcripts, that Judge Kaplan understood more clearly what the trial was about than the plaintiffs did (and sometimes better than the defendants did), and, more to the point, far better than was expressed in his final decision. None of his evident understanding seems to have leaked into his final decision; it reads like it was written by someone who wasn't there.
Who's pulling Kaplan's strings, and how?
According to Bob Baldwin, one reason we see a lot of Blowfish and not much of Twofish and other AES candidates is that Blowfish (like DES and 3DES) works on 8-byte blocks, where the AES candidates work on 16-byte blocks.
Crypto infrastructure is designed to allow different ciphers to be plugged in, but changing block size is more work. If you want to just drop in a cipher without changing anything else, you generally have to pick one that operates on the same size blocks.
I used to sell Thinkpads running Debian GNU/Linux under the Linux Laptops Ltd. brand.
JWZ is right: they are buggy as hell. IBM documents the bugs candidly as "Considerations" in their manual, so they happen in Windows too. Thus, the answer to JWZ's question is, "No, it will be just as buggy under Linux as under Windows."
Incidentally, the IBM laptop drives were the least reliable of any I handled. I never had a Toshiba or Hitachi drive fail, but lost two IBM drives during burn-in.
The BIOS access problem, though, has been mostly solved by Thomas Hood's "tpctl" program. IBM, uniquely, has provided a protected-mode interface to the BIOS so that you can reconfigure BIOS modes without shutting down Linux. Furthermore, IBM's PS2 program runs under DOS, so you still don't need Windows even for the things tpctl doesn't do.
I did get suspend/resume mostly working... on some models you have to unplug from the power main before popping out a network card. Also, you have to have all your programs close the sound devices first, or you won't get sound again until you cycle power. (Rebooting isn't enough!) Thus, the "esd" sound mixer daemon component of Enlightenment, or the equivalent in Gnome, messes up the hardware on suspend. It is useless to try to run APM event scripts: IBM's BIOS doesn't deliver the events, at least on the 600. (The 570 seemed to do better.)
I suspect the buggy BIOS is because they don't really have actual I/O devices; they are all simulated by the DSP gadget that also does the modem. The whole mess is probably so complicated they dare not touch it for fear of breaking something else too. At least, each model has a different set of bugs, and they never get fixed, year after year.
Why do people not complain more? Maybe because very few buy it with their own money, and maybe because most who have them are managers and don't really use them, or spent so much they feel they *must* have got their money's worth; or are embarrassed not to have done their homework. Your guess is as good as mine.