C
Curt Wuollet
Hi Micheal
Michael Griffin wrote:
>
> Curt Wuollet wrote:
> <clip>
> >Only if you are ill prepared enough to go on site and try to install
> >on random hardware. He can't possibly do that often or he would know
> >that even with "built for windows" the occasional nightmare occurs.
>
> This was their mistake - with the mitigating circumstance of
> the limited time available, and their PC supplier was late (of
> course).
I know this because I had days like that. It's a very, very, bad day and what makes it really horrible is that there isn't much you can do after the fact. In fact with closed systems sometimes there isn't anything you can do, period. That's one of the exhilerating things about developing with OSS on Linux. I have never had that sort of disaster. I have energetically researched a few problems on the virge of panic, but it's always worked out all right. The worst I've had to do was trade modems with a customer for a winmodem I trashed at the next rest stop.
>
> >I wouldn't
> >try this without a plan B. Either a known MB I could swap in or a
> >bare bones spare. Anyone that you pay to do PC's should be prepared
> >for this and at least know the configuration is going to work ahead
> >of time.
> <clip>
>
> A known motherboard? How do you do that? If you use "standard"
> office PC style motherboards, you generally find that they go obsolete
> so fast you can't buy two in a row that are exactly the same.
> You must either have a source of motherboards that changes
> their design very little over time, or you must have an operating
> system that is very tolerant of different hardware. I find Windows
> NT's fussiness particularly surprising considering that the
> motherboard suppliers (and the chip designers) are designing their
> products with Windows in mind.
This is much easier with Linux, I keep an FIC VA503+ with a K6-2-500 and an FIC PA2013 around. This is great plenty for Linux. I suppose it'd choke on W2k or WinME. I have used these for about two years and they are still available. I'm researching the next generation. The trick was "super socket 7" a technology designed to extend the life of the MB to future processors and bus speeds. The prospects for next generation aren't quite as good. I've avoided slot a and 1 procs as they are stopgaps. Soyo and AMD Duron are the front runners so far. I research these things very carefully for the reasons you mention it's nice if you don't have two dozen variations out in the field. It's synergistic that the best Linux hardware is very generic and a year back from the leading edge. This happens to be the sweet spot for pricing also. The point is that you can have a sane PC operation if you work at it and manage the details. I enjoy peace and quiet far too much to do it the way most people do. And Linux is _very_ tolerant of hardware, it is written by folks that have every type of system from poor students with a 486 to poor engineers like me with a K6-2-400 to IBM and Compaq who runs it on machines that cost millions. Nothing else has so many qualified testers working on it. Windows, by necessity, lives on fairly new machines. I use very few "gee whiz" features on my test systems and that helps too.
>
> >The blame rests squarely on the integrator. Unfortunately, 99% of the
> >project was beyond his control. That's one of the major reasons I use
> >Linux and OSS. I can handle almost anything that can happen and
> >whatever your code does, it can't run any better than the platform
> >it's on.
>
> Yes in one sense, the blame lies with the integrator. However,
> I see the problems they routinely face, and they are not what I
> consider to be "value added" activities. These guys are supposed to be
> solving *testing* problems, not Windows problems. It isn't just one
> company, or just integrators. I see OEMs having the same difficulties.
> For example, they want to fix a bug, but they upgraded their
> compiler since the last time they worked on it. Now it's no longer
> compatable with the database, so that has to be upgraded. That in turn
> affects something else, which also needs an upgrade. Now we need a
> memory or hard drive upgrade because of all the software upgrades.
> One minor software incompatability leads to a chain reaction
> of cascading upgrades through the whole system. They plan on one
> "minor" change and find themselves being pulled in by an undertow
> whose existence they never suspected. How do you plan anything in an
> enviroment like that?
You realize that that is an insane environment to develop on and support and just say NO. Then you get a $2.98 Linux CD with all the tools and libraries you will ever need and try to forget the bad old days. It works for me :^) If you're a programmer why would you put up with that?
It's strange, all those intelligent people and so very few see the obvious. You don't _have_ to play the Windows game anymore. You have a choice. It's hard for a while, but you'll be grinning soon.
Regards
cww
Michael Griffin wrote:
>
> Curt Wuollet wrote:
> <clip>
> >Only if you are ill prepared enough to go on site and try to install
> >on random hardware. He can't possibly do that often or he would know
> >that even with "built for windows" the occasional nightmare occurs.
>
> This was their mistake - with the mitigating circumstance of
> the limited time available, and their PC supplier was late (of
> course).
I know this because I had days like that. It's a very, very, bad day and what makes it really horrible is that there isn't much you can do after the fact. In fact with closed systems sometimes there isn't anything you can do, period. That's one of the exhilerating things about developing with OSS on Linux. I have never had that sort of disaster. I have energetically researched a few problems on the virge of panic, but it's always worked out all right. The worst I've had to do was trade modems with a customer for a winmodem I trashed at the next rest stop.
>
> >I wouldn't
> >try this without a plan B. Either a known MB I could swap in or a
> >bare bones spare. Anyone that you pay to do PC's should be prepared
> >for this and at least know the configuration is going to work ahead
> >of time.
> <clip>
>
> A known motherboard? How do you do that? If you use "standard"
> office PC style motherboards, you generally find that they go obsolete
> so fast you can't buy two in a row that are exactly the same.
> You must either have a source of motherboards that changes
> their design very little over time, or you must have an operating
> system that is very tolerant of different hardware. I find Windows
> NT's fussiness particularly surprising considering that the
> motherboard suppliers (and the chip designers) are designing their
> products with Windows in mind.
This is much easier with Linux, I keep an FIC VA503+ with a K6-2-500 and an FIC PA2013 around. This is great plenty for Linux. I suppose it'd choke on W2k or WinME. I have used these for about two years and they are still available. I'm researching the next generation. The trick was "super socket 7" a technology designed to extend the life of the MB to future processors and bus speeds. The prospects for next generation aren't quite as good. I've avoided slot a and 1 procs as they are stopgaps. Soyo and AMD Duron are the front runners so far. I research these things very carefully for the reasons you mention it's nice if you don't have two dozen variations out in the field. It's synergistic that the best Linux hardware is very generic and a year back from the leading edge. This happens to be the sweet spot for pricing also. The point is that you can have a sane PC operation if you work at it and manage the details. I enjoy peace and quiet far too much to do it the way most people do. And Linux is _very_ tolerant of hardware, it is written by folks that have every type of system from poor students with a 486 to poor engineers like me with a K6-2-400 to IBM and Compaq who runs it on machines that cost millions. Nothing else has so many qualified testers working on it. Windows, by necessity, lives on fairly new machines. I use very few "gee whiz" features on my test systems and that helps too.
>
> >The blame rests squarely on the integrator. Unfortunately, 99% of the
> >project was beyond his control. That's one of the major reasons I use
> >Linux and OSS. I can handle almost anything that can happen and
> >whatever your code does, it can't run any better than the platform
> >it's on.
>
> Yes in one sense, the blame lies with the integrator. However,
> I see the problems they routinely face, and they are not what I
> consider to be "value added" activities. These guys are supposed to be
> solving *testing* problems, not Windows problems. It isn't just one
> company, or just integrators. I see OEMs having the same difficulties.
> For example, they want to fix a bug, but they upgraded their
> compiler since the last time they worked on it. Now it's no longer
> compatable with the database, so that has to be upgraded. That in turn
> affects something else, which also needs an upgrade. Now we need a
> memory or hard drive upgrade because of all the software upgrades.
> One minor software incompatability leads to a chain reaction
> of cascading upgrades through the whole system. They plan on one
> "minor" change and find themselves being pulled in by an undertow
> whose existence they never suspected. How do you plan anything in an
> enviroment like that?
You realize that that is an insane environment to develop on and support and just say NO. Then you get a $2.98 Linux CD with all the tools and libraries you will ever need and try to forget the bad old days. It works for me :^) If you're a programmer why would you put up with that?
It's strange, all those intelligent people and so very few see the obvious. You don't _have_ to play the Windows game anymore. You have a choice. It's hard for a while, but you'll be grinning soon.
Regards
cww