Link to Original Source
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Link to Original Source
Link to Original Source
I don't think the logistics are really all that difficult - most of the parts (CPU, DRAM, probably LCD screen, etc.) in an iProduct aren't made in China either. They're made in Japan, Germany, the USA, or South Korea, shipped to china and assembled for $8/board at a contract manufacturer like Foxconn.
To make an iPhone (which sells for $5-600) probably costs apple $200, of which ~$10 is final assembly. The US doesn't really have the enormously large-scale contract manufacturers like Foxconn that Apple can say 'here, make 10k of these a day 6 months from now.' Apple could probably build a highly-automated factory in the US that could probably assemble iphones for $50, upping their total cost to $240 or so, but then they would have to run and operate a factory - something they haven't really been in the business of doing for the last decade or so. In addition to being more directly responsible for the welfare of their workers (it's easier to say 'we treat our workers well, we're not responsible for our contract manufacturers'), they would be shouldering more of the risk for no gain in profit. Apple can say, Sorry foxconn, we don't need anymore ipods', and then it's Foxconn's job to figure out what to do with their expensive factory.
I have a Makerbot Thing-o-Matic, and have also used smaller CNC milling machines before. There really are some crucial differences:
1) There's an actual fundamental difference in the types of objects that can be created with an additive process like the ToM uses, and a reductive process like a CNC milling machine uses. Creating lightweight, hollow objects is basically impossible with a mill but trivial with my ToM (I frequently print out multi-layer gear objects for mechanical widgets I'm building).
2) I can operate a small 3D printer in my apartment. It's roughly as loud as my laser printer, and doesn't produce any mess/dust-clouds/bad smells. I would never use a CNC mill in my living room. At best it is way louder, produces way more mess, and basically requires a shop-vac to be running the whole time.
3) Finally - having used a range of both cheap 3D printers and cheap (and not-so-cheap) CNC milling machines - I can get a low-end 3D printer like a makerbot that actually produces useful parts for under $2000. Ever CNC mill I've seen for under $3000 has been crap. If you can spend $5000 (and have at least some background in machining) you can get a pretty good small CNC milling machine and maintain it.
I feel like this argument kind of misses the point. First, 3D printers (of the makerbot variety, as well as more traditional/expensive machines) have both come down drastically in price and improved drastically in quality in the last few years. The same goes for CNC milling equipment (and computing, and printing, etc.). No, they aren't appropriate for making a million widgets to be sold at 2 cents/piece, but they're perfectly appropriate for teaching people how to design things.
A huge segment of the population (often with a lot of knowledge in very specific areas) doesn't know what is possible with tools like this. Setting up an environment for kids to play with where making things (rather than just buying them from a black-box company) is easy can significantly change their world view and make them way more creative/productive/etc. Things like 3D printers are cheap enough that you could have one for almost every kid in a class, and that makes the cost of failure incredibly low. Same with learning to program on cheap computers (and build electronics with cheap microcontrollers like the arduino ecosystem). I feel like that ability to de-mystify the world and teach kids to create something will probably prove extremely valuable to them.
He hooked his own analog-to-digital converter up to the read-head and post-processed the heck out of it to recover the data.
You really think China is going to 'flip a switch' and replace their coal power plants with solar and wind overnight? Even though China uses 50% of the *world's* coal production right now? I think your mental model may be off by a few orders of magnitude in places. China has an estimated 950 Gigawatts of electricity production right now, and 82% of that comes from coal. Of the non-coal 18%, nearly all of that is hydroelectric, with a little bit of nuclear. There just aren't enough rivers left for china to significantly increase their hydro (how many more 3 gorges can they build? Zero! ). China's renewable energy growth might be 'torrid,' but it's still insignificant. China's energy use more than *doubled* in the last 10 years, and it's not slowing down. And what are they meeting that growth with? More coal, making the pollution worse.
In 10 years, I'd bet you almost anything that China is using even more coal than they are today.
As part two (see previous attempt) of my ongoing series in ‘computational necromancy,’ I’ve spent the last year and a half or so constructing my own 1/10-scale, binary-compatible, cycle-accurate Cray-1. This project falls purely into the “because I can!” category - I was poking around the internet one day looking for a Cray emulator and came up dry, so I decided to do something about it. Luckily, the Cray-1 hardware reference manual turned out to be useful enough that implementing most of this was pretty straightforward. The Cray-1 is one of those iconic machines that just makes you say “Now that’s a super computer!” Sure, your iPhone is 10X faster, and it’s completely useless to own one, but admit it . . you really want one, don’t you?
The Cray-1A Architecture
Now, let’s get down to specs - What is this bad boy running? The original machine ran at a blistering 80 MHz, and could use from 256-4096 kilowords (32 megabytes!) of memory. It has 12 independent, fully-pipelined execution units, and with the help of clever programming, can peak at 3 floating-point operations per cycle. Here’s a diagram of the overall architecture:
It’s a fairly RISC-y design, with 8 64-bit scalar (S) registers , 8 64-bit/64-word vector (V) registers, and 8 24-bit address (A) registers. Rather than a traditional cache, it uses a ’software-managed’ cache with an additional 64 64-bit words (T registers) and 64 24-bit words (B registers). There are instructions to transfer data between memory and registers, and then register-to-register ‘compute’ instructions.
One of the coolest aspects of this machine is that everything is fully pipelined. This machine was designed to be fast, so if you’re careful, you can actually get one (or more) instruction every cycle. This has some interesting implications - there’s no ‘divide’ instruction, for instance, because it can take a variable amount of time to finish. To perform a divide, you need to first compute the ‘reciprocal approximation’ (something we *can* do in exactly 13 cycles, it turns out) of the denominator value, and then perform a separate multiply of that result with the numerator.
The vector instructions are particularly cool. A vector Add operation might take only 5 cycles to start producing results (remember, each vector can hold 64 values, so it takes 5 + 64 cycles to finish adding). Why wait for it to finish though? We can take the result output from the adder, and “chain” it straight into another vector unit (say a multiplier). And *that* only takes another 10 cycles or so, so we can chain that result into yet another unit (say, reciprocal approximation). Now, rather than waiting for the first operation to finish, we’re computing up to 3 floating point calculations per cycle. Clever programmers could sustain about 2 floating point operations per cycle, or 160 million instructions per second.
vector_chainingVector Chaining in Action!
The actual design was implemented in a Xilinx Spartan-3E 1600 development board. This is basically the biggest FPGA you can buy that doesn’t cost thousands of dollars for a devkit. The Cray occupies about 75% of the logic resources, and all of the block RAM.
This gives us a spiffy Cray-1A running at about 33 MHz, with about 4 kilowords of RAM. The only features currently missing are:
-Exchange Packages (this is how the Cray does ‘context-switching’ - it was intended as a batch-processing machine)
-I/O Channels (I just memory-mapped the UART I added to it).
If I ever find some software for this thing (or just get bored), I’ll probably go ahead and add the missing features. For now, though, everything else works sufficiently well to execute small test programs and such.
When I started building this, I thought “Oh, I’ll just swing by the ol’ Internet and find some groovy 70’s-era software to run on it.” It turns out I was wrong. One of the sad things about pre-internet machines (especially ones that were primarily purchased by 3-letter Government agencies) is that practically no software exists for them.
***** If Anyone has any Cray-1 software, please contact me!! If you work at one of the National Labs, please take a look!****
After searching the internet exhaustively, I contacted the Computer History Musuem and they didn’t have any either. They also informed me that apparently SGI destroyed Cray’s old software archives before spinning them off again in the late 90’s. I filed a couple of FOIA requests with scary government agencies that also came up dry. I wound up e-mailing back and forth with a bunch of former Cray employees and also came up *mostly* dry. My current best hope is a guy I was able to track down that happened to own an 80 MB ‘disk pack’ from a Cray-1 Maintenance Control Unit (the Cray-1 was so complicated, it required a dedicated mini-computer just to boot it!), although it still remains to be seen if I’ll actually get a chance to try to recover it.
Without a real software stack (compilers, operating systems, etc.), the machine isn’t terribly useful (not that it would be all that useful if I did have software for it). All of the opcodes and registers for the Cray-1 are described in Base-8 (octal), so I did at least write a little script to translate octal machine code into the hexadecimal format that Xilinx’ tools require. All of my programming so far has just been in straight octal machine-code, just assembling it in my head. I have started work on re-writing the CAL Assembler, but that may take awhile, as it employs some tricky parsing that I’m having to teach myself.
Makin’ it look pretty
What’s the point of owning a Cray-1 if it doesn’t *look* like a Cray-1?? Unfortunately, the square-shaped FPGA board isn’t conducive to actually making it the traditional “C” shape, but I think it turned out pretty cool anyway. My friend Pat was nice enough to let me use his CNC milling machine to cut out the base pieces (and help with assembly). It’s a combination of MDF, balsa wood and pine. There was also a healthy dose of blood, sweat and tears (and gorilla glue) involved.
Some random photos from the build process:
Finally, Computer Engineer Barbie has an appropriate place to sit down!
This is awesome! How can I build my own?
This is very much a work-in-progress, but if you’d like to join in the fun, feel free! All you need is a copy of the RTL (almost all Verilog-2001) and a Spartan-3 1600 or equivalent FPGA board. The code is likely riddled with bugs and questionable implementation choices at this point, so on the off-chance anyone actually downloads this, feel free to lend a hand and send me any bug fixes you might make!
Link to Original Source
Link to Original Source
The end result of his hacking produced a homebrew Cray-1A, which is 1/10th the size of the original. Unfortunately, getting software for the machine proved almost impossible. Fenton searched everywhere and eventually found out that SGI destroyed all the old software archives. Not even former Cray employees could help him."
Link to Original Source