There's another way to make polycrystalline (as opposed to single crystals) ceramics transparent: Make the grains smaller than the wavelength of light you're trying to transmit, eliminate porosity completely, and eliminate the sintering aids that go to the grain boundaries and fudge up the refractive index there.
Transparent polycrystalline alumina (not aluminum) has been in regular use for 40+ years. It's called Lucalox by GE and is the refractory material that makes up the tube used to hold the molten sodium in all those yellow/orange sodium streetlamps.
I'm assuming this is what the camera lens is made of, but have nothing to back that up with.
As a side note, you may have noticed that every few years someone publishes a paper on a new way to make transparent polycrystalline alumina, then the non-materials-science media (*cough slashdot*) catches wind and assumes alumina is the same thing as aluminum, and suddenly the prophecy of transparent aluminum from Star Trek IV has come true. It's sort of a running joke in the materials science community.
It serves mentioning that going back through the past few directors, ECS has been much more iron-fisted with the control they want to place on the machines connected to their network than TD has been. Granted, it's like comparing apples to oranges, but isn't that what the original poster was doing in the first place?
Side note...didn't know there were so many of us RU folks on slashdot...I myself work in td, for NetSys. Drop me a line.
This is indeed possible with many of the Archos mp3 players, which take standard 9.5mm 2.5 inch IDE drives. I don't know what the capacity limit of the device firmware is exactly, but 40 GB is possible and quite inexpensive (~US$130 for an IBM Travelstar the last time I looked). In fact, several vendors sell new Archos Recorders pre-modded with 40 GB drives (warantee voided, of course).
This has been discussed in several Archos forums and on the Rockbox mailing list.
I personally have a laptop with a 40 GB drive which is nearing capacity. When the price of 60 or 80 GB 2.5" drives drops some, I plan on buying one of these big drives, then putting the laptop's 40G into my Archos 20 which I never thought I'd fill...
A couple of years ago I had a brain fart where I was (humorously enough) making a boot floppy so I could convert my root fs from ext2 to ext3.
Instead of dd if=/tmp/imagefile.img of=/dev/fd0 bs=1440k,
I did dd if=/tmp/imagefile.img of=/dev/hda bs=1440k
Whoops. After restoring my MBR and partition table, I still had to deal with the fact that I overwrote the first 1438KB of my root filesystem with effectively random data.
e2fsck -y/dev/hda run about 10 times took care of the filesystem's integrity, but I still had about 200 "files" in/lost+found of all sorts of random sizes, names, and types (pipes, fifos, regular, dev entries). The problem was that when I'd try to perform a file operation on any of the files, the kernel would get pissed off saying that the file size was too large, since the inode had random data listed as the filesize, and the operation would fail.
The way I finally fixed it was by running tune2fs and removing the file by hand. It's fairly straightforward, since tune2fs has an interface similar to file navigation from a shell prompt (ls, cd, etc). Just navigate to the target directory and remove the inode listed (by ls) as the inode associated with the file in question. You probably want to run e2fsck one more time to be sure.
Happy ending: I'm still using the filesystem that dd stomped all over and luckily lost only a handful of unimportant files.
How about "Cause Rob wanted to and it's his website." I give wicked props to the job Rob and Hemos did even back when they weren't getting paid for it.
Quit whining and set up a better site if you dont like the way/. does it.
If you remember correctly, it was JC News (dont remember the site, maybe jcnews.com?) that broke the story about the power cycling issue. JC himself had worked for Dell for a couple of months after being turned from temp to perm and they Dell fired him for it. JC claims that he got his info from someone else inside Dell, but they fired him because he was still in his probationary period, and they could.
I agree for the most part with what Mike Dell said about AMD's incompatilility (tho its not true for current athlons), but don't paint him as an impartial observer.
AMD is working really hard trying to push a dual-proc chipset out, but are running behind schedule. Their first estimate was 'late 2000' and now it looks like 1H2001.
I think they'll be called the Irongate 960 and 980 or something like that.
FWIW--I believe that Gateway uses fairly commonly available motherboards (used to be Intel for the socket sevens, probably the same now for the slot 1's). Also, IIRC one of those MS/Intel/Compaq PC specs (eg PC97) set up a port color-coding standard, so many of the mobo manufacturers are now adhering to them. A cool thing indeed, says I.
Red Hat had a lot of momentum going last week after the finding of fact for Micros~1. It jumped something like 15 points the day it was announced. Red Hat is a market sweetheart right now, getting a ton of financial publicity, and people (not just geeks) are being very sensitive to ANY reason to put money into RHAT.
IMHO that's why a relatively minor announcement kicked the stock price (hence, valuation of the company) up ~10%.
Au contraire, no AMD with the K6 core supports OpenPIC, however the K5 and all post-6x86 Cyrix processors do. When the K6 came out, AMD believed that nobody would ever come out with an OpenPIC board, so supporting it would be a waste of silicon. Unfortunately, they were right (except for CHRP compliant PowerPC boards, and there are very few of them).
I'm very very glad that the K7 supports multiprocessing, although it is not via the OpenPIC standard. IMHO OpenPIC is (was) an awesome standard, with virtually unlimited processors and IRQ's. But it looks like it has betamax'd by now.
Im not convinced that the K7 being more expensive than the PIII is totally a bad thing for AMD. I used to sell computers, and it was difficult trying to sell the "budget" amd to newbie computer buyers while saying "trust me...it's faster. Better for almost anything. AMD is a good brand...they're not like a generic chip..." Intel is like the Nabisco of processors, and trying to convince typical consumers to switch to a cheaper "knockoff" can be difficult. If AMD can position the K7 as a premium product that you pay a LITTLE more for, it may turn their image around.
A minor correction on your last point: you are correct in saying that the interface speed isn't that much different, but three factors that scsi is still far superior to IDE in are: expandability to more than 2 drives/channel, simulataneous data transfer to multiple drives on the same channel, and CPU usage.
Re:Will AMD survive until next year? Prob. not...
on
AMD Athlon (K7) Ships
·
· Score: 1
AMD supported OpenPIC with their K5 (as well as Cyrix with every 6x86 and M2 chip made), but dropped it in K6 for lack of mobo support. I'd imagine that the K7 uses OpenPIC as the multiprocessor protocol. AFAIK, OpenPIC has no limit on processors, or maybe it's 255. Anyway, the limit's more than you'll ever fit into a standard box. Of course that's the standard, and making an 8+ processor machine work may never be feasible.
Another thing: the openPIC standard defined that the architecture had 255 IRQ's! Granted, they're not such a big deal today due to PCI and USB (heh), but back then (1994-1995), we were all fighting with ISA cards and conflicts. And a heavily loaded PC would run out of IRQ's damn fast.
Everything I'd read about the K7 was that it was designed from the ground up as a high clock rate chip. At first I thought this was pure marketing bunk...that all fast chips were "designed for high clock rates". More reading revealed I wasn't totally right. Basically, the chip was built to be more forgiving to higher clock rates, with higher cache latencies and the like. Sorry for my vagueness, but apparently the K6 was designed with minimum cache latency, making it do a lot per clock cycle, but at the same time making it very unforgiving to slight manufacturing defects and high speeds. So it looks like the K7 should be pretty o/c'able. Also dont forget that the later.25 um chips should be more oc'able, as they refine the fab process, and of course they should go through the roof when both of amd's fabs go.18u.
Slashdot Mirror
I think that was the last MS product I used that I never saw crash. Not sure how you'd teach it to double-clutch though.
4:path=c:\dos\not_pr0n
There's another way to make polycrystalline (as opposed to single crystals) ceramics transparent: Make the grains smaller than the wavelength of light you're trying to transmit, eliminate porosity completely, and eliminate the sintering aids that go to the grain boundaries and fudge up the refractive index there.
Transparent polycrystalline alumina (not aluminum) has been in regular use for 40+ years. It's called Lucalox by GE and is the refractory material that makes up the tube used to hold the molten sodium in all those yellow/orange sodium streetlamps.
I'm assuming this is what the camera lens is made of, but have nothing to back that up with.
As a side note, you may have noticed that every few years someone publishes a paper on a new way to make transparent polycrystalline alumina, then the non-materials-science media (*cough slashdot*) catches wind and assumes alumina is the same thing as aluminum, and suddenly the prophecy of transparent aluminum from Star Trek IV has come true. It's sort of a running joke in the materials science community.
It serves mentioning that going back through the past few directors, ECS has been much more iron-fisted with the control they want to place on the machines connected to their network than TD has been. Granted, it's like comparing apples to oranges, but isn't that what the original poster was doing in the first place?
Side note...didn't know there were so many of us RU folks on slashdot...I myself work in td, for NetSys. Drop me a line.
This is indeed possible with many of the Archos mp3 players, which take standard 9.5mm 2.5 inch IDE drives. I don't know what the capacity limit of the device firmware is exactly, but 40 GB is possible and quite inexpensive (~US$130 for an IBM Travelstar the last time I looked). In fact, several vendors sell new Archos Recorders pre-modded with 40 GB drives (warantee voided, of course). This has been discussed in several Archos forums and on the Rockbox mailing list. I personally have a laptop with a 40 GB drive which is nearing capacity. When the price of 60 or 80 GB 2.5" drives drops some, I plan on buying one of these big drives, then putting the laptop's 40G into my Archos 20 which I never thought I'd fill...
A couple of years ago I had a brain fart where I was (humorously enough) making a boot floppy so I could convert my root fs from ext2 to ext3.
/dev/hda run about 10 times took care of the filesystem's integrity, but I still had about 200 "files" in /lost+found of all sorts of random sizes, names, and types (pipes, fifos, regular, dev entries). The problem was that when I'd try to perform a file operation on any of the files, the kernel would get pissed off saying that the file size was too large, since the inode had random data listed as the filesize, and the operation would fail.
Instead of dd if=/tmp/imagefile.img of=/dev/fd0 bs=1440k,
I did dd if=/tmp/imagefile.img of=/dev/hda bs=1440k
Whoops. After restoring my MBR and partition table, I still had to deal with the fact that I overwrote the first 1438KB of my root filesystem with effectively random data.
e2fsck -y
The way I finally fixed it was by running tune2fs and removing the file by hand. It's fairly straightforward, since tune2fs has an interface similar to file navigation from a shell prompt (ls, cd, etc). Just navigate to the target directory and remove the inode listed (by ls) as the inode associated with the file in question. You probably want to run e2fsck one more time to be sure.
Happy ending: I'm still using the filesystem that dd stomped all over and luckily lost only a handful of unimportant files.
Hope this helps...
-Fat Fingers
Can somebody fill me in on what exactly qualifies as a Luxury Banana?
How about "Cause Rob wanted to and it's his website." I give wicked props to the job Rob and Hemos did even back when they weren't getting paid for it.
/. does it.
Quit whining and set up a better site if you dont like the way
If you remember correctly, it was JC News (dont remember the site, maybe jcnews.com?) that broke the story about the power cycling issue. JC himself had worked for Dell for a couple of months after being turned from temp to perm and they Dell fired him for it. JC claims that he got his info from someone else inside Dell, but they fired him because he was still in his probationary period, and they could.
I agree for the most part with what Mike Dell said about AMD's incompatilility (tho its not true for current athlons), but don't paint him as an impartial observer.
AMD is working really hard trying to push a dual-proc chipset out, but are running behind schedule. Their first estimate was 'late 2000' and now it looks like 1H2001.
:(
I think they'll be called the Irongate 960 and 980 or something like that.
Oh well.
FWIW--I believe that Gateway uses fairly commonly available motherboards (used to be Intel for the socket sevens, probably the same now for the slot 1's). Also, IIRC one of those MS/Intel/Compaq PC specs (eg PC97) set up a port color-coding standard, so many of the mobo manufacturers are now adhering to them. A cool thing indeed, says I.
Red Hat had a lot of momentum going last week after the finding of fact for Micros~1. It jumped something like 15 points the day it was announced. Red Hat is a market sweetheart right now, getting a ton of financial publicity, and people (not just geeks) are being very sensitive to ANY reason to put money into RHAT.
IMHO that's why a relatively minor announcement kicked the stock price (hence, valuation of the company) up ~10%.
discordia
Au contraire, no AMD with the K6 core supports OpenPIC, however the K5 and all post-6x86 Cyrix processors do. When the K6 came out, AMD believed that nobody would ever come out with an OpenPIC board, so supporting it would be a waste of silicon. Unfortunately, they were right (except for CHRP compliant PowerPC boards, and there are very few of them).
I'm very very glad that the K7 supports multiprocessing, although it is not via the OpenPIC standard. IMHO OpenPIC is (was) an awesome standard, with virtually unlimited processors and IRQ's. But it looks like it has betamax'd by now.
Have you released the mixes on mp3?
Im not convinced that the K7 being more expensive than the PIII is totally a bad thing for AMD. I used to sell computers, and it was difficult trying to sell the "budget" amd to newbie computer buyers while saying "trust me...it's faster. Better for almost anything. AMD is a good brand...they're not like a generic chip..." Intel is like the Nabisco of processors, and trying to convince typical consumers to switch to a cheaper "knockoff" can be difficult. If AMD can position the K7 as a premium product that you pay a LITTLE more for, it may turn their image around.
A minor correction on your last point: you are correct in saying that the interface speed isn't that much different, but three factors that scsi is still far superior to IDE in are: expandability to more than 2 drives/channel, simulataneous data transfer to multiple drives on the same channel, and CPU usage.
AMD supported OpenPIC with their K5 (as well as Cyrix with every 6x86 and M2 chip made), but dropped it in K6 for lack of mobo support. I'd imagine that the K7 uses OpenPIC as the multiprocessor protocol. AFAIK, OpenPIC has no limit on processors, or maybe it's 255. Anyway, the limit's more than you'll ever fit into a standard box. Of course that's the standard, and making an 8+ processor machine work may never be feasible.
Another thing: the openPIC standard defined that the architecture had 255 IRQ's! Granted, they're not such a big deal today due to PCI and USB (heh), but back then (1994-1995), we were all fighting with ISA cards and conflicts. And a heavily loaded PC would run out of IRQ's damn fast.
I think that the 'appendix A' IS necessary, as the GPL says you have to tell the user where to get the software.
Everything I'd read about the K7 was that it was designed from the ground up as a high clock rate chip. At first I thought this was pure marketing bunk...that all fast chips were "designed for high clock rates". More reading revealed I wasn't totally right. Basically, the chip was built to be more forgiving to higher clock rates, with higher cache latencies and the like. Sorry for my vagueness, but apparently the K6 was designed with minimum cache latency, making it do a lot per clock cycle, but at the same time making it very unforgiving to slight manufacturing defects and high speeds. So it looks like the K7 should be pretty o/c'able. Also dont forget that the later .25 um chips should be more oc'able, as they refine the fab process, and of course they should go through the roof when both of amd's fabs go .18u.
HAHAHAHA...that was pretty funny.