Re: [arch-general] upgrading postfix - newaliases: error while loading libdb-5.1.so -- ignore?
On Wed, Jul 6, 2011 at 7:02 PM, Baho Utot baho-u...@columbus.rr.com wrote: On Wednesday, July 06, 2011 05:59:33 PM Paul Ezvan wrote: sudo ln -sf /usr/lib/libdb-5.2.so /usr/lib/libdb-5.1.so Please don't do that, this is a bad workaround ! Why? ... segfaults, leaks?, corruption, security ++ an unending list of random/periodic/hidden/visible/dramatic/subtle/obscure/obvious/minor/major problems, crashes, and/or lockups. soname bumps denote backwards incompatible changes at rather low levels (ABI), ie. an *intentional* break in the interface agreement between the library and any consuming binaries. it causes work downstream and is mostly avoided if possible -- developers usually have good reasons when it happens. [willful] ignorance subjects *any* binary loading the library directly, or by proxy, to a wide list of unknowns -- resultant behavior is roughly 300% unpredictable, and varies heavily by context, circumstance, whim, weather, date, mood, not to mention cosmic alignments ... ... a Bad Idea i daresay :-) C Anthony
Re: [arch-general] upgrading postfix - newaliases: error while loading libdb-5.1.so -- ignore?
On Thursday, July 07, 2011 02:36:10 AM Allan McRae wrote: On 07/07/11 10:02, Baho Utot wrote: On Wednesday, July 06, 2011 05:59:33 PM Paul Ezvan wrote: As a temporary work around, just add a link in /usr/lib from /usr/lib/libdb-5.1.so - libdb-5.2.so: 13:14 providence:~ sudo ln -sf /usr/lib/libdb-5.2.so /usr/lib/libdb-5.1.so 13:14 providence:~ sudo /etc/rc.d/postfix restart That will bring postfix back up until the package is updated. Then don't forget to remove the link later... Please don't do that, this is a bad workaround ! You should rebuild the package instead, it is very easy with ABS. Paul Why? The worst you could do is have pacman complain that the file(s) already exists in the file system. You then only have to remove it and you're good. Still the best way is to build/repackage but the link works as weel. The worst you can do while symlinking libraries is entirely screw your system... just ask the people who could not use pacman to extract .xz packages anymore after symlinking liblzma... Library sonames change for a reason. Allan In this case it would only screwup postfix. I am not talking of whole sale symlinking libs only to temporay fix issues like this while the package is being fixed.
[arch-general] The OpenCL ICD problem
Forwarding discussion to arch-general mailing list. Original Message Subject: The OpenCL ICD problem Date: Thu, 7 Jul 2011 15:48:52 +0200 From: Vojtěch Král kral.vojt...@gmail.com Hello, I'm writing to you because of a problem which has arisen with the OpenCL Arch packages. To introduce myself shortly: My name is Vojtech kralyk Kral (Czech Rep., EU) and I currently maintain AMD APP SDK (aka amdstream) and Intel OpenCL SDK in AUR. I'm sending this to maintainers who maintain involved pkgs. People that might be also interested are in Cc, please let me know should you find this mail too spammy/annoying :) The problem in question is a conflicting file, namely /usr/lib/libOpenCL.so (and possibly so version symlinks too). This file is currently provided by these packages (that I know of): nvidia-utils [extra], lib32-nvidia-utils [multilib], amdstream [AUR], intel-opencl-sdk [AUR], lib32-nvidia-utils-173xx [AUR] and lib32-nvidia-utils-beta [AUR]. The thing is this conflict should be resolved so that it would be possible to install OpenCL implementations from multiple vendors at the same time on the same system (as requested by the standard from Khronos) while still providing this so file to satistfy dependencies for other either existing pkgs (such as pyopencl) or possible funture ones. This should be done in compliance with the ICD standard, see http://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt However, it should hopefully not be that difficult, since most of the packages already comply to the standard by providing appropriate *.icd file in /etc/OpenCL/vendors. And those that don't should be updated accordingly (lib32-nvidia-utils-beta maybe? Not sure.) Also, the standard requests the ICD loader - which is in fact usually the libOpenCL.so library - to be able to enumerate all the ICDs on its own. So this so file is pretty much independent on the vendor it is supplied by, providing the vendor a) follows the standard correctly b) is sane :-) Therefore, a sollution might be to simply pick one of available ICD loaders (a thin one preferably) and make it a dependency for other pkgs. I'm not saying this is an optimal sollution, I'm merely leaving it to your consideration. Feel free to suggest other possibilities. Let me know what you think... Best Regards, Vojtech kralyk Kral
Re: [arch-general] The OpenCL ICD problem
I'm sending this to maintainers who maintain involved pkgs. People that might be also interested are in Cc, please let me know should you find this mail too spammy/annoying :) Next time please send this to the appropriate mailing list (arch-general or aur-general in most cases) and if you feel it's necessary you can still CC the maintainers. The problem in question is a conflicting file, namely /usr/lib/libOpenCL.so (and possibly so version symlinks too). This file is currently provided by these packages (that I know of): nvidia-utils [extra], lib32-nvidia-utils [multilib], multilib/lib32-nvidia-utils (275.09.07-1) : /usr/lib32/libOpenCL.so extra/nvidia-utils (275.09.07-1) : /usr/lib/libOpenCL.so There is no conflict. Therefore, a sollution might be to simply pick one of available ICD loaders (a thin one preferably) and make it a dependency for other pkgs. We only have one in our repos so there's nothing to do as far as I can tell. In case I misunderstood something, please clarify. -- Florian Pritz signature.asc Description: OpenPGP digital signature
Re: [arch-general] The OpenCL ICD problem
There is no conflict. Therefore, a sollution might be to simply pick one of available ICD loaders (a thin one preferably) and make it a dependency for other pkgs. We only have one in our repos so there's nothing to do as far as I can tell. In case I misunderstood something, please clarify. He is saying that some people might want to have both Nvidia, intel or AMD OpenCL installed, like this guy here (comment by Void-995, 4th from top) http://aur.archlinux.org/packages.php?ID=21933 -- дамјан
Re: [arch-general] The OpenCL ICD problem
I've found somebody who tried to implement his own ICD loader: https://github.com/Max-E/libclicd It was not updated for many months, and may be missing a lot of feature. It might be easier to create a package that just provides /usr/lib/libOpenCL.so taken from one of the different implementation. I suggest taking one that supports OpenCL 1.1. I think nvidia support only 1.0, while intel and amd support 1.1. As it looks, /usr/lib/libOpenCL.so does not provide much: it's just a wrapper (the ICD Loader). Intel's is 27 kB while AMD's and nvidia's are 21 kB each. Here's each one's ldd: # AMD $ ldd /opt/amdstream/lib/x86_64/libOpenCL.so.1 linux-vdso.so.1 = (0x7fffab8e7000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fa4b6d4b000) libdl.so.2 = /lib/libdl.so.2 (0x7fa4b6b47000) libc.so.6 = /lib/libc.so.6 (0x7fa4b67e5000) /lib/ld-linux-x86-64.so.2 (0x7fa4b71af000) # Nvidia (on Gentoo) ldd /usr/lib64/libOpenCL.so.1.0.0 linux-vdso.so.1 = (0x7fffa25ff000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68d4981000) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d477c000) libc.so.6 = /lib64/libc.so.6 (0x7f68d4416000) /lib64/ld-linux-x86-64.so.2 (0x7f68d4dcf000) # Intel ldd /opt/intel/opencl-sdk/usr/lib64/libOpenCL.so linux-vdso.so.1 = (0x7fff991ff000) libdl.so.2 = /lib/libdl.so.2 (0x7f198f4b9000) libnuma.so.1 = /usr/lib/libnuma.so.1 (0x7f198f2b1000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f198efa6000) libm.so.6 = /lib/libm.so.6 (0x7f198ed24000) libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7f198eb0e000) libc.so.6 = /lib/libc.so.6 (0x7f198e7ac000) /lib/ld-linux-x86-64.so.2 (0x7f198f906000) On the license side, Intel is not clear. There is an EULA here: http://software.intel.com/en-us/articles/opencl-sdk-EULA/ but it does not say anything about OpenCL... It seems to be a generic EULA from Intel's compiler. But there is an llvm licence file in the package (llvm_release_license.txt). Their compiler is probably based on it. But that's not the wrapper. AMD has a license in /opt/amdstream/docs/opencl/LICENSES but I did not had the courage to read it. Section 2 b) seems to talk about you may not [...] modify, network, rent, lend, loan, distribute or create derivative works based upon the Software in whole or in part; What's is forbidden? Modify or distribute the package or modify/distribute a derivative work? I'm just lost. I can't find a license for nvidia, but it's probably as cryptic... I think it's a good idea to have an ICD wrapper. Actually I need that for myself. Therefore, a sollution might be to simply pick one of available ICD loaders (a thin one preferably) and make it a dependency for other pkgs. We only have one in our repos so there's nothing to do as far as I can tell. In case I misunderstood something, please clarify. There might be just one right now, but OpenCL standard says many different implementation should be able to install side by side, and the choice between them is taken by the ICD loader.
Re: [arch-general] gnome2.32
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/05/2011 12:53 AM, Sergio de Almeida Lenzi wrote: for now, there is a complete gnome 2.32 working with gdm 2.18 (the old one) that have gdmsetup. libreoffice is version 3.3.3 and the pt-br package is libreoffice-pt-BR I have tested on several old notebooks and seems OK What's wrong with Gnome 3 in fallback mode? Have I missed something? - -- vic.demuzere.be :: v...@demuzere.be :: PGP: 0x5F3A08A1 My software never contains bugs, it just develops random features. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOFcbJAAoJEG+257lfOgih3rAIAIZpjdaZ37AzRz7qudCF7wGq zjEsEDZGwRmOmSZe0PD6BkQaL//1tKlJVuzfaCFjABngMyeats5HfZMjhLnoXeok 6Vj+18BXLhP4i9IEq/7YQiq8oW7knOIq7Qj9+ugxcai4mWHeLk0U+LMNGUCNnygA rqm7xDEzj9yT7sAuCEd5ajFElWYBEGM2lp0M2YgR6pqV+gXXOV3/gvl96bbqulyc HCel/erhPAKzANE07c5Os7mFO7Dx10m5/LGk+Cabc3KI6txzYEKlOZThqmTSR9Jn 020QkjuRnUWrR5szW3AuvtI09UYiu5MUfN4fsYcJnIRpVPZIR/GvT8/udIwiXnE= =7Oke -END PGP SIGNATURE-
Re: [arch-general] The OpenCL ICD problem
Thankyou Nicolas for the research, that's exactly what we need. And yes Damjan, you are right.
[arch-general] libreoffice 3.4.1-2 General Error on open and save
Guys, Since updating to libreoffice 3.4.1-2 I get a General Error on opening any document and on saving any document for the first time. (i.e. save a new document or 'save as' new name on existing documents) Libre seems to work. After closing the error dialog, the document opens and after closing the error dialog on save, the document is saved, but this gives some concern when working on critical documents. A screenshot of the error on save dialog is here: http://www.3111skyline.com/dl/arch/bugs/libre/oo-general-error-on-save.jpg Is anyone else seeing this? If so, any idea what needs to be done to fix it? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] libreoffice 3.4.1-2 General Error on open and save
On Thu, Jul 07, 2011 at 09:55:59AM -0500, David C. Rankin wrote: Guys, Since updating to libreoffice 3.4.1-2 I get a General Error on opening any document and on saving any document for the first time. (i.e. save a new document or 'save as' new name on existing documents) Libre seems to work. After closing the error dialog, the document opens and after closing the error dialog on save, the document is saved, but this gives some concern when working on critical documents. A screenshot of the error on save dialog is here: http://www.3111skyline.com/dl/arch/bugs/libre/oo-general-error-on-save.jpg Is anyone else seeing this? If so, any idea what needs to be done to fix it? I also experience this, though I simply put up with it (not having to draft any legal documents). T.
Re: [arch-general] libreoffice 3.4.1-2 General Error on open and save
On 07.07.2011 16:55, David C. Rankin wrote: Guys, Since updating to libreoffice 3.4.1-2 I get a General Error on opening any document and on saving any document for the first time. (i.e. save a new document or 'save as' new name on existing documents) Libre seems to work. After closing the error dialog, the document opens and after closing the error dialog on save, the document is saved, but this gives some concern when working on critical documents. A screenshot of the error on save dialog is here: http://www.3111skyline.com/dl/arch/bugs/libre/oo-general-error-on-save.jpg Is anyone else seeing this? If so, any idea what needs to be done to fix it? https://bugs.archlinux.org/task/25047 -- Florian Pritz signature.asc Description: OpenPGP digital signature
Re: [arch-general] The OpenCL ICD problem
2011/7/7 Nicolas Bigaouette nbigaoue...@gmail.com: I've found somebody who tried to implement his own ICD loader: https://github.com/Max-E/libclicd It was not updated for many months, and may be missing a lot of feature. It might be easier to create a package that just provides /usr/lib/libOpenCL.so taken from one of the different implementation. I suggest taking one that supports OpenCL 1.1. I think nvidia support only 1.0, while intel and amd support 1.1. Although that libclicd thingy looks outdated and/or incomplete, I like the testapps/list_platforms.c utility. It would be nice to have something like that in (a possible) wrapper ICD loader package (the /usr/lib/libOpenCL.so). AMD has a similar (more verbose) utility called 'clinfo'. I have experimentally removed the /usr/lib/libOpenCL.so file from the Intel sdk, installed it alongisde the AMD sdk and tried what these utils would output. The result looks quite nice, see http://codepad.org/NGaPsYbr ~kralyk
Re: [arch-general] The OpenCL ICD problem
Although that libclicd thingy looks outdated and/or incomplete, I like the testapps/list_platforms.c utility. It would be nice to have something like that in (a possible) wrapper ICD loader package (the /usr/lib/libOpenCL.so). AMD has a similar (more verbose) utility called 'clinfo'. I have experimentally removed the /usr/lib/libOpenCL.so file from the Intel sdk, installed it alongisde the AMD sdk and tried what these utils would output. The result looks quite nice, see http://codepad.org/NGaPsYbr I've just written such a library to print available platforms and their devices. Here's the output of it on my Q6600 cpu: https://gist.github.com/1069813 This is just a library, but a simple main() that calls its .Initialize() could print this easily. I'd wish to release that library as opensource at some point. Maybe this could be a nice time for it ;)
Re: [arch-general] upgrading postfix - newaliases: error while loading libdb-5.1.so -- ignore?
On Thu, Jul 7, 2011 at 4:34 AM, Baho Utot baho-u...@columbus.rr.com wrote: On Thursday, July 07, 2011 02:36:10 AM Allan McRae wrote: On 07/07/11 10:02, Baho Utot wrote: Still the best way is to build/repackage but the link works as weel. The worst you can do while symlinking libraries is entirely screw your system... just ask the people who could not use pacman to extract .xz packages anymore after symlinking liblzma... Library sonames change for a reason. In this case it would only screwup postfix. I am not talking of whole sale symlinking libs only to temporay fix issues like this while the package is being fixed. ... but ... why? when it takes a whole 5-10 minutes to rebuild? you have *no idea* why they bumped the soname -- the fact that it works is pure chance/luck -- whatever changed just hasn't been given the opportunity to crash 'n burn you yet, because (IIRC) said function(s) havn't been called, or said data structure(s) haven't been used/manipulated/read ... *yet*. if it does work, you could be clobbering random areas of heap/stack depending on how everything lines up in the end. ... this is bad idea, bad recommendation, pre-now, now, always, post-always ... don't do it. ever ... ever. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135 ... if you care *at all* about you mail or insert important data that is ;-) C Anthony
Re: [arch-general] The OpenCL ICD problem
On 07/07/2011 05:46 PM, Nicolas Bigaouette wrote: snip There might be just one right now, but OpenCL standard says many different implementation should be able to install side by side, and the choice between them is taken by the ICD loader. OKKK after talking with Lukas i now have an idea about what you guys talking about. Right now, what can i do is to take care about nvidia's opencl implementation and loader. What I understand from Nicolas is that we can use any loader, either form nvidia, ati, intel. It will work with any implementation. My propose is to split opencl loader and implementation out from nvidia-utils like this: libcl - containing /usr/lib/libOpenCL.so*. This can be easy replaced with an opensource loader once is available in mesa or other that is better. libcl-nvidia - depending on libcl containing /etc/OpenCL/vendors/nvidia.icd and libcuda.so and maybe nvidia module(need confirmation) for you guys: libcl-intel - depending on libcl libcl-amd - idem How does it sound for you? -- Ionuț
Re: [arch-general] The OpenCL ICD problem
On 7 July 2011 18:34, Ionut Biru ib...@archlinux.org wrote: On 07/07/2011 05:46 PM, Nicolas Bigaouette wrote: snip OKKK after talking with Lukas i now have an idea about what you guys talking about. Right now, what can i do is to take care about nvidia's opencl implementation and loader. What I understand from Nicolas is that we can use any loader, either form nvidia, ati, intel. It will work with any implementation. My propose is to split opencl loader and implementation out from nvidia-utils like this: libcl - containing /usr/lib/libOpenCL.so*. This can be easy replaced with an opensource loader once is available in mesa or other that is better. libcl-nvidia - depending on libcl containing /etc/OpenCL/vendors/nvidia.icd and libcuda.so and maybe nvidia module(need confirmation) for you guys: libcl-intel - depending on libcl libcl-amd - idem How does it sound for you? -- Ionuț I support this proposal. First I was not convinced that splitting nvidia-utils to three packages is necessary and that two packages would be enough. However OpenCL implementation is independent on OpenGL and it's possible to use multiple devices at once it actually makes sense. Lukas
Re: [arch-general] The OpenCL ICD problem
@Ionut, Lukas: I support this proposal too and I'd agree that only the libOpenCL.so (the ICD loader) needs to be split off nvidia-utils. Otherwise it could just stay intact as far as I can tell... Also, it would probably be wise to settle for dependency names once for all, by dependency names I mean what the pkgs provide - right now, all OpenCL pkgs provide both 'opencl' and 'libcl'. So following your proposal, 'libcl' could be provided by the loader, while 'opencl' could be provided by opencl implementations. Or something along those lines... @Nicolas: That looks great. If you released that as opensource, it'd probably be a better choice over the clinfo by Amd. ~kralyk Dne 7. července 2011 18:58 Lukáš Jirkovský l.jirkov...@gmail.com napsal(a): On 7 July 2011 18:34, Ionut Biru ib...@archlinux.org wrote: On 07/07/2011 05:46 PM, Nicolas Bigaouette wrote: snip OKKK after talking with Lukas i now have an idea about what you guys talking about. Right now, what can i do is to take care about nvidia's opencl implementation and loader. What I understand from Nicolas is that we can use any loader, either form nvidia, ati, intel. It will work with any implementation. My propose is to split opencl loader and implementation out from nvidia-utils like this: libcl - containing /usr/lib/libOpenCL.so*. This can be easy replaced with an opensource loader once is available in mesa or other that is better. libcl-nvidia - depending on libcl containing /etc/OpenCL/vendors/nvidia.icd and libcuda.so and maybe nvidia module(need confirmation) for you guys: libcl-intel - depending on libcl libcl-amd - idem How does it sound for you? -- Ionuț I support this proposal. First I was not convinced that splitting nvidia-utils to three packages is necessary and that two packages would be enough. However OpenCL implementation is independent on OpenGL and it's possible to use multiple devices at once it actually makes sense. Lukas
[arch-general] Introducing pacweb, another pyalpm demo
Hello, I am currently working on another toy example use of pyalpm: beside pycman, the command line utility that comes with pyalpm, I have now pacweb, a browsable Web interface to pacman. http://projects.archlinux.org/users/remy/pacweb.git/ It is not suitable for public consumption, but offers an alternative display of the pacman database. Intrepid users might run it as root, to allow performing some actions (changing package install reasons, add/remove individual packages), as well as wide opening seurity breaches on their systems. It is currently based on jinja (recently added to repos for Python 3) for templating, and steals Archweb style for the current appearance. I have also made a PKGBUILD available on the AUR. The amount of actual Python source code is very small and should be easily readable. -- Rémy. pgprCDKoIcqNl.pgp Description: PGP signature
Re: [arch-general] gnome2.32
On Jul 7, 2011 10:26 PM, Ionut Biru ib...@archlinux.org wrote: everything you said above is plain wrong. EVERYTHING go read the wiki or use gnome manuals 1) you can set up nautilus to manage your desktop (use gnome-tweak-tool if you are not skilled enough) 2) alt+right click doh, is specified all over the internet at this point, not only in the manual 3) see 1 and system settings-keyboard-shortcuts Can you please spare us and start discovering? Is not that hard to open a manual or search on google That's what I thought, but I have never used fallback mode so I don't know how usable it is. I do know some non-geek end users who actually like gnome 3 shell, though. I think it's a better idea to spend your time on improving fallback mode in gnome 3, than spending it on maintaining outdated software. -- Vic
Re: [arch-general] gnome2.32
On Thu, Jul 7, 2011 at 5:38 PM, Vic Demuzere v...@demuzere.be wrote: On Jul 7, 2011 10:26 PM, Ionut Biru ib...@archlinux.org wrote: everything you said above is plain wrong. EVERYTHING go read the wiki or use gnome manuals 1) you can set up nautilus to manage your desktop (use gnome-tweak-tool if you are not skilled enough) 2) alt+right click doh, is specified all over the internet at this point, not only in the manual 3) see 1 and system settings-keyboard-shortcuts Can you please spare us and start discovering? Is not that hard to open a manual or search on google That's what I thought, but I have never used fallback mode so I don't know how usable it is. I do know some non-geek end users who actually like gnome 3 shell, though. I think it's a better idea to spend your time on improving fallback mode in gnome 3, than spending it on maintaining outdated software. indeed. i personally find gnome3 to be incredibly intuitive to use, and minus the first week or so tweaking to my needs i am rather productive at this point -- though i'm def in power/super/awesome/better-than-you/geek-to-the-max user group, and spend most time in a term/vim/tmux/browser anyways ... ... but on that note, my partner/fiancé definitely does not. she is the embodiment of an anti-user ... an aspiring art-therapist that *hates* computers and will use paper/non-digital for everything unless external forces imposes otherwise (how we work at all together is a great mystery :-). she didn't even own a computer until college @ ~20yrs old, and prior to that had very little exposure via the minimum required at school. frankly, even the most basic UX assumptions potentially confuse her; while very intelligent, some people just don't have the expected exposure required in today's environment. ... anyways, the moral of the story is she loves gnome3 and finds it totally make sense; she had no trouble finding her way around the activities UI layout, and she does not use key-bindings at all (just click Activities or move mouse to top-left). she even says she *likes* it, which is the only time i've ever heard her speak of a computer like that in years :-) ... i think the only thing i did was reinstate the icons on her desktop, even though it can have some odd consequences. over the years i've tried compiz/gnome2/kde/xfce/.../... ie. slews of DE's and WM's, tweaked to the max, and nothing has even come close to gnome3 success with her. so, while gnome3 does have plenty to improve on, and 3.2 might be a better transition target, IMO it's done very well, and your clients deserve a chance to demonstrate just how competent they can be (even if they seem totally n00b, and believe me, i know what that is ;-) C Anthony
Re: [arch-general] gnome2.32
On Thu, Jul 7, 2011 at 10:11 PM, C Anthony Risinger anth...@xtfx.me wrote: On Thu, Jul 7, 2011 at 5:38 PM, Vic Demuzere v...@demuzere.be wrote: On Jul 7, 2011 10:26 PM, Ionut Biru ib...@archlinux.org wrote: everything you said above is plain wrong. EVERYTHING go read the wiki or use gnome manuals 1) you can set up nautilus to manage your desktop (use gnome-tweak-tool if you are not skilled enough) 2) alt+right click doh, is specified all over the internet at this point, not only in the manual 3) see 1 and system settings-keyboard-shortcuts Can you please spare us and start discovering? Is not that hard to open a manual or search on google That's what I thought, but I have never used fallback mode so I don't know how usable it is. I do know some non-geek end users who actually like gnome 3 shell, though. I think it's a better idea to spend your time on improving fallback mode in gnome 3, than spending it on maintaining outdated software. I know you are right... I must have to find a way to present a transition if ever, between gnome2 and gnome 3. My users needs an update perhaps once a year.. Meanwhile I will install again gnome3 in the test computer nvidia chipset, amd 2 cores. So I expect theat by JUN 2012, gonome3 have become more stable, and then I will start to send new notebooks with gnome3 interface... C Anthony
Re: [arch-general] gnome2.32
On Thu, Jul 7, 2011 at 8:40 PM, sergio lenzi lenzi.ser...@gmail.com wrote: On Thu, Jul 7, 2011 at 10:11 PM, C Anthony Risinger anth...@xtfx.me wrote: On Thu, Jul 7, 2011 at 5:38 PM, Vic Demuzere v...@demuzere.be wrote: On Jul 7, 2011 10:26 PM, Ionut Biru ib...@archlinux.org wrote: everything you said above is plain wrong. EVERYTHING go read the wiki or use gnome manuals 1) you can set up nautilus to manage your desktop (use gnome-tweak-tool if you are not skilled enough) 2) alt+right click doh, is specified all over the internet at this point, not only in the manual 3) see 1 and system settings-keyboard-shortcuts Can you please spare us and start discovering? Is not that hard to open a manual or search on google That's what I thought, but I have never used fallback mode so I don't know how usable it is. I do know some non-geek end users who actually like gnome 3 shell, though. I think it's a better idea to spend your time on improving fallback mode in gnome 3, than spending it on maintaining outdated software. I know you are right... I must have to find a way to present a transition if ever, between gnome2 and gnome 3. My users needs an update perhaps once a year.. Meanwhile I will install again gnome3 in the test computer nvidia chipset, amd 2 cores. So I expect theat by JUN 2012, gonome3 have become more stable, and then I will start to send new notebooks with gnome3 interface... C Anthony 8-| did I just read that you're shipping snapshots of archlinux to users and plan on updating them next year??? archlinux may not be the distro for you...
