WSANDERS.NET

Nvidia, KDE, and Xorg Gamma settings: The Three Stooges

wsanders — Sun, 15 Apr 2012 18:51:50 GMT

Wondering why your display is always looking funny? Different displays need different gamma settings and color correction. My cheapo LG E2241 (non IPS) display is very twitchy about display settings - if it's not exactly right it looks like crap. So I was wondering why each time I calibrated the screen the settings seemed to look bad again the next day. My gammas have to be adjusted substantially fo the cheapo LG display, to something like 0.65.

Oh yeah, this is the legacy computer from heck: ancient generic whitebox with ancient nVidia GeForce2 MX 400, CentOS, KDE, and the above 1920x1080 pixel which is kind of pushing the MX400 as far as it was designed to go. (I do have the current nVidia legacy driver installed, which they graciously still support.)

Now the fun starts: There are three different places where display gamma gets set in CentOS + KDE. First, on X startup, /etc/X11/Xorg.conf gets read. This sets up the settings for the login screen only, so just leave this alone unless the gamma is intolerably bad.

That in turn will be overridden by KDE, which appears to run the "xgamma" command to source in gammas it finds in ~/.kde/share/config/kgammarc. This file is updated by the Monitor Gamma tab in the KDE Display Setting widget.

This is turn is overridden only when you happen to run the utility nVidia provides with the driver, /usr/bin/nvidia-settings, which is invoked by the nVidia driver settings widget that gets installed in the KDE System menu. This utility stores its gamma settings in ~/.nvidia-settings-rc.

So to keep these three stooges of apps from messing up your settings:

- Remove the nVidia driver utility from the KDE menu so you are never tempted to run it, and delete the .nvidia-settings-rc file. The settings aren't used unless you run the nvidia-setting utility.

- Use only the the Monitor Gamma tab in the KDE Display Setting widget to set gammas / color correction.

- If you want to make the login screen look nice, edit /etc/X11/xorg.conf.

- You could "lock in" the values by running either xgamma or nvidia-settings from your .bashrc file. Or both, if you are not easilty confused.

And don't forget - with LCDs, "brightness" is really "contrast" and vice versa. http://www.poynton.com/notes/brightness_and_contrast/ has a pretty good sum-up of that.

Fonts still suck

wsanders — Sun, 08 Jan 2012 19:25:42 GMT

I am still in font hell since my screen res changed from 95 to 101 DPI. On my box there are four separate font rendering systems:
- "Classic" X fonts, those which would use XFS if I was running XFS. These are ancient X apps like xterm, etc.
- KDE, which uses Xft.
- Mozilla / Firefox
- OpenOffice

All these use four different DPI and antialiasing settings:
- No antialiasing at all in the case of classic bitmapped X fonts
- KDE allows you to control the Xft antialiasing setting via Control Center abd DPI via /etc/X11/Xresources
- Mozilla does its own thing, which looks like crap.
- Openoffice does its own thing, which looks even crappier.

Setting "Xft.dpi: 100" in Xresources helped the most. At 96 (the old default DPI) and 101 (as the video driver calculatea the DPI) some kind of rounding error caused all kinds of problem with kerning, 0's looking like O's, etc. I think I've just about straightened it out.

I'll just bring shame on us all by saying, "Microsoft figured this out years ago."

New Monitor, Old Eyes, Linux Fonts

wsanders — Thu, 05 Jan 2012 17:48:24 GMT

The venerable 1280x1024 flat panel I've had for 11 years finally died on Sunday night so I had to run out to Best Buy and settle for what they had in stock. I settled for an LG FLatiron E2241 (21.5", 1900x1080, 100dpi) for now (the IPS panels were way too expensive), which is your basic consumer model. It's still a TN panel, and the gamma is quite nonlinear, so my photos look like crap, but it's fine for office use.

The increase from 95 to 100 dpi makes quite a difference (I probably should have bought the 23-inch model; same price). Either:

- Linux fonts still suck
- My eyes are getting old

Which is true? I vote for a combination theory - Linux fonts are developed by young whippersnappers with perfect vision. We need more geezers designing fonts.

Funniest Slashdot comment ever, regarding announcement of Debian release of Hurd:

wsanders — Thu, 14 Jul 2011 23:28:25 GMT

BSD userland on top of GNU Hurd.

"What the hell do you call an OS like that?"

"I'll call it 'The Aristocrats'"

Good GNUPLOT Intro

wsanders — Sat, 18 Jun 2011 20:54:02 GMT

The Gnuplot docs are not very well organized for beginners (hey, I know what a sine wave looks like. What if a have a big file of disorganized, real-world data, with missing data points?) Here's a good guide:

http://t16web.lanl.gov/Kawano/gnuplot/index-e.html

I'm still trying to figure out how to load only lines N through M of a data file.....

Launching Ganglia Daemons at Mac OSX Bootup

wsanders — Wed, 15 Jun 2011 00:10:39 GMT

The daemon launch process at http://www.deanspot.org/comment/reply/261 says "could use some help here", so here's how I did it:

I never got gmond and gmetad to start under launchctl as background daemons at boot, gmetad would die after a while and gmond would go nuts and respawn over and over until the machine was unusable. Running in the foreground works, this is how to set it up:

OSX 10.6.7, ganglia built in /opt/local from sources, rest of dependencies from Ports, daemons are in /opt/local/sbin, using OSX's Apache and PHP:

- Create two files in /Library/LaunchDaemons:

org.ganglia.gmetad.plist:

"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >

Labelorg.ganglia.gmetad
ProgramArguments

/opt/local/sbin/gmetad
-d
1

RunAtLoad

org.ganglia.gmond.plist

"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >

Labelorg.ganglia.gmond
ProgramArguments

/opt/local/sbin/gmond
-d
1

RunAtLoad

- Incorporate them into launchctl's config:

sudo launchctl load -w /Library/LaunchDaemons/org.ganglia.gmond.plist

sudo launchctl load -w /Library/LaunchDaemons/org.ganglia.gmetad.plist

- Reboot to test. You should see

54 - org.ganglia.gmond
55 - org.ganglia.gmetad

in the output of "sudo launchctl list", the first column is the PID which you will see in the output of ps. Output goes into the system log.

Saving Battery on an iPhone4

wsanders — Tue, 22 Feb 2011 02:50:47 GMT

I have a new iPhone 4 with Verizon service. It is, like, TOTALLY FREAKING AWESOME kind of. Since I had a Sprint HTC Evo in my previous job, I can compare firsthand.

Like the EVO, I first got only about 8 hrs standby time with location services ON and push ON. So:

1) Disable location services for all apps, or at least until the GPS arrow disappears from the top bar. Just like on all phones, GPS is a huge battery suck, and it won't work indoors anyway. Particularly, with Navigation - The Google Nav app that comes free with the Evo is considerably more awesome than anything available for the iPhone, but I could barely drive to the grocery store without using a car charger.

2) Disable Push if you can. Disabling Push globally still allowed my Exchange account to push (Push for Inbox is the default); I had to change that to "fetch" separately in the Push "Advanced" settings.

3) Disable Wifi if you can. Wifi isn't as big a battery suck as on the HTC Evo, though.

3) In spite of what the fanboys say, it's still possible for a badly behaved app to suck battery in the background. Try not to download dodgy apps, and worst case it's probably faster to just reboot your phone than kill off the apps one by one in the recently used view.

Once I found out it was Google Latitude background location updating that was sucking my battery dry in a day, I disabled that and now can get 2, maybe more, days battery life with location services ON, Wifi ON, and Bluetooth ON. I could *not* do that on the HTV Evo.

Would be nice to disable GPS entirely and rely on passive Wifi/Cell triangulation, but application whack-a-mole type tools, like on the Droid, don't seem to be necessary. Steve just wants you to quit fiddling, shut up, and enjoy your wonderful phone. So, compared to the Evo, I *do* like the iPhone 4 more.

The Juniper EX Debacle

wsanders — Tue, 12 Oct 2010 17:24:10 GMT

I had a job interview a couple days ago and the subject of Juniper EX series switches came up. Basically the interviewer had some EX devices gathering dust in a closet, having found them unreliable.

I'd say he was being a tad harsh, but then he needed a super-high-availability environment instead of a garden variety corporate LAN, and so his judgment was appropriate. In retrospect:

- Stacking devices into a virtual chassis is overrated. The EX virtual chassis is still buggy, and will probably be buggy forever. This is actually true of every manufacturer. Everyone's stacking is buggy.

- Instead, standalone boxes, with bog standard routing or trunking between them, will work just fine, and the relatively low cost of Juniper's 10Gb optics can make up for the lack of a 64Gb VC backplane interconnect.

- Juniper tech support is mediocre. They possess a gatekeeper mentality, and don't have much authority to fix your problem. Open a P1 support case, and tech support will try to convince you to reduce the priority. Stand firm - if you have a down building, open a P1 case and insist that asses be kicked until you have a point patch in hand to fix your bug.

- Avoid calling tech support by keeping your configs simple and your protocols standard.

On to New Projects

wsanders — Mon, 04 Oct 2010 17:35:54 GMT

Some things that interest me right now:

- Cisco IOS to Juniper JunOS transitions - why put up with a 100Mbit network when you can get all-gigabit (and more) for the same price? Plus, learning JunOS is really easy.

- Enterprise email: Cyrus IMAP is OK, but if your users can't (or won't) set up Thunderbird themselves, insist on a web interface, and you aren't able to outsource to GMail, there is no better enterprise MTA+MUA I have found than Stalker Software's CommuniGate Pro. Forget about Exchange.

- Virtualization / consolidation / storage: These three, which are all part of the same thing, should make it easier, not harder, to roll out new services, but you need to drink the whole pitcher of virtualization kool-aid, not just a cup here and there, for it to be really game-changingly useful.

- Tape backup: It's OK for some situations, but this is what your Grandpa used for disaster recovery. See "virtualization kool-aid".

- 3rd Party Bloatware: If you just bought Remedy, Weblogic, eHealth, Netbackup, or some such 3rd party bloatware, and it doesn't work, then ask for your money back, and spend your refund check to hire *us* instead.

- Building out a data center? I am an infrastructure guru. Measure twice, cut once. Including the BTU calculations.

- Finally, monitor everything and anything with Nagios, MRTG, and/or Cacti. Why spend tens of thousands to install and license proprietary 3rd party monitoring software, then tens of thousands more for their consultants to come in and set it up for you, when you can do the same thing for only the cost of the expert assistance?

Amanda Remodel: Down the Bare Studs, and Goodbye Zmanda For Now

wsanders — Thu, 16 Sep 2010 21:08:45 GMT

We're just going to have to rip out Zmanda and start over. When we installed Zmanda 3.0.2 last year, it was buggy, and used Amanda 3.0.0 as the backend, which was even more not ready for prime anything. It was pretty much hopeless, especially on Solaris 10 (which we must have because of ZFS.) Even "amtapetype" didn't work. Zmanda thus set our splitsize to 100MB, so the backups span tens of thousands of files on each tape. Because of a tape positioning bug that Amanda and Solaris point at each other having to do with the "fsf after filemark" property, and that Amanda seems to need to assemble nearly an entire media's worth of data in /tmp, our backups are all useless. Well, we never really made it out of the testing phase and our primary backup is to save a few month's backups in ZFS snapshots.

I'm just going to have to rip it out and start all over. Because Zmanda uses a massively tweaked version of Amanda, I think I am just going to blow off Zmanda entirely. Sorry, guys, it was a nice idea, to commericialize Amanda, but Zmanda required just as much tweaking as Amanda, and required fairly comprehensive knowledge of Amanda internals to get working, so, now that I know Amanda better, why should I bother? Zmanda does have Windows, MySQL, etc clients, but we don't need 'em. It will back up to a cloud, but cloud backup isn't cheap. (Or I should say it has "recurring costs", which tend to not recur around here.)