Slashdot makes me laugh. Originally people here worried about flash memory and people worked out the life with wear levelling. And it was indeed fifty years.
For ages and ages I see people saying "but you can't put swap on flash it will wear out" and I post a link to the above
Now the "it will last for fifty years even if you hammer the shit out of it" meme seems to have penetrated the hive mind. And Intel and Samsung and others have launched flash disks. But those disks are based on MLC flash, not SLC like in the first example. So you need to update the calculation.
Slashdot being slashdot by the time this meme becomes common, something in the calculation will change since the industry knows that 6 months is too short and the worst case lifetime will go up to a couple of decades again. Or more than the 5 year average life of a hard disk at least.
Regular flash works just fine for swap. If you write nonstop at top speed to a standard chip, you'll wear I'd out in about fifty years. Thus I don't understand why we should care about an even longer lifetime.
That used to be true with SLC chips. It's not true with MLC.
It's a simple matter to plug new data for MLCs into the calculation I did for the worst case wear-out process for flash SSDs - which I called the Rogue Data Recorder.
Instead of the 64GB example I used then, I'll assume the MLC SSD has 128GB capacity. MLC SSDs have more capacity than SLC. And more capacity means longer operating life - before cells wear out.
I'll still use the 80M bytes / sec sustained write speed - because the fastest MLC products (in Feb 2008) can already do that. (Meanwhile the fastest SLC products have moved up in the world and are about 50% faster.)
The next factor is where we hit the big problem... Instead of a write endurance rating of 2 million cycles (for the best SLC) - I can only use a figure of 10,000 for MLC. MLC has a much lower rating due to the complex interaction of discriminating multiple logic levels reliably coupled with the intrinsic failure mechanism of wear-out.
Plugging these numbers in the same calculation gives an estimated MLC flash SSD operating life (at max write throughput) which is 6 months! (instead of 51 years for a 64GB SLC SSD).
All the affordable SSDs I've seen from Intel and Samsung are based on MLC flash because it costs much less per bit. Down to $2 per GB in fact. SLC currently costs 2-4x as much. E.g.
SLC is 2.7x more expensive for 1Gx8 and 3.9x more expensive for 2Gx8. So it's not surprising that most SSDs are MLC based. But if you write at full speed to them they will die very quickly.
Incidentally look at the price of 4Gx8 MLC. $2.31 per gigabyte. Pretty damn cheap.
There's definitely an "open source" trend starting to build. Not that long ago the idea of an open source phone was ridiculous, but now there's Google's Android platform and Nokia and friends are open-sourcing Symbian. There's a lot of good reasons for hardware manufacturers to want quality, fully-featured open-source drivers for their hardware.
Nokia and friends are not "open sourcing Symbian". They've said they will open up a few modules at some unspecficied time, not putting all the code into an archive for public download right now.
Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.
Exactly.
It was written by Greg Kroah Hartman who famously broke the Philips webcam driver, causing the maintainer to quit.
An interesting sidenote, with the announcement that the 360 can install games to the HDD, but you have to have the disc in (for verification that you own the game), if they allowed a full game install of FFXIII, allowing the first disc to be the "verification" disc, the "LOL1l!! multiple disc" arguement would go away. Get on in MS, for those who don't like getting off the couch every 10 hours.
Making gamers get up of the couch every ten hours significantly increases the amount of exercise they take. This translates into a longer life expectancy and that translates into a shallower drop in the revenue vs time projection for the console.
Still phase modulation at 9kbaud+ would be a tight fit on an audio tape. I don't think things like QAM would be possible given the size of the package
Quadrature amplitude modulation was in use in the 1960s: it's just two AM carriers out of phase by 90 degrees. The color encoding in NTSC and PAL used QAM.
This modem was potted circuit board. It had space for a couple of 8 pin chips a few passive components, all of which had to be available in the 80s, so we're talking OpAmps and 4000 series CMOS chips. It cost £20 so it the cost of the components had to be less than that. You're not going to build a QAM modem with those constraints.
The computer I designed and built around 1981 did 9600 bps with some TTL logic i designed myself. The format used was Manchester II, very simple to encode and decode if the clock can be recovered (the difficult part) for the decode phase. I think I used less PCB space than what was needed for the common 300 bps Kansas City format.
When the Atari sent data to the tape it had an internal modulator. But IIRC the demodulator was in the tape deck. And in any case you could output data to the disk drive, when it was a selectable baud 0-19200 rate and not modulated. So it seems like the turbo tape interface could use custom software to get 9600 baud TTL data to or from the tape and do its 9600 modem baud magic internally with a handful of components.
Tapes are stereo, so you could send the clock one one channel and the phase shifted clock (the signal) on the other.
You need an oscillator and a phase shifter made out of an XOR gate to modulate. Shifted single goes on one channel say left, unshifted one on the other, say right
To demodulate you use a phase detector made out of an XOR gate to compare the phase of the two channels.
This would be analogous to Manchester BPSK coding, except that you use one of the two audio channels to store the carrier so you don't need to spend expensive electronics regenerating it.
So something like this seems plausible. Unfortunately I didn't know enough about electronics back in the Atari days to try it.
Yes. But a few people did some very magical things with tapes before the became obsolete. I saw a demo of a turbo tape system on an Atari 800XL which could load games "faster than a disk drive". Actually it about tied, but that was still impressive. The disk drive could probably managed 9600 baud sustained.
The modulator / demodulator was lump of potted electronics I could easily fit in my hand. Potting compound was a blank gunk you applied to electronics you didn't want people to tamper with, in this case to stop people seeing the components used. But whatever they were they could modulate and demodulate data at around 9600 baud. This was in the 80's back before DSPs too, so whatever circuit was used must have been made of Op Amps, transistors and passive components.
I never worked out how it worked. Though I can imagine exploiting the stereo nature of the tapes to send one carrier and phase shifted signal might work. Phase modulation is easy and demodulation is too if you have the carrier. Still phase modulation at 9kbaud+ would be a tight fit on an audio tape. I don't think things like QAM would be possible given the size of the package, the selling price (about twenty English pounds, or $40), and the primitive nature of 80's technology.
The sad thing is... USA would never attack China... Would never support Taiwan, and would never return to N Korea...
BUT... the Question is, would China take that bet? and is there any oil where China is likely to invade?
America, as long as they are backwards we can bomb them further back.
Face it, if America had any interests outside of its own greed S. Africa & Congo would be showering you all in thanks.
I'm in Taiwan now and the the US sent to aircraft carriers to patrol off Taiwan last time there was an election here. And actually if the US hadn't regularly sent an aircraft carrier or two when there was an election Taiwan would likely have been swallowed up long ago and there wouldn't be any elections here.
And back in Cold War I'm pretty sure the US would have fought the Russians if they'd have invaded West Europe even if that have ended up in a full on nuclear exchange. And then there's the issue of the US slogging through France to get to Germany in WWII, or planning to invade Japan. Basically, as Patton put it, all real Americans love to fight. And the US's foreign policy and military capability reflect this. Even when they're not fighting, the fact that they could tends to force their opponents to shelve their plans for conquest.
What if the US has to fight China over Taiwan? Or support Japan being attacked by China? Or anywhere being attacked by China.
Then I'd say you'd need all the carpet bombing and nukes you can get. More to the point if the US has the capability to do this stuff, the Chinese will most likely not start the war in the first place.
The great irony of your post is that if policy makers listened then in 20 years time I'd be reading similar posts from US soldiers fighting in some big conventional war complaining that the only available weapons systems were designed for use against a few poorly armed insurgents in house in some third world shithole, not armoured battalions and hostile navies built by large industrialized state bent on occupying a US ally, when if the US had ignored you they would most likely not have had to fight at all.
The reason people troll is that Apple fanboys were telling us PPC was much faster than Intel right up to the switch, at which point they started telling us they were much slower.
It's like Big Brother fanboys telling you that they have always been at war with Eurasia one day and the very next day that Eurasia has always been their ally. This sort of thing invites trolling and/or rocket bombs.
Plus a Cell processor would be hopeless in Mac. The PPC core was relatively underpowered - most of the horsepower was in the SPEs and OS X would only have used those in very special circumstance with a lot of work.
E.g. you could imagine Photoshop using them for filters but given how slow Adobe has been at moving to X86 which is very similar to PPC, I wouldn't hold my breath waiting for a Photoshop which was tuned for a very different architecture like Cell.
Is that really true? I've got a dual core laptop and most of the time it's doing web/email type stuff. The only times I've ever hit 100% CPU were encoding video and playing games. And if you look at Performance Monitor, both of those ended up maxing out both cores. So it certainly seems that people that write code that will max out CPUs have done a decent job of trying to make their code use multiple cores. Maybe not a 32 thread system like this one, but certainly on a 2 core one.
And on a server it's probably even better. Serving HTTP or SMB should be embarassingly parallel since each users can have a server thread dedicated to them. In both cases I'd expect things to be IO limited, not parallelism limited.
I think the people that complain about Global Warming hype are not complaining about the science but the dumbed down and politically motivated 'summary of what the vast majority of respectable scientists believe' from people who are activists not scientists.
Peter Gibbons: Let me ask you something. When you come in on Monday, and you're not feelin' real well, does anyone ever say to you, 'Sounds like someone has a case of the Mondays'? Lawrence: No. No, man. Shit, no, man. I believe you'd get your ass kicked sayin' something like that, man.
Here's me shouting to no one in particular the other morning: "Hey, look, Brad's gotta do the Laptop Drive of Shame." Gales of laughter ensue.
Paul McNamara, you live in a country with the Second Amendment and you work in IT where there are a lot of 'ticking time bomb' types. Maybe a little tact might be a good idea.
I think it's a question of mindset. If you build something like how most modern desktop applications are built - a complicated and very abstract C++ class hierarchy and lots of dynamic allocation / deallocation - don't be surprised if it takes a good long to stabilize. And that's assuming the people that wrote it are conscientious about bug reports. If they mark 'em all "Can't reproduce" or "Try a later version" then it won't stabilize.
But people have worked out a ways to build reliable software and those could be applied in either the desktop or the embedded world. But embedded programmers usually work in an environment where what they're shipping will end up in a device somewhere and there won't be a next version, at least not in that device. So the approach of making a simple system and getting it right first time is much more popular there. But was you say it's not universal. I can think of a handful of desktop apps which are stable and a worrying number of embedded systems which aren't.
But mostly it's about what you worry about. If you worry about code beauty, pureness of Object Oriented model and how cool your tools are and ignore timing problems, how to handle out of memory conditions and all the low level stuff then your code will be shit. It's much more easy to do this on desktop stuff than embedded code. Hell, most desktop programmers assume that they don't need to worry about memory leaks or out of memory conditions because of garbage collection. And you can sort of see the results of that if you run their code overnight and watch the memory usage balloon.
If you watch your scriptures carefully, they take place "a long time ago in a galaxy far, far away". So it would clearly be heresy to suggest that Earth and Hoth are the same planet.
It was very useful. I found before I was missing step 3). Essentially I would write my learnings in a notebook and then go out and get piss drunk which caused my internal stored knowledge to go back to the previous checkpoint.
Slashdot Mirror
Slashdot makes me laugh. Originally people here worried about flash memory and people worked out the life with wear levelling. And it was indeed fifty years.
http://www.storagesearch.com/ssdmyths-endurance.html
For ages and ages I see people saying "but you can't put swap on flash it will wear out" and I post a link to the above
Now the "it will last for fifty years even if you hammer the shit out of it" meme seems to have penetrated the hive mind. And Intel and Samsung and others have launched flash disks. But those disks are based on MLC flash, not SLC like in the first example. So you need to update the calculation.
http://www.storagesearch.com/ssd-slc-mlc-notes.html
Oh noes! Your data will disappear in 6 months!
Slashdot being slashdot by the time this meme becomes common, something in the calculation will change since the industry knows that 6 months is too short and the worst case lifetime will go up to a couple of decades again. Or more than the 5 year average life of a hard disk at least.
Regular flash works just fine for swap. If you write nonstop at top speed to a standard chip, you'll wear I'd out in about fifty years. Thus I don't understand why we should care about an even longer lifetime.
That used to be true with SLC chips. It's not true with MLC.
http://www.storagesearch.com/ssd-slc-mlc-notes.html
It's a simple matter to plug new data for MLCs into the calculation I did for the worst case wear-out process for flash SSDs - which I called the Rogue Data Recorder.
Instead of the 64GB example I used then, I'll assume the MLC SSD has 128GB capacity. MLC SSDs have more capacity than SLC. And more capacity means longer operating life - before cells wear out.
I'll still use the 80M bytes / sec sustained write speed - because the fastest MLC products (in Feb 2008) can already do that. (Meanwhile the fastest SLC products have moved up in the world and are about 50% faster.)
The next factor is where we hit the big problem... Instead of a write endurance rating of 2 million cycles (for the best SLC) - I can only use a figure of 10,000 for MLC. MLC has a much lower rating due to the complex interaction of discriminating multiple logic levels reliably coupled with the intrinsic failure mechanism of wear-out.
Plugging these numbers in the same calculation gives an estimated MLC flash SSD operating life (at max write throughput) which is 6 months! (instead of 51 years for a 64GB SLC SSD).
All the affordable SSDs I've seen from Intel and Samsung are based on MLC flash because it costs much less per bit. Down to $2 per GB in fact. SLC currently costs 2-4x as much. E.g.
Here are the average prices for flash
32Gb 4Gx8 MLC 9.27
16Gb 2Gx8 SLC 15.61
16Gb 2Gx8 MLC 3.97
8Gb 1Gx8 SLC 6.31
8Gb 1Gx8 MLC 2.34
SLC is 2.7x more expensive for 1Gx8 and 3.9x more expensive for 2Gx8. So it's not surprising that most SSDs are MLC based. But if you write at full speed to them they will die very quickly.
Incidentally look at the price of 4Gx8 MLC. $2.31 per gigabyte. Pretty damn cheap.
There's definitely an "open source" trend starting to build. Not that long ago the idea of an open source phone was ridiculous, but now there's Google's Android platform and Nokia and friends are open-sourcing Symbian. There's a lot of good reasons for hardware manufacturers to want quality, fully-featured open-source drivers for their hardware.
Nokia and friends are not "open sourcing Symbian". They've said they will open up a few modules at some unspecficied time, not putting all the code into an archive for public download right now.
Summary: A stable API doesn't mean you're weighed down with cruft, and any argument based on that premise is nonsense. Any intelligent person making that argument is really saying that they think all drivers should be GPL.
Exactly.
It was written by Greg Kroah Hartman who famously broke the Philips webcam driver, causing the maintainer to quit.
http://www.smcc.demon.nl/webcam/
1. Posting AC with a comment like that displays very poor judgement.
2. Why are you using a printer manufacturer that refuses to make available either a driver of their own creation or the documentation to write one?
DING! DING! DING! Linux Fault Threshold reached
http://www.adequacy.org/stories/2001.10.2.33542.4010.html
3. Don't be cheap. Buy a new (or used office-class) HP and enjoy!
Hmm, wouldn't an OEM copy of Windows be cheaper?
An interesting sidenote, with the announcement that the 360 can install games to the HDD, but you have to have the disc in (for verification that you own the game), if they allowed a full game install of FFXIII, allowing the first disc to be the "verification" disc, the "LOL1l!! multiple disc" arguement would go away. Get on in MS, for those who don't like getting off the couch every 10 hours.
Making gamers get up of the couch every ten hours significantly increases the amount of exercise they take. This translates into a longer life expectancy and that translates into a shallower drop in the revenue vs time projection for the console.
Still phase modulation at 9kbaud+ would be a tight fit on an audio tape. I don't think things like QAM would be possible given the size of the package
Quadrature amplitude modulation was in use in the 1960s: it's just two AM carriers out of phase by 90 degrees. The color encoding in NTSC and PAL used QAM.
This modem was potted circuit board. It had space for a couple of 8 pin chips a few passive components, all of which had to be available in the 80s, so we're talking OpAmps and 4000 series CMOS chips. It cost £20 so it the cost of the components had to be less than that. You're not going to build a QAM modem with those constraints.
The computer I designed and built around 1981 did 9600 bps with some TTL logic i designed myself. The format used was Manchester II, very simple to encode and decode if the clock can be recovered (the difficult part) for the decode phase. I think I used less PCB space than what was needed for the common 300 bps Kansas City format.
When the Atari sent data to the tape it had an internal modulator. But IIRC the demodulator was in the tape deck. And in any case you could output data to the disk drive, when it was a selectable baud 0-19200 rate and not modulated. So it seems like the turbo tape interface could use custom software to get 9600 baud TTL data to or from the tape and do its 9600 modem baud magic internally with a handful of components.
Tapes are stereo, so you could send the clock one one channel and the phase shifted clock (the signal) on the other.
You need an oscillator and a phase shifter made out of an XOR gate to modulate. Shifted single goes on one channel say left, unshifted one on the other, say right
To demodulate you use a phase detector made out of an XOR gate to compare the phase of the two channels.
This would be analogous to Manchester BPSK coding, except that you use one of the two audio channels to store the carrier so you don't need to spend expensive electronics regenerating it.
So something like this seems plausible. Unfortunately I didn't know enough about electronics back in the Atari days to try it.
A much better PPC for a laptop would be the PWRficient. How does 2 GHz at 7 W per core sound?
Much worse than Atom?
Yes. But a few people did some very magical things with tapes before the became obsolete. I saw a demo of a turbo tape system on an Atari 800XL which could load games "faster than a disk drive". Actually it about tied, but that was still impressive. The disk drive could probably managed 9600 baud sustained.
The modulator / demodulator was lump of potted electronics I could easily fit in my hand. Potting compound was a blank gunk you applied to electronics you didn't want people to tamper with, in this case to stop people seeing the components used. But whatever they were they could modulate and demodulate data at around 9600 baud. This was in the 80's back before DSPs too, so whatever circuit was used must have been made of Op Amps, transistors and passive components.
I never worked out how it worked. Though I can imagine exploiting the stereo nature of the tapes to send one carrier and phase shifted signal might work. Phase modulation is easy and demodulation is too if you have the carrier. Still phase modulation at 9kbaud+ would be a tight fit on an audio tape. I don't think things like QAM would be possible given the size of the package, the selling price (about twenty English pounds, or $40), and the primitive nature of 80's technology.
The sad thing is ... USA would never attack China... Would never support Taiwan, and would never return to N Korea...
BUT... the Question is, would China take that bet? and is there any oil where China is likely to invade?
America, as long as they are backwards we can bomb them further back.
Face it, if America had any interests outside of its own greed S. Africa & Congo would be showering you all in thanks.
I'm in Taiwan now and the the US sent to aircraft carriers to patrol off Taiwan last time there was an election here. And actually if the US hadn't regularly sent an aircraft carrier or two when there was an election Taiwan would likely have been swallowed up long ago and there wouldn't be any elections here.
And back in Cold War I'm pretty sure the US would have fought the Russians if they'd have invaded West Europe even if that have ended up in a full on nuclear exchange. And then there's the issue of the US slogging through France to get to Germany in WWII, or planning to invade Japan. Basically, as Patton put it, all real Americans love to fight. And the US's foreign policy and military capability reflect this. Even when they're not fighting, the fact that they could tends to force their opponents to shelve their plans for conquest.
What if the US has to fight China over Taiwan? Or support Japan being attacked by China? Or anywhere being attacked by China.
Then I'd say you'd need all the carpet bombing and nukes you can get. More to the point if the US has the capability to do this stuff, the Chinese will most likely not start the war in the first place.
The great irony of your post is that if policy makers listened then in 20 years time I'd be reading similar posts from US soldiers fighting in some big conventional war complaining that the only available weapons systems were designed for use against a few poorly armed insurgents in house in some third world shithole, not armoured battalions and hostile navies built by large industrialized state bent on occupying a US ally, when if the US had ignored you they would most likely not have had to fight at all.
The reason people troll is that Apple fanboys were telling us PPC was much faster than Intel right up to the switch, at which point they started telling us they were much slower.
It's like Big Brother fanboys telling you that they have always been at war with Eurasia one day and the very next day that Eurasia has always been their ally. This sort of thing invites trolling and/or rocket bombs.
Plus a Cell processor would be hopeless in Mac. The PPC core was relatively underpowered - most of the horsepower was in the SPEs and OS X would only have used those in very special circumstance with a lot of work.
E.g. you could imagine Photoshop using them for filters but given how slow Adobe has been at moving to X86 which is very similar to PPC, I wouldn't hold my breath waiting for a Photoshop which was tuned for a very different architecture like Cell.
Is that really true? I've got a dual core laptop and most of the time it's doing web/email type stuff. The only times I've ever hit 100% CPU were encoding video and playing games. And if you look at Performance Monitor, both of those ended up maxing out both cores. So it certainly seems that people that write code that will max out CPUs have done a decent job of trying to make their code use multiple cores. Maybe not a 32 thread system like this one, but certainly on a 2 core one.
And on a server it's probably even better. Serving HTTP or SMB should be embarassingly parallel since each users can have a server thread dedicated to them. In both cases I'd expect things to be IO limited, not parallelism limited.
I think the people that complain about Global Warming hype are not complaining about the science but the dumbed down and politically motivated 'summary of what the vast majority of respectable scientists believe' from people who are activists not scientists.
http://www.imdb.com/title/tt0151804/quotes
Peter Gibbons: Let me ask you something. When you come in on Monday, and you're not feelin' real well, does anyone ever say to you, 'Sounds like someone has a case of the Mondays'?
Lawrence: No. No, man. Shit, no, man. I believe you'd get your ass kicked sayin' something like that, man.
I feel the same way about this
http://www.networkworld.com/community/node/29791
Here's me shouting to no one in particular the other morning: "Hey, look, Brad's gotta do the Laptop Drive of Shame." Gales of laughter ensue.
Paul McNamara, you live in a country with the Second Amendment and you work in IT where there are a lot of 'ticking time bomb' types. Maybe a little tact might be a good idea.
It's a CAPTPHA - "Completely Automated Public Turing test to tell Pedants and Humans Apart".
I think it's a question of mindset. If you build something like how most modern desktop applications are built - a complicated and very abstract C++ class hierarchy and lots of dynamic allocation / deallocation - don't be surprised if it takes a good long to stabilize. And that's assuming the people that wrote it are conscientious about bug reports. If they mark 'em all "Can't reproduce" or "Try a later version" then it won't stabilize.
But people have worked out a ways to build reliable software and those could be applied in either the desktop or the embedded world. But embedded programmers usually work in an environment where what they're shipping will end up in a device somewhere and there won't be a next version, at least not in that device. So the approach of making a simple system and getting it right first time is much more popular there. But was you say it's not universal. I can think of a handful of desktop apps which are stable and a worrying number of embedded systems which aren't.
But mostly it's about what you worry about. If you worry about code beauty, pureness of Object Oriented model and how cool your tools are and ignore timing problems, how to handle out of memory conditions and all the low level stuff then your code will be shit. It's much more easy to do this on desktop stuff than embedded code. Hell, most desktop programmers assume that they don't need to worry about memory leaks or out of memory conditions because of garbage collection. And you can sort of see the results of that if you run their code overnight and watch the memory usage balloon.
If you watch your scriptures carefully, they take place "a long time ago in a galaxy far, far away". So it would clearly be heresy to suggest that Earth and Hoth are the same planet.
I went on a training training course, to teach people to make better use of training courses. They said the steps are
1) Read
2) Comprehend
3) Update internal stored knowledge
It was very useful. I found before I was missing step 3). Essentially I would write my learnings in a notebook and then go out and get piss drunk which caused my internal stored knowledge to go back to the previous checkpoint.
That reminds of a great story in a book somewhere "Ugh, son of Ugh ...". And then it goes with all the nouns and verbs replaced with Ugh.
http://www.penny-arcade.com/comic/2004/03/19/
No.
Makes you wonder what the internet would look like if you had real privacy actually. Hope you like /b/