The point is that the (abstract of) the article is along the lines of "now that China has added 1000 pieces of junk, LEO is nearly full". I tried to explain that the US has launched many more pieces of junk, sometimes very useless too. And that it clearly is not "full" but just hitting some arbitrary limit.
I don't want to advocate the launch of arbitrary junk into space. But those that are without sin, should throw the first stone. Not NASA or the USA. Doing something about it is a different matter. But that can be done without fingerpointing.
One reason this is not so simple, is that there is so much space to vacuum. You will not find much junk by just vacuuming (especially in the vacuum of space)... Then there is the problem that speeds are very high. A particle in a different orbit than your Roomba will probably go right through it, instead of being properly processed.
It is of course very easy to point at the Chinese for shattering a satellite into a thousand pieces, but don't forget that the US has their share of stupid mistakes as well. For example, in 1963 the US Military launched 480 million tiny needles into orbit (project West Ford), to see if they could be used to reflect radio signals. That did not work well, but the needles remained in orbit for years. And if scientists would not have been very opposed to it, they probably would have launched even more to see if the idea would work.
Also, it is difficult to say that space is "full" of junk. The LEO area has such a large volume that even hundres of millions of junk particles at a uniform distribution still means they are all many kilometers apart. So what is "full"?
He has personal investments in oil and relations with Saudi-Arabian oil magnats, and it is to his own advantage and that of his relations to drive up the oil price by unstabilizing Iraq.
It always amazes me that there are so few US citizens that recognize that. If I were living in a state governed by Bush, I would immediately see that the is heavily trying to spread fear, uncertainty and doubt only to his own advantage and adversely affecting the wellbeing of his citizens. Even if there is a real threat from terrorism, a one-day study of the matter would reveal that the best way to avoid terrorism is not to fight a war against the people you suspect of committing it. The second thing one would realize is that fear is what the terrorists want to spread, and it is unwise to help them with that.
There are a couple of things that you can do to avoid this kind of mishap:
- office workers should not work under an account with administrator privileges. when applications exist in the company that require administrator rights, they should be phased out. there is no excuse for still having such bad program code around in 2007.
- the user account being used should not have write permission in directories like/windows/program files etc. in our systems, the only directory with write permission is the user's own directory in/documents and settings.
- you can use a tool like "TrustNoExe" to allow program execution only from read-only directories (allow from C:\ deny from C:\Documents and Settings). this will prevent the user from executing programs written in %Temp%, like this exploit does. It also prevents execution of programs and pifs received by mail.
- you could also refuse incoming mail at the external mail MX with a source address internal to the company. that may be a problem in some special cases, though.
Apparently they read Slashdot. The article has been corrected. At the time I made my posting the article included the same fragment as quoted higher up in this thread. It included the slashes.
The linked article is correct in that they measure "energy consumption" rather than "power consumption", but they a wrong in expressing it in watts-per-hour instead of watt-hours.
The first IBM PC had a "technical manual" (available as an optional extra) that contained all the schematics and even a source listing of the BIOS. No disassembly required.
This was a truely open-source product. Had they not done this, the development of addon products and clones would have been much more difficult. (even though it was claimed that cloned systems had been "cleanroom" reverse-engineered from the specs, not copied from the technical manual, this would have been more difficult when a spec as detailed as the technical manual had not been available)
Had IBM not made their product open-source at that time, we now might all have been using Apple computers.
It often is near impossible to submit a bug report when you are not a user of their product,
If they "eat their own dogfood" they might have difficult reading any emails sent to them.
What I mean is that submitting a bug report is only possible when you register the software, and tell all kinds of details about it that you don't necessarily know as an outside observer (version, patches, platform it is running on, where it was obtained, etc). It seems they do not understand that a communicating piece of software may not only cause problems for its users, but also for the people that communicate with it (the other end). So it is plain silly that you can only report bugs as a registered user.
I had this setup for some time. See elsewhere. It breaks a NAI antivirus product, or at least some versions of it. (when there is a 550 reply from legit-mailserver.domain.com they will continue and try bar-blackhole.domain.com. when it is unreachable they stupidly queue the mail as "server not reachable for now" and try again and again and again...)
For a couple of years, I had the mail system at work running with about 5 MX records, of which only one really worked. There was a lowest MX value that always failed, then one that worked, and then 3 more that always failed. (over time there have been different responses on the failing MXes, from just no response to TCP RESET and even a "421" message)
It seems it sort of worked and spammers often tried the higher records, but there was a major problem with a NAI antivirus product: when someone would send a message to a nonexisting user in our domain and the working server sent back a 550 reply, that broken product would continue through the MX list (even though it is a final failure reply) and when the last MX in the list would not work, they kept the message on their queue and re-send it for the maximum attempt time. Without any retry interval backoff. A particular broken installation in our local municipality would attempt to re-send the message every 10 minutes for two days before it would return a delivery failure to the sender.
It took a lot of effort to convince NAI that this was a bug, but even though I think it was fixed in some later release it was never fixed in that installation and at some point I removed the extra MX records.
Firewalls and anti-spam appliances have often very broken SMTP implementations, and not only do they have bad support (when you report it is broken, you get a "it works with most servers so it must be YOUR server that is broken!") but also when an update IS released, it can take years before it is installed by the users.
However, I still believe that the best way to handle this situation is by not working around it. When users complain that a good fraction of their mail gets bounced for no apparent reason, there may be action. When you implement a workaround, things will remain as they are.
This does not only affect greylisting. I have seen bad SMTP bugs in NAI's virus checker, "SurfControl E-mail Filter", "logsat spamfilter for ISP", and another spamfilter whose name I forgot. tried to issue bug reports via their support system. It often is near impossible to submit a bug report when you are not a user of their product, and once you get through they are completely uninterested when you are not Microsoft or Sendmail. Pointing them to the RFC does not work at all, they fix bugs by the "if it delivers mail then it must be OK" paradigm.
I still consider it a very unfortunate decision that the Mozilla suite was split in Firefox and Thunderbird (dropping the composer). It was always possible to install only the browser, and the result of the split is that configuration information required for both programs is now fragmented, and that shared components like Gecko are no longer shared.
Unfortunately it does not look like Seamonkey will ever take over from Firefox and Thunderbird again, and we will have to live with this.
No. It means that when you have 182 drives in use for 3 years, about 3 of them will be defective. This cannot be extrapolated to the number of defects after 182 years, because the MTBF is only defined for a certain service life (like 3 or 5 years). After that, the number of failures will increase so the MTBF will decrease.
Incredible that you are so enthousiastic about Seagate when you have experience from those days. Most users back then have seen an ST-225 fail. The ST-238R was even worst (same drive but used with RLL instead of MFM).
As also explained by others, it is an average failure rate figure. It does not tell you how long it will take for one drive to fail, but it tells you how many of your drives will fail when you have a large number of them in use.
If Microsoft's patch will cause Windows XP (or Vista) to show the WRONG time for files saved near the DST change dates/times in years past, then it is NOT A FIX.
It doesn't. But that is because MS Windows has never done this correctly, even when the DST date does not change. Unix systems with a modern timezone library keep history about DST changes, and they can even be prepared for future algorithm changes as soon as they are decided, instead of having to be patched at exactly the right moment (after the last old-rule change and before the new rule takes effect).
Well, I am not really talking about price. Just about options. When I get a Dell Optiplex, I can run Windows (2000, XP, Vista), Linux or BSD. Probably even more. But no OS X. When the company has bought hundreds of Dell systems, there is no way they are going to get to OS X from where they are now. They would go to Vista.
So nobody should be surprised when more companies migrate from XP to Vista, no matter what the qualities of OS X are. Even when they do it only when buying new systems.
Would there exist an option of running OS X on a Dell (and probably some other common business machines, like HP) it surely would be a different story. But it is as you say, they are a hardware company and not interested in marketing their software. This will keep the markets as separate as they are now. No chance to convert customers over from the Windows world, and probably the same vice-versa. But that may still be the best option for them.
However, it is quite pointless to compare the systems in that case.
he doesn't say Vista is bad, just that technically speaking, OS X remains way ahead. Do you agree?
As long as OS X cannot run on the computers I have available at home or at work, I cannot compare. So it is impossible to make that judgement. And even when OS X would come out as superior, there is no way I would get my boss to discard all the investments in hardware and replace it with Apple, so there is no need to even think about evaluating the differences between the systems.
This is something Apple needs to fix. OS X must be running on PC hardware, even if only to evaluate it and be able to support a migration. As it is now, they are in certain markets where they are known, and outside of those markets they receive little or no attention. I have never touched a real MAC in my life, and the only thing I have seen of its software was emulation on my old Atari ST. But PCs are all around. So it is easy to look at Linux or whatever alternative OS to Windows, but very difficult to look at OS X.
a change in their process to let 1% of their customers pay $50 less is really a bad business decision
Why? There are many options in the customization screen that decrease the price, or are ticked by default and can be unticked to reduce the price.
I am surprised how many people dismiss the argument "because it is a small amount". They are entirely happy to pay a $50 tax to Microsoft "because it is a small amount not worth spending time on". What if this will become standard practice, and other companies start doing it on all kinds of products? You pay $50 extra on a CD player for a stack of music CDs, $50 on a home theatre for some DVDs you are not going to play, $50 on a switch for a year subscription on LAN Magazine, etc etc etc. All of course with a possible refund after an hour-long phone call.
Would you still put up with that?
You mention the company that works on a narrow margin, but at the same time you enrich the richtest man on earth by paying for a product you do not even want to use. That has got to end...
About 20 years ago, we had an NCR Tower 1632 computer, an 8MHz 68000 machine with 1MB of RAM. It ran Unix. There were two 8-port serial boards in it, and about 14 serial terminals connected for users. Those could operate at 19200 baud without trouble.
Then, there was the MODEM to use for UUCP connection. It was an all-new-tech 2400 baud modem, but it had to be locked down to 1200 because the entire machine would choke when the data was coming in at a whopping 2400 baud.
It turned out to be like this: the 8-port serial boards were "intelligent". They had their own micro that serviced the ports and communicated with the main processor using some protocol that apparently could transfer largish blocks of data quite efficiently. So the terminals, that were mostly-output, worked fine on it. Blocks of characters were transferred to the serial boards and sent at 19200. Receiving was a different story. Apparently the boards cooked up transfer blocks of only one character in size, not knowing how much they could buffer and combine without upsetting the particular protocol running on the line (they were not using information from the serial port ioctls to know that). The overhead of transferring such a buffer was so high that the system could not do it quickly enough, resulting in many overruns and general slowness of the system. At 1200 baud it could cope.
Ironically, it would have worked just fine when that entire coprocessor crap had been left out and 16 uarts were directly interrupting the main 68000. With efficiently coded interrupt handlers it could have well handled the load.
(not the first and not the last time I have observed "cpu offloading" solutions that in practice were more of a drag than an improvement)
Slashdot Mirror
The point is that the (abstract of) the article is along the lines of "now that China has added 1000 pieces of junk, LEO is nearly full".
I tried to explain that the US has launched many more pieces of junk, sometimes very useless too. And that it clearly is not "full" but just hitting some arbitrary limit.
I don't want to advocate the launch of arbitrary junk into space. But those that are without sin, should throw the first stone. Not NASA or the USA.
Doing something about it is a different matter. But that can be done without fingerpointing.
One reason this is not so simple, is that there is so much space to vacuum. You will not find much junk by just vacuuming (especially in the vacuum of space)...
Then there is the problem that speeds are very high. A particle in a different orbit than your Roomba will probably go right through it, instead of being properly processed.
It is of course very easy to point at the Chinese for shattering a satellite into a thousand pieces, but don't forget that the US has their share of stupid mistakes as well.
For example, in 1963 the US Military launched 480 million tiny needles into orbit (project West Ford), to see if they could be used to reflect radio signals.
That did not work well, but the needles remained in orbit for years.
And if scientists would not have been very opposed to it, they probably would have launched even more to see if the idea would work.
Also, it is difficult to say that space is "full" of junk. The LEO area has such a large volume that even hundres of millions of junk particles at a uniform distribution still means they are all many kilometers apart. So what is "full"?
He has personal investments in oil and relations with Saudi-Arabian oil magnats, and it is to his own advantage and that of his relations to drive up the oil price by unstabilizing Iraq.
It always amazes me that there are so few US citizens that recognize that. If I were living in a state governed by Bush, I would immediately see that the is heavily trying to spread fear, uncertainty and doubt only to his own advantage and adversely affecting the wellbeing of his citizens.
Even if there is a real threat from terrorism, a one-day study of the matter would reveal that the best way to avoid terrorism is not to fight a war against the people you suspect of committing it. The second thing one would realize is that fear is what the terrorists want to spread, and it is unwise to help them with that.
There are a couple of things that you can do to avoid this kind of mishap:
/windows /program files etc. in our systems, the only directory with write permission is the user's own directory in /documents and settings.
- office workers should not work under an account with administrator privileges. when applications exist in the company that require administrator rights, they should be phased out. there is no excuse for still having such bad program code around in 2007.
- the user account being used should not have write permission in directories like
- you can use a tool like "TrustNoExe" to allow program execution only from read-only directories (allow from C:\ deny from C:\Documents and Settings). this will prevent the user from executing programs written in %Temp%, like this exploit does. It also prevents execution of programs and pifs received by mail.
- you could also refuse incoming mail at the external mail MX with a source address internal to the company. that may be a problem in some special cases, though.
Apparently they read Slashdot. The article has been corrected.
At the time I made my posting the article included the same fragment as quoted higher up in this thread. It included the slashes.
The linked article is correct in that they measure "energy consumption" rather than "power consumption", but they a wrong in expressing it in watts-per-hour instead of watt-hours.
They measure "power consumption", express it in "watts per hour" and still expect us to take them seriously?
The first IBM PC had a "technical manual" (available as an optional extra) that contained all the schematics and even a source listing of the BIOS.
No disassembly required.
This was a truely open-source product. Had they not done this, the development of addon products and clones would have been much more difficult.
(even though it was claimed that cloned systems had been "cleanroom" reverse-engineered from the specs, not copied from the technical manual, this would have been more difficult when a spec as detailed as the technical manual had not been available)
Had IBM not made their product open-source at that time, we now might all have been using Apple computers.
It often is near impossible to submit a bug report when you are not a user of their product,
If they "eat their own dogfood" they might have difficult reading any emails sent to them.
What I mean is that submitting a bug report is only possible when you register the software, and tell all kinds of details about it that you don't necessarily know as an outside observer (version, patches, platform it is running on, where it was obtained, etc).
It seems they do not understand that a communicating piece of software may not only cause problems for its users, but also for the people that communicate with it (the other end). So it is plain silly that you can only report bugs as a registered user.
I had this setup for some time. See elsewhere. It breaks a NAI antivirus product, or at least some versions of it.
(when there is a 550 reply from legit-mailserver.domain.com they will continue and try bar-blackhole.domain.com. when it is unreachable they stupidly queue the mail as "server not reachable for now" and try again and again and again...)
For a couple of years, I had the mail system at work running with about 5 MX records, of which only one really worked.
There was a lowest MX value that always failed, then one that worked, and then 3 more that always failed.
(over time there have been different responses on the failing MXes, from just no response to TCP RESET and even a "421" message)
It seems it sort of worked and spammers often tried the higher records, but there was a major problem with a NAI antivirus product: when someone would send a message to a nonexisting user in our domain and the working server sent back a 550 reply, that broken product would continue through the MX list (even though it is a final failure reply) and when the last MX in the list would not work, they kept the message on their queue and re-send it for the maximum attempt time. Without any retry interval backoff.
A particular broken installation in our local municipality would attempt to re-send the message every 10 minutes for two days before it would return a delivery failure to the sender.
It took a lot of effort to convince NAI that this was a bug, but even though I think it was fixed in some later release it was never fixed in that installation and at some point I removed the extra MX records.
Firewalls and anti-spam appliances have often very broken SMTP implementations, and not only do they have bad support (when you report it is broken, you get a "it works with most servers so it must be YOUR server that is broken!") but also when an update IS released, it can take years before it is installed by the users.
However, I still believe that the best way to handle this situation is by not working around it. When users complain that a good fraction of their mail gets bounced for no apparent reason, there may be action. When you implement a workaround, things will remain as they are.
This does not only affect greylisting. I have seen bad SMTP bugs in NAI's virus checker, "SurfControl E-mail Filter", "logsat spamfilter for ISP", and another spamfilter whose name I forgot. tried to issue bug reports via their support system. It often is near impossible to submit a bug report when you are not a user of their product, and once you get through they are completely uninterested when you are not Microsoft or Sendmail. Pointing them to the RFC does not work at all, they fix bugs by the "if it delivers mail then it must be OK" paradigm.
I still consider it a very unfortunate decision that the Mozilla suite was split in Firefox and Thunderbird (dropping the composer).
It was always possible to install only the browser, and the result of the split is that configuration information required for both programs is now fragmented, and that shared components like Gecko are no longer shared.
Unfortunately it does not look like Seamonkey will ever take over from Firefox and Thunderbird again, and we will have to live with this.
No. It means that when you have 182 drives in use for 3 years, about 3 of them will be defective.
This cannot be extrapolated to the number of defects after 182 years, because the MTBF is only defined for a certain service life (like 3 or 5 years).
After that, the number of failures will increase so the MTBF will decrease.
Incredible that you are so enthousiastic about Seagate when you have experience from those days.
Most users back then have seen an ST-225 fail. The ST-238R was even worst (same drive but used with RLL instead of MFM).
As also explained by others, it is an average failure rate figure. It does not tell you how long it will take for one drive to fail, but it tells you how many of your drives will fail when you have a large number of them in use.
Before you think that this means it has a lifetime of 182 years: this is not the case. The definition of MTBF is not related to lifetime.
You are assuming an administrator that knows more than "doubleclick setup.exe then click NEXT NEXT NEXT FINISH".
/s somefile.reg" on each system apparently is beyond what you can expect.
Those are rare, and the dumbing-down that is popular in operating systems will not make that better.
Running a "regedit
If Microsoft's patch will cause Windows XP (or Vista) to show the WRONG time for files saved near the DST change dates/times in years past, then it is NOT A FIX.
It doesn't. But that is because MS Windows has never done this correctly, even when the DST date does not change.
Unix systems with a modern timezone library keep history about DST changes, and they can even be prepared for future algorithm changes as soon as they are decided, instead of having to be patched at exactly the right moment (after the last old-rule change and before the new rule takes effect).
It seems Windows users are not really interested.
Well, I am not really talking about price. Just about options.
When I get a Dell Optiplex, I can run Windows (2000, XP, Vista), Linux or BSD. Probably even more. But no OS X.
When the company has bought hundreds of Dell systems, there is no way they are going to get to OS X from where they are now. They would go to Vista.
So nobody should be surprised when more companies migrate from XP to Vista, no matter what the qualities of OS X are. Even when they do it only when buying new systems.
Would there exist an option of running OS X on a Dell (and probably some other common business machines, like HP) it surely would be a different story.
But it is as you say, they are a hardware company and not interested in marketing their software.
This will keep the markets as separate as they are now. No chance to convert customers over from the Windows world, and probably the same vice-versa.
But that may still be the best option for them.
However, it is quite pointless to compare the systems in that case.
he doesn't say Vista is bad, just that technically speaking, OS X remains way ahead. Do you agree?
As long as OS X cannot run on the computers I have available at home or at work, I cannot compare. So it is impossible to make that judgement.
And even when OS X would come out as superior, there is no way I would get my boss to discard all the investments in hardware and replace it with Apple, so there is no need to even think about evaluating the differences between the systems.
This is something Apple needs to fix. OS X must be running on PC hardware, even if only to evaluate it and be able to support a migration.
As it is now, they are in certain markets where they are known, and outside of those markets they receive little or no attention.
I have never touched a real MAC in my life, and the only thing I have seen of its software was emulation on my old Atari ST.
But PCs are all around. So it is easy to look at Linux or whatever alternative OS to Windows, but very difficult to look at OS X.
a change in their process to let 1% of their customers pay $50 less is really a bad business decision
Why? There are many options in the customization screen that decrease the price, or are ticked by default and can be unticked to reduce the price.
I am surprised how many people dismiss the argument "because it is a small amount". They are entirely happy to pay a $50 tax to Microsoft "because it is a small amount not worth spending time on".
What if this will become standard practice, and other companies start doing it on all kinds of products?
You pay $50 extra on a CD player for a stack of music CDs, $50 on a home theatre for some DVDs you are not going to play, $50 on a switch for a year subscription on LAN Magazine, etc etc etc.
All of course with a possible refund after an hour-long phone call.
Would you still put up with that?
You mention the company that works on a narrow margin, but at the same time you enrich the richtest man on earth by paying for a product you do not even want to use.
That has got to end...
About 20 years ago, we had an NCR Tower 1632 computer, an 8MHz 68000 machine with 1MB of RAM. It ran Unix.
There were two 8-port serial boards in it, and about 14 serial terminals connected for users. Those could operate at 19200 baud without trouble.
Then, there was the MODEM to use for UUCP connection. It was an all-new-tech 2400 baud modem, but it had to be locked down to 1200 because the entire machine would choke when the data was coming in at a whopping 2400 baud.
It turned out to be like this: the 8-port serial boards were "intelligent". They had their own micro that serviced the ports and communicated with the main processor using some protocol that apparently could transfer largish blocks of data quite efficiently. So the terminals, that were mostly-output, worked fine on it. Blocks of characters were transferred to the serial boards and sent at 19200.
Receiving was a different story. Apparently the boards cooked up transfer blocks of only one character in size, not knowing how much they could buffer and combine without upsetting the particular protocol running on the line (they were not using information from the serial port ioctls to know that). The overhead of transferring such a buffer was so high that the system could not do it quickly enough, resulting in many overruns and general slowness of the system. At 1200 baud it could cope.
Ironically, it would have worked just fine when that entire coprocessor crap had been left out and 16 uarts were directly interrupting the main 68000. With efficiently coded interrupt handlers it could have well handled the load.
(not the first and not the last time I have observed "cpu offloading" solutions that in practice were more of a drag than an improvement)