LWN.net Logo

Kamp: A Generation Lost in the Bazaar

Kamp: A Generation Lost in the Bazaar

Posted Aug 20, 2012 19:01 UTC (Mon) by hummassa (subscriber, #307)
In reply to: Kamp: A Generation Lost in the Bazaar by juhl
Parent article: Kamp: A Generation Lost in the Bazaar

I know it's slashdot (the user, not the site) but I actually agree with him and I think that Kamp ignored what is the Cathedral and what is the Bazaar in the original esr's text, amongst many other things. And slashdot's complains about the text actually make a lot of sense. So please, re-read the text and hit yourself with your cluestick.


(Log in to post comments)

Kamp: A Generation Lost in the Bazaar

Posted Aug 20, 2012 19:36 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

(Quoting the article here)

> Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff
> is one of the 122 packages on the road to www/firefox, yet the
> resulting Firefox browser does not render TIFF images. For
> reasons I have not tried to uncover, 10 of the 122 packages need
> Perl and seven need Python; one of them, devel/glib20, needs both
> languages for reasons I cannot even imagine.

Libtiff, python and perl are used by various components of the GTK+ library / stack that Firefox uses. Firefox uses GTK+ rather than completely implementing printing and such on its own as it used to do (but even before that, Firefox relied on GTK+ for some basics. I believe that this is what the article refers to as code reuse. If the author's desktop is GNOME, XFCE and/or LXDE, or even if he merely uses the GIMP, he probably already has GTK+ built from a previous install and did not need to build it just for installing Firefox.

> you will find that you need three different versions of the
> make program

Maybe this is just FreeBSD? Where in Firefox's recursive build dependency on Linux can I fine any make other than gmake?

As for building glib without perl / python support: I have no idea if the FreeBSD ports system is designed to support this. The Gentoo portage system was designed to support exactly those things. But then again, most users of "Ubuntu" (as in slashdot's comment) and the likes normally don't bother (and hence don't consider this a required feature of the packaging system :-).

Kamp: A Generation Lost in the Bazaar

Posted Aug 20, 2012 21:45 UTC (Mon) by epa (subscriber, #39769) [Link]

He still has a legitimate point. If Firefox does nothing with TIFFs, why does it require libtiff? If the answer is that GTK contains functions which call libtiff, that's not a good enough reason if those functions are never used by Firefox. Fixing this would require more conditional compilation and/or looser, run-time linking of dependencies. Unfortunately both those things multiply the number of possible configurations and hence places for bugs to hide.

Kamp: A Generation Lost in the Bazaar

Posted Aug 20, 2012 23:25 UTC (Mon) by hummassa (subscriber, #307) [Link]

Have you considered the fact that it's possible that internally one or more of ff's dependencies uses libtiff for something?

Or -- more probable -- the fact that the ports system has a bug (because it does not have USE flags like portage or something) that does not let you compile those dependencies without libtiff?

Kamp: A Generation Lost in the Bazaar

Posted Aug 20, 2012 23:25 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

Libtiff is not required by Firefox (Firefox). It is required by oy one of the GTK+ packages. GTK+ would actually work just fine without TIFF support. But I figure that the maintainers of the GTK+ port in FreeBSD figured it would be a nice idea for GTK+ programs to have TIFF support.

So you could potentially have two copies of GTK+ on the system. But that would in fact involve a longer build time. Assuming you do want TIFF support in some other GTK+ programs, why not have it just enabled in GTK+?

So either fix it the "Ubuntu" way (build GTK+ with TIFF support for everybody) or the "Gentoo" way (build GTK+ without TIFF support for everybody. Keeping multiple copies increases your overall build time (not to mention other types of overheads).

Oh, and do you mean that Firefox (and Chromium, likewise) have this nice habit of not reusing system components? Well, this is a know issue. In the works, I guess.

Kamp: A Generation Lost in the Bazaar

Posted Aug 21, 2012 1:52 UTC (Tue) by roc (subscriber, #30627) [Link]

Supporting TIFF in a Web browser is simply a bad idea. There's no important use-case which isn't just as well served by other image formats. Exposing TIFF support means that some site might come to depend on it and now the Web platform has just a bit more unnecessary complexity. Also, you'll have increased the security attack surface for no good reason.

Firefox can use system codecs, that's not the issue here.

Kamp: A Generation Lost in the Bazaar

Posted Aug 21, 2012 23:10 UTC (Tue) by epa (subscriber, #39769) [Link]

Yup, the problem is that the build process tends towards maximalism, since there is only one official build for GTK and it has to include any feature that anybody might want. Any work done by upstream to make dependencies optional is neutralized by the packager, who has the choice of building with libfoo as a hard dependency, or not at all.

Kamp: A Generation Lost in the Bazaar

Posted Aug 21, 2012 4:56 UTC (Tue) by dvdeug (subscriber, #10998) [Link]

I'm trying to understand what possible difference it makes. Yes, in the theoretical world where everything is perfect, we'd only have one language to fill the whole that Python/Perl/Ruby fills. But even in that world, if it had to interact with this world and its variety of graphic formats, I still think libtiff would likely be one of the basic support packages that would get pulled in when building all the libraries that Mozilla depends on. There is no reason that libgtk should be limited to the features that Mozilla needs, or that Mozilla shouldn't depend on it because it provides a feature that Mozilla doesn't need. Libraries just don't work that way.

Back to Perl and Python ... so? What's the cost? If you're talking about a tiny embedded system where only supporting one is a major space saver, then I understand the frustration, but if you're compiling Mozilla, both Perl and Python are negligible in size.

Kamp: A Generation Lost in the Bazaar

Posted Aug 20, 2012 22:41 UTC (Mon) by nix (subscriber, #2304) [Link]

I note also that he spends much of the article complaining about Autoconf and Libtool. Go look at their principal authors -- not much dotcom abandoned generation there, many of them were doing free software development in the early 90s or even before, and most of those people are still around, so the callow newcomers get their stuff vetted by the old farts of PHK's generation.

(I do wonder if, as a Linux user since 1997 and a Unix user since 1993, I would count as a dotcom abandoned generation member simply because I entered the workforce in 1999...)

Kamp: A Generation Lost in the Bazaar

Posted Aug 22, 2012 13:50 UTC (Wed) by markhb (guest, #1003) [Link]

You are apparently the only person Google is aware of who has ever used the phrase, "dotcom abandoned generation". For the benefit of those of us whose work and life experience hasn't had anything at all to do with Silicon Valley or even any technology startups, can you please explain what you meant by the phrase and how it relates to the rest of the discussion?

Kamp: A Generation Lost in the Bazaar

Posted Aug 22, 2012 16:34 UTC (Wed) by jwakely (subscriber, #60262) [Link]

From the original PHK article:

> "So far they have all failed spectacularly, because the generation of lost dot-com wunderkinder in the bazaar has never seen a cathedral and therefore cannot even imagine why you would want one in the first place, much less what it should look like."

Lost dot-com wunderkinder?

Posted Aug 22, 2012 17:40 UTC (Wed) by man_ls (subscriber, #15091) [Link]

Many in the dot-com generation have seen enough crumbled cathedrals to last us a lifetime, while the bazaars continue to thrive. Look the previous generation of monolithic operating systems (VMS, System/3x0), all the proprietary Unixen, their intellectual successor Plan 9, the *BSD family, all reduced to legacy state. Consider closed browsers as they lose the ongoing war against open source. Behold the multitude of proprietary abandoned web servers, while their Free counterparts continue to live in Linux repos and promiscuously accept patches from anywhere. Even the GNU project, the original cathedral, has adopted a more open approach to development. Not to speak about proprietary developments, supposedly cathedralicious but in reality more like oversized shacks, with reeking innards that require breathing equipment just to delve into.

It's a mystery how PHK can blame the bazaar for anything. In fact I wonder why he even wants to install Firefox on FreeBSD at all instead of, I don't know, Abaco for Minix.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds