We have had very good archival quality CD's already. For example, Kodak Gold and Mitsui Gold. Both manufacturers published extensive technical documents about accelerated age testing under extreme conditions, and the results indicated lifetimes greater than 100 years in normal or good storage conditions. The reflective surface was real gold, the dye used was the "good one" (phthalocyanine), and there was a decent top layer over the reflective surface (IMHO Kodak was the clear winner here).
The difficulty is that these disks cost a dollar or two each. Compare this with the el-cheapo ones that sell by the billions. Few mass consumers bought the good CD's, and Kodak stopped making them entirely and the Mitsui's are now specialty products that are not widely available.
There's also been a major shift in where and how CD-R's are manufactured. At first they were high-spec products, made in a few select factories in the US and Japan. Then manufacturing scaled up and cheaped out as the plants moved to Taiwan. Now a lot of those plants are going even lower-budget and moving to Mexico and mainland China.
The point is that consumers rarely buy for longevity... they go for neat packaging or cheap price or high burn speed or something else. The CD manufacturers have learned that lesson well. That's why it's so hard to buy good archival CD-R's anymore.
While the goal of the project currently seems to be to play the
kid's movies on a PC instead of the VIDEONOW, doing the
reverse seems far more interesting to me. It seems to me that it'd
be straightforward to take any video material (episodes of Friends, baby pictures, whatever you've got), reduce it to 80x80 grayscale, burn it to a CD, and play it back on your own little $50 player.
When I was a kid, the much-wanted equivalent to this was a Fisher-Price movie projector that had a little screen and took cartridge filmstrips. The movies were at best a few minutes long and there was no sound. Twenty or thirty years later I see these for sale on E-bay.
I never had one of those, but my Dad would go to yard sales and brought home a circa 1955 equivalent which was marketed by Disney and had clips from the Mickey Mouse club and other short cartoons. This was much cooler IMHO.
The NY Times editorial has a good perspective in the manager vs engineer battle, but in the end we will never have a pefectly safe mode of travel (on or off earth) because Safety Costs Money.
Now that money may be in the form of lower gas mileage in a car, or in the form of hundreds of unmanned test flights before putting a human in, or obscene safety margins.
But to pretend that anything is ever perfectly safe is to ignore the fundamental economic issue that at some point you have to stop putting money into safety concerns and just fly the damn thing.
If it weren't for them, I feel there would be a thriving underground economy of industrial
espionage and personal information theft because it would be so easy.
There is such a thriving underground economy, and
it is ridiculously easy. You don't even have to break into the system - companies mail around Microsoft Word documents and Excel spreadsheets with the undelete buffer still in them. Back off the changes and you see their internal notes, or the previous customer/client they talked to.
Or guess URL's based on patterns commonly used. (This made the newspapers when it was discovered how easy it was to get embargoed SEC documents and rulings ahead of schedule). Or increment UPS tracking numbers to find out who a company's other clients/customers are. etc.
It turns out that the wu-ftpd report for the crack of alpha.gnu.org on slashdot was in fact wrong, and in fact alpha.gnu.org wasn't even running wuftpd. It was "just" the linux kernel ptrace vulnerability and a local user.
My information that the GNU alpha.gnu.org compromise was due to wu-ftpd came from this quote posted to slashdot after the compromise:
iSEC Security Research reports that wu-ftpd contains an off-by-one bug in the fb_realpath function which could be exploited by a logged-in user (local or anonymous) to gain root privileges. A demonstration exploit is reportedly available.
BIND was originally was an implementation in C of Jeeves, which was the original PDP-10 DNS implementation. This explains some of the cruft (but in fact I don't feel that BIND has all that much cruft).
Sendmail started out with lots of regex ability because it was designed from the start to route mail not only through SMTP but into/out-of other mail systems - i.e. uucp mail, bang paths, corporate-internal mail systems, etc. So it needed to be able to dynamically rewrite and forward mail to non-SMTP systems.
This configurability honestly isn't needed today in 99% of cases. The number of people I know who need a bang-path to get mail to them (uucp) is now down to two.
But the ability to do things dynamically in sendmail through its configuration file isn't necessarily a weakness, the regex abilities are often used for other things today.
Citing a long history of security holes and patches is one way of justifying going with a less-populare but maybe more secure package. Right off the top of my head are these long-standing open-source packages with long histories of security holes:
wu-ftpd. Most recently known for the crack of alpha.gnu.org.
sendmail. "Not having sendmail is like not having VD", according to popular wisdom
vixie-cron. I don't even know of a "virgin" distribution of this, which is probably a good thing; all the Linux vendors have their own set of extensive patches to vixie-cron.
There are multiple choices for replacing each of these, most of them a written-from-scratch replacement. Not all of these are perfect, either, but at least they're less popular, so (hopefully?) less likely to get hacked.
I personally run fcron, postfix, and proftpd instead of the more popular packages. I don't honestly claim that they're any more secure, in all cases they were mostly personal choices having to do with cleanness/installation ease.
Train Control and Signalling systems are universally designed for Fail Safe == Stop Working. The low-level, safety critical systems are controlled with very low-tech Vital Relays which which will stop train movement and/or make all the signals present a Red Aspect in case of computer failure, and that's what they did.
Train control has this luxury. Computer systems onboard airplanes do not... simply turning off jet engines in case of computer failure is not an appealing possibility.
If you're going to Japan with your wife for an extended period, it'll work out that your wife gets a student visa and you get tacked onto it. (In computerese, your visa will reference hers.) Your wife's visa will say that she's not allowed to work in Japan, just go to school, and your visa will say that you're not allowed to work or study in Japan.
Now, it is very likely that no Japanese officials will ever find out if you never tell them, but you and your wife will have to lie every time you enter/leave Japan or renew visas. It's not the hardest lie in the world to make, but you will arouse additional suspiscion if you ever go back to the US on business.
I'm a distributor. If you modify the code and give it to anyone, you're a distributor. If you download the code and then make a copy, SCO also classifies you as a distributor.
Please, do not go down the slippery slope of thinking that only Red Hat will have to go to trial if SCO has its way. Everyone who has ever been involved with free software by necessity made a "copy" and will get dragged to court by your "distributor" argument. This is not SCO vs Red Hat and IBM, this is SCO vs everyone who has ever done GPL software.
This means the companies, users using linux aree insulated because their case will not proceed until the above cases are solved.
That means SCO can kiss my ass.
Not so simple for me and many others... lots of us run Linux, but do not run a commercial distribution. We build the kernel (or everything) from the sources, downloaded over the net.
The Umbrella you're postulating doesn't protect us unless we get the contested code from a commercial distribution. That kind-of violates the spirit of the GPL and free software.
I agree completely. I run my machines for weeks with memtest86 before making them operational. And while I have found memory and motherboard problems, even with the most el-cheapo power supply it's either success or failure. This sort of reliably intermittent memory test failure that Anandtech regards as "normal" puzzles me to no end. Maybe it's just part of overclocker attitude?
They already have something like that at the post office, it's called Delivery Confirmation and it costs about 40 cents extra to get it on a parcel.
Delivery confirmation is part-way there but not
all the way there. Database-wise only a single
entry is made, and that's at the point of delivery. I think that what is being proposed tracks every item through every single step of the entry/sorting/distribution/sorting/distribution/so rting/delivery process, in particular down to the "which sorting machine and which person touched the item and when and in what order", something vastly more ambitious.
This isn't too different than how UPS and Fedex currently track packages. It's not all that difficult to send a package via UPS or Fedex semi-anonymously, but I doubt that more than a few percent of their shipments go that way.
UPS, in particular, has the 2-D barcode, and I don't have any idea what's encoded in that. Both UPS and Fedex certainly have "Tracking numbers" which is an effectively unique identifier in their databases for everything to do with a particular package, even if all that information isn't encoded on the package itself.
yet over a 6 hour time there was a range of only 1
up to 7 memory errors.
Gees, I run my systems for years without a single memory error (mix of parity and ECC systems under my control). What the fuck was AnandTech doing wrong?
The view of this (and other reports) is towards the "big fish in the big pond" - in other words, Intel. Anything not Intel-related is simply not on their radar.
It sucks, but that's the way it is.
In total units sold, by far the biggest selling microprocessors are 8051 derivatives, there are literally billions sold every year. But these aren't 80x86 compatible so they don't even know how to classify these sales.
Because "Market share" is by total dollars sold, and not by numbers of processors sold, Intel gets a very real boost in these figures.
OTOH the low-end sellers (like Via and Transmeta who target set-top and embedded devices) end up
underrepresented because their processors are so cheap (or in some cases not even sold at retail).
Now clearly, this is a business report so only those who make big bucks count there. I'm just pointing out that the methodology, by design, ignores trends towards lower-cost pervasive computing.
I don't use Gentoo, but I do use Linux From Scratch, and I do see substantial improvements with command-line type activities:
A kernel build on a Athlon is about 20 percent faster when I do it with a custom LFS build vs a stock RedHat installation.
Most of the comparisons in the article were for X-related graphics applications, and while they were comparing the versions of the applications, they were not comparing the libraries underneath them (glibc, X11, and probably the window manager too come into play) and they should've compared versions there too. It becomes complicated because for a typical X11-based app there are probably
several dozen libraries involved (in addition to all the configure-time options for them...)
At least 5 years ago it was fairly common
knowledge that if you found any webserver's
access_log you would get some juicy URL's. The
method still works...
Don't just complain, DO SOMETHING
on
Software Archaeology
·
· Score: 3, Informative
I know it's far easier to complain about the situation rather than do something about it. But there are groups doing something about it:
The difficulty is that these disks cost a dollar or two each. Compare this with the el-cheapo ones that sell by the billions. Few mass consumers bought the good CD's, and Kodak stopped making them entirely and the Mitsui's are now specialty products that are not widely available.
There's also been a major shift in where and how CD-R's are manufactured. At first they were high-spec products, made in a few select factories in the US and Japan. Then manufacturing scaled up and cheaped out as the plants moved to Taiwan. Now a lot of those plants are going even lower-budget and moving to Mexico and mainland China.
The point is that consumers rarely buy for longevity... they go for neat packaging or cheap price or high burn speed or something else. The CD manufacturers have learned that lesson well. That's why it's so hard to buy good archival CD-R's anymore.
While the goal of the project currently seems to be to play the kid's movies on a PC instead of the VIDEONOW, doing the reverse seems far more interesting to me. It seems to me that it'd be straightforward to take any video material (episodes of Friends, baby pictures, whatever you've got), reduce it to 80x80 grayscale, burn it to a CD, and play it back on your own little $50 player.
I never had one of those, but my Dad would go to yard sales and brought home a circa 1955 equivalent which was marketed by Disney and had clips from the Mickey Mouse club and other short cartoons. This was much cooler IMHO.
Actually, LFS is a little more like buying a "make beer at home" kit than true homebrew, but that's a minor nit...
Now that money may be in the form of lower gas mileage in a car, or in the form of hundreds of unmanned test flights before putting a human in, or obscene safety margins.
But to pretend that anything is ever perfectly safe is to ignore the fundamental economic issue that at some point you have to stop putting money into safety concerns and just fly the damn thing.
There is such a thriving underground economy, and it is ridiculously easy. You don't even have to break into the system - companies mail around Microsoft Word documents and Excel spreadsheets with the undelete buffer still in them. Back off the changes and you see their internal notes, or the previous customer/client they talked to.
Or guess URL's based on patterns commonly used. (This made the newspapers when it was discovered how easy it was to get embargoed SEC documents and rulings ahead of schedule). Or increment UPS tracking numbers to find out who a company's other clients/customers are. etc.
It turns out that the wu-ftpd report for the crack of alpha.gnu.org on slashdot was in fact wrong, and in fact alpha.gnu.org wasn't even running wuftpd. It was "just" the linux kernel ptrace vulnerability and a local user.
BIND was originally was an implementation in C of Jeeves, which was the original PDP-10 DNS implementation. This explains some of the cruft (but in fact I don't feel that BIND has all that much cruft).
This configurability honestly isn't needed today in 99% of cases. The number of people I know who need a bang-path to get mail to them (uucp) is now down to two.
But the ability to do things dynamically in sendmail through its configuration file isn't necessarily a weakness, the regex abilities are often used for other things today.
- wu-ftpd. Most recently known for the crack of alpha.gnu.org.
- sendmail. "Not having sendmail is like not having VD", according to popular wisdom
- vixie-cron. I don't even know of a "virgin" distribution of this, which is probably a good thing; all the Linux vendors have their own set of extensive patches to vixie-cron.
There are multiple choices for replacing each of these, most of them a written-from-scratch replacement. Not all of these are perfect, either, but at least they're less popular, so (hopefully?) less likely to get hacked.I personally run fcron, postfix, and proftpd instead of the more popular packages. I don't honestly claim that they're any more secure, in all cases they were mostly personal choices having to do with cleanness/installation ease.
Train control has this luxury. Computer systems onboard airplanes do not... simply turning off jet engines in case of computer failure is not an appealing possibility.
Now, it is very likely that no Japanese officials will ever find out if you never tell them, but you and your wife will have to lie every time you enter/leave Japan or renew visas. It's not the hardest lie in the world to make, but you will arouse additional suspiscion if you ever go back to the US on business.
Please, do not go down the slippery slope of thinking that only Red Hat will have to go to trial if SCO has its way. Everyone who has ever been involved with free software by necessity made a "copy" and will get dragged to court by your "distributor" argument. This is not SCO vs Red Hat and IBM, this is SCO vs everyone who has ever done GPL software.
The Umbrella you're postulating doesn't protect us unless we get the contested code from a commercial distribution. That kind-of violates the spirit of the GPL and free software.
I agree completely. I run my machines for weeks with memtest86 before making them operational. And while I have found memory and motherboard problems, even with the most el-cheapo power supply it's either success or failure. This sort of reliably intermittent memory test failure that Anandtech regards as "normal" puzzles me to no end. Maybe it's just part of overclocker attitude?
Delivery confirmation is part-way there but not all the way there. Database-wise only a single entry is made, and that's at the point of delivery. I think that what is being proposed tracks every item through every single step of the entry/sorting/distribution/sorting/distribution/so rting/delivery process, in particular down to the "which sorting machine and which person touched the item and when and in what order", something vastly more ambitious.
UPS, in particular, has the 2-D barcode, and I don't have any idea what's encoded in that. Both UPS and Fedex certainly have "Tracking numbers" which is an effectively unique identifier in their databases for everything to do with a particular package, even if all that information isn't encoded on the package itself.
Whatever happened to the grandaddy of all govt information systems, SCMODS = State County Municipal Offender Data System?
It works on so many levels!, according to reviewer Homer Simpson.
Gees, I run my systems for years without a single memory error (mix of parity and ECC systems under my control). What the fuck was AnandTech doing wrong?
It sucks, but that's the way it is.
In total units sold, by far the biggest selling microprocessors are 8051 derivatives, there are literally billions sold every year. But these aren't 80x86 compatible so they don't even know how to classify these sales.
OTOH the low-end sellers (like Via and Transmeta who target set-top and embedded devices) end up underrepresented because their processors are so cheap (or in some cases not even sold at retail).
Now clearly, this is a business report so only those who make big bucks count there. I'm just pointing out that the methodology, by design, ignores trends towards lower-cost pervasive computing.
Most of the comparisons in the article were for X-related graphics applications, and while they were comparing the versions of the applications, they were not comparing the libraries underneath them (glibc, X11, and probably the window manager too come into play) and they should've compared versions there too. It becomes complicated because for a typical X11-based app there are probably several dozen libraries involved (in addition to all the configure-time options for them...)
At least 5 years ago it was fairly common knowledge that if you found any webserver's access_log you would get some juicy URL's. The method still works...