Bill Rugolsky Jr. wrote:
By two networking configuration stacks you mean the traditional method and the NetworkManager way? Wouldn't it have been better to have an actual design ... rather than thinking up a GUI interface to some use case, then starting coding? Pete's condescension is right on target: core Linux components are being replaced by people who, by their own admission, "hate Unix."
Well, the former goes hand in hand with the latter, apparently. There is a saying: "Those that don't understand Unix are comdemned to reimplement it ... poorly".
It seems that an "unusual requirement" is one that is difficult and inconvenient for that other operating system, i.e., a requirement that foregoes the monkey pressing buttons in front of a bitmapped display.
The irony is that legacy operating systems are moving in the opposite direction, introducing text, tools and domain-specific little languages.
Unix/Linux carries years of baggage, mis-designed features, and half-baked implementations. But today's GNOME hackers seem to have completely missed the value of (1) text, (2) tools, and (3) domain-specific little languages and protocols. One area where Unix went somewhat astray is that script and config syntax differences created unnecessary impedance [the original point of this thread] -- the Lisp machine folks had that much right. Two decades later, it's easy to see that domain-specific languages are best built without inventing lots of arcane syntax; these days S-exprs have been replaced by XML, XSLT (*vomit*), and worse.
In my experience, XML does not really work for domain specific languages because it is too heavy on syntax baggage for humans - it is best thought of as textual XDR: good for program-to-program data interchange. I believe your reaction to XSLT confirms this.
Unfortunately, simply stuffing name/value config pairs in a file is not the same as domain-specific design. I'm not holding my breath waiting for support for 20-year-old "unusual requirements" to be bolted on later.
Davide Bolcioni -- There is no place like /home. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
