[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: living with phoebe (pt.2)

On Tue, 2003-02-11 at 09:11, Robert Tinsley wrote:

> * when you run sensors-detect from lm_sensors, the final output is "Copy
> prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors for
> initialization at boot time." which prog/ directory, which
> lm_sensors.init file, and is that single copy command really enough to
> start lm_sensors at boot time?

This text message is clearly misworded...and frankly I'm okay with
that..you make lmsensors configuration for bootup deployment a one step
process and yer creating a bootup->lockup situation for some people. 
Right now with lmsensors you kinda have to know what yer doing to mess
with it or you can start creating lockups real easily.  I'm all for
redhat making things easier to use...when appropriate..but
damn...lmsensors isn't something a normal user should be messing with
yet...or ever.  I had on over heating problem all summer with my mobo
(it finally resolved itself when the harddrive crashed and i found out
it was the blasted hd enclosure that was causing the apparent cpu
overheating...the fans in the enclosure weren't working and it was
acting like an oven right next to the cpu), and i've been dickering with
lmsensors on this box for a year now...no way in hell do i trust
lmsensors to run at boot.  Lmsensors should not be something mere
mortals feel comfortable with...and it should take some active braincell
use before deciding to deploy it.

> * starting applications from a launcher: the square which expands to
> fill the screen is extremely disconcerting if the app itself doesn't
> start full-screen.

Isnt metacity great?

> * evolution: loading help pages, the user gets no feedback until mozilla
> has started up. this might be quite a while. (presumably true of other
> applications which also call moz?)
There is a long long argument about how mozilla and Oo startup
notification is a pain in the arse. This is probably just another
interesting example of the same problem. 

> * evolution: "Relay denied: You must check for new mail before sending
> mail." no idea if this (transient) issue is an isp problem or not.
> anyone else seeing this?
Pop or Imap or what?  I've never come across this. i use only imap
servers right now.

> * gnome-terminal: occasionally stops accepting the input focus (on all
> tabs). both times this has happened, opening a new tab fixed it (for the
> existing tabs as well.)
hmmm...havent see that...i have seen gnome-terminal not exiting a shell
cleanly and leaving a tab open..but not this input focus problem.

> * EDITOR is not set, so 'crontab -e' under X still gives you vi

And this is a problem?  So what yer saying is that the EDITOR should be set
to a graphical editor all the time? Or do you want Redhat to write some
sort of logic and try to figure out if yer running the terminal under X
and set the editor accordingly? Or do you want an editor set on a case
by case basis for each commandline utility.  Bah...opening up Oo to
working with a commndline tool like crontab is patently stupid.  Maybe
it just makes more sense to have commandline application that you have
to go to a terminal for, use a terminal based editor, for
simplicity..and why can't vi be that editor? Or do you prefer pico? If
you don't like vi...stand in line for the flamethrower...but vi is a
perfectly valid "preference" for a terminal editor...feel free to set
that "preference" in yer .bashrc file. Crontab isn't in the pulldown
menus is it?  I see no problem with using vi as the default
terminalbound editor for a terminalbound command...its a much better
option than forcing a graphical editor down someone's throat.  If you
want to give users a graphical way to edit crontab...use a crontab gui
wrapper in the menus, there were a couple of decent g1.x based
applications like cromagnon...though a g2 based cron gui doesn't seem to
be out there afaik.  Why don't you start up a new g2 based crontab
editor project..it would be a very useful tool to have in the user
preferences menu i think...hell write a nautilus view for it
even....you'd get bonus style points for the nautilus view for crontab.

> * gnome apps: when launching: "** (gedit:20218): WARNING **: Owner of
> /tmp/orbit-rjt-test is not the current user" this is quite correct as
> the current user is "rjt", not "rjt-test" (rjt-test is just a temp
> account.) it is possible that this bug is purely cosmetic.

is the oafd process running as rjt-test? I'm no expert in the mysteries
of all things oaf and orbit related..but I thought oafd was the process
that really used these tmp directories.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]