Discuss

discuss@lists.centos.org

1 participants
34753 discussions

yum setup help and extra repos including centosplus
by Robert Hanson 06 Jun '05

06 Jun '05

greetings recently i asked a question and i was directed to the possibility that a certain fully enabled compiled kernel for CentOS 4 might help me. so, i am looking at http://ftp.osuosl.org/pub/centos/4/centosplus/Readme.txt and wondering how to cover all bases.... can i cover all bases if i put an *blanket* package(s) exclude in /etc/yum.conf ? or do i have to put package(s) exclude in every config file in the /etc/yum.repos.d/ directory ? specifically, the CentOS-Base.repo file. do i put it at the top and then it will be in effect for all sub-repos in that file?? at the top of the CentOS-Base.repo only? :) i realize that i can do it as a command line switch yet then my brains will fall out trying to remember everything. regards and tia for any clarification. - rh

3 4

rpmbuild and stripping libraries
by Maciej Żenczykowski 06 Jun '05

06 Jun '05

Hi, I've just completed a rebuild of php and the rpms came out a _lot_ bigger than the originals... after comparisons it seems stuff isn't being stripped, a comparison of sections on one library reveals the following: > 21 .gnu_debuglink < 21 .comment < 22 .debug_aranges < 23 .debug_pubnames < 24 .debug_info < 25 .debug_abbrev < 26 .debug_line < 27 .debug_frame < 28 .debug_str < 29 .debug_ranges < tons of symbols I'm sure someone knows how to get a normal small build? Pointers? Cheers, MaZe. PS. I used rpmbuild --rebuild php.src.rpm

2 2

PHP mcrypt
by Maciej Żenczykowski 06 Jun '05

06 Jun '05

Hi, Could someone tell me how I'd go about compiling php with mcrypt support from src.rpm? ie. configure -with-mcrypt[=DIR] Is it just a matter of calling rpmbuild --rebuild src.rpm --with=mcrypt ? Cheers, MaZe.

4 7

Grisbi 0.5.7
by Aph 06 Jun '05

06 Jun '05

Grisbi is a personnal accounting application released under the GPL licence. Grisbi RPMS version 0.5.7 for CentOS are now available on our download page http://www.grisbi.org/download.en.html#centos. Regards. -- Ce que je comprends pas, c'est pourquoi leurs votes compte plus ? Et surtout, ca leur rapporte QUOI ???? Putain faut vraiment être CON, grave. -+- A in GNU - La Cabale, c'est plus FORT que toi ! -+-

2 1

Re: dragging windows leaves traces -- running older GeForce drivers on newer cards
by Bryan J. Smith <b.j.smith＠ieee.org> 06 Jun '05

06 Jun '05

From: Robin Mordasiewicz <robin(a)bullseye.tv> > I have an excellent nvidia graphics card, I get excellent fps, all agp > features are installed correctly etc. In Windows or Linux? And by "all agp features are installed correctly," what do you mean and how are you getting this? > When I drag windows around wit hthe opaque settings on it leaves traces > for a couple milliseconds as it redraws the window, but it just looks so > crummy to see. Hmmm, sounds like a window manager/environment issue, unless you're having a video card issue (see below). What is your desktop environment? > I am having a hard time convincing people that using linux is a good idea. Umm, what Windows version offers translucent settings comparable to Linux desktops? None that I know of. And by "opaque," do you mean translucent/ "see through" is turned on, but set to 0%? If so, that's still transcluent. No shipping Windows or Linux distribution I know of uses video card framebuffer to off-load such complex rendering. It's done 100% in software, hence why Microsoft doesn't bother to offer it, and Linux desktops are slow at it. The only major OS I know of that ships using OpenGL to manage window framebuffer directly in video framebuffer is MacOS X via "QuartzExtreme." Microsoft was adding this capability to NT6.0 "Longhorn" in its new, Avalon desktop, but the development has been pushed back and out of NT6.0 "Longhorn" client. To put a "good face" on this, Microsoft is still releasing NT6.0 "Longhorn" client with this next generation Windows Graphics Foundation (WGF), but only version 1.0 which uses existing DirectX 9 code. In a nutshell, DirectX 9 still doesn't have the full geometry setup of OpenGL, which makes it far, far less capable of what QuartzExtreme is capable of with age-old OpenGL 1.2+. WGF 2.0, which incorporates many new features to address these deficiencies (in a nutshell, what was DirectX 10) will ship at a latter date and supposedly address WGF 1.0's shortcomings (I'll believe it when I see it -- there's still a lot of legacy GDI issues to overcome). For more on this, see my PC_Support post here: http://lists.leap-cf.org/pipermail/pc_support/2005-May/000333.html Now in the Linux world, The FreeDesktop.org "Cario" project (not to be confused with the original NT4.0 release codename) adds many things, including direct window-to-video framebuffer via OpenGL over X11 (GLX). It iss being adopted by a number of desktop suites, including Enlightment R17 as well as GNOME 3. A few window managers already implement it, or their own solution. Sun's LookingGlass desktop actually uses a non-X11 system (and quite a number of other, innovative APIs -- including 3D _input_ as _standard_), but offers X11/GLX for compatibility (and, thus, should support "Cario" interfaces as well). But until these features ship as standard in either Windows or Linux distros (think Fedora Core 5 / RHEL 5 / CentOS 5 time-frame ;-), don't expect good performance with opaque desktops where the software is doing really slow and ugly memory maps to/from the video card, over the system interconnect, etc... I.e., don't blame Linux for attempting to implement a feature in software that Microsoft won't care attempt because it has the same issues. ;-> > People make judgements on this type of thing and they think that > linux is slow compared to Windows. > When I had windows installed on this same machine dragging > windows around did not produce any traces. When you say opaque, do you mean translucent but 0% in Linux? Sometimes people enable this feature not realizing that you're adding a massive amount of overhead to the software framebuffer of the window manager. > Using linux on the desktop looks like a throwback to windows 95 on a 486. > Does anyone have any advice on how to make X redraw windows better. Turn off any translucent features, period. You don't want them enabled. From: Sukru TIKVES <sukru(a)cs.hacettepe.edu.tr> > Are you using the x.org driver (nv) or the nvidia one? I'm going to guess the former, or possibly an earlier version of the latter. Unless he has some translucent settings enabled. It would be nice to know what is exactly enabled. From: Robin Mordasiewicz <robin(a)bullseye.tv> > I am using the nvidia driver, with XFree86 centos3.4 > Moving windows is mostly smooth, not all applications leave traces as X > redraws, but I have a dual 3gig machine with a top nvidia card. > Also when resizing windows it seems to redraw much slower than windows. What exact video card on what exact nVidia driver release? Although nVidia has maintained a level of upward compatibility since the original NV0x series (Riva TNT/TNT2) up to the latest NV4x (GeForce 6000 series), if you load an older driver that was never designed for the latest series, you will get similiar symtopms. Example 1: NV2x/NV30-era XFree86 (FC1) with NV40 card Last summer I had upgraded another system, a dual Athlon MP2400+, from a GeForce4 Ti4200 (NV25) to a GeForce 6800GT (NV40). Running Fedora Core 1 at the time, I was using a similar XFree86 release as RHEL/CentOS 3. That version includes only NV2x (GeForce3/4Ti) and early NV30 (GeForce FX5800) era support . I got the same results until I upgraded to the nVidia driver. Example 2: NV1x-era Windows XP with NV40 card Just this past April, I loaded _Windows_XP on a brand new Athlon64 3200+ system with a GeForce 6800GT (NV40) card. XP detected a GeForce compatible card and loaded the driver from when the NV1x series was current (GeForce2 era). I experienced the _exact_same_ issues in XP until I grabbed the latest WHQL driver for XP. Example 3: NV4x-era Xorg (FC3) with NV40 card Now on the _very_same_system_, I loaded Fedora Core 3 AMD64 which includes a newer Xorg release with not only NV40 (GeForce 6800), but even some NV41/43 (GeForce 6200/6600) and the latest NV45 (GeForce 6800, PCIe native). So I didn't have an issue even using the stock Xorg driver. So, are you sure you are using the nVidia driver _downloaded_ from nVidia? Or are you simply using the nVidia (nv) driver CentOS 3 is detecting when installed? I want to say, given your symptomps, you're using the later, which (even with update 4) is still a NV2x/NV30 driver, and not good for later NV31/34 (GeForce FX5200/5500) let alone NV4x (GeForce 6000 series) cards. And if you are using the nVidia driver, please note that you want to be running with the _latest_ 1.0-6xxx series driver (avoid the new 1.0-7xxx series driver until it matures). The 1.0-6xxx series driver is required for NV40 (GeForce 6800 series), and latter versions for NV41/43/NV45. From: Sukru TIKVES <sukru(a)cs.hacettepe.edu.tr> > As far as I know there are significant speed improvements between xorg > and XFree86 servers, but I may be wrong. The Xorg and XFree86 releases are pretty tandem. What most Red Hat users may assume is that because the last XFree86 in any Red Hat release (FC1/RHEL3) was from the NV2x/NV30 era, Xorg was added when the nv driver added NV3x/NV40 support (FC2+). XFree86 has matched those updates, but they just aren't in any newer releases in any Red Hat distro. > I guess CentOS is not suited for desktop machines, you may try your > chance with the upcoming FC4 release. (No, i am not talking about > workstations). Nope, that shouldn't be a factor. > [ Btw, my machine was Athlon XP 2800+ with GeForce FX 5200. Linux > install was smooth as in Windows 95 smooth on a P4. ] The GeForce FX5200 is the NV34 (or NV31?, I think that was the FX5900 or FX5700 -- the higher designation is not necessary faster, just newer, and can be actually an economy design). Anything Fedora Core 2+ (including CentOS 4) should support it, or possibly late Fedora Core 1 (and CentOS 3) with the final XFree86 updates. <TANGENT> BTW, I know people get into the big "proprietary" debate on nVidia. Just some facts to know of: 1) nVidia released the source code back in the XFree86 3.3.x days 2) Intel, Microsoft and other 3rd parties who owned IP in that release were not amused, and even though nVidia obfusciated the identifiers and structure of the C code, people started "cleaning it up" and exposing what Intel, Microsoft and others did not want. 3) XFree86 4.0 is MIT licensed introduced a modular design that supports closed source drivers, which nVidia and Matrox quickly took advanatge of. 4) It was at that time nVidia decided to "unify" it's entire NV0x on-ward driver model (Riva TNT and GeForce on-ward, but not earlier, pre-NV0x Riva/128). This has driven all their other decisions. 5) As part of the unified driver and its AGPgart and memory functions, nVidia was contractually forbidden to release it GPL -- by Intel itself. Intel considered AGP a "trade secret" implementation of PCI (AGP is _not_ a PCI Standards Group standard), hence why nVidia's AGP implementation and specifications were only in their closed video driver (not even the nForce -- it only worked for nForce+GeForce). The Intel AGPgart in the kernel is largely a clean-room design (and rather limited). NOTE: #5 is going away as with the release of PCI-Express by the PCI SG (an actual, open standard), Intel no longer considers AGP a "trade secret" and has freed up some of nVidia's obligations. There is already AGPgart code for nVidia chipsets in newer kernels, so you don't have to have a GeForce on a nForce chipset. 6) nVidia puts more developers on the MIT-licensed XFree86/Xorg drivers than anyone else. nVidia is completely open with its 2D drivers and specifications, including video-in/video-out and other scan converters. In a nutshell, the 2D MIT (nv) driver is very, very good as long as recent for the latest card support, because nVidia supports it. Of course, older releases with newer cards will always be a performance issue, and system-specific implementations (such as the Go Mobile series in notebooks) will definitely lack compatibility. The nVidia-licensed "nvidia" driver is a unifed 2D/3D with complete OpenGL-standards, ARB extensions as well as a few nVidia extension (this is far, far less common in the OpenGL world). The OpenGL on X11 (GLX) implementation is unmatched and without it, Linux would have not been so widely adopted as the primary visual workstation in the CAM and EDA world over the last 5-7 years (only as a back-end solution). If you just need 2D, you don't need the "nvidia" driver, not even for TV scan conversion. But the 3D version at least gives you an "open standard" platform, meaning you write applications to an "open standard" that does not require nVidia hardware. nVidia drivers continue to be trusted, based on open standard GLX performance and reliability. I see a few people complaining about the new 1.0-7xxx series of drivers, but that's not unexpected because it's a brand new driver release with OpenGL 2.0 and some major changes in how it handles VESA defaults (it's a bit more conservative, which is breaking things that used to be autodetected). 7) ATI tried to "go clean-room 3D" with its indirect support of UtahGLX and Direct Rendering Infrastructure (DRI) and releasing of the R100 series (Radeon 7500-8000) and R200 (Radeon 8500-9000) series. These 3D implementations were add-ons to the stock MIT drivers. Unfortunately, the lag time between release and lack of variant endless support (e.g., RV280/Radeon 9200, etc...) often caused major headaches and issues -- let alone performance sucked. Worse yet was the fact that nVidia had established itself as _the_ video card/ driver combo for production GLX. So as of the R300 (Radeon 9500+) series, ATI has _withheld_ 3D specifications. In reality, ATI has always withheld not only some 3D, but even 2D interfaces. This is largely because ATI has some really advanced 2D image encoding and other logic in their GPUs that are partially driven by software/algorithms licensed from a 3rd party (whereas nVidia largely off-chipsets much of its capabilities, or uses commodity approaches/algorithms that it has no issues documenting). Although some of the UtahGLX/DRI code still works for R300+ series cards, they are now severely lagging. Which means ATI now offers a "closed source" unified driver as well. 8) My final comments The reality is that video card products are _obsoleted_ within 12 months. GPUs double in performance 2-3 times faster than CPUs, which means driver development goes hand-in-hand with engineering development _pre-release_. In other words, we can dream of a day where there is no cutting-edge intellectual property in GPUs so vendors can release drivers as GPL, and not have to hack kernel interfaces because of 3rd party NDA obligations. But the idea that video card drivers can be community developed means that their drivers wouldn't be released until the GPU is already 1-2 generations behind. This is the reality of the product. Now, luckily, OpenGL/GLX are "open standards," and most vendor extensions are submitted and formalized by an architectural review board. This is very different than the DirectX world where "features" are often vendor-only extensions, and not always standardized in the API -- which is largely a wrapper to required, physical and often eccentric GPU functions until almost commodity 3-4+ generations behind and all video cards have them. This is why many applications in Windows require specific video cards, and not even after 2-3 generations the titles will run (if ever). So by supporting the OpenGL/GLX "open standards," even if you are running a proprietary, closed source driver to run your OpenGL/GLX application, it means you will be able to run it in the future on another video card. Even if the ARB extensions utilized and only supported by 1-2 "cutting edge" video cards (namely ATI and nVidia), they are typically supported by other cards within 1-2 generations by the very nature of how the OpenGL ARB works. </TANGENT> -- Bryan J. Smith mailto:b.j.smith@ieee.org

5 6

Re: [CentOS] Re: dragging windows leaves traces -- running older GeForce drivers on newer cards
by Bryan J. Smith <b.j.smith＠ieee.org> 06 Jun '05

06 Jun '05

From: "Hilliard, Jay" <Jay.Hilliard(a)disney.com> > We've had lots of trouble with nvidia's driver version 1.0-7174 which > was current last week. Yep, it's the first of a new series (7000 -- sounds like it'll support NV5x out-of-the-box), so that's expected. > Today there is a new driver (1.0-7664) which has fixed lots of issues > for us, specifically openGL applications and problems when dragging > windows around. Yep. They probably spent so much time testing OpenGL 2.0 that they missed some OpenGL 1.x compatibiltiy testing that end-user quickly found. At least they addressed it in short-order. -- Bryan P.S. I know there weren't any complaint about nVidia being "proprietary" on this list, but several people on the Fedora lists snickered about it not been open source as the problem. The reality is that if it was community developed, it would probably be available in another 6-12 months (much like ATI's prior UtahGLX/DRI endeavors were for newer cards). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: dragging windows leaves traces -- running older GeForce drivers on newer cards
by Bryan J. Smith <b.j.smith＠ieee.org> 06 Jun '05

06 Jun '05

From: Robin Mordasiewicz <robin(a)bullseye.tv> > Is it possible that some windowing libraries are responsible for slow > re-drawing. Re-sizing firefox seems slow, but resizing any native kde > application is quick. > resizing adobe acrobat reader is amazing slow, and moving the window > around the screen leaves a tracing streak. Ah-ha! Now that's some info that might provide a lead. Are you using KDE as your desktop? If so, it is Qt widget library based. Firefox is GTK+-based, and Acrobat is statically linked to Motif. If you can give more examples, maybe we can confirm this. Qt/KDE is built with some optional X11 (RENDER?) extensions which don't play nice with non-Qt apps (Xt, Xaw, GTK+, Motif, etc...). Didn't know this was the case on CentOS, or maybe it's some other configuration? I use GTK+/GNOME (gdm/nautilus/metacity session/file/window manager). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: dragging windows leaves traces -- running older GeForce drivers on newer cards
by Bryan J. Smith <b.j.smith＠ieee.org> 06 Jun '05

06 Jun '05

From: Sukru TIKVES <sukru(a)cs.hacettepe.edu.tr> > Looks like I've complete misunderstood the issue. > Actually I've never thought it would still be problem. > I usually feel no difference between windows and linux. Correct. But in select operations, you are seeing this. That could be an application-specific setting, including the Window Manager which includes a number of applications. It's using a very slow, software-based set of buffers/overlays as you move the windows. Or it could be that application is attempting to use functions that implemented differently on newer GeForce cards than the driver which was designed for an older release. It's just hard to tell without seeing it or getting more, exact information. > Nevertheless as others mentioned it may be a window manager > (metacity is famed as "slow") or a Gtk2 issue (Gtk2 is getting > faster with each release aster 2.0). I've never had an issue myself, and I've been running with nVidia cards with both the MIT XFree86/Xorg "nv" and nVidia "nvidia" since first-generation NV0x Riva TNT/GeForce series on every GNOME 1.2+ through the latest 2.x revisions. I think either a setting is enabled, something Linux supports, but typically via software with a massive performance hit (much like what will happen with Avalon/WGF1.0 in the initial NT6.0 "Longhorn" release ;-), or you have a driver that is not current for your card and using functions that are deprecated or requires newer options. > Sorry for the irrelevant comments. I don't think they were irrelevant. At this point, the door is still very open on what the cause is. Again, it sounds like either an app setting or an app X11 call/ extension that the driver doesn't do well because it's dated. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: dragging windows leaves traces -- running older GeForce drivers on newer cards
by Bryan J. Smith <b.j.smith＠ieee.org> 06 Jun '05

06 Jun '05

From: Sukru TIKVES <sukru(a)cs.hacettepe.edu.tr> > NVidia has its own desktop utility for Windows. It works fine. It also > has a "keystone" function which allows you transform (stretch, skew, > resize, etc) your "entire desktop" freely. Actually, there is a GUI management program in the nVidia driver suite. Unfortunately, by the way X works, some of these things the Win32 GDI allows is not always possible in X, for a variety of reasons. > There is a new X extension called RENDER. It comes disabled with xorg > server, however once you enable the extension and install necessary user > level tools, you'll have hardware accelerated (ie: true) transparent > windows. Unfortunately, it's a hack. It uses unused video memory as a faster, local store than main memory, but still doesn't address the reality that you should be using your GPU functions instead of memory tricks. I.e., a window is simply a set of vectors and/or bitmaps on a plane. It doesn't matter if it looks like 3D to a user, or is perfectly perpendiular and appears to be 2D (but is still using 3D in the GPU, even if no Z buffer). >From simple concepts to the Xgl server to FreeDesktop Cario which brings full aliasing, vector graphics on planes as well as traditional bitmaps on planes, it is the X11/GLX's equivalent to QuartzExtreme. IMHO, I think Sun's got the right idea. Go 3D everything, solve the inconsistency, hacks upon hacks and overall inefficiency of layers upon layers with Looking Glass. What really sold me that Sun is "thinking ahead" is that even the input is 3D. The "technology demo" of Looking Glass doesn't do their innovative approach an ounce of justice. It's not eye candy, it's efficiency. > See my previous post. I've tried the setup on a gentoo installation > and it works very well. On nVidia cards with the nVidia driver, but that's about all right now. It largely has to do with the fact that nVidia driver has that proprietary memory management module in the kernel that is tied to the X11/GLX driver/libraries. nVidia knows what it's doing, because they solved the problem 5+ years ago. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

When is the next CentOS release?
by Sukru TIKVES 06 Jun '05

06 Jun '05

Hello all, There are significant kernel defects in CentOS 4 which affects our servers. Our most serious bug is mentioned in http://bugs.centos.org/view.php?id=870 however it says: "Some of these kernel issues are known to have been fixed upstream and should make the 4.1 Release ( due soon now )" How soon is the release of the CentOS 4.1 version? -- sukru

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss