A while ago we wanted to move out "host based" (accessed via telnet) database applications to a windowed environment (because that is what the customers wanted).
The key advantage of the telnet based solution was that there was only one copy of the executable on the host - even though it was being run from hundreds of desktops. This makes upgrades/admin a lot easier. So the problem was how to get this kind of model, but deliver the windowed environment.
We looked at X, but running an X server on the desktops (PCs with Windows) was too expensive per seat
We looked at HTML/http. No good for data base applications (field validation, field completion, lookups etc aren't easy with a page at time model, session management etc).
We looked at Java. Too slow, immature and not really that "thin".
Then we came across DSI. This stands for Development Solution for the Internet. It is built on XVT's GUI portability kit. You create your application as normal. At run time, instead of calling the local graphical API, the GUI calls are routed across the network, then displayed using a "browser". So you get a Windowed application with a native look running on the client desktop - but the real application is running on the server. You only need a single "browser" (a bit like a telnet application) on the PC.
It's taken quite a while to iron out performance issues etc, but we are now deploying some nice graphical applications which are as easy to manage as the old telnet style applications.
One of the strengths of UNIX is the availablity of various scripting languages/facilites which can be used to automate things - a System Administrator would probably not type in the RPM command on all 2000 machines, but would automate it.
Some keywords to help you: "perl", "cron", "bash", "at", "expect", "init".
Try searching for these either using the web or the "man" command.
Mmm.. Your missing something here when you say "..instead of having to track down 21 security fixes from different sources, which in some cases might require recompiling. That requires more work and a knowledgable systems administrator.
ZD were testing RedHat Linux. This is a distribution. This means that it is put together by (the evidence suggests) some knowledgable people. So you DO have one trusted source, and one set of files. This is why it is worth paying RedHat for their distriubtion - because it relieves your of the burden (but not the responsibility) for continually monitoring and updating your system.
It is far, far, far easier to maintain a few RH systems (especially remotely) than it is the same number of NT servers.
If you think that "good" system administration is:
Download a great big service pack
Don't bother to read any release notes or even to think why you might be applying the fixes
Install and reboot your server
Place a Big Fat Tick (Check?) mark by the "I've installed the Service Pack on this server" item on your job sheet
Repeat for another n servers
Then they might have a point.
If you think that good system administration involves: Understanding your system; Understanding the problem; Understanding the solution, then of course you don't want to blindly install hundreds of megabytes of new code...
It really is a question of mindset. Given a handful of servers it is far easier to do
ftp some site cd update directory mget *.rpm quit rpm -Uvh *.rpm
And then telnet to another server and repeat the same. Without rebooting your machine.
[That's if you really wanted to of course, and weren't that bothered in working out what the impact of each RPM is].
Slashdot Mirror
But this only works if you can actually spell "EPOC" ;-)
The key advantage of the telnet based solution was that there was only one copy of the executable on the host - even though it was being run from hundreds of desktops. This makes upgrades/admin a lot easier. So the problem was how to get this kind of model, but deliver the windowed environment.
We looked at X, but running an X server on the desktops (PCs with Windows) was too expensive per seat
We looked at HTML/http. No good for data base applications (field validation, field completion, lookups etc aren't easy with a page at time model, session management etc).
We looked at Java. Too slow, immature and not really that "thin".
Then we came across DSI. This stands for Development Solution for the Internet. It is built on XVT's GUI portability kit. You create your application as normal. At run time, instead of calling the local graphical API, the GUI calls are routed across the network, then displayed using a "browser". So you get a Windowed application with a native look running on the client desktop - but the real application is running on the server. You only need a single "browser" (a bit like a telnet application) on the PC.
It's taken quite a while to iron out performance issues etc, but we are now deploying some nice graphical applications which are as easy to manage as the old telnet style applications.
Some keywords to help you: "perl", "cron", "bash", "at", "expect", "init".
Try searching for these either using the web or the "man" command.
ZD were testing RedHat Linux. This is a distribution. This means that it is put together by (the evidence suggests) some knowledgable people. So you DO have one trusted source, and one set of files. This is why it is worth paying RedHat for their distriubtion - because it relieves your of the burden (but not the responsibility) for continually monitoring and updating your system.
It is far, far, far easier to maintain a few RH systems (especially remotely) than it is the same number of NT servers.
Then they might have a point.
If you think that good system administration involves: Understanding your system; Understanding the problem; Understanding the solution, then of course you don't want to blindly install hundreds of megabytes of new code...
It really is a question of mindset. Given a handful of servers it is far easier to do
ftp some site
cd update directory
mget *.rpm
quit
rpm -Uvh *.rpm
And then telnet to another server and repeat the same. Without rebooting your machine.
[That's if you really wanted to of course, and weren't that bothered in working out what the impact of each RPM is].