![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
altivoSupposed to be weaving or else editing a newsletter, but I'm avoiding those tasks. Doing laundry (and you know I'm avoiding other things when I get around to that!) Fixing home made potato salad and baked beans to go with our dinner. Digging through boxes of old pet supplies to find (eureka!) the doggy tooth brushes and tooth paste that I knew were there. (Red needs tooth brushing. He doesn't chew on his chew toys, and will develop tooth and gum problems in a few years unless we do this. Simon had serious gum problems last winter, and we had to use an antibiotic to clear it up, so now I'm feeling guilty of course.)
I've wasted a lot of time over the last couple of days on a computer problem of my own making. I knew the cause had to be something simple, but it was elusive.
DECnet was working well on my desktop at home and on the machine at work. Since part of the network involves communication between the host Linux and a virtual guest operating system (emulated VAXserver running OpenVMS) there is an issue with them hearing each other that requires some sort of virtual bridging. I've been using brctl and taptap to create a working bridge. This does work, but is sometimes a bit on the slow side. This is especially true here at home where the hardware is also slower, while at work I have faster machines and a faster LAN so it seems quite peppy. I thought perhaps a different approach to bridging would help, and I installed the UML (User Model Linux) utilities to try them out. DECnet communications were working fine on the old system, but I couldn't get them to run on the new one. I thought I just didn't understand the configuration, as the documentation is very thin. Went back to my previous setup, and it didn't work either. Rebooted. Still didn't work.
The next day I fired up the real hardware Alpha with its OpenVMS system. Oddly enough, both the Linux host and the guest VAX could communicate with the Alpha and vice versa, but they still couldn't see/hear each other. It was as if there were no bridge, though all the status reports showed that it was active and configured just as it had always been.
This morning I finally realized that the UML utilities run a switching process in the background. This daemon has been launched every time I booted the machine from the time UML was installed. I stopped the daemon. Lo, DECnet worked again. Apparently the UML switcher process was interfering with the tunnel created by taptap.c, and keeping it from operating in the host to guest direction, though it still worked in the guest to host direction. I disabled the thing entirely, rebooted, and all is well.
This is a perpetually peeving thing to me: so much code is written now by youngsters who have no depth of experience or vision. They've never seen a DECnet packet, or Novell IPX, or AppleTalk, or any of the other protocols that can operate over an Ethernet (simultaneously, even) and assume that everything is just IP. So it seems that the UML bridging tools do not support any protocols other than the IP subset. Because no experienced analyst was involved in the design, the potential of other systems using the bridge was completely ignored.
DECnet Phase IV has "logical addresses" all right, but doesn't use them the way IP uses the analogous IP address. Instead it alters the MAC address of the hardware interface to reflect the logical address. Connections are established by sending a request packet "blind" using the predicted MAC address of the other machine unless the logical address indicates a different "area" than the local net. Only then is a router sought to forward the data. It appears that UML somehow blocked that initial packet where it had to make the leap from the bridge to the tunnel device.
I realize we live in a world where more and more of the population has never seen, let alone used, a rotary dial telephone. Many kids in their 20s or younger can't tell time on an analog clock, and, as I've recently discovered, can't read or write cursive script. But does that mean we can design roads that can't be navigated by older vehicles? Or networks that can't be used by older software? Most of the time, I think the answer to that is "no." And if such roads or networks are created, then they should be labeled for what they are.
I've wasted a lot of time over the last couple of days on a computer problem of my own making. I knew the cause had to be something simple, but it was elusive.
DECnet was working well on my desktop at home and on the machine at work. Since part of the network involves communication between the host Linux and a virtual guest operating system (emulated VAXserver running OpenVMS) there is an issue with them hearing each other that requires some sort of virtual bridging. I've been using brctl and taptap to create a working bridge. This does work, but is sometimes a bit on the slow side. This is especially true here at home where the hardware is also slower, while at work I have faster machines and a faster LAN so it seems quite peppy. I thought perhaps a different approach to bridging would help, and I installed the UML (User Model Linux) utilities to try them out. DECnet communications were working fine on the old system, but I couldn't get them to run on the new one. I thought I just didn't understand the configuration, as the documentation is very thin. Went back to my previous setup, and it didn't work either. Rebooted. Still didn't work.
The next day I fired up the real hardware Alpha with its OpenVMS system. Oddly enough, both the Linux host and the guest VAX could communicate with the Alpha and vice versa, but they still couldn't see/hear each other. It was as if there were no bridge, though all the status reports showed that it was active and configured just as it had always been.
This morning I finally realized that the UML utilities run a switching process in the background. This daemon has been launched every time I booted the machine from the time UML was installed. I stopped the daemon. Lo, DECnet worked again. Apparently the UML switcher process was interfering with the tunnel created by taptap.c, and keeping it from operating in the host to guest direction, though it still worked in the guest to host direction. I disabled the thing entirely, rebooted, and all is well.
This is a perpetually peeving thing to me: so much code is written now by youngsters who have no depth of experience or vision. They've never seen a DECnet packet, or Novell IPX, or AppleTalk, or any of the other protocols that can operate over an Ethernet (simultaneously, even) and assume that everything is just IP. So it seems that the UML bridging tools do not support any protocols other than the IP subset. Because no experienced analyst was involved in the design, the potential of other systems using the bridge was completely ignored.
DECnet Phase IV has "logical addresses" all right, but doesn't use them the way IP uses the analogous IP address. Instead it alters the MAC address of the hardware interface to reflect the logical address. Connections are established by sending a request packet "blind" using the predicted MAC address of the other machine unless the logical address indicates a different "area" than the local net. Only then is a router sought to forward the data. It appears that UML somehow blocked that initial packet where it had to make the leap from the bridge to the tunnel device.
I realize we live in a world where more and more of the population has never seen, let alone used, a rotary dial telephone. Many kids in their 20s or younger can't tell time on an analog clock, and, as I've recently discovered, can't read or write cursive script. But does that mean we can design roads that can't be navigated by older vehicles? Or networks that can't be used by older software? Most of the time, I think the answer to that is "no." And if such roads or networks are created, then they should be labeled for what they are.
no subject
Date: 2011-07-04 10:00 am (UTC)I'd still like to get one of these, but I doubt I ever am going to. :)
Not being able to write cursive doesn't sound like such a big deal to me. I'm sure there's people who deplore the fact that nobody (except for the grandparent generation) these days can write Sütterlin, but that's the way life goes. At least most people can still read cursive, although this isn't true for Sütterlin anymore, either: I can barely read it at all. My mother can read it, but I don't think she can write it, and my grandmother uses it to write christmas cards and the like.
no subject
Date: 2011-07-04 12:54 pm (UTC)Inability to read cursive is a much more deeply-rooted risk. One reason that the Middle Ages lasted as long as they did was the breakdown of scholarship and communication that followed the collapse of the Roman Empire and its system of roads and trade. Much of science and philosophy was hidden for centuries because scholars, even those in the monastic libraries, forgot how to read Greek. One of the great contributions that helped push the Renaissance along was the rediscovery of the classical Greek scientific and historical treatises and their translation into vernacular languages.
Historically, a sudden shift in language or writing systems tends to cause a breakdown or at least a slowing of civilization's advance. Prior to World War II, the bulk of civil record keeping was still handled in cursive script. All those original records become inaccessible mysteries when we have a population that can no longer read them. There is also a more immediate generational disconnect, similar to the one you mention here with the Sütterlin script, but much more widespread. Considering the minimal cost in time involved with teaching this, I find it very disturbing that schools have simply chucked it into the trash as "useless." Keyboards are not always and will not always be available, just as we find that during natural disasters (or wars) our cell phones strangely enough seem to quit working.
By the way, I don't find Sütterlin to be so different from modern cursive as to be unintelligible. It just slows me down until I get used to it. My rudimentary German is more of an obstacle than the script can be. The history of Sütterlin and the reason it has faded, as given in that Wikipedia article, is much more interesting and tends to emphasize my point here. These changes can be politically dangerous because they tend to obscure the past and disenfranchise or devalue older generations. That was the intent of the NAZIs when they outlawed Black-letter and Sütterlin.
no subject
Date: 2011-07-04 04:09 pm (UTC)no subject
Date: 2011-07-05 11:16 am (UTC)Not "no one knows how to fix it" which is disappointing but understandable, but "you don't matter."
The thing is, in this particular case, while DECnet may be a pretty small number of users compared to the whole, I suspect that IPX is still in significant demand and it's affected as well. Apparently, the prescribed fix for poor routing in UML is to manually add things to the ARP table. That is not going to help protocols that don't use IP addresses. Duh.