| |||||||||||||
|
| |||||||||||||
The Cairo operating systemThe Cairo operating systemPosted Jul 5, 2006 14:13 UTC (Wed) by evgeny (guest, #774)In reply to: The Cairo operating system by farnz Parent article: Cairo release 1.2.0 now available
> Why exactly do you want to prevent prelink(8) from working?
I want the cairo library (and hence my app) to not be prelinked against anything which is strictly necessary for the 2D rendering core itself.
> By using dlopen(3), you prevent prelink from determining the relocations itself, and force the dynamic linker to recalculate the relocation values every time the library is used.
The time needed for the dynamic linker to recalculate the relocation of a plugin (typically containing only a couple of functions) is negligible comparing to the rest of initialization of any GUI app. The rest (actual libraries doing the hard work) can be prelink'ed to the plugin object.
(Log in to post comments)
The Cairo operating system Posted Jul 5, 2006 14:16 UTC (Wed) by evgeny (guest, #774) [Link] Oops. s/which is strictly/which is NOT strictly/
The Cairo operating system Posted Jul 5, 2006 14:43 UTC (Wed) by farnz (guest, #17727) [Link] Your application should only be prelinked against the backends if they're installed, as your application should only be linked against the 2D rendering engine (cairo), and not against the backends. The 2D rendering engine is linked against the installed backends; when prelink does the work needed to guarantee that the runtime linker does not need to do any relocations, it'll pick up the backends.Why does it bother you that I've done the caculations to determine how to do the relocations in advance? If you never use the DirectFB or X11 backends, that data is simply ignored, as the backend is never called, so the relocation never takes place, and the backend library is never loaded into memory. If you're complaining because your choice of distribution doesn't provide you with some mechanism to only have the backends you need installed, bitch at your distribution, not the authors, who provide you with compile-time switches to disable the backends you don't want. For some classes of applications, notably C++ applications, the relocation time is significant. Plus, you're ignoring the effects of hot caches; when an executable is fully prelinked, all the code pages, including the GOT and PLT, are never dirtied, so they are shared with all other executables using that library; when you've not got much RAM, not having to keep a private copy of these pages helps. This is especially true on a desktop, where the chances are high that another application is using the library, and thus has pulled the pages you'll need into memory already. In short, you seem to be advocating that cairo drops a perfectly reasonable compile-time method for controlling which backends are installed, and goes to a runtime mechanism with some disadvantages for desktop applications, just because your distro doesn't provide a decent selection of packages without the backends you don't need. I'd like you to justify that position, or correct my misunderstanding of what you're after.
The Cairo operating system Posted Jul 5, 2006 15:28 UTC (Wed) by evgeny (guest, #774) [Link] > If you're complaining because your choice of distribution doesn't provide you with some mechanism to only have the backends you need installed, bitch at your distribution, not the authors, who provide you with compile-time switches to disable the backends you don't want.
I'm complaining NOT as an end-user, but as a developer. My application does NOT need X/FB/...; it's a server-level utility. As such, when I consider the use of Cairo for 2D-rendering, I ask myself: what's the chance that potential users of my app will have Cairo installed on their servers? Right now, the answer is "hardly if at all", since for most mainstream binary distros, Cairo will require X/gtk/what not, probably entire Gnome libs, so who in a sane mind would install all this cruft on e.g. a web server?! Thus, the stone-age inflexibility of Cairo precludes me from using it.
> For some classes of applications, notably C++ applications, the relocation time is significant.
Cairo is not C++, and so isn't my app.
> you seem to be advocating that cairo drops a perfectly reasonable compile-time method for controlling which backends are installed,
Huh? You call it a perfectly reasonable method? Then why don't you advocate for returning to pre-1.0 linux version when drivers were built monolithically in the kernel? or just try persuading Firefox or Gimp users and developers that compile-time selection of extensions/plugins is very reasonable, if not perfect? I bet you'd be laughed at.
> and goes to a runtime mechanism with some disadvantages for desktop applications
Do you have hard figures proving this claim? I'd expect we're talking about some milliseconds or even less, that's all.
The Cairo operating system Posted Jul 5, 2006 16:03 UTC (Wed) by farnz (guest, #17727) [Link] 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? If Cairo provides enough benefits to you, write to it; at the moment, you're saying that you might want to use Cairo in a situation the Cairo developers aren't designing for, but are scared to because if distributions don't provide a server-suited Cairo build, and if Cairo turns out to be the best way for you to do something, you don't think anyone (Cairo developers or distribution builders) will flex to accomodate you.You seem to advocate changing everything at runtime or startup time; 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? My point is that the mechanism works for the currently intended uses of Cairo, and provides a small, but measurable benefit for them in terms of memory usage as well as time in their choice of application. It also makes their code considerably simpler to write in the first place (and yes, I've written code in both styles - dlopen is slightly harder to get right, and harder to debug if you get it wrong). You are asking them to drop that gain, in order to get into a class of applications that they're not targetting. If using Cairo makes your application simpler, use it. If the result is that Cairo needs better backend selection (so that your users don't have to install any X11 libraries), that will happen. In the meantime, you're asking them to drop a small gain from doing things the way they've done them, for a potential future benefit.
The Cairo operating system Posted Jul 5, 2006 16:58 UTC (Wed) by jimmybgood (guest, #26142) [Link] > You seem to advocate changing everything at runtime or startup time; 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?Those possibilities are very appealing. It probably would sacrifice some performance for people who have powerful computers and want all the features anyway. But it would make it much easier for less-advantaged people the world around to install reduced feature set software on legacy computers. Cairo is not like a new RSS aggregator that we can just delete from our computer, if we feel uncomortable with it. Gtk2 is central to the desktop. I think it's reasonable to ask the developers to consider the needs of all users, not just the power users and to anticipate the potential misuses and abuses of package managers and application writers. On the other hand, it's still possible to have a desktop without the bloated, insecure monstrosities that QT and now GTK2 have become. I see several comments that say to the effect, X and OpenGl do something so it's OK that Cairo does it. Let me repeat, it's easy to keep OpenGL on a tight leash and turn it off completely. As for X, it's a very old application that was written in a different era. If experienced developers were to rewrite it from scratch, if they wanted to they could make it much more controllable, stable and secure.
The Cairo operating system Posted Jul 5, 2006 20:26 UTC (Wed) by evgeny (guest, #774) [Link] > 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.
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.
|
|
||||||||||||