On Nov 9, 2007 1:00 PM, Tyrone Hed <[EMAIL PROTECTED]> wrote: > And, frankly, telling me that yet another variant should be tried does not > inspire confidence. I have to wonder: is this the way you guys planned this > to be? With guess-which-version works with your stuff?
I am getting pretty sick of this question being asked over and over again, so I'm going to write something to address this question once and for all. Back in the 1990s, Microsoft thought, "You know, there is a real market for interchangable parts to programs." OLE 1.0 was what had initially shown them the light. However, there were a number of technical issues that interfered with capitalizing on this market, so thus they invented COM. COM offers components with standardized interfaces that, indeed, makes good on their promise of interchangable parts. But all was not well; COM had run into severe usability issues in the form of lack-luster and ill-defined security mechanisms and, of course, "DLL-hell." Of relevance to your issues, I'm focusing on the DLL-hell that ensued. A whole industry evolved out of DLL hell, called "installers." Installers took care of placing things where they needed to be, updated the registry, and so much more, all to give the end-user the illusion of a seamless, effortless install. Largely, it worked. But every time Microsoft alters some technology, you inevitably end up dealing with DLL hell again -- what version of MSVCRT.DLL does THIS program need, and why is it incompatible with THAT program? These issues continue to plague Windows developers today, albeit not as much as they used to, because Windows 2000 introduced per-program library path searches and registry key organizations. Still, it happens more often than you think. I know -- I used to administer a large collection of Win2K and 2K3 servers for a significant ISP. Still, despite all this effort, the problem of re-usable software remains unsolved. People are all the time re-inventing the wheel, because programmers are realizing that wooden wagon wheels don't fit on Ferraris, and wheels for a Toyota Prius don't work well on shopping carts. The end result is a multitude of programs which depend on a multitude of different components, to this very day. It seems that the only thing truely reusable is the _concept_ of a wheel, while the physical reiification of that concept is as domain-specific as the domain to which it's applied. So, why can Windows largely "just work" and not Unix? Let's ignore the subjectivity of this question, and concentrate on what can be objectively measured from the perspective of a Windows developer. Frankly, it's because Microsoft Is God when it comes to the Windows platform. They decide (A) what CPU the OS runs on, (B) what libraries get searched, where, and when, (C) the semantics of various registry keys, etc. There is never any question about "what distribution" of Windows you have -- they have total, precise, and absolute control over all distributions of Windows. (Footnote: It turns out this isn't entirely true; there are a myriad different implementations of WinCE, and try as they might, not all implementations are compatible with each other. But, we see distinct parallels between WinCE and Unix-derived platforms, in that Microsoft _doesn't_ control (A) when it comes to the embedded world. It's amazing how flimsy a tripod becomes when you kick out one of its legs, eh?) This is not the case with Linux, BSD, Solaris, or other Unix-type OSes. Here, POSIX (the common API all these OSes share) is a paper standard, not an implementation standard. Therefore, differing implementations of the API may have subtly different semantics which, largely, isn't usually of any real concern. Part of those semantics covers how the shell finds executables, how the dynamic linker finds shared libraries, and other non-kernel-related stuff. Remember, POSIX covers not just the kernel API, but the user's experience and expectations as well. It is a shame, but POSIX is more nebulous about the latter than the former; it has to be, or else there is no point in having multiple vendors competing with each other in the free market. An all-encompassing standard is no different than a monopoly, and POSIX was careful to avoid the pitfalls of stifling unique selling points of various vendors. Nonetheless, the open source community has discovered that it largely has already solved the "code reusability" problem long before Microsoft had identified it as a potentially profitable market. There are programs and libraries distributed all the time, and no proprietary, binary-level interface is needed. The problems of coupling programs together seems to always depend on filesystem-level or shell environment dependencies. It almost never depends on anything else. This speaks volumes of the technique, considering, after all, there is no grand overlord, no Binary God, no planned design to cover this interoperation. It is an organic evolution, driven by necessity. Observe: the open source community couples programs together with, usually, shell environment variables (e.g., PYTHONPATH in Trac, used to find a Python module that couples to ClearSilver); to the Windows crowd, this is equivalent to a registry setting with a well-known HKEY. Two different technologies, each with their own pros and cons, but at the end of the day, both doing the same job: facilitating two program modules, written by different authors, possibly on different continents, to work together. To summarize: Windows gives computer users the illusion that software is simple, easy to install and administer, and equally easy to upgrade later on. This illusion, however, disperses as soon as you run into the need for periodic registry cleaners, and any time you must manually summon REGEDT32.EXE or its ilk to look at how a program has wedged itself into the registry to fix some obscure problem. COM did nothing to make the solutions easier; it only created additional layers of complexity and indirection that allowed a market addressing its problems to grow. The Windows UI did nothing to make installing a program easier; it merely shifted the burden of difficulty from "easy installation" to "stupifying difficulty" when things go wrong later, resolving DLL-hell and other problems. Just as your "neo_cgi.so" file problems give you heart-ache, you get the exact same problems in Windows, where a CLASSID of some kind refers to a non-existent process or DLL. Go ahead and remove or rename a file referred to by any HKEY_CLASS registry key, and just watch how crippled your dependent applications become. It's the same thing. The fact is: programs these days rarely exist in a vacuum. They depend, at a minimum, upon the interfaces exposed by the operating system. They very often depend on services written by other authors, and distributed in other modules, precisely because the programmer isn't interested in solving an already solved problem. Whether your interfaces are exposed as Python modules or as COM objects is utterly immaterial -- a dependency is a dependency is a dependency, and it must, at some level, be dealt with. There are many many thousands of satisfied Trac users. I'm one of them. I installed TWO instances in a very short amount of time, on two very different OS environments (Ubuntu, with the help of apt-get, and GoboLinux, which required installation by hand). My web service provider installed it, upon my request, in less then one day. This isn't hard stuff. But it IS perhaps DIFFERENT stuff from what you're used to. The problem of software complexity is intrinsic in software itself; it has nothing at all to do with how Microsoft, Apple, IBM, or the bazillions of different Linux distributions handles it. Likewise, the folks who wrote Trac didn't sit down and nefariously plan, "Bwaahaha! This will weed out the slackers from the real men!" No; they identified a problem relevant to them, and they solved that problem with the best tools available at that time. They list their dependencies relatively clearly, certainly clearly enough for someone as disinterested in how Trac works under the hood as I am, to install it effortlessly. OTOH, I'm familiar with how open source and Unix dependency management works. You're obviously not. Your world is dominated by how Microsoft does things. This isn't Microsoft; welcome to a wider world. Moreover, it's been identified several times that AIX is a problematic implementation of Unix. You know how problematic it is? IBM, the very authors of AIX itself, have all but swept AIX under the carpet to persue Linux-only solutions. Even IBM is embarrassed by AIX. Promotional materials for AIX-based solutions mention it seemingly in passing only. In fact, I can't remember the last time I've actually seen a promotion for AIX. That should tell you something. So, I ask you, once again, to please refrain from blaming Trac, Trac's authors, or the Trac community in general, for problems that are singularly your own. We've offered to help, and we do regret that our proposals have not worked for you. No enterprise can satisfy all its customers. Particularly since we've given you far more technical support than your $125/incident would get you at Microsoft. There are alternatives available; I've already identified Sourceforge as a potentially viable alternative. Savannah is another (it's actually a GNU version of Sourceforge). Or, have you considered writing your own? I know for a fact that, e.g., MoinMoin wiki has a bug tracker plug-in for it (the Darcs website is implemented this way, for example), and Trac's other features can be implemented via various CGI modules offered through other parties. It may not be as "all inclusive/integrated" as you'd like, but the solutions do work. They've worked for years for many people. -- Samuel A. Falvo II --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
