=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [01:46] Besides familarity, is there any real advantages with using a "display server" or a compositor? === chihchun is now known as chihchun_afk [01:48] jsgrant__, you are free to use a text console.... but most people prefer a graphical interface which involves a display server and compositing. Which component does the compositing is not relevant to users [01:49] Oh! Sorry, I meant "over a compositor". [01:49] jsgrant__, it's not a choice of one or the other. All desktops contain both [01:50] It's better to think of it as all desktops involve a display server, and "compositing" is something that some part of the desktop does. Don't think of "compositor" as a component [01:51] duflu: Are we talking about compistor in the same sense, I'm wondering; I mean a'la a Wayland implementation of/on a client or the like. [01:52] jsgrant__, yes we are but your question only makes sense in a Wayland world. In Wayland you build a compositor as a component. In other desktops compositing already exists and is done by some existing part of the system [01:53] So there is no answer to the question if the question isn't relevant to other systems [01:53] duflu: Is there some overview somewhere of the actual architectural diffrences between the two systems/methods, that you know of? Looked around & can't find anything. [01:54] jsgrant__, let me check... [01:54] I've seen "Wayland is nicer than Xorg, because xorg is bloated" arguments -- that's about it. [01:56] duflu: If you don't know any offhand, don't let me assign you hw; Just find it curious I really can't find any in-depth comparissions. [01:56] jsgrant__, Yes I found a useful page (http://wiki.ubuntu.com/MirSpec). Confusingly it refers to compositor and shell as the same thing. That's true but only true for Mir :) [01:56] Maybe my searchfu is just poori.] [01:58] Will certainly look into page (notice now it's in the topic) & will look further; Have a feeling it must be out there more-so than I've been able to find thusfar, maybe just being drowned out by Wayland hype-pieces. [01:58] duflu: Ty. [02:12] I know people like to draw architectural diagrams where "compositor" or "window manager" are labelled boxes. However those only make sense in certain contexts. Specifically, having a separate "compositor" component is only really true for Wayland and Xorg. And having a separate "window manager" is only really true for Xorg (where it typically is also the compositor). But neither of those are true for Mir. You might have a Mir server which [02:12] does both compositing and window management, but those are not themselves separate components you need to build or reinvent. This is one way in which Mir tries to be different [02:18] Are there any alternative "window manager" environment you're aware of for Mir, that I can take a look at? Again if you aren't aware, don't have me give you hw. [02:19] "window manager"-like* [02:19] Sans Unity of course. [02:21] Just found, https://insights.ubuntu.com/2016/11/28/mir-is-not-only-about-unity8/ -- which kinda orbits this. [02:22] jsgrant__, yes the 'mir-demos' package contains 'mir_proving_server' and the 'miral-examples' package contains 'miral-shell' [02:23] Although none were ever really nice and ready for general use [02:23] * jsgrant__ wonders if it's worth the effort to try to run on Fedora or just spin up an Ubuntu VM. :^P [02:24] Will probably end up doing both. Have spare box already running a minimal F25 install. [02:25] Mir by itself will run perfectly smoothly even on an original Atom from 2008. It's only Unity8 that had less backward-compatibility/performance [02:27] And actually Mir's backward compatibility is only limited by Mesa. Mesa chose to drop compatibility for older chips, so Mir (and others) can't go back that far [02:27] It's only Mesa dictating that limitation [02:29] *"so Mir (and others) can't go back much further than 2008 for Intel chips" [02:34] Have boxes about that old, but not in active rotation; Shouldn't be a problem then -- neat! :^) [07:41] hey [07:41] morning all [07:41] tvoss: hey === chihchun_afk is now known as chihchun === JanC_ is now known as JanC [12:43] alan_g: so apparently mir can't find capnproto on Fedora :/ [12:44] because Debian changed how the capnproto cmake stuff looks compared to upstream [12:44] well, and upstream doesn't install it when using autotools (which is what they recommend for Linux) [12:44] and there's the fun bigger problem that capnproto isn't building on GCC7 :( === chihchun is now known as chihchun_afk