Almost got it
Jul. 7th, 2011 09:20 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
altivoHot on the trail of the issues with ethernet bridging, DECnet, etc. It is clear that the sequence in which things are initialized becomes critical. DECnet appears to be much more sensitive to this than TCPIP is. It seems that the bridge must come up first, and be assigned the appropriate DECnet MAC address. Then the real NIC is brought up, assigned the SAME MAC address (counterintuitive, no?) and attached to the bridge interface. After that, the taptap tunnel devices can be initialized, but tun0 also must be assigned a valid MAC address that is higher than the one given to the br0 and eth0 devices. Otherwise, the bridge will change its own MAC address to the lowest of the attached interfaces. This seems like weird behavior and I can't imagine why they do that, but they do.
Anyway, getting these things to happen in the correct order under Ubuntu's synchronous "upstart" configuration is not simple, nor is it well-documented. Another black mark for Ubuntu. "Documentation? We don't need no stinkin' documentation!" Well, I don't need a system that won't let me configure it for my needs either. When I decide I must upgrade again, I'll probably go back to plain Debian.
Ubuntu already had two big black marks. One was for non-standard gdm controls and unpredictable X server behaviors. The second was for the obnoxious and irritating "Unity" interface that they are now trying to force on all their users, in a true Apple-like manner. That's not what Linux is about, guys. It's precisely about the ability to configure things to the user's taste or need, rather than to what you think everyone should be forced to use. If I wanted that, I'd be using Windows, or Macintosh. That's exactly what chased me away from them.
Now there's this issue caused by 'upstart.' Admittedly, Canonical's new approach to system initialization gains some speed by executing processes in parallel where it is possible to do so. However, without any decent documentation, I am left unable to convert startup processes that I need into the 'upstart' format. They still get started, but I have no control over WHEN they start, or what is finished before them. This applies not only to DECnet initialization, which must happen before IP networking is started, but also to various amateur radio processes like AX.25 protocol. Canonical's message to those of us who need more advanced control over initialization is looking pretty clear. They are saying "buzz off, we don't want you" and that's probably what I'll be doing.
Anyway, getting these things to happen in the correct order under Ubuntu's synchronous "upstart" configuration is not simple, nor is it well-documented. Another black mark for Ubuntu. "Documentation? We don't need no stinkin' documentation!" Well, I don't need a system that won't let me configure it for my needs either. When I decide I must upgrade again, I'll probably go back to plain Debian.
Ubuntu already had two big black marks. One was for non-standard gdm controls and unpredictable X server behaviors. The second was for the obnoxious and irritating "Unity" interface that they are now trying to force on all their users, in a true Apple-like manner. That's not what Linux is about, guys. It's precisely about the ability to configure things to the user's taste or need, rather than to what you think everyone should be forced to use. If I wanted that, I'd be using Windows, or Macintosh. That's exactly what chased me away from them.
Now there's this issue caused by 'upstart.' Admittedly, Canonical's new approach to system initialization gains some speed by executing processes in parallel where it is possible to do so. However, without any decent documentation, I am left unable to convert startup processes that I need into the 'upstart' format. They still get started, but I have no control over WHEN they start, or what is finished before them. This applies not only to DECnet initialization, which must happen before IP networking is started, but also to various amateur radio processes like AX.25 protocol. Canonical's message to those of us who need more advanced control over initialization is looking pretty clear. They are saying "buzz off, we don't want you" and that's probably what I'll be doing.
