The last place I worked that still used SCO also used it mainly for microfocus COBOL. That SCO install was also prone to periodic kernel panics.
The solution we finally arrived on (after spending much time chasing an assumed hardware issue) was to kick off a cron job to reboot the damn thing every night. After that it was quite solid. Of course this is not an option for everyone and YMMV.
Step down? Bleh! Look carefully your equipment before bothering. I was suprised to find that the majority of my electronics are rated from 120 all the way to 240. (Canon stuff, fuji stuff, toshiba stuff, ipaq charger, etc.) You just need an adapter for the receptacle style. This has served me well for several asian countries, you just need to be careful when you buy your gear.
Now for the freaks on different freqs, you may need to start worrying about serious adapters. Then again a lot of gear is OK with 50 and 60Hz. Read all that little fine print on the power supplies.
(Besides, you should be using a solar charger for you GPS and laptop while in the field. Takes all the worry out of it.)
This sounds like a cool project. There is a ton of existing free GIS software to support it. If you do end up on windows, avoid Delorme. Their GPS gear is alright (nothing wonderful), but their software is pretty awful.
Obsolescence is not just for the sake of upgrading
on
DECnet Isn't Dead
·
· Score: 1
You're right, upgrading just to upgrade isn't such a hot idea. However, upgrading because DEC/Compaq/HP dropped VAX support a couple of years back is a different thing entirely. Several places I've worked kept on going in an unsupported config and patching it together until they were forced to upgrade under extreme pressure, and none of those ever turned out well.
Yeah, you can make the jump from VAX to Alpha to stay on VMS, but I guess where I work we see VMS on Alpha as a ship that's already going down. If we are going to have to migrate, moving to a dying platform just didn't seem like the way to go. Also I think that someone high up in our organization has a lot of microsoft stock, but that's just my cynical side speaking.
(And downtime doesn't quite cost us a grand a minute! Ouch... although actually if you count all of the engineering time being blown when the system is down it does get ugly really fast. I'd never really thought about it in terms of money per time.)
We were seeing situations where a rogue system would cause the entire cluster to reboot! VAXes, micros, alphas, VAXstations, everything! It was kind of hard to defend against. And the support guys from compaq said everything was setup correctly. It WAS rooted in bad hardware on one of the stations, but still...
100% uptime ... oh please ...
on
DECnet Isn't Dead
·
· Score: 2, Interesting
The projects I've worked for the last 8 years or so have used VAX and Alpha VMS and I can say that the much-vaunted uptime for VMS tends to be exaggerated. Yes VMS is generally solid, that I won't argue. However, it is very vulnerable to HW failure, just like anything else, and maybe more so than anything else we have around. We have had many many instances of a rogue VAXStation or microVAX taking out an entire cluster, redundancy and all. I see that as unacceptable.
You might say it must have been a admin/config problem. Weeeellll maybe (those guys seem to really know their sh-t cold, but one never knows) but then if it's that easy to misconfigure, how reliable is it really? And have you ever tried FINDING people that can maintain this stuff?
Lately we've been migrating off to the wintel world (and to some SGI as well) and the uptime numbers really have not changed that much. Some windows services tend to go down more often than their VMS equivalent, but things are mostly the same. The only reason we have to keep VAXen around is legacy applications that would be very very hard to port off of VMS. Anyone who has ever had to convert a G-Float to an IEEE double in order to use old VAX centric data sets know what I'm talking about here... bleh.
This article is badly focused. Their porting problems are not with the Linux platform. Their problems are related to lousy application architecture. (Or they would seem to be. Since I have not seen what they did I really can't say.)
Yes, distributing software is HARD, but it's something that can be modeled ahead of time with suprising fidelity. That's the difference between engineering and hacking... we do the up front analysis, and should have a pretty damn good idea that it will actually work when we build it. It sounds like this system might have been hacked.
This seems to be a common issue and I don't understand why CIO types can't outgrow it. If you build the software correctly the platform becomes more or less irrelevant (E.g, Linux, BSD, SCO, LynxOS, whatever.) Why is this so difficult to understand? I've personally DONE this for several large systems (albeit not as large as GDS) and the guys in charge of the port are always locked into moving to a specific hardware/software platform. Maybe it just comes from an olde skool mainframe oriented mindset.
Unless, of course, this was truly a port and not a new architecture. I which case I have nothing but respect for these guys. It's always a miracle when those work at all...
When I visited DIII-D a while back there seemed to be very very few windows machines in the control room. The majority of their computing base looked to be unix based (various flavors). I'm guessing that they built their control system on linux because it worked and it was cheap.
Having said that, I have noticed that a lot of the data analysis community in general (i.e. people that toss around multi-gb files for number crunching and analysis) tend to like UNIX a lot more than windows. I know I sure prefer the tools available to me on Linux versus what's on windows. You can get some pretty good analysis tools for windows as well these days (PVWave) but they are expensive.
One thing that may be of interest to the slashdot community: ITER will likely be using Linux heavily. The plasma control system for ITER (the system the controls the plasma shape in real-time) was developed at General Atomic's DIII-D reactor in San Deigo. It runs Linux. The DIII-D contribution (main one anyway) to the ITER project will be the plasma control system.
So RT Linux will end up in another interesting role.
This reminds me of my experience in new car buying when I graduated. I was in roughly the same price range as you were. I look very young for my real age, so at 21 you can imagine the response I got. I guess the beat up old chevy corsica and faded jeans probably didn't help either.
So after a week of wasting evenings with this bravo sierra, I ended up at a Mercedes-Benz dealership. They were the only people that didn't treat me like shit the entire week. Blew my mind. Here I was, on the higher end of the vehicle lineup everywhere else, and got blown off. The MB people treated me well and I was buying their cheapest vehicle!
It's funny how these things work out. I actually ended up saving money over a high end jeep or tahoe, and got a much more capable 4x4 in the bargin (even if it does vaguely resemble a minivan!)
So, after a couple of years out of school when I suddenly have larger amounts of money to spend on a car where do you think I'll start looking? Jeep again? Probably not.
A while back you could go to comdex and find little, low glitz, booths with neat stuff. As the PC and consumer computing market took off, COMDEX started to cater to the new audience. If attendance is slacking off, maybe things have finally come full circle and you will see more research type stuff in the future.
Not that I believe this of course, but it is a nice thought.
My parents live on a Mac65. They have had several laptops, cell phones, GPS units, autopilots (and AutoHelms are NOT cheap!!) cooked by lightning hits.
It doesn't even have to be plugged in, the emp or induced current will get you. Just hard to deal with that big tall lightning rod called the mast.
They have finally ended up only using cheap laptops and keeping extra hand held nav gear in a small metal box. Seems to work so far.
Where I work we all have those old WWII era writing desks. They suck for computer work. (Duh?) The company recently dumped a bunch of money into ergochairs for the whole workforce.
When I received my new chair I no more back/neck aches but my wrists were totally wasted. I eventually figured out that the armrests on the chair were causing me to rest forward body weight on my wrists. This was due to the armrests not allowing the chair into the proper position relative to the desk. I think. 2 minute hack job later and the chair has no arms. Immediate posture and pain improvement.
Several years later (still the same lame desks... I should call osha or my lawyer or something...) my wrists are fine. So the moral of the story is : figure out what is causing YOUR problems. Don't just trust some shit hot human factors specialist if what they are suggesting doesn't feel correct.
Of course I did start climbing exercises during that time period as well. Added some heavy duty grip strength which I believe helped a lot. Those 1 lb. grip balls REI sells are good. Also look at Metolius rock rings
A company I used to work for dealt with financial equipment. Heavy iron like Unisys A's, V's, the infamous NIE sorters, and the star of our story : the S4000 proof machine.
This particular S4 had a big 10 pocket (IIRC) module and a microfilmer on it. That makes it around 12+ feet long, waist high, and about 3 feet deep. These things are true big iron, as they have a heavy steel frame, huge power supplies, etc. I think they weigh in at around a ton or so. Enough weight that the warehouse schmucks can't just toss em around like sparc stations (ahhh another story for another time...) Anyway, these things are crated up for shipping by truck. They usually ship really well. Again I suspect this is do the size/weight garnering some respect.
So, this machine shows up at our door with a little hole in the end of the crate. About a 6 in long crack. The shipping/receiving guy notes it on the BOL, and signs for it. Later that day we find out that the hole was from a fork lift fork. The operator has shoved the fork all the way through the machine END WISE! Through around 6 heavy gauge steel panels, structular tubing, big cap banks, all the assorted mechanics in the unit, etc. Hard to imagine this being an accident, ya know?
Machine was scrapped out. I think it took around 8 months to get any money out of the shipper.
In any case, an emulator is a godsend when you are writing OS code, because otherwise you have to reboot your machine and wait for it to POST each time you change you code rather than just simply firing off a much quicker and easier run of the emulator. Also, the emulators often print out useful messages when there is an unusual processor condition or a processor exception, which can be very helpful in tracking down the cause of lockups. Plex86 was particularly good in this regard at the time that I was using it.
You missed the other biggy for developing system level code under an emulator... almost unlimited "realtime" traceback! Although I haven't done this with bochs/plex86 I've developed embedded systems under other emulators. As long as you have good models for the hardware your software needs to deal with development is wonderful. If you need to setup a super complex trigger to try and catch a bug, you can just hack 20 pages of logic into the emulation and do it. This is the kind of thing that you can't even do with an ICE since under the emulator even the peripherals are all software.
IIRC, The Python 4 has been deployed and capable of doing this for some time. The Israelis have had helmet mounted sighting for a long time. High Off-Boresight capable missiles are nothing new.
The AIM9X is late, and it is not state of the art. A true tribute to the royally fscked up air force procurement process. I seem to recall that lockmart and elbit both set some speed records during the python 4 integration on the F-16. It was supposed to have been (rumored anyway) a real model fast track development effort.
Also, one of the reason the Israelis have done so well in joint exercises is that they CAN take HOBS shots. The US deployment of such a system would just level the playing field a bit rather than give American pilots an advantage.
I looked at getting one of those last year (the Honda anyway). Be aware the cargo (weight) capacity sucks out loud. IIRC, if you are carrying two adults you barely have any weight left for things like luggage.
I'll grant you that it would still be a sweet commuter vehicle, but I would want to own another "real" car as well.
I could be wrong, but the last time I researched fuel cells, I got the impression that a properly designed cell could ingest propane, methane, etc. directly. No extra stuff required. It would produce some more nasty byproducts than a straight up hydrogen/oxygen cell. However, I think there was a bonus that you usually didn't have to humidify the input gas when you used something like methane.
(IIRC humidification was one of those things that became pretty important when you started getting out of the pure research grade fuel cell sizes and into something that could be useful. I.e. something that runs hot.)
Been a while since I looked at that stuff. Could be way wrong.
With your average application from scratch rewites are probably UnCool for the reasons mentioned in the article.
For other kinds of systems I'm going to have to argue that rewites can be very beneficial.
For systems where the development team has access to a regression test suite and the old (working) code at the same time rewrites are much more easily done. You simply treat the existing code like a prototype. Something that captures all of your requirements, but maybe not using a design that ended up working out (read as: turned into a freaking hairball as time passed!) You work through the old code, understand it, and then build up a new design that works out cleanly in all of the places where the old code was a hack.
When you are all done (or as you are working), you hit it with the test suite. This works out best if your process requires that all of those pesky little bugs found in the old code had to have test cases to reproduce them. (Obvisouly there are limits to this... the infamous 1 in a million "random" crash, etc.)
Anyway, I think Joel's statement was just a little to broad. He's correct in some cases, but not all. Of course maybe I'm just one of those overly confident coder types...
The question I can't find an answer to in their doc (and I don't have time to install the tools yet) is : Can you do a parallel (multiprocess) build like gnu make?
People I have talked to from south africa painted a picture of the entire region that, quite frankly, scared the hell out of me.
What they talked about, and they did talk about more than just their contry, was pretty bad. Of course from what you are saying it may be that the rest of the country is more sane...
I guess I chalk up my thoughts to very limited (and probably quite biased) input.
It's interesting to hear from someone with an experience 180 degrees out of phase.
And yes I KNOW that there is no electric grid. There are already places where solar powered data terminals with radio and/or satellite uplinks are just BFE out in the middle of nothing...
And I'm in no way trying to imply that health care and educational infrastructure isn't important, just that good information connectivity could possibly help these move from non-existant to much better faster.
Of course, you are correct about the government. THAT is something that really can't be developed in parallel with IT structure until after a certain point.
People seem to be suggesting that you build up to the current modern tech level gradually. Like you, I think it may be worth trying to use the tech level of the US, Europe, etc. to try and pull the third world up faster. This could make for some really interesting research.
I think a lot of it would be installing infrastructure that is REALLY REALLY robust. Not necessarily state of the art.
Could be an interesting type of project. If there wasn't such a danger of getting killed just because I'm white and american, I would love to be involved for a while. Sigh.
We have to take chances. To be honest, we are hugely in debt (ethically) to the third world. Our lavish lifestyles are to an uncomfortably large extent built on the suffering of people in the poorest countries on earth
How so? I mean this not as flamebait, but quite seriously.
Total Impact also seems to have these daughter cards that drop into an intel PCI system. With up to 4 powerpc CPUs on a card, and multiple cards per system!!
You could keep your intel workstation, and still run powerpc applications... Might be an interesting environment to adapt something like MOSIX to. (Load balance between multiple cards in the same system, etc.)
In any case, this could allow for a LOT of CPU power in one box. Neat product.
Slashdot Mirror
The last place I worked that still used SCO also used it mainly for microfocus COBOL. That SCO install was also prone to periodic kernel panics.
The solution we finally arrived on (after spending much time chasing an assumed hardware issue) was to kick off a cron job to reboot the damn thing every night. After that it was quite solid. Of course this is not an option for everyone and YMMV.
Step down? Bleh! Look carefully your equipment before bothering. I was suprised to find that the majority of my electronics are rated from 120 all the way to 240. (Canon stuff, fuji stuff, toshiba stuff, ipaq charger, etc.) You just need an adapter for the receptacle style. This has served me well for several asian countries, you just need to be careful when you buy your gear.
Now for the freaks on different freqs, you may need to start worrying about serious adapters. Then again a lot of gear is OK with 50 and 60Hz. Read all that little fine print on the power supplies.
(Besides, you should be using a solar charger for you GPS and laptop while in the field. Takes all the worry out of it.)
This sounds like a cool project. There is a ton of existing free GIS software to support it. If you do end up on windows, avoid Delorme. Their GPS gear is alright (nothing wonderful), but their software is pretty awful.
You're right, upgrading just to upgrade isn't such a hot idea. However, upgrading because DEC/Compaq/HP dropped VAX support a couple of years back is a different thing entirely. Several places I've worked kept on going in an unsupported config and patching it together until they were forced to upgrade under extreme pressure, and none of those ever turned out well.
... although actually if you count all of the engineering time being blown when the system is down it does get ugly really fast. I'd never really thought about it in terms of money per time.)
Yeah, you can make the jump from VAX to Alpha to stay on VMS, but I guess where I work we see VMS on Alpha as a ship that's already going down. If we are going to have to migrate, moving to a dying platform just didn't seem like the way to go. Also I think that someone high up in our organization has a lot of microsoft stock, but that's just my cynical side speaking.
(And downtime doesn't quite cost us a grand a minute! Ouch
We were seeing situations where a rogue system would cause the entire cluster to reboot! VAXes, micros, alphas, VAXstations, everything! It was kind of hard to defend against. And the support guys from compaq said everything was setup correctly. It WAS rooted in bad hardware on one of the stations, but still ...
The projects I've worked for the last 8 years or so have used VAX and Alpha VMS and I can say that the much-vaunted uptime for VMS tends to be exaggerated. Yes VMS is generally solid, that I won't argue. However, it is very vulnerable to HW failure, just like anything else, and maybe more so than anything else we have around. We have had many many instances of a rogue VAXStation or microVAX taking out an entire cluster, redundancy and all. I see that as unacceptable.
... bleh.
You might say it must have been a admin/config problem. Weeeellll maybe (those guys seem to really know their sh-t cold, but one never knows) but then if it's that easy to misconfigure, how reliable is it really? And have you ever tried FINDING people that can maintain this stuff?
Lately we've been migrating off to the wintel world (and to some SGI as well) and the uptime numbers really have not changed that much. Some windows services tend to go down more often than their VMS equivalent, but things are mostly the same. The only reason we have to keep VAXen around is legacy applications that would be very very hard to port off of VMS. Anyone who has ever had to convert a G-Float to an IEEE double in order to use old VAX centric data sets know what I'm talking about here
This article is badly focused. Their porting problems are not with the Linux platform. Their problems are related to lousy application architecture. (Or they would seem to be. Since I have not seen what they did I really can't say.)
... we do the up front analysis, and should have a pretty damn good idea that it will actually work when we build it. It sounds like this system might have been hacked.
...
Yes, distributing software is HARD, but it's something that can be modeled ahead of time with suprising fidelity. That's the difference between engineering and hacking
This seems to be a common issue and I don't understand why CIO types can't outgrow it. If you build the software correctly the platform becomes more or less irrelevant (E.g, Linux, BSD, SCO, LynxOS, whatever.) Why is this so difficult to understand? I've personally DONE this for several large systems (albeit not as large as GDS) and the guys in charge of the port are always locked into moving to a specific hardware/software platform. Maybe it just comes from an olde skool mainframe oriented mindset.
Unless, of course, this was truly a port and not a new architecture. I which case I have nothing but respect for these guys. It's always a miracle when those work at all
When I visited DIII-D a while back there seemed to be very very few windows machines in the control room. The majority of their computing base looked to be unix based (various flavors). I'm guessing that they built their control system on linux because it worked and it was cheap.
Having said that, I have noticed that a lot of the data analysis community in general (i.e. people that toss around multi-gb files for number crunching and analysis) tend to like UNIX a lot more than windows. I know I sure prefer the tools available to me on Linux versus what's on windows. You can get some pretty good analysis tools for windows as well these days (PVWave) but they are expensive.
One thing that may be of interest to the slashdot community: ITER will likely be using Linux heavily. The plasma control system for ITER (the system the controls the plasma shape in real-time) was developed at General Atomic's DIII-D reactor in San Deigo. It runs Linux. The DIII-D contribution (main one anyway) to the ITER project will be the plasma control system.
So RT Linux will end up in another interesting role.
This reminds me of my experience in new car buying when I graduated. I was in roughly the same price range as you were. I look very young for my real age, so at 21 you can imagine the response I got. I guess the beat up old chevy corsica and faded jeans probably didn't help either.
So after a week of wasting evenings with this bravo sierra, I ended up at a Mercedes-Benz dealership. They were the only people that didn't treat me like shit the entire week. Blew my mind. Here I was, on the higher end of the vehicle lineup everywhere else, and got blown off. The MB people treated me well and I was buying their cheapest vehicle!
It's funny how these things work out. I actually ended up saving money over a high end jeep or tahoe, and got a much more capable 4x4 in the bargin (even if it does vaguely resemble a minivan!)
So, after a couple of years out of school when I suddenly have larger amounts of money to spend on a car where do you think I'll start looking? Jeep again? Probably not.
A while back you could go to comdex and find little, low glitz, booths with neat stuff. As the PC and consumer computing market took off, COMDEX started to cater to the new audience. If attendance is slacking off, maybe things have finally come full circle and you will see more research type stuff in the future.
Not that I believe this of course, but it is a nice thought.
My parents live on a Mac65. They have had several laptops, cell phones, GPS units, autopilots (and AutoHelms are NOT cheap!!) cooked by lightning hits.
It doesn't even have to be plugged in, the emp or induced current will get you. Just hard to deal with that big tall lightning rod called the mast.
They have finally ended up only using cheap laptops and keeping extra hand held nav gear in a small metal box. Seems to work so far.
When I received my new chair I no more back/neck aches but my wrists were totally wasted. I eventually figured out that the armrests on the chair were causing me to rest forward body weight on my wrists. This was due to the armrests not allowing the chair into the proper position relative to the desk. I think. 2 minute hack job later and the chair has no arms. Immediate posture and pain improvement.
Several years later (still the same lame desks ... I should call osha or my lawyer or something ...) my wrists are fine. So the moral of the story is : figure out what is causing YOUR problems. Don't just trust some shit hot human factors specialist if what they are suggesting doesn't feel correct.
Of course I did start climbing exercises during that time period as well. Added some heavy duty grip strength which I believe helped a lot. Those 1 lb. grip balls REI sells are good. Also look at Metolius rock rings
A company I used to work for dealt with financial equipment. Heavy iron like Unisys A's, V's, the infamous NIE sorters, and the star of our story : the S4000 proof machine.
This particular S4 had a big 10 pocket (IIRC) module and a microfilmer on it. That makes it around 12+ feet long, waist high, and about 3 feet deep. These things are true big iron, as they have a heavy steel frame, huge power supplies, etc. I think they weigh in at around a ton or so. Enough weight that the warehouse schmucks can't just toss em around like sparc stations (ahhh another story for another time ...) Anyway, these things are crated up for shipping by truck. They usually ship really well. Again I suspect this is do the size/weight garnering some respect.
So, this machine shows up at our door with a little hole in the end of the crate. About a 6 in long crack. The shipping/receiving guy notes it on the BOL, and signs for it. Later that day we find out that the hole was from a fork lift fork. The operator has shoved the fork all the way through the machine END WISE! Through around 6 heavy gauge steel panels, structular tubing, big cap banks, all the assorted mechanics in the unit, etc. Hard to imagine this being an accident, ya know?
Machine was scrapped out. I think it took around 8 months to get any money out of the shipper.
You missed the other biggy for developing system level code under an emulator ... almost unlimited "realtime" traceback! Although I haven't done this with bochs/plex86 I've developed embedded systems under other emulators. As long as you have good models for the hardware your software needs to deal with development is wonderful. If you need to setup a super complex trigger to try and catch a bug, you can just hack 20 pages of logic into the emulation and do it. This is the kind of thing that you can't even do with an ICE since under the emulator even the peripherals are all software.
The AIM9X is late, and it is not state of the art. A true tribute to the royally fscked up air force procurement process. I seem to recall that lockmart and elbit both set some speed records during the python 4 integration on the F-16. It was supposed to have been (rumored anyway) a real model fast track development effort.
Also, one of the reason the Israelis have done so well in joint exercises is that they CAN take HOBS shots. The US deployment of such a system would just level the playing field a bit rather than give American pilots an advantage.
I looked at getting one of those last year (the Honda anyway). Be aware the cargo (weight) capacity sucks out loud. IIRC, if you are carrying two adults you barely have any weight left for things like luggage.
I'll grant you that it would still be a sweet commuter vehicle, but I would want to own another "real" car as well.
I could be wrong, but the last time I researched fuel cells, I got the impression that a properly designed cell could ingest propane, methane, etc. directly. No extra stuff required. It would produce some more nasty byproducts than a straight up hydrogen/oxygen cell. However, I think there was a bonus that you usually didn't have to humidify the input gas when you used something like methane.
(IIRC humidification was one of those things that became pretty important when you started getting out of the pure research grade fuel cell sizes and into something that could be useful. I.e. something that runs hot.)
Been a while since I looked at that stuff. Could be way wrong.
With your average application from scratch rewites are probably UnCool for the reasons mentioned in the article.
... the infamous 1 in a million "random" crash, etc.)
...
For other kinds of systems I'm going to have to argue that rewites can be very beneficial.
For systems where the development team has access to a regression test suite and the old (working) code at the same time rewrites are much more easily done. You simply treat the existing code like a prototype. Something that captures all of your requirements, but maybe not using a design that ended up working out (read as: turned into a freaking hairball as time passed!) You work through the old code, understand it, and then build up a new design that works out cleanly in all of the places where the old code was a hack.
When you are all done (or as you are working), you hit it with the test suite. This works out best if your process requires that all of those pesky little bugs found in the old code had to have test cases to reproduce them. (Obvisouly there are limits to this
Anyway, I think Joel's statement was just a little to broad. He's correct in some cases, but not all. Of course maybe I'm just one of those overly confident coder types
The question I can't find an answer to in their doc (and I don't have time to install the tools yet) is : Can you do a parallel (multiprocess) build like gnu make?
Dare I ask how you ended up hitchhinking across the continent? Hopefully for fun? :-)
People I have talked to from south africa painted a picture of the entire region that, quite frankly, scared the hell out of me.
What they talked about, and they did talk about more than just their contry, was pretty bad. Of course from what you are saying it may be that the rest of the country is more sane ...
I guess I chalk up my thoughts to very limited (and probably quite biased) input.
It's interesting to hear from someone with an experience 180 degrees out of phase.
I was thinking of things like fiber ... :-)
...
And yes I KNOW that there is no electric grid. There are already places where solar powered data terminals with radio and/or satellite uplinks are just BFE out in the middle of nothing
And I'm in no way trying to imply that health care and educational infrastructure isn't important, just that good information connectivity could possibly help these move from non-existant to much better faster.
Of course, you are correct about the government. THAT is something that really can't be developed in parallel with IT structure until after a certain point.
People seem to be suggesting that you build up to the current modern tech level gradually. Like you, I think it may be worth trying to use the tech level of the US, Europe, etc. to try and pull the third world up faster. This could make for some really interesting research.
I think a lot of it would be installing infrastructure that is REALLY REALLY robust. Not necessarily state of the art.
Could be an interesting type of project. If there wasn't such a danger of getting killed just because I'm white and american, I would love to be involved for a while. Sigh.
How so? I mean this not as flamebait, but quite seriously.
Total Impact also seems to have these daughter cards that drop into an intel PCI system. With up to 4 powerpc CPUs on a card, and multiple cards per system!!
... Might be an interesting environment to adapt something like MOSIX to. (Load balance between multiple cards in the same system, etc.)
You could keep your intel workstation, and still run powerpc applications
In any case, this could allow for a LOT of CPU power in one box. Neat product.