There is a difference, say, with being (for example) in your mid 30s, in good health, and fully expecting to live between 40 and 60 years more - and being in your mid 30s, diagnosed with type 4 metastatic cancer and not expecting to be alive this time next year.
Sourcing the parts and getting it made really isn't a problem. I've done it for electronics with even more limited demand than this for a similar sized, similar part count board. There are assembly shops that can do runs of assembled boards right from just one example to hundreds of thousands, they do all the parts sourcing for you, you just give them a BOM and they organize it all. Most the parts on the Raspberry Pi will be common parts (resistors, capacitors, standard connectors, various ICs that get put into many different products) and are very easily sourced.
I've managed it *as an individual* with no organization backing me using these services.
I would agree on the marketing-the-product bit. The electronics really isn't a problem these days unless you're making something really odd with very unusual parts. Nothing about the Raspberry Pi is hard to source, especially since one of the team actually work at Broadcom and therefore can probably easily source the only thing that might cause problems, the SOC.
Discounting the elimination of possible "songs" that don't make musical sense, most 90 measure MAFIAA-type songs are not a 90 measure long melody and chord structure, rather two sets of the same segment of a tune repeated three or four times (three or four verses plus three or four choruses), so while the number of combinations is large, for a realistic MAFIAA-style song it's much less than 9^390.
Others have already pointed out that you're wrong about Airbus aircraft, but you do realise that all new designs from Boeing are also digital fly-by-wire? And anything much bigger than a Boeing 737, the pilots no longer have any direct physical control over the flight control surfaces (either they rely on hydraulic mechanical systems, or fly by wire). There have been several incidents involving loss of hydraulic pressure that have caused the crew to have no control at all over the flight control surfaces: google Sioux City DC-10 for one particularly famous incident.
The same thing can be said of humans: if the sensors are giving wrong data (which they do very often), then what can a human do? A case in point with aviation: if a pilot is flying by hand in the clouds (no visual reference) or over a sparsely populated area on a moonless night, then if they use their sensors (inner ear) for orientation, they will crash sooner rather than later because their sensors will give them bad information. So the pilot is trained to fly on instruments. If those instruments give the pilot bad information, the pilot will be in trouble just as much as an automated system will be in trouble. How much trouble depends on how many instruments are giving bad information.
Of course the brain determines in advance how much pressure you can apply!
Have you ever been to some place where they serve your drink in what looks like a substantial heavy glass tankard, but in actual fact it's lightweight plastic? When you go to lift your drink, you give the glass far too much lifting power and almost throw your drink across the room because it's unexpectedly light. (You also grip it harder than need be, because you're expecting it to be glass and much heavier than it is - so yes, you've attempted to analyse the composition of the glass before lifting it) The second time you lift it you don't though, because you know in advance that it's plastic and light. You're not doing the glass-lift purely by feedback, your brain figures out how much power to use in lifting it from assumptions its already made.
Now if the pilot in a purely manually controlled aircraft had been flying, say, in the clouds lacking visual reference, and suddenly the airspeed started to decay very rapidly, yes, he probably would lower the nose to prevent a stall. Long before fly-by-wire, airliners also had "stick shakers" and "stick pushers" which automatically lower the nose if it looks like the aircraft is about to stall. There have been interesting crashes related to stick pushers, for instance the Trident that crashed in Staines in the 1970s (to cut a long story short, amongst many factors including possibly the health of the captain, an inexperienced first office and an inadvertant retraction of the leading edge slats, there had been reports of false stick pusher activations on that type of aircraft. The aircraft really was stalling, but a crew member disabled the stick pusher believing the activation to be false, and the aircraft entered a deep stall and crashed, killing everyone on board).
You can run chipscope (Xilinx) to see what's going on inside. You can also run simulations before you instantiate your hardware in the FPGA. In a simulation, you can indeed do the equivalent of "printf".
When I worked in the US, between graduating (1995) until 2001, we were already "exempt", in other words exempt from getting overtime payments. It's one of the reasons I left the US, the crappy work/life balance and the expectation that working unpaid overtime was the norm for software developers (I've since heard my old workplace now effectively requires - not during crunch times, but the actual norm - something like 50 hour weeks while only paying for 40. During crunch times of course they demand far more).
And if it weren't for Acorn, the ARM would never have existed for Apple to put in $800M in hard cold cash. The ARM project started in 1983, years before Apple or anyone else for that matter even knew of the project. The BBC Micro was the seed, the ARM's original purpose was to put in the next BBC Micro (the Acorn Archimedes).
Apple saved the ARM, and the ARM saved Apple, it went both ways:-)
What the 6502 in the C64 (and the BBC Micro, under discussion) had which most people who started asm on the Z80 missed was the zero page. Effectively, using the zero page you had 256 registers. Zero page operations on the 6502 were as fast as register operations on the Z80. While I'm much more proficient at Z80 asm than 6502, I really appreciate the very straightforward and uncomplicated - but powerful - design of the 6502.
The BBC Micro at 2MHz was considerably faster than the Spectrum at 3.5MHz. The Z80 is a CPU that I like (I still write Z80 assembler, indeed I'm much more proficient at Z80 than 6502 and I've designed and made an ethernet card for the ZX Spectrum fairly recently as a fun retro project). However, we have to consider this. The fastest 6502 instruction executes in 2 T-states, most execute in 3 T-states, and the slowest take 7 T-states. The fastest Z80 instruction takes 4 T-states and the slowest over 20 T-states. The 6502 therefore has better interrupt latency (that monster 23 T-state index register instruction on the Z80 can't be interrupted).
The other thing the 6502 has going for it is the very fast zero page instructions, which are tantamount to giving you 256 extra registers.
The competing ZX Spectrum also had contended memory. Thanks to the 6502's predictable memory cycle when compared to the Z80, the BBC Micro designers could interleave screen memory access with CPU access, so no memory is contended. The Spectrum has to pause the processor while the ULA accesses the screen memory, meaning anything in the lower 16K of RAM takes a noticable performance penalty (and you can't use the lowest 16K for anything timing critical that must run while the ULA is reading the frame buffer).
Don't get me wrong, I love the Speccy, it's probably my favorite 8 bit (and I own several!) - it did an awful lot for very little money, it was immense value for money - but the BBC Micro was at the time had excellent performance.
I hadn't heard of Dreamhack until I started watching the SC2 tournament held there a week or so ago, no. (And the final game between LiquidHero and EG's Puma was one of the best pro SC2 games I've seen)
And I thought Euskal Encounter was pretty monumental (big LAN party in the Bilbao Exhibition Centre in Spain every year, which I go to). Here's a couple of pics from the 2010 event (I've been too lazy to upload 2011's pics):
I go to Euskal Encounter every year (in Bilbao, Spain), it's one of the biggest in Europe with over 4000 attendees, and there's never any trouble - the whole thing is always really good natured and fun. Of course the organization is very good, and being held in the BEC there's the usual exhibition centre security staff there (you don't ever want to mess with the Matafrikis, she can kill a man at 50 paces with one lash of her tongue).
I go to Euskal Encounter every year (a LAN party in the Bilbao Exhibition Centre in Bilbao, Spain. I go there to help put on one of the stands, I'm a member of RetroacciÃn, a retrocomputing group, and we put on RetroEuskal which is a zone where you can go to do some classic gaming. That's not to say I don't also get in a few games of Starcraft 2) which has 4096 LAN ports, and this is exactly what they do. 48 port switch at the end of each table, cables laid out to each one.
Euskal Encounter is quite interesting, they allow attendees to camp on site. One of the exhibition halls is set aside for tents... I can however afford a hotel so I don't subject myself to that:-)
Yes. Gaming requirements are measured in kilobits per second, not megabits. Gaming usually needs low latency more than it needs high bandwidth. Considering many games won't even go out of the LAN they probably get that.
(1) is impractical in IPv6. Network scanning will go away when each subnet in an organization is 64 bits long. Even if you find a subnet, to scan it you must scan an address size *four billion times larger* than the entire IPv4 internet. Even if there's some predictability to IPv6 autoconfigured addresses, you still end up having to scan address spaces thousands of times larger than the entire IPv4 internet.
(2) It's not NAT that makes hacks like this harder to pull off (they are generally pulled off by compromising a computer via things like drive-by website exploits), it's good host security and good network security. If you don't have these, NAT really isnÂt much of a barrier. NAT is not a security mechanism.
Cars and buses get stuck in traffic jams. Planes require you to get to the terminal (which is often in the middle of nowhere due to airport noise) an hour before you go, which really reduces the total speed of the trip. Trains often go from right in the middle of the population centre. The other good thing about most modern railways is they are electric, and therefore decoupled from their energy source. When peak oil comes, they can be running on nuclear, wind, coal - anything that feeds the power station.
Slashdot Mirror
There is a difference, say, with being (for example) in your mid 30s, in good health, and fully expecting to live between 40 and 60 years more - and being in your mid 30s, diagnosed with type 4 metastatic cancer and not expecting to be alive this time next year.
We still have milk deliveries here. With all the recreational horsey-people about, there's still blacksmiths too.
Sourcing the parts and getting it made really isn't a problem. I've done it for electronics with even more limited demand than this for a similar sized, similar part count board. There are assembly shops that can do runs of assembled boards right from just one example to hundreds of thousands, they do all the parts sourcing for you, you just give them a BOM and they organize it all. Most the parts on the Raspberry Pi will be common parts (resistors, capacitors, standard connectors, various ICs that get put into many different products) and are very easily sourced.
I've managed it *as an individual* with no organization backing me using these services.
I would agree on the marketing-the-product bit. The electronics really isn't a problem these days unless you're making something really odd with very unusual parts. Nothing about the Raspberry Pi is hard to source, especially since one of the team actually work at Broadcom and therefore can probably easily source the only thing that might cause problems, the SOC.
They already have a manufacturer lined up, from what I've read.
Discounting the elimination of possible "songs" that don't make musical sense, most 90 measure MAFIAA-type songs are not a 90 measure long melody and chord structure, rather two sets of the same segment of a tune repeated three or four times (three or four verses plus three or four choruses), so while the number of combinations is large, for a realistic MAFIAA-style song it's much less than 9^390.
Comments like this sort of make my stomach turn. If we had all thought like this, we would still be living in caves.
Others have already pointed out that you're wrong about Airbus aircraft, but you do realise that all new designs from Boeing are also digital fly-by-wire? And anything much bigger than a Boeing 737, the pilots no longer have any direct physical control over the flight control surfaces (either they rely on hydraulic mechanical systems, or fly by wire). There have been several incidents involving loss of hydraulic pressure that have caused the crew to have no control at all over the flight control surfaces: google Sioux City DC-10 for one particularly famous incident.
The same thing can be said of humans: if the sensors are giving wrong data (which they do very often), then what can a human do? A case in point with aviation: if a pilot is flying by hand in the clouds (no visual reference) or over a sparsely populated area on a moonless night, then if they use their sensors (inner ear) for orientation, they will crash sooner rather than later because their sensors will give them bad information. So the pilot is trained to fly on instruments. If those instruments give the pilot bad information, the pilot will be in trouble just as much as an automated system will be in trouble. How much trouble depends on how many instruments are giving bad information.
Of course the brain determines in advance how much pressure you can apply!
Have you ever been to some place where they serve your drink in what looks like a substantial heavy glass tankard, but in actual fact it's lightweight plastic? When you go to lift your drink, you give the glass far too much lifting power and almost throw your drink across the room because it's unexpectedly light. (You also grip it harder than need be, because you're expecting it to be glass and much heavier than it is - so yes, you've attempted to analyse the composition of the glass before lifting it) The second time you lift it you don't though, because you know in advance that it's plastic and light. You're not doing the glass-lift purely by feedback, your brain figures out how much power to use in lifting it from assumptions its already made.
Now if the pilot in a purely manually controlled aircraft had been flying, say, in the clouds lacking visual reference, and suddenly the airspeed started to decay very rapidly, yes, he probably would lower the nose to prevent a stall. Long before fly-by-wire, airliners also had "stick shakers" and "stick pushers" which automatically lower the nose if it looks like the aircraft is about to stall. There have been interesting crashes related to stick pushers, for instance the Trident that crashed in Staines in the 1970s (to cut a long story short, amongst many factors including possibly the health of the captain, an inexperienced first office and an inadvertant retraction of the leading edge slats, there had been reports of false stick pusher activations on that type of aircraft. The aircraft really was stalling, but a crew member disabled the stick pusher believing the activation to be false, and the aircraft entered a deep stall and crashed, killing everyone on board).
You can run chipscope (Xilinx) to see what's going on inside. You can also run simulations before you instantiate your hardware in the FPGA. In a simulation, you can indeed do the equivalent of "printf".
The UK switched from coal to NG? That's news to me.
At this exact moment in time, UK electricity generation is:
Coal: 21.42 GW
CCGT 12.23 GW
Nuclear 7.29 GW
Wind 2.9 GW
It's not a switch from coal, rather increased capacity via CCGT. Coal still produces the lion's share of electricity.
When I worked in the US, between graduating (1995) until 2001, we were already "exempt", in other words exempt from getting overtime payments. It's one of the reasons I left the US, the crappy work/life balance and the expectation that working unpaid overtime was the norm for software developers (I've since heard my old workplace now effectively requires - not during crunch times, but the actual norm - something like 50 hour weeks while only paying for 40. During crunch times of course they demand far more).
And if it weren't for Acorn, the ARM would never have existed for Apple to put in $800M in hard cold cash. The ARM project started in 1983, years before Apple or anyone else for that matter even knew of the project. The BBC Micro was the seed, the ARM's original purpose was to put in the next BBC Micro (the Acorn Archimedes).
Apple saved the ARM, and the ARM saved Apple, it went both ways :-)
What the 6502 in the C64 (and the BBC Micro, under discussion) had which most people who started asm on the Z80 missed was the zero page. Effectively, using the zero page you had 256 registers. Zero page operations on the 6502 were as fast as register operations on the Z80. While I'm much more proficient at Z80 asm than 6502, I really appreciate the very straightforward and uncomplicated - but powerful - design of the 6502.
You're not quite correct: it's actually a 16MHz ARM that runs circles around a 100MHz 68000. The ARM is *astonishingly* faster than the 68K.
No, it's not at all related to the Ohio Scientific. The only thing they have in common is they are both 6502-based.
The BBC Micro at 2MHz was considerably faster than the Spectrum at 3.5MHz. The Z80 is a CPU that I like (I still write Z80 assembler, indeed I'm much more proficient at Z80 than 6502 and I've designed and made an ethernet card for the ZX Spectrum fairly recently as a fun retro project). However, we have to consider this. The fastest 6502 instruction executes in 2 T-states, most execute in 3 T-states, and the slowest take 7 T-states. The fastest Z80 instruction takes 4 T-states and the slowest over 20 T-states. The 6502 therefore has better interrupt latency (that monster 23 T-state index register instruction on the Z80 can't be interrupted).
The other thing the 6502 has going for it is the very fast zero page instructions, which are tantamount to giving you 256 extra registers.
The competing ZX Spectrum also had contended memory. Thanks to the 6502's predictable memory cycle when compared to the Z80, the BBC Micro designers could interleave screen memory access with CPU access, so no memory is contended. The Spectrum has to pause the processor while the ULA accesses the screen memory, meaning anything in the lower 16K of RAM takes a noticable performance penalty (and you can't use the lowest 16K for anything timing critical that must run while the ULA is reading the frame buffer).
Don't get me wrong, I love the Speccy, it's probably my favorite 8 bit (and I own several!) - it did an awful lot for very little money, it was immense value for money - but the BBC Micro was at the time had excellent performance.
I hadn't heard of Dreamhack until I started watching the SC2 tournament held there a week or so ago, no. (And the final game between LiquidHero and EG's Puma was one of the best pro SC2 games I've seen)
And I thought Euskal Encounter was pretty monumental (big LAN party in the Bilbao Exhibition Centre in Spain every year, which I go to). Here's a couple of pics from the 2010 event (I've been too lazy to upload 2011's pics):
http://photo.alioth.net/RE10/pabellon.jpg - the main hall, it's about the size of a football pitch
http://photo.alioth.net/RE10/tentcity.jpg - Where many people sleep, another BEC hall full of tents!
http://photo.alioth.net/RE10/bushnell1.jpg Nolan Bushnell, Atari's founder visited us.
http://photo.alioth.net/RE10/bushnell2.jpg
Nolan Bushnell is still highly enthusiastic about gaming, it was a real pleasure to meet him.
http://photo.alioth.net/RE10/twitter-euskera.jpg Retro activities, twittering from a 1980s vintage Sinclair Spectrum!
http://photo.alioth.net/RE10/descansar.jpg Random geeks getting a bit too tired :)
Where were these LAN parties?
I go to Euskal Encounter every year (in Bilbao, Spain), it's one of the biggest in Europe with over 4000 attendees, and there's never any trouble - the whole thing is always really good natured and fun. Of course the organization is very good, and being held in the BEC there's the usual exhibition centre security staff there (you don't ever want to mess with the Matafrikis, she can kill a man at 50 paces with one lash of her tongue).
I go to Euskal Encounter every year (a LAN party in the Bilbao Exhibition Centre in Bilbao, Spain. I go there to help put on one of the stands, I'm a member of RetroacciÃn, a retrocomputing group, and we put on RetroEuskal which is a zone where you can go to do some classic gaming. That's not to say I don't also get in a few games of Starcraft 2) which has 4096 LAN ports, and this is exactly what they do. 48 port switch at the end of each table, cables laid out to each one.
Euskal Encounter is quite interesting, they allow attendees to camp on site. One of the exhibition halls is set aside for tents... I can however afford a hotel so I don't subject myself to that :-)
Yes. Gaming requirements are measured in kilobits per second, not megabits. Gaming usually needs low latency more than it needs high bandwidth. Considering many games won't even go out of the LAN they probably get that.
No, you want to use a firewall.
(1) is impractical in IPv6. Network scanning will go away when each subnet in an organization is 64 bits long. Even if you find a subnet, to scan it you must scan an address size *four billion times larger* than the entire IPv4 internet. Even if there's some predictability to IPv6 autoconfigured addresses, you still end up having to scan address spaces thousands of times larger than the entire IPv4 internet.
(2) It's not NAT that makes hacks like this harder to pull off (they are generally pulled off by compromising a computer via things like drive-by website exploits), it's good host security and good network security. If you don't have these, NAT really isnÂt much of a barrier. NAT is not a security mechanism.
Cars and buses get stuck in traffic jams. Planes require you to get to the terminal (which is often in the middle of nowhere due to airport noise) an hour before you go, which really reduces the total speed of the trip. Trains often go from right in the middle of the population centre. The other good thing about most modern railways is they are electric, and therefore decoupled from their energy source. When peak oil comes, they can be running on nuclear, wind, coal - anything that feeds the power station.
Don't bank on this story actually being true, the Daily Fail^W Mail has published many blatantly false articles.
If you want to know what the Daily Mail is like, just watch this Dan & Dan song about the paper and it tells you pretty much all you need to know:
http://www.youtube.com/watch?v=5eBT6OSr1TI