| |||||||||||||
|
| |||||||||||||
The Cairo operating systemThe Cairo operating systemPosted Jul 5, 2006 20:26 UTC (Wed) by evgeny (guest, #774)In reply to: The Cairo operating system by farnz Parent article: Cairo release 1.2.0 now available
> So, by the same token, I assume you avoid all libraries, in case a distribution is fool enough to build versions that depend on libraries your users won't install?
I avoid all libraries that invariably chain with themselves absolutely different (and optional to their core functionality) API layers.
> You seem to advocate changing everything at runtime or startup time;
I advocate for maximal flexibility (as far as it hasn't noticeable negative side effects - and in this case, it doesn't).
> why can't I choose a different VM at startup time? Why can't Firefox drop the XUL handler, if I only need a HTML renderer without a UI? Why can't GIMP run without GTK+, if I'm only using it from the command line? If I'm not planning to use text, why does GIMP pull in FreeType and Pango?
1. Not sure what you meant (i.e., in which context) by VM, but the rest would be really great. Why don't you think so?
> My point is that the mechanism works for the currently intended uses of Cairo,
No, it doesn't. The fact is you _can_ build Cairo without the X stuff and other cholesterol additions, so such a use (alongside with others) _was_ intended. Yet, when considering Cairo as a mainstream 2D rendering API (which is obviously what Cairo devs think of it as), it becomes clear that with the current monolithic design this will never be realized except in DIY distros like Gentoo.
> and provides a small, but measurable benefit for them in terms of memory usage as well as time in their choice of application.
Who cares about extra half a millisecond or a few bytes?! And are you serious the choice (i.e., monolithic vs. plugin design) was ever discussed and decided upon based on the performance considerations?
> It also makes their code considerably simpler to write in the first place
OK, now this boils down to the truth. That's the whole reason - it simply has NOT been designed/thought of/coded YET. Adding another mumbo-jumbo backend is cooler than doing the backend separation in a proper way, that's all.
Now, please notice that I'm NOT criticizing the priority list of the Cairo devs. Most of us (myself including) is coding FOSS stuff for fun. Let mumbo-jumbo be first. But please, don't call a bad design by any other name. Perhaps this will help releasing Cairo-2.0 with all the backends as optional plugins.
(Log in to post comments)
The Cairo operating system Posted Jul 5, 2006 21:44 UTC (Wed) by farnz (guest, #17727) [Link] I'm still not clear what you're after; Cairo has the needed separation between backends and core library internally. They just haven't spent the hours needed to write dlopen() boilerplate code, and their own runtime linking of backends derived from this, especially since the backend interface isn't stabilised, and thus this boilerplate code would need plenty of changes.You're still arguing that because your distribution of choice combines a lack of flexibility in providing alternative versions of a package with maintainers unwilling to do the extra (manual) work involved in providing those alternatives, all library developers should do the extra (manual) work in working round this deficiency. Plus, as you've said yourself, who cares about a few bytes? If you never use anything other than the SVG backend for Cairo, the other backends and their associated libraries won't be used in memory at all, and disk is even cheaper than RAM (which you're happy to burn). Indeed, if the dynamic linker is bright enough (and I've never checked this), you could delete the X11 and OpenGL backends, and not even notice that you're missing compile-time dependencies. If it's security that worries you, I'd just like to point out that you're advocating that the Cairo developers stop making use of the dynamic linker's symbol resolution, and write their own version; there's no guarantee that this code won't be buggy. In addition, bugs in a manually coded subset of a dynamic linker are likely to lead to arbitrary code execution, not to output faults. Here's a constructive suggestion for you; if the dynamic linker isn't bright enough to cope with missing libraries (despite the fact that they're not used), why don't you motivate someone to fix this? The result should be that your server code (which presumably never touches the DirectFB backend) can link to a version of Cairo that was compiled with all the backends, and never notice that someone didn't install the DirectFB backend. Then, your distribution of choice can compile Cairo with everything turned on, but ship it in a split set of packages with different backends.
The Cairo operating system Posted Jul 5, 2006 22:35 UTC (Wed) by evgeny (guest, #774) [Link] > I'm still not clear what you're after; Cairo has the needed separation between backends and core library internally. They just haven't spent the hours needed to write dlopen() boilerplate code
Exactly, that's my point.
> especially since the backend interface isn't stabilised, and thus this boilerplate code would need plenty of changes.
I don't believe it. If the internal API changes, they still need doing practically the same amount of work, be it a direct linking or glued by dlopen. As far as the core and the backends are maintained by the same team, at least - which is the case now.
> You're still arguing that because your distribution of choice combines a lack of flexibility
NO! why don't you read carefully what I've said earlier? _My_ distribution of choice (Gentoo) is flexible enough to accomodate my needs, not to mention I'm pretty much content with compiling from the source tarballs. But this doesn't matter. What I care about are _users_ of my software, which is NOT specific to Gentoo, so if a sysadmin doing e.g. "apt-get install myapp" on a server will see about entire Gnome lib pack selected (due to the deps) plus the kitchen sink, he will (and rightfully so) say "No". That's what I'm afraid of. I don't agree to cut the number of potential users of my app tenfold because of the dumb Cairo architecture.
> Plus, as you've said yourself, who cares about a few bytes?
Now you're comparing apples to the oranges...
> Here's a constructive suggestion for you; if the dynamic linker isn't bright enough to cope with missing libraries (despite the fact that they're not used), why don't you motivate someone to fix this?
Huh? May I have a contr-suggestion for you: write about this idea to LKML or the glibc maillist, or better both. And don't forget letting me know - I want to enjoy the show ;-)
The Cairo operating system Posted Jul 7, 2006 0:26 UTC (Fri) by nix (subscriber, #2304) [Link] It's not half a millisecond. It's hundreds of Kb per running instance and 10--20 seconds of extra startup time for applications with large numbers of symbols.
Prelinking *matters*.
(FWIW, Jakub Jelinek and Ulrich Drepper recently designed a new ELF symbol hash table format that should reduce the relocation time of non-prelinked apps by 40% or so: but that's a glibc-2.5 thing and requires apps to be relinked to benefit anyway. Plus it can't reduce the memory hit.)
The Cairo operating system Posted Jul 7, 2006 10:40 UTC (Fri) by evgeny (guest, #774) [Link] Oh come on, why on Earth are you continuing to talk about some thought-out-of-the-thin-air situations? Let's focus on Cairo - I'm not suggesting to convert a C++ bloatware to a thousand of plugins! Each Cairo backend (total number < 10) should have a single dlopen'd init entry! Add another one per plugin for maximal flexibility (i.e., the versioning check), but that's all.
The Cairo operating system Posted Jul 8, 2006 22:54 UTC (Sat) by nix (subscriber, #2304) [Link] Cairo is *in use* by large C++ applications.
I repeat: prelinking matters.
The Cairo operating system Posted Jul 9, 2006 17:33 UTC (Sun) by evgeny (guest, #774) [Link] I repeat: one or two dlopen's per backend in Cairo will be unnoticeable in your favorite C++ bloatware app.
|
|
||||||||||||