Autoreply: annoyances Digest, Vol 9, Issue 1
[email protected] Fri, 11 Mar 2005 15:00:50 -0500
| Newsgroups | gmane.linux.usability.annoyances |
|---|---|
| Message-ID | <[email protected]> |
The Mailbox jason.eberly is currently unavailable. It is in deactivated state and is not receiving mails. Your message reads: Received: from razor.electric.net (unverified [216.129.90.118]) by ucmmail.com (Rockliffe SMTPRA 6.1.17) with ESMTP id <[email protected]> for <[email protected]>; Fri, 11 Mar 2005 15:00:50 -0500 Received: from emrelay.onebox.com by razor.electric.net with host-route (Exim 4.34) id 1D9qJV-0002G7-4T for [email protected]; Fri, 11 Mar 2005 12:00:49 -0800 Received: by emcmailer; Fri, 11 Mar 2005 12:00:49 -0800 Received: from cerberus.renaissoft.com ([24.82.132.245] helo=davinci.renaissoft.com) by razor.electric.net with esmtp (Exim 4.34) id 1D9qJT-0002EC-5f for [email protected]; Fri, 11 Mar 2005 12:00:48 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by davinci.renaissoft.com (Postfix) with ESMTP id 9CFBC5E01FE; Fri, 11 Mar 2005 12:00:35 -0800 (PST) Received: from davinci.renaissoft.com ([127.0.0.1]) by localhost (davinci.renaissoft.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00826-05-3; Fri, 11 Mar 2005 12:00:33 -0800 (PST) Received: from davinci.renaissoft.com (localhost.localdomain [127.0.0.1]) by davinci.renaissoft.com (Postfix) with ESMTP id DC1495E01FF; Fri, 11 Mar 2005 12:00:03 -0800 (PST) From: annoyances-request-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org Subject: annoyances Digest, Vol 9, Issue 1 To: [email protected] Reply-To: [email protected] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-BeenThere: [email protected] X-Mailman-Version: 2.1.2 Precedence: list List-Id: Seeking Linux annoyances for a book. <annoyances.dee-annleblanc.com> List-Unsubscribe: <http://michelangelo.renaissoft.com/mailman/listinfo/annoyances>, <mailto:annoyances-request-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org?subject=unsubscribe> List-Archive: <http://michelangelo.renaissoft.com/mailman/private/annoyances> List-Post: <mailto:[email protected]> List-Help: <mailto:annoyances-request-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org?subject=help> List-Subscribe: <http://michelangelo.renaissoft.com/mailman/listinfo/annoyances>, <mailto:annoyances-request-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org?subject=subscribe> Sender: annoyances-bounces-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org Errors-To: annoyances-bounces-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org Message-Id: <20050311200003.DC1495E01FF-2A2DHvHJb7V8EFJQjm9EuJZ3qXmFLfmx@public.gmane.org> Date: Fri, 11 Mar 2005 12:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new 2.2.0 + Maia Mailguard 1.0.0 RC5 X-Origin-IP: 24.82.132.245 X-Virus-Status: Scanned by VirusSMART (s) Send annoyances mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://michelangelo.renaissoft.com/mailman/listinfo/annoyances or, via email, send a message with subject or body 'help' to annoyances-request-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org You can reach the person managing the list at annoyances-owner-DzJonyRHso41Ayx8vbq1stBPR1lH4CV8@public.gmane.org When replying, please edit your Subject line so it is more specific than "Re: Contents of annoyances digest..." Today's Topics: 1. Building Hell (Brandon Warhurst) 2. Re: Building Hell (Alex Butcher) ---------------------------------------------------------------------- Message: 1 Date: Thu, 10 Mar 2005 21:46:04 +0000 From: Brandon Warhurst <[email protected]> Subject: [Annoyances] Building Hell To: [email protected] Message-ID: <roboknight-0j1kMA3/[email protected]> Content-Type: text/plain Hi, I've seen several things related to "dependency hell" on your archive, however, I've got a slight variation on dependency hell. Well, it may be part of what actually causes dependency hell, but here goes. Let me state, before I start, that I've used linux for quite a long time, before modules, when a kernel compile resulted in a monolithic beast. So I've compiled my share of packages, and suffered through dependency hell all through my use of linux. In fact, for those that want to put a date to it, I started using linux when you still had to install from several diskettes... around '94... linux was around before that, but before that, I'd been using SunOS 4.1.3 and 4.1.4... So I'm no newbie to general dependency hell. In fact, it really started with source distributions. You'd get some distributions of some great new software package, you'd explode the source, try to make it, and it would fail. You'd find out you needed package Z to complete your install... and so on and so forth... Sounds like general dependency hell so far. Well, the thing I find annoying about linux, is that while back then, this was an "annoying" task, it was feasible. Now, linux has succeeded in making this much less feasible. Why Linux? Well, mainly because it was the impetus for the Open Source Movement. While I love the OSM like the next geek, the biggest problem is the fact that it *IS* free and open. People are free to choose whatever language suits them, choose whatever libraries are convenient, and build in whatever way they feel like. All this freedom sounds good. And in general, it is good. The problem comes when you want or need to muck about in someone else's code for yourself. So you get the source distribution. Its written in a language you don't use regularly, so you have to download the language. Then, once the language is downloaded, you find out that the package still won't run because it depends on some *EXTENSION*. And this is where dependency hell ends and "extensionitis" begins. So, you get the first extension to the language, you find out it depends on a number of things, and you get those... more dependency hell... But, once you get *THAT* language extension installed, you find out that the language has *ANOTHER* extension you need for something else you don't use. Perfect example is BitPim. BitPim is written in Python. Python is a nice little language. But if you think you'll be able to run BitPim from the source with just Python, you're mistaken! Here's the dependency list for just the *FIRST* language extension: BitPim - Requires wxPython.... wxPython - requires GTK and PyOpenGL GTK - requires pango, atk, glib, freetype2 and others glib - mercifully compiles mostly on its own pango - requires freetype2 atk - again mercifully compiles mostly on its own. PyOpenGL - requires Mesa Looks like normal dependency hell.. but as I stated, that was just the *FIRST* language extension. BitPim ALSO requires you use APSW, a thing that links python to SQLite. So why is this more of an annoyance that dependency hell? Well, I've now tried to run bp.py NUMEROUS times without success. At first, I got unfamiliar errors about finding wx... What was wx? How was I to find out? Fortunately (or unfortunately), I ran across some stuff about wxPython and figured that must be the wx that was being referred to. Once I finally installed wxPython, I tried running it again. I found out I had conflicting versions of wxPython in place. I finally got rid of one. Now I'm a bit further, but I need yet another extension! In addition to the above, installing wxPython was no picnic either. Not only is there dependency hell, but "build hell" which refers to the different ways in which people like to package source code. I was perfectly happy with makefiles. I could fix those when they didn't work. Then people switched to configure... they seemed okay at first because they just about always worked. It was when they broke that I started to get white-knuckled. But now, because someone wanted to write BitPim in Python, its "setup.py"... much less robust that the configure scripts I must say, and much harder to trace when you can't find out why the compiler can't find the header files you've just installed. All of these can be traced back to the "do it the way *YOU* want to do it" attitude of open source. It makes for a terrific development environment because you truly have the freedom to develop anyway you want. So if I don't like setup.py, configure, or anything else, I can stick with makefiles. But it doesn't allow the users of the software any freedom at all. Particularly if they want or need to install from source instead of from RPM. They become locked into the developers world almost immediately. While I can understand this notion for libraries (part of the reason dependency hell comes along in the first place), some of these other languages have extended this notion further by adding language extensions that link the language to a particular piece of software. So now, not only do I have to worry about which libraries I've got installed, but I have to install additional, full blown pieces of software that I'll never use except with this one package. Finally, before someone flames me for picking on BitPim (I'm not trying to target any particular software, and I don't even dislike BitPim, but this one is a great example of everything I've said), try taking a fresh install of Fedora Core 3 (or any other fresh install for that matter) and after the installation, download the BitPim source and see if it runs. Regardless of whether FC3 is a broken installation (I know some will feel it is and they'll want me to switch to Gentoo, or GNU/Linux or something else), this "extensionitis"/"build hell"/"extreme dependency hell" really needs to end. It just gets worse with so many supported languages and new extensions being added to each. Its almost another Tower of Babel out there. All the freedom is great, but no one seems to want to clean up the mess that's left over in the aftermath of all the unconstrained freedom. ------------------------------ Message: 2 Date: Fri, 11 Mar 2005 14:02:29 +0000 (GMT) From: Alex Butcher <[email protected]> Subject: Re: [Annoyances] Building Hell To: [email protected], "Seeking Linux annoyances for a book." <[email protected]> Message-ID: <Pine.LNX.4.62.0503111350140.7294-Nsr+b6K69mHqAR0jHRq2QOybFVwmEEaK8htcxDm17Xw@public.gmane.org> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 10 Mar 2005, Brandon Warhurst wrote: > Finally, before someone flames me for picking on BitPim (I'm not trying > to target any particular software, and I don't even dislike BitPim, but > this one is a great example of everything I've said), try taking a fresh > install of Fedora Core 3 (or any other fresh install for that matter) > and after the installation, download the BitPim source and see if it > runs. This is a common problem that people cite with FOSS, but this is only because people are having to deal with the positives AND negatives of having a level of freedom they've never had before. I tell people to consider having access to FOSS upstream packages as like being a member of Microsoft (or Sun, or IBM) staff and having access to all the goodies that are doubtless being developed behind doors that are closed to the general user population. If you consider yourself a general user, then the way you obtain software - FOSS or otherwise - probably shouldn't be to grab a compiler and start building it yourself; you should probably be either picking a product/distribution that includes the features you need, or petitioning the vendor of the product that's closest to your requirements to include the functionality. The power of FOSS is that it allows you the opportunity to grab the source and a compiler and have access to extra functionality if you /choose/ to do so, and /before/ it might otherwise be available in a boxed product. Just because you have that freedom doesn't mean to say you /have/ to use it. > Regardless of whether FC3 is a broken installation (I know some > will feel it is and they'll want me to switch to Gentoo, or GNU/Linux or > something else), this "extensionitis"/"build hell"/"extreme dependency > hell" really needs to end. It just gets worse with so many supported > languages and new extensions being added to each. Its almost another > Tower of Babel out there. All the freedom is great, but no one seems to > want to clean up the mess that's left over in the aftermath of all the > unconstrained freedom. The alternatives are far, /far/ worse: a) application developers start re-inventing wheels in their own (probably broken and/or incomplete) ways, each mutually incompatible with other implementations. Application development is slowed as the level of re-invention rises. or b) application start bundling all their pre-requisites a la Windows applications. This gives rise to horrid auditing and installation problems when you're trying to find out exactly what is being used on a given system. This is particularly appropriate when you're trying to patch *all* the applications that make use of a particular dependency which is discovered to have a security flaw (cf. <http://lists.seifried.org/pipermail/security/2004-September/004765.html> and <http://www.gzip.org/zlib/advisory-2002-03-11.txt>/ <http://www.gzip.org/zlib/apps.gz.html>. Best Regards, Alex. -- Alex Butcher Brainbench MVP for Internet Security: www.brainbench.com Bristol, UK Need reliable and secure network systems? PGP/GnuPG ID:0x271fd950 <http://www.assursys.com/> ------------------------------ _______________________________________________ annoyances mailing list [email protected] http://michelangelo.renaissoft.com/mailman/listinfo/annoyances End of annoyances Digest, Vol 9, Issue 1 ****************************************