I have now converted to the ubuntu religion.
One of my recent adventures concerned fitting a gigantic screen (1920x1200, 24 inch) monitor to my home workstation - a small box with a 915 Intel built-in chipset.
It didn't work.
Somehow, it insisted on coming up in 1600x1200 mode, giving everything a "stretched" appearance. On my usual solution (googling), I came up with a lot of tricks involving "915resolution", a tool for tweaking this graphics card.
Didn't work either.
More reading.... someone mentions a "new driver". Can I use this? YES!
Solution:
sudo apt-get install xserver-xorg-video-intel
sudo dpkg-reconfigure xserver-xorg
answer default to *everything*, but enable 1920x1200 explicitly.
Voila! Now it works!
Lesson for the day:
There's tons of Linux documentation out there. Most of it is not up-to-date.
Monday, December 31, 2007
Wednesday, October 24, 2007
IETF meeting in July 2007
Very belatedly, I got out my notes from the July 2007 IETF meeting in Chicago.
Even more belatedly, I got around to mentioning them here.
http://www.alvestrand.no/reiser/ietf-july2007.html
Even more belatedly, I got around to mentioning them here.
http://www.alvestrand.no/reiser/ietf-july2007.html
Tuesday, April 10, 2007
More clockwrestling....
Of course things couldn't be so simple as I thought they were. I'd forgotten that great property of PCs: They reboot.
And then I discovered that adjtimex, being such an ancient piece of technology, didn't keep state - and neither did it have a standard /etc/ file to put its adjustments in.
Finally I found that if I just added this single line to /etc/rc.local, everything would be dandy:
/usr/sbin/adjtimex --tick 9985 --freq 0
In the Old Times, /etc/rc.local was for local adaptions of your init scripts. Now, of course, we all do it by pointing, clicking and headscratching. And /etc/rc.local comes full of interesting stuff from your friendly Linux distribution vendor.
At least the headscratching hasn't changed.
And then I discovered that adjtimex, being such an ancient piece of technology, didn't keep state - and neither did it have a standard /etc/ file to put its adjustments in.
Finally I found that if I just added this single line to /etc/rc.local, everything would be dandy:
/usr/sbin/adjtimex --tick 9985 --freq 0
In the Old Times, /etc/rc.local was for local adaptions of your init scripts. Now, of course, we all do it by pointing, clicking and headscratching. And /etc/rc.local comes full of interesting stuff from your friendly Linux distribution vendor.
At least the headscratching hasn't changed.
Saturday, March 10, 2007
Infrant ReadyNas: Simply works (for now)
Today's toy was an Infrant ReadyNAS NV+ from Infrant - bought from a local Norwegian distributor called "masseplass.no" (lots of room..... cute name!).
Together with 3x400 Gbyte disks, it's now, a few hours later, providing my local network with 700+ Gbytes of (theoretically) disk-crash-proof storage space.
The nicest thing about it is that it "just works" - I plugged in the disks, flipped a few parameters, and got it running with no hitches. And both my Windows boxes and my Linux (NFS) boxes saw it with no problem - the software included the option of setting the UID for the users I installed on the box.
So what's not to like?
Well, security for NFS is a laugh. But then, unKerberized NFS has always had laughable security.
And there's limited possibilities for limiting access to NFS on a per-host basis; basically, "list them all" is the only option available. No ranges.
And when you install users, it sends notifications to those users in CLEARTEXT email - WITH the initial password. Shudder; should have been a warning on the "add user" screen about this.
But once those things are considered, I really like the box. It Just Works.
I know there's a Linux box inside it. But I'm not too anxious to get it out.
Together with 3x400 Gbyte disks, it's now, a few hours later, providing my local network with 700+ Gbytes of (theoretically) disk-crash-proof storage space.
The nicest thing about it is that it "just works" - I plugged in the disks, flipped a few parameters, and got it running with no hitches. And both my Windows boxes and my Linux (NFS) boxes saw it with no problem - the software included the option of setting the UID for the users I installed on the box.
So what's not to like?
Well, security for NFS is a laugh. But then, unKerberized NFS has always had laughable security.
And there's limited possibilities for limiting access to NFS on a per-host basis; basically, "list them all" is the only option available. No ranges.
And when you install users, it sends notifications to those users in CLEARTEXT email - WITH the initial password. Shudder; should have been a warning on the "add user" screen about this.
But once those things are considered, I really like the box. It Just Works.
I know there's a Linux box inside it. But I'm not too anxious to get it out.
Wednesday, March 7, 2007
Linux Time games: Wrestle the clock and win!
So what do you do when your PC doesn't know what time it is?
One of my Linux servers was misbehaving; even with NTP installed, it was drifting out of time sync with depressing regularity. The dreaded "Frequency error -512 PPM exceeds tolerance 500 PPM" explained that NTP was refusing to even consider adjusting the time on such a deeply broken system. And the clock was drifting into la-la-land whenever I didn't reset it for a week.
It would have been easy to buckle under and add a cron job to just sync the time every 5 minutes - but I just couldn't believe there wasn't another solution. So today, after watching this problem for (literally) years, I sat down and started Googling for the answer.
An hour later, the win was in: There is a magic utility in the distro (but not installed by default!) called "adjtimex", which brutally and forcefully corrects the clock rate for you. If you have a clock that is fast by 500 parts per million (43 seconds per day), just enter this magic command:
adjtimex --tick 9995
What this will do is to tell the kernel that every time your system thinks that 10 milliseconds have passed by, and it should count up the clock by this much, it should instead add 9.995 milliseconds to the clock. Losing that magic 500 ppm (0.05%) every single clock tick, and getting the clock back in touch with reality.
The adjtimex program has more options than this, including "--print", which is very useful for seeing what the variables are before you start playing with them - always a wise move.
And the NTP daemon actually plays with another of the variables that adjtimex can touch: the "frequency" variable - making small adjustments to the clock that will ensure that you are JUST in sync.
You can watch it being adjusted with this little command line:
while true; do date; adjtimex --print | grep frequency; sleep 300; done
This will then print a line every 5 minutes, showing how the frequency changes up and down as the NTP daemon hunts for the optimal value.
And now my clocks will be all right. I'm happy!
One of my Linux servers was misbehaving; even with NTP installed, it was drifting out of time sync with depressing regularity. The dreaded "Frequency error -512 PPM exceeds tolerance 500 PPM" explained that NTP was refusing to even consider adjusting the time on such a deeply broken system. And the clock was drifting into la-la-land whenever I didn't reset it for a week.
It would have been easy to buckle under and add a cron job to just sync the time every 5 minutes - but I just couldn't believe there wasn't another solution. So today, after watching this problem for (literally) years, I sat down and started Googling for the answer.
An hour later, the win was in: There is a magic utility in the distro (but not installed by default!) called "adjtimex", which brutally and forcefully corrects the clock rate for you. If you have a clock that is fast by 500 parts per million (43 seconds per day), just enter this magic command:
adjtimex --tick 9995
What this will do is to tell the kernel that every time your system thinks that 10 milliseconds have passed by, and it should count up the clock by this much, it should instead add 9.995 milliseconds to the clock. Losing that magic 500 ppm (0.05%) every single clock tick, and getting the clock back in touch with reality.
The adjtimex program has more options than this, including "--print", which is very useful for seeing what the variables are before you start playing with them - always a wise move.
And the NTP daemon actually plays with another of the variables that adjtimex can touch: the "frequency" variable - making small adjustments to the clock that will ensure that you are JUST in sync.
You can watch it being adjusted with this little command line:
while true; do date; adjtimex --print | grep frequency; sleep 300; done
This will then print a line every 5 minutes, showing how the frequency changes up and down as the NTP daemon hunts for the optimal value.
And now my clocks will be all right. I'm happy!
Subscribe to:
Posts (Atom)
