[opensuse] Wayland?
I've seen 'libwayland' come up a few times recently when running 'zypper up'. What is the status of the Wayland project wrt openSuse? I'm thinking that it would be nice to have a graphics server that supported Qt or GTK directly rather than the deep layers of X. I'm not convince Wayland is that, but lets face it, X was a solution to a problem of the 1980s, long before Pcs, long before the powerful GPUs we have today, long before the powerful CPUs and their advanced instruction sets. -- Warning: Klein Bottle. No user-serviceable parts inside. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/07/14 a las #4, Anton Aylward escribió:
I've seen 'libwayland' come up a few times recently when running 'zypper up'.
What is the status of the Wayland project wrt openSuse?
It is in early integration phase, developer mode..;-) switching to wayland is a shitload of work and AFAIK all the coding needed is incomplete..let alone the distribution assembly. I am also looking forward to this but I doubt it will be used by default before late 2015/2016.. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 11:03 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
I've seen 'libwayland' come up a few times recently when running 'zypper up'.
What is the status of the Wayland project wrt openSuse?
It is in early integration phase, developer mode..;-) switching to wayland is a shitload of work and AFAIK all the coding needed is incomplete..let alone the distribution assembly.
I am also looking forward to this but I doubt it will be used by default before late 2015/2016..
Thank you. So what's with these which have appeared when I 'zypper up'. libwayland-client0-32bit-1.2.1-1.1.x86_64 libwayland-client0-1.2.1-1.1.x86_64 libwayland-server0-32bit-1.2.1-1.1.x86_64 libwayland-cursor0-1.2.1-1.1.x86_64 libwayland-server0-1.2.1-1.1.x86_64 libwayland-egl1-10.2.4-381.1.x86_64 -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/07/14 a las #4, Anton Aylward escribió:
libwayland-client0-32bit-1.2.1-1.1.x86_64 libwayland-client0-1.2.1-1.1.x86_64 libwayland-server0-32bit-1.2.1-1.1.x86_64 libwayland-cursor0-1.2.1-1.1.x86_64 libwayland-server0-1.2.1-1.1.x86_64 libwayland-egl1-10.2.4-381.1.x86_64
Some application has native Wayland support, which requires those libraries.."one small step for man.." more and more apps should at some point gain those as direct or indirect dependencies.. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 11:24 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
libwayland-client0-32bit-1.2.1-1.1.x86_64 libwayland-client0-1.2.1-1.1.x86_64 libwayland-server0-32bit-1.2.1-1.1.x86_64 libwayland-cursor0-1.2.1-1.1.x86_64 libwayland-server0-1.2.1-1.1.x86_64 libwayland-egl1-10.2.4-381.1.x86_64
Some application has native Wayland support, which requires those libraries.."one small step for man.." more and more apps should at some point gain those as direct or indirect dependencies..
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/07/14 a las #4, Anton Aylward escribió:
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these?
You can't. unless you want a system without X or a desktop environment. Currently removing the first package triggers removal of ~400 packages. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 11:31 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these?
You can't. unless you want a system without X or a desktop environment. Currently removing the first package triggers removal of ~400 packages.
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/07/14 a las #4, Anton Aylward escribió:
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It is a real dependency.. code is using the API provided by those libraries.. of course it is not active unless you are running wayland. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 11:55 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It is a real dependency.. code is using the API provided by those libraries.. of course it is not active unless you are running wayland.
Eh? There's something that doesn't seem right in that explanation. If Wayland isn't there to make use of the APIs, *and* the APIs are encapsulated in these libraries, then these libraries should be removable if Wayland isn't around to make use of them. Think about the call tree. The only reason that these libraries would be required is if they were required by something else, that is they contained code that was called by a non-wayland layer. In which case three is something very strange about the call tree. I've read David's note about dynamic and static linking, but I don't see that it is really an answer. If there is nothing in the call tree then its matter of how things are packaged. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/07/14 a las #4, Anton Aylward escribió:
On 07/31/2014 11:55 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It is a real dependency.. code is using the API provided by those libraries.. of course it is not active unless you are running wayland.
Eh?
There's something that doesn't seem right in that explanation.
If Wayland isn't there to make use of the APIs, *and* the APIs are encapsulated in these libraries, then these libraries should be removable if Wayland isn't around to make use of them. Think about the call tree.
That's not how things work..libraries are linked, have a dependency at the binary level, what you are proposing is somehow similar to making the apps use dlopen() to load the libraries on demand.. that ain't gonna work well unfortunately. I 'll let you just the tip of the iceberg.. RPM has no clue how to handle dlopen()'ed libraries, therefore dependency and version handling is let to the packager..and is gonna break everytime the library version changes..plus.. you are requesting this to be done in a component which is under heavy development..its api may or may not be stable..and down the drain we go... -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 05:03 PM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
On 07/31/2014 11:55 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It is a real dependency.. code is using the API provided by those libraries.. of course it is not active unless you are running wayland.
Eh?
There's something that doesn't seem right in that explanation.
If Wayland isn't there to make use of the APIs, *and* the APIs are encapsulated in these libraries, then these libraries should be removable if Wayland isn't around to make use of them. Think about the call tree.
That's not how things work..libraries are linked, have a dependency at the binary level, what you are proposing is somehow similar to making the apps use dlopen() to load the libraries on demand.. that ain't gonna work well unfortunately.
Re reading what I wrote I can see how you might think that I mean that the search for the libraries was carried out at call-time rather than earlier. I realise that the link-loader (or should it be called a load-linker) has 'compile time" and execute/load time components. The compile linkage identifies the required libraries; the link-loader finds them and resolves the links at load time by reference to LD_LIBRARY_PATH thank you ld.so and ld-linux.so. Linux wasn't the first to do this :-)
I 'll let you just the tip of the iceberg.. RPM has no clue how to handle dlopen()'ed libraries, therefore dependency and version handling is let to the packager..and is gonna break everytime the library version changes..plus.. you are requesting this to be done in a component which is under heavy development..its api may or may not be stable..and down the drain we go...
You are correct in the above but I'm not sure what relevance it has with what I'm trying to establish. Right now we are not using Wayland. We don't need the Wayland libraries I mentioned, the Wayland functions at http://wayland.freedesktop.org/docs/html/chap-Library.html So long as the KDE components don't make direct calls to X, so long as they use the Qt library, then this should work Before using Wayland, have LD_LIBRARY_PATH direct the runtime link-loader to libraries that have Qt making calls to the X.org API When Wetland is being used have the LD_LIBRARY_PATH direct to the Wayland API. Right now it seems that the Wayland libraries such as -client0 are somehow involved. I don't have time to trace though source of the 300+ items and follow the call trees to see if they do in fact make calls to any of those functions in /usr/lib64/libwayland-client.so or if this is a packaging issue. If we have current high level applications calling Wayland I'm very curious as to why, if, as you say, Wayland isn't stable and isn't going to be around for a couple of years. -- The major advances in civilization are processes that all but wreck the societies in which they occur. -- A.N. Whitehead -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 31 Jul 2014, Anton Aylward wrote:
On 07/31/2014 11:31 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these?
You can't. unless you want a system without X or a desktop environment. Currently removing the first package triggers removal of ~400 packages.
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It's a matter of dynamic linking. You can either link to a lib, then you'll need that lib to be installed, or you don't. The only alternative is dynamic linking (cue plugins for e.g. vlc), but that has its own traps. I guess, with libwayland* (as with most other libs) it is just not possible to load these libs dynamically via libdl. So, you have to link to these libs, thus you need to install the libs. AFAIR they won't get actually loaded into memory until actually used. If you do not install all linked-to libs, you'll just get a linker error, when you try to run the program. You'll have to look closely at the dependencies, some you can ignore (explicitly set deps in a "aggregating" package (see below)), some you can not. E.g.: $ rpm -q --requires kdebase4-runtime | grep soprano libsoprano.so.4()(64bit) libsopranoserver.so.1()(64bit) soprano-backend-redland $ rpm -qa '*soprano*' libsoprano4-2.8.0-122.5.x86_64 "libsoprano.so.4()(64bit)" is a real dependency of at least one program/lib packaged in kdebase4-runtime, but "soprano-backend-redland" is a "manual explicit" dep, which I can ignore as I do not intend to ever use soprano. The programs using soprano will still run, as libsoprano* are installed, but their soprano-functionality won't. Same with wayland. You'll need the libwayland*, but not wayland itself and you can ignore manual deps on it if you do now want to use wayland. Actually: many such "explicit manual" deps could be "Recommends", or programs needing a lib could be split out into a seperate package. Vlc (vlc-noX, vlc (uses gtk), vlc-qt, libvlc*) is a prime example how it can be done. But the program(s) need to be seperatable as vlc is too. HTH, -dnh -- Freeman Dyson recounts how the RAF tried hard to locate the admin hq for German aircraft production, found it, bombed it into oblivion... and were horrified when German aircraft production rates went *up* -- Henry Spencer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 02:18 PM, David Haller wrote:
Hello,
On Thu, 31 Jul 2014, Anton Aylward wrote:
On 07/31/2014 11:31 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these?
You can't. unless you want a system without X or a desktop environment. Currently removing the first package triggers removal of ~400 packages.
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It's a matter of dynamic linking. You can either link to a lib, then you'll need that lib to be installed, or you don't. The only alternative is dynamic linking (cue plugins for e.g. vlc), but that has its own traps.
I guess, with libwayland* (as with most other libs) it is just not possible to load these libs dynamically via libdl. So, you have to link to these libs, thus you need to install the libs. AFAIR they won't get actually loaded into memory until actually used.
If you do not install all linked-to libs, you'll just get a linker error, when you try to run the program.
You'll have to look closely at the dependencies, some you can ignore (explicitly set deps in a "aggregating" package (see below)), some you can not. E.g.:
$ rpm -q --requires kdebase4-runtime | grep soprano libsoprano.so.4()(64bit) libsopranoserver.so.1()(64bit) soprano-backend-redland $ rpm -qa '*soprano*' libsoprano4-2.8.0-122.5.x86_64
"libsoprano.so.4()(64bit)" is a real dependency of at least one program/lib packaged in kdebase4-runtime, but "soprano-backend-redland" is a "manual explicit" dep, which I can ignore as I do not intend to ever use soprano. The programs using soprano will still run, as libsoprano* are installed, but their soprano-functionality won't.
Same with wayland. You'll need the libwayland*, but not wayland itself and you can ignore manual deps on it if you do now want to use wayland.
Actually: many such "explicit manual" deps could be "Recommends", or programs needing a lib could be split out into a seperate package. Vlc (vlc-noX, vlc (uses gtk), vlc-qt, libvlc*) is a prime example how it can be done. But the program(s) need to be seperatable as vlc is too.
Each of those packages contains just the one bianry and link. rpm -ql libwayland-client0-1.2.1-1.1.x86_64 \ libwayland-cursor0-1.2.1-1.1.x86_64 \ libwayland-server0-1.2.1-1.1.x86_64 \ libwayland-egl1-10.2.4-381.1.x86_64 /usr/lib64/libwayland-client.so.0 /usr/lib64/libwayland-client.so.0.1.0 /usr/lib64/libwayland-cursor.so.0 /usr/lib64/libwayland-cursor.so.0.0.0 /usr/lib64/libwayland-server.so.0 /usr/lib64/libwayland-server.so.0.1.0 /usr/lib64/libwayland-egl.so.1 /usr/lib64/libwayland-egl.so.1.0.0 So that eliminates the possibility that there is some other function in the package. Those like like dynamic libraries. Let me run 'file' on each...) /usr/lib64/libwayland-client.so.0: symbolic link to `libwayland-client.so.0.1.0' /usr/lib64/libwayland-client.so.0.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e23c66009f0244b0941f667292532428a4526115, stripped /usr/lib64/libwayland-cursor.so.0: symbolic link to `libwayland-cursor.so.0.0.0' /usr/lib64/libwayland-cursor.so.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=fb03ad69713143387df0e2c4b0b32c0647045c74, stripped /usr/lib64/libwayland-server.so.0: symbolic link to `libwayland-server.so.0.1.0' /usr/lib64/libwayland-server.so.0.1.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2b279857315e09f5bc23acbf49eea0415727680e, stripped /usr/lib64/libwayland-egl.so.1: symbolic link to `libwayland-egl.so.1.0.0' /usr/lib64/libwayland-egl.so.1.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8261041ceddb470d9c2167361eadfa307e37088d, stripped So yes they are. So lets see what they call ldd /usr/lib64/libwayland-client.so.0.1.0 linux-vdso.so.1 (0x00007fff1133f000) libffi.so.4 => /usr/lib64/libffi.so.4 (0x00007f3d496d9000) librt.so.1 => /lib64/librt.so.1 (0x00007f3d494d1000) libc.so.6 => /lib64/libc.so.6 (0x00007f3d49121000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3d48f03000) /lib64/ld-linux-x86-64.so.2 (0x00007f3d49b12000) ldd /usr/lib/libffi.so.4 linux-gate.so.1 (0xf76f3000) libc.so.6 => /lib/libc.so.6 (0xf7516000) /lib/ld-linux.so.2 (0xf76f4000) ldd /usr/lib64/librt.so linux-vdso.so.1 (0x00007fff335fe000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f693282d000) libc.so.6 => /lib64/libc.so.6 (0x00007f693247e000) /lib64/ld-linux-x86-64.so.2 (0x00007f6932a4b000) All that is pretty vanilla., so there is nothing further down in the call tree that would cause the dependency. Therefore it must be something in those hundreds of packages that is calling The following 349 packages are going to be REMOVED: akonadi akonadi-runtime apper apper-lang appmenu-qt ark audex [....] DirectFB DirectFB-Mesa dolphin [....] xf86-input-evdev xf86-input-joystick xf86-input-keyboard xf86-input-mouse xf86-input-synaptics xf86-input-vmmouse xf86-input-void xf86-input-wacom xf86-video-fbdev xf86-video-modesetting xf86-video-nouveau xf86-video-nv xf86-video-vesa xorg-x11-driver-input xorg-x11-driver-video xorg-x11-server xscreensaver-data-extra yast2-control-center yast2-control-center-qt Now in a couple of years I can see all those making use of Wayland at the lower levels of the stack, or some of them. I hope we're not running X on top of Wayland; I thought the idea was to shrink the stack. But why now? Somewhere in all that tree something calls calls on of the leyland functions: http://wayland.freedesktop.org/docs/html/chap-Library.html WHY? This isn't Wayland we're running What's really going on? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 31 Jul 2014, Anton Aylward wrote:
On 07/31/2014 02:18 PM, David Haller wrote:
On Thu, 31 Jul 2014, Anton Aylward wrote:
On 07/31/2014 11:31 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
So, right now, given that I'm not using wayland, and as you say probably won't be for some while, can I simply delete these?
You can't. unless you want a system without X or a desktop environment. Currently removing the first package triggers removal of ~400 packages.
WTF! Why? Is this a real dependency that the code has to be there, even if we're not using Wayland, or is this simply "yes another stupid packaging issue"?
It's a matter of dynamic linking. You can either link to a lib, then you'll need that lib to be installed, or you don't. [..] Same with wayland. You'll need the libwayland*, but not wayland itself and you can ignore manual deps on it if you do now want to use wayland. [..] Each of those packages contains just the one bianry and link.
rpm -ql libwayland-client0-1.2.1-1.1.x86_64 \ libwayland-cursor0-1.2.1-1.1.x86_64 \ libwayland-server0-1.2.1-1.1.x86_64 \ libwayland-egl1-10.2.4-381.1.x86_64 [..] All that is pretty vanilla., so there is nothing further down in the call tree that would cause the dependency.
You've got that backwards. There is stuff that needs those libs, because it links to it. Which, as I tried to explain, does not neccessarily mean, those libs are actually used (or even loaded from the disks rotating rust (or flash)). AFAIK ld mmap's the libs (i.e. allocates address space), but they only get actually loaded from DRR/Flash when they're used.
Therefore it must be something in those hundreds of packages that is calling
The following 349 packages are going to be REMOVED: [..]
Linked to != actually calling in use! There may be 349 packages (indirectly) linking to libwayland*, but any of them actually _using_ that interface is probably nil. Yet. I don't know Wayland. I don't see its use (yet). I'm uninformed about it. But I know how the ELF linking works. So there might be some app somewhere amongst those 349 packages, that actually uses libwayland* when you start it and do stuff, but I guess most don't. Yet. I've not really an opinion on Wayland. But guessing from history, I'll hate it. Probably with a vengeance. Not as much as systemd, I assume. That's hard^Wimpossible to exceed.
Now in a couple of years I can see all those making use of Wayland at the lower levels of the stack, or some of them. I hope we're not running X on top of Wayland; I thought the idea was to shrink the stack.
AFAIK, Wayland is supposed to replace X11. I.e. be a X12 of some sort. As systemd replace[sd] sysvinit. I haven't looked into the details yet, but I'm already rather sure I won't like them. At all.
But why now?
Prepping for the switch to Wayland would be my guess.
Somewhere in all that tree something calls calls on of the leyland functions: http://wayland.freedesktop.org/docs/html/chap-Library.html
WHY? This isn't Wayland we're running What's really going on?
http://wayland.freedesktop.org/docs/html/chap-Introduction.html#sect-Motivat... ff. I assume. BTW: I never ever used a "Compositor" ... nor KMS. What the fuck for? -dnh, as expected, now off puking, 'scuse me PS: I boot with "splash=native vga=normal"[1], no bootsplashy thingymagummmy even installed, and start WindowMaker via startx. Thankyouverymuch. PPS: has LP has anything to do with Wayland? PPPS: has _anything_ good come out of freedesktop.org yet? Besides libs they gobbled up like freetype? [1] I could have various other stuff via some fb/vesa mode, but I can't be arsed to. I used to use the Matrox-FB with some fancy mode ... -- SMTP is cute, fluffy and goes Woof! When well treated she wags her tail, licks your face and delivers your mail. When badly treated by spammers or people running exchange/<insert other pseudo-SMTP systems here>/etc she tends to bite back. -- Simon Burr -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 06:48 PM, David Haller wrote:
You've got that backwards. There is stuff that needs those libs, because it links to it. Which, as I tried to explain, does not neccessarily mean, those libs are actually used (or even loaded from the disks rotating rust (or flash)). AFAIK ld mmap's the libs (i.e. allocates address space), but they only get actually loaded from DRR/Flash when they're used.
Therefore it must be something in those hundreds of packages that is calling
The following 349 packages are going to be REMOVED: [..]
Linked to != actually calling in use!
I agree with that last line but don't think I have this backwards. Let me explain it in a different manner then. I can take the old "hello World" C program that just uses STDIO but when I package it I do two things. The first is that I tell the build process to include the un-needed libk5crypto.so.3. The second is that I tell the RPM build that the package OpenPrintingPPDs-postscript-4.0.0-21.1.2.noarch is a required dependency. Both are really irrelevant. So when zypper - or yast if you want - tried to install AntonsHello-0.1.x86_64 its going to make sure that two other packages are installed as well. But code wise, neither of them are really needed. They are an artefact of the way I defined the what was to be required. Now when, in due course, I use the CLI to run this program the link-loader will see that libc is needed (for the STDIO stuff) and also that libk5crypto.so.3 should be loaded. When the code runs I see "hello world" appear. The functions in libk5crypto.so.3 are never called. This illustrates the "Linked to != actually calling in use!" point. Next I go away and set up a build service and my own repository and make a copy of .... Oh, say DirectFB-Mesa-1.6.3-4.1.3.x86_64 I make no changes to to code, I just add to the configuration a dependency on AntonsHello-0.1.x86_64. Yes it completely irrelevant, but so what. Until recently the 'tar' package included 'rmt' because once upon a time tar was a Tape Archiver and so was always used with magnetic tape. Conversely to get the tape driver you ended up with tar whether you wanted it or not. I recall we discussed that here some years ago. I'm sure there are many idiotic and unnecessary dependencies like this. Now having illustrated the "Linked to != actually calling in use!" point lets go back to the wayland-client package and library. I checked the downstream because there were hundreds of items in the upstream. Suppose I were to pick one. It might not be a good illustration adn we start playing yes-but games, but suppose it was a "good one". I run it under the debugger and I find that there are never calls to anything in the wayland-client. So, the counter argument goes, it was there but never called because we aren't using wayland. It seems like a circular argument to me, but there was a tool I used back in the days of SunOS and the old ATT 3B machines that you could apply to a pile of source and libraries and binaries and it figured out the complete call tree of the program. It was used for documenting archaic code and figuring out if changing something would impact ... Whatever. Sort of like the Gnu 'cflow' program but could handle binaries as well as source. Applying that to my HellowWorld binary would make it clear that there were no calls to any functions in libk5crypto.so.3. So I'd love to apply it to all the programs in the 300+ packages and see it any actually did call the functions in libwayland-client0. My suspicion is that they don't. Back to the "Linked to != actually calling in use!" So why is it being linked in ?
There may be 349 packages (indirectly) linking to libwayland*, but
I suspect that there are about 300 in the "indirectly" category; after all, what zypper has returned is the flattened tree. Say there are just 49 packages that have a dependency, whether or not they have a program that links (but never calls). There is still a dependency tree at the package level.
any of them actually _using_ that interface is probably nil. Yet.
We are in agreement, but I have my reservations about the "yet" being the best way of doing things. If we have X running on top of Wayland that all we've done is slide an extra layer in at the bottom of the stack. I don't see an advantage in that. However if we have an either/or situation where there is a set of Qt libraries supporting KDE which makes use of the X server and separate set of libraries that make use of the Wayland server (and similar for GTK) and so we have a Wayland stack that better suits modern GPUs without all the overhead of the X protocols hat never gets used. As I said, LD_LIBRARY_PATH can take care of this.
I don't know Wayland. I don't see its use (yet). I'm uninformed about it. But I know how the ELF linking works. So there might be some app somewhere amongst those 349 packages, that actually uses libwayland* when you start it and do stuff, but I guess most don't. Yet. I've not really an opinion on Wayland. But guessing from history, I'll hate it. Probably with a vengeance. Not as much as systemd, I assume. That's hard^Wimpossible to exceed.
Let me put it this way. Familiarity doesn't mean its better. The automobile carburettor ended up being quite complicated with all the stuff that had been piled on the original concept to deal with starting the engine, different weather conditions resulting in different air pressure (and driving up mountains and across deserts), humidity, engine temperature, air temperature, and more. When petrol injection came along it confused many auto mechanics because it was new even though, by comparison it was simpler. I had a European car with PI and so long as I took it to a 'factory trained' guy who had migrated here it was fine. He died and a regular mechanic screwed it up. Now PI is considered the norm. Familiarity. The X protocol was a piece of academia which, for the lack of any alternative, became adopted. Perhaps modern GPUs have been driven by he needs of Microsoft, but X always had cruft that no-one used, and the way it was 'device independent' made it very complicated. I've read that Wayland can support X, but my reaction is "Why?"
Now in a couple of years I can see all those making use of Wayland at the lower levels of the stack, or some of them. I hope we're not running X on top of Wayland; I thought the idea was to shrink the stack.
AFAIK, Wayland is supposed to replace X11. I.e. be a X12 of some sort.
That would make sense if we weren't to un X on top of Wayland as I've read about. Reducing the depth of the stack, as I say, implementing Qt and GTK directly on Wayland since they are the "HLL" in which KDE and Gnome/LXDE/xfce are written, makes sense. Adding another layer to the stack doesn't.
But why now?
Prepping for the switch to Wayland would be my guess.
That doens't make sense to me.
Somewhere in all that tree something calls calls on of the leyland functions: http://wayland.freedesktop.org/docs/html/chap-Library.html
WHY? This isn't Wayland we're running What's really going on?
http://wayland.freedesktop.org/docs/html/chap-Introduction.html#sect-Motivat... ff.
I assume.
Lots of words but its a bit confused. Mind you, on the next age there's the lovely bit: X will always be relevant, in the same way Fortran compilers and VRML browsers are, but it’s time that we think about moving it out of the critical path and provide it as an optional component for legacy applications. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- The chief forms of beauty are order and symmetry and definiteness, which the mathematical sciences demonstrate in a special degree. -- Aristotle (384-322 B.C.), Metaphysics -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 11:03 AM, Cristian Rodríguez wrote:
switching to wayland is a shitload of work
So I wonder ... Is there anyone trying to implement Qt or GTK without the need for all the X-Widnwws layering? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 31/07/14 a las #4, Anton Aylward escribió:
On 07/31/2014 11:03 AM, Cristian Rodríguez wrote:
switching to wayland is a shitload of work
So I wonder ... Is there anyone trying to implement Qt or GTK without the need for all the X-Widnwws layering?
QT5 and GTK3 are well under way and working. There are already commercial products using the QT5 version. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 11:20 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
On 07/31/2014 11:03 AM, Cristian Rodríguez wrote:
switching to wayland is a shitload of work
So I wonder ... Is there anyone trying to implement Qt or GTK without the need for all the X-Widnwws layering?
QT5 and GTK3 are well under way and working. There are already commercial products using the QT5 version.
Is this like the st3, qt4 and gtk2 that we know and locae and make life easier when one wants to write applications without knowing all the ins and outs of X-Windows BUT STILL MAKES USE OF X-WINDOWS AT THE BOTTOM OF THE GRAPHICS STACK, or are these packages that allow the Gnome and KDE applications we know and love to run -- somehow -- without having X-Windows underneath gobbling space ...with a RSS of over 150M and the kwin of nearly twice that. Kconsole takes less than 1M and bash-login less than 2M, but if you run a trace of what it takes when you press a key while running a shell in Kconsole to see it echo back, its horrendous! And just think of what its taking me here with T'Bird composing this! Another has been talking about bloat as in items in /usr/local, but that just ignores the bloat of the items in /usr/lib, doesn't it? But what really counts is the bloat at the lower levels of the graphics stack, since its runtime that matters, not what's sitting there on disk waiting to be used. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 31 Jul 2014, Anton Aylward wrote:
applications we know and love to run -- somehow -- without having X-Windows underneath gobbling space ...with a RSS of over 150M and the kwin of nearly twice that.
# cat /proc/2910/status Name: X State: R (running) [..] VmRSS: 61692 kB # uptime 19:21pm up 7:06, 11 users, load average: 0.17, 0.19, 0.50 The RSS of X is _very_ dependent on what Apps do. Mapping Pixmaps makes a _big_ difference. They end up in X RSS and (I think) not in the RSS of the App (or both). Try using _one_ small tiled bitmap or just a plain colour as background and do not run Firefox/Seamonkey. They heavily map bitmaps in a way they "burden" X's memory.
Kconsole takes less than 1M and bash-login less than 2M, but if you run a trace of what it takes when you press a key while running a shell in Kconsole to see it echo back, its horrendous! And just think of what its taking me here with T'Bird composing this!
Konsole is a mem-Hog (freshly started: RSS: 21616). Xterm is too, but less so (freshly started: RSS: 5648), uxterm a bit more (RSS: 8004). BTW: $ free total used free shared buffers cached Mem: 4053224 3884260 168964 0 72356 2582980 -/+ buffers/cache: 1228924 2824300 Swap: 2092756 16652 2076104 That's with running XEmacs (Xt/Xaw3d/Athena UI), kaffeine (KDE4 App), TVBrowser (Java), Seamonkey (Gtk-App) and a dozen xterms for basically the whole of the uptime. So, I've got basically all Mem-Hog-UIs in use, but still need just over a GiB and plenty of buffers/cache ;) Well, I still run 12.1/64bit though and esp. I run WindowMaker, so kaffeine just causes the needed libs being loaded. $ ps aux | grep wm # VSZ # RSS dh 2891 0.0 0.0 13912 1352 tty2 S+ 12:16 0:00 /bin/sh /usr/bin/startx wmaker -- dh 2909 0.0 0.0 13740 684 tty2 S+ 12:16 0:00 xinit xterm wmaker -- /etc/X11/xinit/xserverrc :0 -auth /home/dh/.serverauth.2891 -nolisten tcp dh 2918 0.0 0.0 50452 904 ? Ss 12:16 0:00 /usr/bin/wmaker dh 2946 0.0 0.1 71928 6384 ? S 12:16 0:13 /usr/bin/wmaker --for-real dh 2947 0.0 0.0 36696 1728 ? SN 12:16 0:00 wmsetbg -helper -d And that's with 3 desktops with largish images as backgrounds. And all that WindowMaker consists of. FWIW, HTH, etc., -dnh -- The only "intuitive" interface is the nipple. After that, it's all learned. (Bruce Ediger, bediger@teal.csn.org, in comp.os.linux.misc, on X interfaces.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 01:41 PM, David Haller wrote:
The RSS of X is _very_ dependent on what Apps do. Mapping Pixmaps makes a _big_ difference. They end up in X RSS and (I think) not in the RSS of the App (or both). Try using _one_ small tiled bitmap or just a plain colour as background and do not run Firefox/Seamonkey. They heavily map bitmaps in a way they "burden" X's memory.
I wasn't aware that the bitmaps are kept in X as opposed to the application. That makes a big difference if, say, I use a different icon for each one of half a dozen Konsole tabs. It sounds to me like something isn't right. I see in C and know from the Perl/Tk and Ruby/Tk I've done that the application makes the reference to embedded graphics and icons. I'd think the bitmaps would be in the application address space though whether BSS or DATA I can't say. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/31/2014 10:43 AM, Anton Aylward wrote:
On 07/31/2014 11:20 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
On 07/31/2014 11:03 AM, Cristian Rodríguez wrote:
switching to wayland is a shitload of work
So I wonder ... Is there anyone trying to implement Qt or GTK without the need for all the X-Widnwws layering?
QT5 and GTK3 are well under way and working. There are already commercial products using the QT5 version.
Another has been talking about bloat as in items in /usr/local, but that just ignores the bloat of the items in /usr/lib, doesn't it? But what really counts is the bloat at the lower levels of the graphics stack, since its runtime that matters, not what's sitting there on disk waiting to be used.
Oh no, it's much better than than. We get to keep both X and Wayland for the foreseeable future as Xapplications will continue to need X, there is currently no remote rendering with Wayland, etc.. So in a sense, we are just adding Wayland compositing to what we have for now... http://wayland.freedesktop.org/ http://wayland.freedesktop.org/faq.html Seems freedesktop.org has been at the forefront of both *pain* and *progress* for Linux over the past several years. systemd, wayland, ... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/01/2014 12:50 AM, Cristian Rodríguez wrote:
El 31/07/14 a las #4, Anton Aylward escribió:
switching to wayland is a shitload of work So I wonder ... Is there anyone trying to implement Qt or GTK without
On 07/31/2014 11:03 AM, Cristian Rodríguez wrote: the need for all the X-Widnwws layering? QT5 and GTK3 are well under way and working. There are already commercial products using the QT5 version.
For what its worth Enlightenment will probably have experimental wayland support in openSUSE 13.2 and full support in 13.3 but this may well change. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Anton Aylward -
Cristian Rodríguez -
David C. Rankin -
David Haller -
Simon