Discuss June 2005

discuss@lists.centos.org

197 participants
362 discussions

Temperature monitoring tools
by William Warren 07 Jun '05

07 Jun '05

Are there any easy to use snmp(mainly temperature monitoring) tools around for Centos -4? This is on a Dell sc420 server. -- Computer House Calls, Networks, Security, Web Design: http://www.emmanuelcomputerconsulting.com What businesses are in Brunswick, Maryland? Check Brunswick First! http://www.checkbrunswickfirst.com My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD. -- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician) Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/

5 5

dragging windows leaves traces
by Robin Mordasiewicz 07 Jun '05

07 Jun '05

I have an excellent nvidia graphics card, I get excellent fps, all agp features are installed correctly etc. 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. I am having a hard time convincing people that using linux is a good idea. 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. 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. --

4 6

RE: [CentOS] Temperature monitoring tools
by Rudi Starcevic 07 Jun '05

07 Jun '05

Hi, >> Are there any easy to use snmp(mainly temperature monitoring) >> tools around for Centos -4? This is on a Dell sc420 server. I use 'lm-sensors' on the assorted servers I admin. Things like CPU temp, FAN speed, Volts etc. Works on dual CPUs nicely too. You may need to compile a kernel with support for the on-board sensor chip. Use 'sensors-detect' to find out. I think you can then use 'sensord' to rig up mrtg or something similar. HTH. Regards, Rudi. -- -- Internet Media Productions

1 0

Gnu Gadu 2
by Maciej Żenczykowski 07 Jun '05

07 Jun '05

Hi, if anyone needs Gnu Gadu 2 [Instant Messaging Program] for Centos 4, I've compiled it (some packages from dag, possibly dries) and it's up at: http://tcs.ii.uj.edu.pl/~maze/centos/gnu-gadu-2/ Cheers, MaZe.

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> 07 Jun '05

07 Jun '05

From: Robin Mordasiewicz <robin(a)bullseye.tv> > [root@zephyr config]# cat /proc/driver/nvidia/agp/status > Status: Enabled > Driver: NVIDIA > AGP Rate: 4x > Fast Writes: Enabled > SBA: Enabled > I get more than 9000FPS running glxgears so the card is doing well. Hmmm, interesting to see both Fast Writes and Side Band Addressing working. Traditionally nVidia has been very conservative. Maybe we'll see a larger performance boost yet! Is this the new 1.0-7xxx series driver? If so, which revision? > I mean by showing the window contents while dragging. As another poster said, if it's the brand new 1.0-7xxx series driver, there were reported performance issues with moving windows. Have you updated to 1.0-7664 (past buggy 1.0-7174)? [ 7664? Wow, that's a lot of builds in a short period of time! ] -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

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

← Newer
1
...
24
25
26
27
28
29
30
...
37
Older →

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 June 2005