[01:46] <jsgrant__> Besides familarity, is there any real advantages with using a "display server" or a compositor?
[01:48] <duflu> 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] <jsgrant__> Oh! Sorry, I meant "over a compositor".
[01:49] <duflu> jsgrant__, it's not a choice of one or the other. All desktops contain both
[01:50] <duflu> 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] <jsgrant__> 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] <duflu> 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] <duflu> So there is no answer to the question if the question isn't relevant to other systems
[01:53] <jsgrant__> 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] <duflu> jsgrant__, let me check...
[01:54] <jsgrant__> I've seen "Wayland is nicer than Xorg, because xorg is bloated" arguments -- that's about it.
[01:56] <jsgrant__> 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] <duflu> 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] <jsgrant__> Maybe my searchfu is just poori.]
[01:58] <jsgrant__> 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] <jsgrant__> duflu: Ty.
[02:12] <duflu> 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] <duflu> 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] <jsgrant__> 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] <jsgrant__> "window manager"-like*
[02:19] <jsgrant__> Sans Unity of course.
[02:21] <jsgrant__> Just found, https://insights.ubuntu.com/2016/11/28/mir-is-not-only-about-unity8/ -- which kinda orbits this.
[02:22] <duflu> jsgrant__, yes the 'mir-demos' package contains 'mir_proving_server' and the 'miral-examples' package contains 'miral-shell'
[02:23] <duflu> 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] <jsgrant__> Will probably end up doing both. Have spare box already running a minimal F25 install.
[02:25] <duflu> 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] <duflu> 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] <duflu> It's only Mesa dictating that limitation
[02:29] <duflu> *"so Mir (and others) can't go back much further than 2008 for Intel chips"
[02:34] <jsgrant__> Have boxes about that old, but not in active rotation; Shouldn't be a problem then -- neat! :^)
[07:41] <Son_Goku> hey
[07:41] <Son_Goku> morning all
[07:41] <Son_Goku> tvoss: hey
[12:43] <Son_Goku> alan_g: so apparently mir can't find capnproto on Fedora :/
[12:44] <Son_Goku> because Debian changed how the capnproto cmake stuff looks compared to upstream
[12:44] <Son_Goku> well, and upstream doesn't install it when using autotools (which is what they recommend for Linux)
[12:44] <Son_Goku> and there's the fun bigger problem that capnproto isn't building on GCC7 :(