Replies

It sounds as if the drive is in the process of dying. If you cloned it and saved the data anyway, at most I would try a full reformat of the drive in question. The format process may report bad sectors, which would itself give you a solid clue as to what is happening.

If you do a full low-level format and it works, then a high level format and that works, you may simply have had a bad write in a critical area at some point–which might point to intermittent problems elsewhere in the system. I have seen old power supplies cause such things in the past, for example, as could an intermittent short in the mother board circuitry somewhere.

If both low-level and high-level formats have gone smoothly and nothing has shown up as being a problem at that point, you can try reloading the OS and drivers, then the data and being back where you were before the hassles…but with a clean disk.

Note: don’t “clone” the disk again, as any faulty data will be faulty once more. Copy the relevant data files instead.

All of this said, disks are cheap enough today that I would seriously consider replacing it and start from the ground up with a new disk.

David

Thanks to all who replied to my thread. I suspect that Clint’s suggestion (above) would have worked just as well had I seen it before using the solution mentioned here.
Clint, with regard to your comments about it not being necessary to use “Safely Remove Hardware” with USB drives, I have seen conflicting opinions on this.

If a drive is still being accessed–say, by data that has been cached somewhere–and you power it down, the data will be corrupt.

Thus, to unplug without going through the “safely remove” step, be sure the drive light has been off for some seconds first. Then, simply unplugging it is not harmful to drive or data.

I frequently use USB drives, both rotating disks and solid state, and haven’t had a problem with one in several years–but I learned the hard way originally to be sure any disk writes were concluded before pulling the disk! Experience is often the best teacher, after all…

David

In many cases, the network manager called wicd can make life much easier for Linux wireless connectivity. If you have a system on which you have loaded Linux, and can’t seem to get the wireless working–if you have a router, try plugging in an Ethernet cable between it and the Linux machine. That should be a simple connection to get on the Internet. Then, look at your package manager for wicd, download and install it. I have found it far more forgiving of otherwise difficult wireless cards.

Of course, if your distro of choice doesn’t offer it–or if the version is quite old, as some are–you can also go to the wicd home page at

Reading through the thread, I was amused at some of the posts. For example, the gentleman who “tried” Linux but found it “no fun” because he couldn’t download and install programs–but didnt’ try the package manager in his distribution. That is much like saying “I tried that car, but it was no fun. Of course, I didn’t take it out of first gear!”

Also, the many people who don’t find Linux or MacOS “intuitive”. To a large extent, what is “intuitive” is what you are accustomed to. For them, it’s probably wise to try a version of Linux which uses KDE as its desktop. Out of the box, that is the closest to the familiar Windows approach–although like nearly everything Linux, it is highly configurable.

As for me, my DVD drive on my old laptop died several months ago–followed a month or so ago by the hard disk. Thus, when I slipped in the drive I had used as a backup in an external case, I could not reinstall the XP setup from the OEM DVD I have. Thus, it’s been all Linux since then–no biggie, as 90% of my work previously was in Linux anyway. The machine is to be replaced this Summer when I visit the States again–machines here in Ukraine are quite expensive, as it happens, and I am on a very limited income these days so every little bit helps.

If the replacement machine has Windows 7 pre-installed, I’ll likely keep it and install Linux as a dual boot–simply to be able to answer questions from acquaintances and family. However, a very real possibility is that I’ll replace the original drive with a solid state disk, where space will be precious enough that I won’t bother installing Windows on it–but I’ll hold on to the original disk in case I ever want to run it again. My plan is to get another laptop–and which distribution to use is a rather fun question. Presently, I’m using an Ubuntu variant. Next month, I’ll probably go to Kubuntu after the new version is out…but I am also quite fond of several others.

Finally, several people have said that Linux seems “slower” than Windows on the Internet. That, friends, is quite a laugh. The network stack in Linux is very efficient–and Linux doesn’t send countless “keep alive” messages over the network as Windows does. In fact, on a network of Windows machines, the amount of useless traffic is incredible. On this machine, for example, when I was running XP in dual boot, my usual complement of open Firefox windows–using the exact same plugins as I run in Linux–would consume so much memory, as would the various anti-malware apps, that I often had to close things just to get it to respond at all. Many new websites would not load at all, while others loaded very slowly. (I suppose I should mention this is a dual core machine of 1.66 GHz and with 1.5 GB of RAM). After dual booting into Linux, opening the same browser windows, I could easily listen to Internet streaming radio and have a number of applications open all at once without strain.

The simple fact that Linux can perform well on old machines with few resources that Windows chokes on should give a few people a clue that it is far more efficient.

If I wanted to run even faster, of course I have the choice of using a much lighter-weight windowing environment. The Elive distribution, for example, is one such–but is far from deficient in an “eye candy” sense.

David

I worked for some years as a technical and corporate writer. I can tell you from having to revise and edit too many documents created by people who didn’t understand or properly use styles that this is something well worth learning about and using properly.

Unfortunately, Word makes it entirely too easy to unknowingly create far too many style variations, at least in the standard installation.

If you have a good set of styles created, try to avoid manually setting things like font or spacing issues–use styles instead. That way, you make future revisions a snap and the document will load and print with far less hassle.

One tutorial that appears reasonably good is at http://www.addbalance.com/usersguide/styles.htm

David

You would be far better off with one or more of these resources:

http://www.klariti.com/framemaker/index.shtml

http://forums.adobe.com/community/framemaker

Finally, there is a Framers’ List–an email list of FrameMaker users, where you can ask specific questions and knowledgeable folks should be around to answer your question quickly:

http://lists.frameusers.com/mailman/listinfo/framers

I’m a former tech writer, but as my history with Frame recedes farther into the past I would only be guessing to try to help, I’m afraid, as I no longer have a copy of it installed–and the last version I used was 6 IIRC.

Good luck getting your question sorted out!

It would be difficult to say offhand whether your diskless clients are compatible with one version or another of Linux. For that purpose, either the manufacturer’s site may say or, as usual, “Google is your friend.” However, quite a few people are using Linux on them so it should be doable; I just don’t know how simple it has been for them.

PuTTY is avaialable for Linux, so that should not be an issue–although telnet is a basic function in Linux and fairly easy to implement if you choose.

I have no earthly idea about your “Windows macro program” running via WINE, but it really should not be necessary. There are various macro solutions in Linux that should work fine–just google “Linux macro” and you will find plenty of info.

Regarding distributions–I would not necessarily use the heavyweight ones in a 512 MB environment. It can be done, but the lighter-weight graphical environments would be much faster. Running it from a memory card shouldn’t be a big deal, so long as you have a machine to install it from. Since your terminals won’t run XP without the card installed, unless you have a second card slot on one of them it would seem a difficulty. However, a card reader you can use on a PC should do the trick nicely.

I presume that one of the available utilities also used to install to a USB drive may well work for the purpose, such as unetbootin (on Sourceforge: http://unetbootin.sourceforge.net ). In fact, if your Maxterms have a choice to boot from USB, you can install the OS that way–and even run a live version from the USB while you work out the various issues that may come up before putting it onto the memory card–so you preserve your current embedded XP setup at least until you are confident that everything has been foreseen.

Various people have their own opinions about the LInux lightweight distributions, ranging from Puppy to DSL. If it runs on your hardware, a surprisingly good one is called Elive, which is built on the Englightenment window manager. That one is famous for taking few resources but still having considerable “eye candy” yet being extremely high performance. You didn’t specify a model of Maxterm, but I noticed a few moments ago an article in the Google search results that spoke of Puppy Linux recognizing the hardware including sound for the Maxterm 3300–apparently an older model, which bodes well for the newer ones.

A couple other possibilities might include Crunchbang Linux, now based on Debian, which uses the Openbox/XFCE environment, or perhaps Lubuntu–an unofficial Ubuntu variant which employs the very lightweight LXDE environment.

My goal for your setup would be for a distribution which is very lightweight for optimum performance in your environment.

If your office uses a terminal server, that is another issue to contend with to be sure the resulting setup is compatible with it.

I hope these few comments may prove helpful.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Actually, the GUI ran atop DOS for the entire Win9x series.

For consumers, few of whom ran any of the NT series, which continued through Win 2K, which was NT5 renamed, they did not experience a true Windows OS until the release of XP.

Sorry, but that’s just silly. What constituted “Windows” certainly changed greatly–but it is Microsoft, and not you, who determined what “Windows” was and is. They named Windows 1.0 “Windows” after all, and defined it when they did. Later, that definition obviously changed.

The NT basic architecture was done by a gentleman who had previously been in charge of Digital Equipment Corporation’s operating system development (Dave Cutler)–and many programmers at the time it was under development referred to it as “Portable VMS”–because various features were simply re-implementations of the VMS design.

Thus, it could with some justification be said that the later versions were a “true VMS experience” in some ways.

It is true that the Windows 9X series used many parts of DOS in its underpinnings, but as I said the kernel was no longer replaceable for the reasons I stated. In fact, in that same Win 9X series, a surprising number of processes were reduced to 16 bit operations through a process known as “thunking”. I remember a Microsoft representative giving sales reps a talk about the Win 95 OS and claiming it was a “32 bit operating system”…she was somewhat embarrassed when I asked her about “thunking” and the various limitations that 16 bit processes imposed upon it.

The fact remains that having the GUI connected so deeply into the operating system kernel is what causes the need for the frequent reboots more than any other single thing. Otherwise, many software updates would not interrupt the running system. All the details about file system operation and such are significant precisely because Windows has so much cruft being accessed at any given time. That, in turn, has serious consequences in updates not playing nicely together, as too much else must be considered at any given time through a nearly infinite combination of drivers, other running programs, etc.

Finally, the number of processes most systems have running at startup are yet another complication that hogs memory, often for no more than to have a particular application start a few seconds faster. For many reasons, it is often best to get rid of as many of these elements in startup as possible–they slow down the reboot process and can suck a surprising amount of memory from smaller systems such as netbooks and computers with limited ram.

Originally, back in the earliest days of Windows, the entire GUI ran as a process on top of a DOS kernel. When people started to use DRDOS or IBM’s PCDOS instead of MSDOS underneath, to keep control of the entire software stack, Microsoft drove the GUI code down into the kernel space for Win 95. After that, the multiple reboots were required.

Still later, with the introduction of excessively obtuse and fragile Registry, even more was “baked in” and required this kind of shenanigans.

It is worth noting that UNIX and its variants such as Linux still separate all the GUI code from the operating system kernel, and only require rebooting when an update is to the kernel itself. Even if a misbehaving graphical app takes down the GUI, the kernel and associated services are still running, and only the GUI needs to be restarted–which is blessedly seldom with modern iterations of any of these systems.

When I am in Linux, therefore, and find some programs need updating, usually I simply go on working while the updates are downloaded and installed. Then too, the configuration files in Linux are text files, and can be edited with any text editor–none of this “registry” foolishness to contend with.

Windows has many good features, but architecturally it is a nightmare. How often have you had a “fix” that merely broke other things on the system? I know I have, too many times to count. Generally, that comes from far too much complexity mixed together, and makes patches very difficult.

It would be very good if Microsoft bit the bullet and ripped out much of the underlying plumbing and replaced it–as Apple did when they went to OSX. That would be painful, granted, but in the end it could result in a far better system for everyone.

Remember, for example, the “Min-Win” version they showed off in a user group meeting or two, that had far less code to run the basic system? That was extremely promising–but so far as I am aware it never saw the light of day in an actual product. Windows remains as bloated as ever.