I've not seen anything actually shipping that includes Tegra 2, although it's been coming Real Soon Now for a year or so.
Toshiba's AC100 netbook and Folio 100 tablet both use Tegra 2. The AC100 is definitely available, as I'm using one to type this! It came with Android 2.1 installed, which isn't usable in the netbook form factor. However, I've put Ubuntu onto it and it works OK (I bought it with this intention, I never intended to run Android on it).
Perhaps a better analogy of a diode valve would be the valve in a bicycle tyre which only allows air into the tyre but not out. Or a heart valve. The bicycle tyre analogy is used in "The Manual of Modern Radio" (1932, John Scott-Taggart). Not the best title in hindsight:)
Ambrose Fleming (English) patented the thermionic valve in the UK in 1904 and in the US in 1905. This was a two electrode device (anode and cathode) which acted as a rectifier/detector, i.e. a diode. It was called a thermionic valve as it was analogous to a standard valve, e.g. in a water pipe. It only allowed current flow in one direction.
In 1908, Lee De Forest (American) invented the triode, which was a three electrode device (this has a grid in addition to cathode and anode). This is analogous to the transistor, not Fleming's diode valve. A charge on the grid varies the electron flow between cathode and anode. This enables amplification.
In the UK, what (was) known as a thermionic valve (or valve) is what is called in the US a vacuum tube. But as with everything else, the old British terms are dying out, and you often hear them called tubes, e.g. "tube radios" here as well. Much to my disgust:)
We also used to call :
Aerial = antenna
Earth = ground
I collect and restore pre-WWII valve radios! (pre WWII a condensor = capacitor).
Most of your points are right, however, I take issue with the statement that the bytecode loop is trivial. This, I'm afraid, is a widely held misconception:)
While a simple switch-based interpreter is trivial to implement, it will perform abysmally on modern processors because of the overhead of the computed jumps. Writing an efficient interpreter has been an active research area in itself (see http://www.complang.tuwien.ac.at/projects/interpre ters.html for some good papers). In fact, the difference between a poor interpreter and a good interpreter can be greater than that between an intepreter and a JIT.
Several improvements over a switched interpreter are possible. Firstly, indirect-threading can be used to minimise dispatch overhead. This can further be improved by moving to direct-dispatching, but this requires rewriting the original bytecode stream. Splitting instruction fetch and address computation via prefetching can also lead to substantial gains, as can the use of "super-instructions".
Additionally, an interpreter can attempt to do stack-caching (either simple top-of-stack caching or more advanced 2 or more levels). This can be used to overcome the inefficiency of executing stack-based bytecodes on a register-based CPU.
Many of these techniques move into the grey area between interpreters and JIT compilers. But no commercial VM uses a simple bytecode interpreter. Even with a JIT, modern VMs still initially execute code using the interpreter, only compiling the "hot spots" to native code. With full JIT compilation, the start-up time of the VM becomes prohibitive.
Many of these techniques are also used in some of the open-source VMs. For example, the interpreter in JamVM, depending on architecture, makes use of direct-dispatching, super-instructions, prefetching, and true, 2 level stack-operand caching. It is many times faster than a simple bytecode interpreter, and it has not been trivial to implement!
Funny, because Sun employs a team of 20+ to work on the VM, and IBM even more. I'll tell them to sack them all, because any semi-decent programmer can knock a VM off in an afternoon.
Wake up. A simple VM may take a year, but a high performance VM takes a _huge_ amount of effort. And this is code that is qualitatively different to the class-library. There the problem is sheer quantity. The VM has to deal with high-performance synchronisation, execution, etc. Make even a tiny mistake and you might as well go home. Much of this was research topics only a few years ago. Hardly the province of the amateur coder.
JamVM is hardly state-of-the-art, but it's not a trivial VM implementation either.
Yeah, they were sequential. They had one reel, containing a single continuous loop of tape. The tape was pulled out of the middle of the reel and wound back onto the outside. Supposedly it was made out of "industrial strength" video tape, but it explains why they were so unreliable. The tape must have been under considerable strain. It was also why they were so slow.
If I remember, it would go round the loop 5 times, and if it still couldn't read it, it would give up, with the dreaded IO error:) You'd sit there listening to the tape going round, counting the passes with your fingers crossed. All the old tricks, like trying it in multiple drives, giving it a shake, or a wiggle when it was in the drive. You only lived with it because it was vastly better than cassette tapes. How many people today would put up with trying 3 or 4 times to load a game, each time with different volume settings?
When I took my microdrives apart (to clean the rollers, etc.), the head looked suspiciously like a cassette player head, but I don't know if it was.
The 68000 wasn't truly 32-bit until the 68020 was introduced. The programmers model may have been 32-bit internally (i.e. registers) but the 68000 (and 68010) had a 16-bit data bus, meaning all loads and stores were done in two lots.
As you said, the 68008 had an 8-bit bus, meaning all loads and stores took 4 operations! Strangely enough, it was actually introduced after the 68000, to try and encourage its adoption at a time when 8-bit systems, and their cheap boards ruled.
Incidently, the 16/32 bit split of the 68000 was supposedly where the ST came from in the Atari ST range (e.g. 520ST). That or Sam Tramiel (son of the CEO of Atari Jack Tramiel)...
My mistake was thinking a couple of minutes reading slashdot would help me relax in the middle of a _very_ stressful day! What do I find but an article about the very industry which will probably lead me to having a heart attack by the time I'm 40.
Got to go and say goodbye to some colleagues who are "leaving" today...
God, I do hate loud-mouth fucking Americans talking out of their asses about things they know fuck all about.
For your information, I DO know who my company sells phones for, what their target sales price is, what their average price they get is, and how much they cost to manufacture. Unless you work for Nokia and can back up your figures I suggest you keep your big mouth shut.
Unlike your girlfriend, I WORK for a mobile phone handset manufacturer, designing the next gen phones. The article is completely accurate.
Handset manufacturers are very aware of market share, and are always trying to increase their share by exploiting new markets, under-cutting whatever. The key factor is that this is all dependent on the operators within each domain. This means the operators can demand almost anything, and the handset manufacturers compete themselves into the ground to win the contracts.
The operators may pay for the phones, but the manufacturer with the lowest price for the features will win. Margins are razor thin. Last quarter Nokia lost market share, and ended up slashing the prices on handsets to try to win it back. This led to other manufacturers having to drop prices to compete, leading to even faster price reductions than normal.
Design cycles are getting shorter and shorter. The number of phones we have in design at any one time is going up and up, as is the number of features. Each operator has their own testing, and their own particular sets of requirements.
As a fashion accessory, phones are now in the bargain-bin only a couple of months after we finished them! The ability to make money in this environment is almost zero, and the work soul-destroying.
I can't say what measures my company has made to cut costs in case it can be traced back. But people and resources were already cut to the bone. The unlucky ones are now those left behind.
And you think the alarm clock is implemented in Java do you? Just because it's "Java-powered" doesn't mean it's all written in Java.
The Java VM is usually just another application on the phone which is used to run Java games (MIDlets).
If the phone crashes when it's used as a phone it's not Java's problem. If you have Java installed on your peecee and the peecee crashes when you're using Internet Explorer, do you turn round and blame the Java VM? Knowing the rediculous amount of knee-jerk Java bashing that goes on you probably do.
I think people are missing the point here! Microsoft isn't a distributor, it's the originator.
Linux distributors don't write the bulk of what they distribute, that's why it's called a Linux distribution. They bundle what's out there already. They're non-partisan -- a better widget appears on the radar and it'll go into the next release.
Microsoft on the other hand writes the OS and everything in the release. They're partisan. They might want to ship you everything you ever need but's that uncompetitive and people obviously get upset.
I admit by first post was a bit OTT -- it's been a long and hard day today (it's 20:15, and I'll be here a while yet). No, it isn't working on a VM:)
I agree that there's a long way between a basic VM and a state-of-the-art one. However, you were making the point that the libraries were the stumbling block to a truly free Java implementation. My point was that it is the sheer size of the class library that's making this difficult, not the complexity of the code per se.
While it may be possible to write a _very_ basic VM in a couple of months(*), it'll be just as unusable as a half completed swing implementation would be. We need both a complete class library and a state-of-the-art VM. One without the other is pointless.
(*) Having said that, there's been a lot of feature creep in the VM to keep up with the ever expanding APIs. Support for Reflection is fairly non-trivial as is class-loaders. Neither of these are covered in the VM spec (class loaders obliquely in places). Nor is GC support for weak, phantom, etc. references. In fact, you don't need a GC to fulfill the spec. A toy VM will not only be slow, but very incomplete as well.
Come on then, Mr. Big Mouth. When YOU pick up the Virtual Machine spec and implement your own VM from scratch, THEN I'll believe you when you say any monkey can write a VM. In the meantime, talk about things you actually know something about.
I HAVE written a VM from scratch, and worked on Sun and IBM's Virtual Machines. I can tell you from experience that writing a VM is definately not a trivial task. In fact, it is probably harder than the libraries. The libraries are by definition Java code. The major problem is the sheer size of them.
A modern VM on the other-hand, covers a wide range of techniques. Writing an efficient thin-locking implementation is far from trivial - the code is extremely complex, and even a slight mistake can lead to race conditions, leading to unexpected behaviour which is very difficult to track down.
Likewise, a modern garbage collector is an advanced field in itself (e.g. parallel collectors, generational collectors, etc.). Again, a simple mistake can take weeks to find.
Have you also forgotten about the JIT? Or more accurately a DAC (dynamic adaptive compiler). Whereas a standard compiler can spend as long as it likes optimising the code and be slow as hell, a modern VM must profile the code on the fly, and transfer control between compiled and interpreted modes efficiently. Again, not trivial.
Even following the spec is non-trivial. There's enough grey areas to cause a VM implementor to pull their hair out.
Sun and IBM have large teams working on these VM's, many from research backgrounds and with PhDs (including me). Thanks for calling us all monkeys.
So you think it's "fairly easy to create" a Java Virtual Machine because there's a specification?
Have you tried to write a JVM from scratch using it? If not, in all politeness, you haven't a clue as to what you're talking about.
First of all, the VM specification is a specification, not a guide as to how to write a VM. The VM is regarded as a "black box" - as long as a VM behaves from the outside according to the specification, it can be implemented anyway you like. So don't expect to find anything about object models, interpreter design, garbage collection, threading, synchronisation, method tables, compilers or anything else.
The specification is deliberately vague about implementation details to give the implementor flexibility. For example, it is strictly not necessary for a VM to implement garbage collection. Once the heap is full, just abort. Likewise, the native interface is implementation dependent. Don't expect to find anything about the Java Native Interface (JNI) in the spec because it isn't there, nor is reflection.
What this means is that writing a toy VM which minimally obeys the spec may be fairly easy (e.g. runs Hello World). Writing a practical VM which could usefully be used as a replacement for Sun's is a big and very difficult task, involving some of the hardest and most error-prone code you can write (fast locking implementations. etc.). In constrast, the Java libraries are (obviously) written in Java with all the advantages that gives. The major difficulty is the size, and keeping up with Sun. They haven't got to spend days tracking down a subtle GC bug which causes references to get trashed.
I really believed it was only the low-skill grunt work being off-shored until I did a global search on monster.com. The number of jobs in India/China asking for advanced skills and knowledge is truly staggering. Just think of the number of "foreigners" in grad schools in both the US and Europe -- most of them won't be staying but will be returning as the job situation is now better at home. Most of the big IT companies such as IBM, HP and Intel have set up new research labs in India and China to tap into this talent.
The reality is that R&D follows the growth markets. The new markets are in India and China and Western companies are falling over themselves to invest in order to get a slice of the pie.
If anything I think IT in the west will increasingly be near-customer integration and customisation of basic technology developed and manufactured in China/Taiwan/South Korea and India. Companies who started off as sub-contractors for Western companies are waking up and realising they're the ones who call the shots. Just look at Samsung who now control flat screen development and moves by Chinese manufacturers to develop their own standards so that they no longer rely on Western IP.
A lot of programmers are going back to school to get Masters and PhD degrees. My fear would be that they will leave in 4 years time with no more market for their skills than before and just an even bigger pile of debts to pay off.
Sorry, but speaking as someone who returned to the UK from the States at the beginning of 2001, that's complete and utter rubbish!
It's estimated that between 30 and 50% of IT contractors in the UK are currently unemployed. I've been lucky - since coming back I've had 3 six month contracts. However, I've spent in total 9 months unemployed, and my hourly rate has steadily gone down - it's now half what it was.
In the UK last year over 22,000 IT work permits were issued, the majority going to Indians - this is roughly the number of contractors estimated to be out-of-work. Earlier this year, after the Professional Contractors Guild (PCG) successfully lobbied for all IT skills to be removed from the Skills Shortage list, the Government, after lobbying from Indian companies added the Indian Business Group to the IT Skills Panel to represent UK employers!
I'm not one who believes all the conspiracy theories floating around, and take what I read with a large pinch of salt but it does seem as if the IT Industry is being used in some poker game being played by the UK and EU Governments in exchange for developing countries opening up their markets.
I don't blame the Indians. The real villian is big business - in the face of globalisation, national Governments have very little real power as companies can just threaten to move if they don't like something (as in Deutsche Bank). However, Governments should be working in the interests of the people not business. What's so bad about the UK Labour party is that they were founded by the workers, whom they now seem to have abandoned.
Oh, good luck in sitting on the dole queue for 3 months of the year. In the UK the basic dole money is now 80 dollars/week, independent of how much you used to earn!
If you're interested in the state of IT in the UK have a look on namesfacesplaces.com.
Wow! Lots of questions!
Both of them are running Yellow Dog Linux 3.0. I have tried Debian Woody (last year), but prefer YDL.
I don't think it matters in which order the partitions are. I usually put MacOS X first, because I install it first. I then put Linux on and setup yaboot to dual boot them.
Last time (i.e. Saturday), I stuck the Jaguar DVD in, used Drive Setup utility (now accessed via a menu option) to partition the disk in 2, and installed MacOS X on the first.
Then, under the YDL 3.0 installer, I deleted the 2nd partition and replaced it with 3. A 1Mb Bootstrap partition (Apple_Bootstrap) for yaboot, a 512Mb swap partition and the rest for root (/), and that's it - the installer does the rest...
Oh, if you're installing on a new 12", make sure you get the a recent version of XFree86. The one that came with YDL 3.0 (from June?) doesn't recognise the GeForce FX go5200. Upgrading to the one from YDL 3.0.1 fixes this.
Also, watch out for the MacOS X 10.2.8 upgrade. The cpufreq code in the linuxppc kernel contains a protocol error and doesn't work after the upgrade (crashes on boot). Either recompile the kernel with it turned off, or grab a (very) recent kernel from benh where it's been fixed.
Well, I hope this doesn't come out as anonymous coward like my last pos.
As I said (newly created account, AstroByte in case I'm a coward again) it sounds like a PPC7455. Interestingly (for Slashdotters anyway), it makes it a worse Linux laptop than before.
Clock for clock, on non-altivec code, a 800MHz 7455 will perform worse than a 900MHz 750fx. And the 750fx had 512K of cache as opposed to 256K...
BTW, I have a 700MHz iBook and a 1GHz 12" Powerbook both running Linux. 12" wipes the floor under MacOSX which is obviously why they've done it.
Slashdot Mirror
I've not seen anything actually shipping that includes Tegra 2, although it's been coming Real Soon Now for a year or so.
Toshiba's AC100 netbook and Folio 100 tablet both use Tegra 2. The AC100 is definitely available, as I'm using one to type this! It came with Android 2.1 installed, which isn't usable in the netbook form factor. However, I've put Ubuntu onto it and it works OK (I bought it with this intention, I never intended to run Android on it).
Perhaps a better analogy of a diode valve would be the valve in a bicycle tyre which only allows air into the tyre but not out. Or a heart valve. The bicycle tyre analogy is used in "The Manual of Modern Radio" (1932, John Scott-Taggart). Not the best title in hindsight :)
Ambrose Fleming (English) patented the thermionic valve in the UK in 1904 and in the US in 1905. This was a two electrode device (anode and cathode) which acted as a rectifier/detector, i.e. a diode. It was called a thermionic valve as it was analogous to a standard valve, e.g. in a water pipe. It only allowed current flow in one direction. In 1908, Lee De Forest (American) invented the triode, which was a three electrode device (this has a grid in addition to cathode and anode). This is analogous to the transistor, not Fleming's diode valve. A charge on the grid varies the electron flow between cathode and anode. This enables amplification. In the UK, what (was) known as a thermionic valve (or valve) is what is called in the US a vacuum tube. But as with everything else, the old British terms are dying out, and you often hear them called tubes, e.g. "tube radios" here as well. Much to my disgust :)
We also used to call :
Aerial = antenna
Earth = ground
I collect and restore pre-WWII valve radios! (pre WWII a condensor = capacitor).
While a simple switch-based interpreter is trivial to implement, it will perform abysmally on modern processors because of the overhead of the computed jumps. Writing an efficient interpreter has been an active research area in itself (see http://www.complang.tuwien.ac.at/projects/interpre ters.html for some good papers). In fact, the difference between a poor interpreter and a good interpreter can be greater than that between an intepreter and a JIT.
Several improvements over a switched interpreter are possible. Firstly, indirect-threading can be used to minimise dispatch overhead. This can further be improved by moving to direct-dispatching, but this requires rewriting the original bytecode stream. Splitting instruction fetch and address computation via prefetching can also lead to substantial gains, as can the use of "super-instructions".
Additionally, an interpreter can attempt to do stack-caching (either simple top-of-stack caching or more advanced 2 or more levels). This can be used to overcome the inefficiency of executing stack-based bytecodes on a register-based CPU.
Many of these techniques move into the grey area between interpreters and JIT compilers. But no commercial VM uses a simple bytecode interpreter. Even with a JIT, modern VMs still initially execute code using the interpreter, only compiling the "hot spots" to native code. With full JIT compilation, the start-up time of the VM becomes prohibitive.
Many of these techniques are also used in some of the open-source VMs. For example, the interpreter in JamVM, depending on architecture, makes use of direct-dispatching, super-instructions, prefetching, and true, 2 level stack-operand caching. It is many times faster than a simple bytecode interpreter, and it has not been trivial to implement!
Funny, because Sun employs a team of 20+ to work on the VM, and IBM even more. I'll tell them to sack them all, because any semi-decent programmer can knock a VM off in an afternoon. Wake up. A simple VM may take a year, but a high performance VM takes a _huge_ amount of effort. And this is code that is qualitatively different to the class-library. There the problem is sheer quantity. The VM has to deal with high-performance synchronisation, execution, etc. Make even a tiny mistake and you might as well go home. Much of this was research topics only a few years ago. Hardly the province of the amateur coder. JamVM is hardly state-of-the-art, but it's not a trivial VM implementation either.
If I remember, it would go round the loop 5 times, and if it still couldn't read it, it would give up, with the dreaded IO error :) You'd sit there listening to the tape going round, counting the passes with your fingers crossed. All the old tricks, like trying it in multiple drives, giving it a shake, or a wiggle when it was in the drive. You only lived with it because it was vastly better than cassette tapes. How many people today would put up with trying 3 or 4 times to load a game, each time with different volume settings?
When I took my microdrives apart (to clean the rollers, etc.), the head looked suspiciously like a cassette player head, but I don't know if it was.
As you said, the 68008 had an 8-bit bus, meaning all loads and stores took 4 operations! Strangely enough, it was actually introduced after the 68000, to try and encourage its adoption at a time when 8-bit systems, and their cheap boards ruled.
Incidently, the 16/32 bit split of the 68000 was supposedly where the ST came from in the Atari ST range (e.g. 520ST). That or Sam Tramiel (son of the CEO of Atari Jack Tramiel)...
Got to go and say goodbye to some colleagues who are "leaving" today...
For your information, I DO know who my company sells phones for, what their target sales price is, what their average price they get is, and how much they cost to manufacture. Unless you work for Nokia and can back up your figures I suggest you keep your big mouth shut.
Unlike your girlfriend, I WORK for a mobile phone handset manufacturer, designing the next gen phones. The article is completely accurate.
Handset manufacturers are very aware of market share, and are always trying to increase their share by exploiting new markets, under-cutting whatever. The key factor is that this is all dependent on the operators within each domain. This means the operators can demand almost anything, and the handset manufacturers compete themselves into the ground to win the contracts.
The operators may pay for the phones, but the manufacturer with the lowest price for the features will win. Margins are razor thin. Last quarter Nokia lost market share, and ended up slashing the prices on handsets to try to win it back. This led to other manufacturers having to drop prices to compete, leading to even faster price reductions than normal.
Design cycles are getting shorter and shorter. The number of phones we have in design at any one time is going up and up, as is the number of features. Each operator has their own testing, and their own particular sets of requirements.
As a fashion accessory, phones are now in the bargain-bin only a couple of months after we finished them! The ability to make money in this environment is almost zero, and the work soul-destroying.
I can't say what measures my company has made to cut costs in case it can be traced back. But people and resources were already cut to the bone. The unlucky ones are now those left behind.
If the phone crashes when it's used as a phone it's not Java's problem. If you have Java installed on your peecee and the peecee crashes when you're using Internet Explorer, do you turn round and blame the Java VM? Knowing the rediculous amount of knee-jerk Java bashing that goes on you probably do.
Linux distributors don't write the bulk of what they distribute, that's why it's called a Linux distribution. They bundle what's out there already. They're non-partisan -- a better widget appears on the radar and it'll go into the next release.
Microsoft on the other hand writes the OS and everything in the release. They're partisan. They might want to ship you everything you ever need but's that uncompetitive and people obviously get upset.
Don't forget about JamVM!
I agree that there's a long way between a basic VM and a state-of-the-art one. However, you were making the point that the libraries were the stumbling block to a truly free Java implementation. My point was that it is the sheer size of the class library that's making this difficult, not the complexity of the code per se.
While it may be possible to write a _very_ basic VM in a couple of months(*), it'll be just as unusable as a half completed swing implementation would be. We need both a complete class library and a state-of-the-art VM. One without the other is pointless.
(*) Having said that, there's been a lot of feature creep in the VM to keep up with the ever expanding APIs. Support for Reflection is fairly non-trivial as is class-loaders. Neither of these are covered in the VM spec (class loaders obliquely in places). Nor is GC support for weak, phantom, etc. references. In fact, you don't need a GC to fulfill the spec. A toy VM will not only be slow, but very incomplete as well.
I HAVE written a VM from scratch, and worked on Sun and IBM's Virtual Machines. I can tell you from experience that writing a VM is definately not a trivial task. In fact, it is probably harder than the libraries. The libraries are by definition Java code. The major problem is the sheer size of them.
A modern VM on the other-hand, covers a wide range of techniques. Writing an efficient thin-locking implementation is far from trivial - the code is extremely complex, and even a slight mistake can lead to race conditions, leading to unexpected behaviour which is very difficult to track down.
Likewise, a modern garbage collector is an advanced field in itself (e.g. parallel collectors, generational collectors, etc.). Again, a simple mistake can take weeks to find.
Have you also forgotten about the JIT? Or more accurately a DAC (dynamic adaptive compiler). Whereas a standard compiler can spend as long as it likes optimising the code and be slow as hell, a modern VM must profile the code on the fly, and transfer control between compiled and interpreted modes efficiently. Again, not trivial.
Even following the spec is non-trivial. There's enough grey areas to cause a VM implementor to pull their hair out.
Sun and IBM have large teams working on these VM's, many from research backgrounds and with PhDs (including me). Thanks for calling us all monkeys.
First of all, the VM specification is a specification, not a guide as to how to write a VM. The VM is regarded as a "black box" - as long as a VM behaves from the outside according to the specification, it can be implemented anyway you like. So don't expect to find anything about object models, interpreter design, garbage collection, threading, synchronisation, method tables, compilers or anything else.
The specification is deliberately vague about implementation details to give the implementor flexibility. For example, it is strictly not necessary for a VM to implement garbage collection. Once the heap is full, just abort. Likewise, the native interface is implementation dependent. Don't expect to find anything about the Java Native Interface (JNI) in the spec because it isn't there, nor is reflection.
What this means is that writing a toy VM which minimally obeys the spec may be fairly easy (e.g. runs Hello World). Writing a practical VM which could usefully be used as a replacement for Sun's is a big and very difficult task, involving some of the hardest and most error-prone code you can write (fast locking implementations. etc.). In constrast, the Java libraries are (obviously) written in Java with all the advantages that gives. The major difficulty is the size, and keeping up with Sun. They haven't got to spend days tracking down a subtle GC bug which causes references to get trashed.
The reality is that R&D follows the growth markets. The new markets are in India and China and Western companies are falling over themselves to invest in order to get a slice of the pie.
If anything I think IT in the west will increasingly be near-customer integration and customisation of basic technology developed and manufactured in China/Taiwan/South Korea and India. Companies who started off as sub-contractors for Western companies are waking up and realising they're the ones who call the shots. Just look at Samsung who now control flat screen development and moves by Chinese manufacturers to develop their own standards so that they no longer rely on Western IP.
A lot of programmers are going back to school to get Masters and PhD degrees. My fear would be that they will leave in 4 years time with no more market for their skills than before and just an even bigger pile of debts to pay off.
I have a BSc, MSc and PhD and I'm scared...
It's estimated that between 30 and 50% of IT contractors in the UK are currently unemployed. I've been lucky - since coming back I've had 3 six month contracts. However, I've spent in total 9 months unemployed, and my hourly rate has steadily gone down - it's now half what it was.
In the UK last year over 22,000 IT work permits were issued, the majority going to Indians - this is roughly the number of contractors estimated to be out-of-work. Earlier this year, after the Professional Contractors Guild (PCG) successfully lobbied for all IT skills to be removed from the Skills Shortage list, the Government, after lobbying from Indian companies added the Indian Business Group to the IT Skills Panel to represent UK employers!
I'm not one who believes all the conspiracy theories floating around, and take what I read with a large pinch of salt but it does seem as if the IT Industry is being used in some poker game being played by the UK and EU Governments in exchange for developing countries opening up their markets.
I don't blame the Indians. The real villian is big business - in the face of globalisation, national Governments have very little real power as companies can just threaten to move if they don't like something (as in Deutsche Bank). However, Governments should be working in the interests of the people not business. What's so bad about the UK Labour party is that they were founded by the workers, whom they now seem to have abandoned.
Oh, good luck in sitting on the dole queue for 3 months of the year. In the UK the basic dole money is now 80 dollars/week, independent of how much you used to earn!
If you're interested in the state of IT in the UK have a look on namesfacesplaces.com.
Wow! Lots of questions! Both of them are running Yellow Dog Linux 3.0. I have tried Debian Woody (last year), but prefer YDL. I don't think it matters in which order the partitions are. I usually put MacOS X first, because I install it first. I then put Linux on and setup yaboot to dual boot them. Last time (i.e. Saturday), I stuck the Jaguar DVD in, used Drive Setup utility (now accessed via a menu option) to partition the disk in 2, and installed MacOS X on the first. Then, under the YDL 3.0 installer, I deleted the 2nd partition and replaced it with 3. A 1Mb Bootstrap partition (Apple_Bootstrap) for yaboot, a 512Mb swap partition and the rest for root (/), and that's it - the installer does the rest... Oh, if you're installing on a new 12", make sure you get the a recent version of XFree86. The one that came with YDL 3.0 (from June?) doesn't recognise the GeForce FX go5200. Upgrading to the one from YDL 3.0.1 fixes this. Also, watch out for the MacOS X 10.2.8 upgrade. The cpufreq code in the linuxppc kernel contains a protocol error and doesn't work after the upgrade (crashes on boot). Either recompile the kernel with it turned off, or grab a (very) recent kernel from benh where it's been fixed.
Well, I hope this doesn't come out as anonymous coward like my last pos. As I said (newly created account, AstroByte in case I'm a coward again) it sounds like a PPC7455. Interestingly (for Slashdotters anyway), it makes it a worse Linux laptop than before. Clock for clock, on non-altivec code, a 800MHz 7455 will perform worse than a 900MHz 750fx. And the 750fx had 512K of cache as opposed to 256K... BTW, I have a 700MHz iBook and a 1GHz 12" Powerbook both running Linux. 12" wipes the floor under MacOSX which is obviously why they've done it.