Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #12430 > unrolled thread

what VESA/vga *AM* I useing?

Back to article view | Back to comp.os.linux.misc

Contents

  what VESA/vga *AM* I useing? not.socialnetwork@gmail.com - 2014-10-23 06:07 +0000
    Re: what VESA/vga *AM* I useing? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-23 08:22 +0000
    Re: what VESA/vga *AM* I useing? not.socialnetwork@gmail.com - 2014-10-23 12:04 +0000
      Re: what VESA/vga *AM* I useing? Joe Beanfish <joebeanfish@nospam.duh> - 2014-10-23 13:25 +0000
        Re: what VESA/vga *AM* I useing? not.socialnetwork@gmail.com - 2014-10-24 06:14 +0000
    Re: what VESA/vga *AM* I useing? ebenZEROONE@verizon.net (Hactar) - 2014-10-23 21:45 -0400
      Re: what VESA/vga *AM* I useing? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-24 06:56 +0000
      Re: what VESA/vga *AM* I useing? Unknown <dog@gmail.com> - 2014-10-26 03:07 +0000
    Re: what VESA/vga *AM* I useing? "Chester A. Arthur" <deadprez@whitehouse.com> - 2014-10-23 22:18 -0500
      Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-23 22:09 -0800
        Re: what VESA/vga *AM* I useing? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-24 07:07 +0000
          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 00:02 -0800
        Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 12:46 +0000
          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 05:39 -0800
            Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 09:31 -0500
              Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 08:37 -0800
                Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 12:09 -0500
                  Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 09:30 -0800
                    Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 12:44 -0500
                      Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 10:15 -0800
                        Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 18:38 +0000
                          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 11:09 -0800
                            Re: what VESA/vga *AM* I useing? Richard Kettlewell <rjk@greenend.org.uk> - 2014-10-24 21:31 +0100
                              Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 12:53 -0800
                                Re: what VESA/vga *AM* I useing? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2014-10-25 13:56 +0100
                                  Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-25 05:12 -0800
                                    Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-25 09:24 -0500
                                      Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-26 00:15 +0000
                        Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 14:17 -0500
                          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 12:55 -0800
                            Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 16:23 -0500
                            Re: what VESA/vga *AM* I useing? Richard Kettlewell <rjk@greenend.org.uk> - 2014-10-24 22:33 +0100
                    Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 18:28 +0000
                      Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 10:43 -0800
                        Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 22:52 +0000
                      Re: what VESA/vga *AM* I useing? Eef Hartman <E.J.M.Hartman@gmail.com> - 2014-10-24 18:57 +0000
            Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 17:04 +0000
            Re: what VESA/vga *AM* I useing? Eef Hartman <E.J.M.Hartman@gmail.com> - 2014-10-24 17:09 +0000
              Re: what VESA/vga *AM* I useing? Allodoxaphobia <knock_yourself_out@example.net> - 2014-10-24 21:02 +0000
                Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 16:30 -0500
                  Re: what VESA/vga *AM* I useing? Martin <m@abc.invalid> - 2014-10-25 14:40 +0200
                    Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-25 04:50 -0800
                      Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-25 09:17 -0500
                        Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-25 13:26 -0800
                          Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-25 16:49 -0500
                      Re: what VESA/vga *AM* I useing? Martin <m@abc.invalid> - 2014-10-25 19:54 +0200

Page 1 of 3  [1] 2 3  Next page →

#12430 — what VESA/vga *AM* I useing?

The worst kind of bugs are those that pretend to self-fix;
like some kind of hidden disease, to appear later and kill you.
--
Only after an unknown sequence of applications [and sleep mode]
did my prefered distribution slip into a fuzzy-display-mode, for certain
programs, eg. xpdf, certain-text-of <mozilla>...

Frustrating attempts to trace the bug of the *xorg* system, caused me
to switch to an earlier/forked version of the distribution; with the
needed wastefull <re-setting all your preferences>. 
It's worst than moving house!!

After settling in to the better system, I wanted to check something on
the previous bad-display-system.  For booting I selected "vga=ask"
and then selected one [that seemed familiar] from the menu of 
vga/VESA.

Now I've been using it for 12 hours and the damned-thing won't
go-wrong. So I fear that I MAY have chosen a *magic* vga/VESA
selection, which avoids the original problem.

Of course I'd rather *understand* why/what's happening, but
if that's not possible. I need to know which of a zillion vga/VESA
choices displays without the complex/unsolved problem.

ls -l /etc/X11/xorg.conf*
  shows that none of these was updated by the latest reboot.
  
Any help on this frustrating problem is much appreciated.

== TIA

PS. how do you easily set the RTC back by 7 minutes, 
without decoding the absurd `man'?

[toc] | [next] | [standalone]

#12431

["Followup-To:" header set to comp.os.linux.misc.]
On 2014-10-23, not.socialnetwork@gmail.com <not.socialnetwork@gmail.com> wrote:
> The worst kind of bugs are those that pretend to self-fix;
> like some kind of hidden disease, to appear later and kill you.
> --
> Only after an unknown sequence of applications [and sleep mode]
> did my prefered distribution slip into a fuzzy-display-mode, for certain
> programs, eg. xpdf, certain-text-of <mozilla>...
>
> Frustrating attempts to trace the bug of the *xorg* system, caused me
> to switch to an earlier/forked version of the distribution; with the
> needed wastefull <re-setting all your preferences>. 
> It's worst than moving house!!
>
> After settling in to the better system, I wanted to check something on
> the previous bad-display-system.  For booting I selected "vga=ask"
> and then selected one [that seemed familiar] from the menu of 
> vga/VESA.

These are the vga/VESA modes, typical at least when using video cards
with computers that have a PC BIOS.

The thing here that sounds weird to me is that X will still make its own
choice of which video mode to set once it starts up, the video mode you
set here will *not* be inherited by X, or at least that was how things
were last time I checked it.

> Now I've been using it for 12 hours and the damned-thing won't
> go-wrong. So I fear that I MAY have chosen a *magic* vga/VESA
> selection, which avoids the original problem.

I'll say there's still some room for a problem (corruption, something)
caused by the text consolve vga/VESA mode, it may be indeed a problem
with the initial choice.

>
> Of course I'd rather *understand* why/what's happening, but
> if that's not possible. I need to know which of a zillion vga/VESA
> choices displays without the complex/unsolved problem.
>
> ls -l /etc/X11/xorg.conf*
>   shows that none of these was updated by the latest reboot.
>   
> Any help on this frustrating problem is much appreciated.

There could have been changes in the X system *or* in the
kernel. Nowadays, part of the graphics stack is in the linux kernel.

>
>== TIA
>
> PS. how do you easily set the RTC back by 7 minutes, 
> without decoding the absurd `man'?

You should just need to
1. set the current system (software) clock to the desired time
date [MMDDhhmm[[CC]YY][.ss]]

that is, for 2014-10-23, 11:10:

  date 10231110

(And that should be enough to set the date, just check if it is ok by
running "date".)

Now you need to sync the software clock with the hardware clock:

  hwclock -w

(from the hwclock help, "-w, --systohc set the hardware clock from the
current system time")

(Apparently, you can also set the hardware clock directly with hwclock,
if you prefer.)


-- 
Nuno Silva (aka njsg)
Helsinki, Finland

[toc] | [prev] | [next] | [standalone]

#12432

In article <m2a5ur$e5b$1@dont-email.me>, cat.satonmat@gmail.com wrote: 

> The worst kind of bugs are those that pretend to self-fix;
> like some kind of hidden disease, to appear later and kill you.
> --
> Only after an unknown sequence of applications [and sleep mode]
> did my prefered distribution slip into a fuzzy-display-mode, for certain
> programs, eg. xpdf, certain-text-of <mozilla>...
> 
> Frustrating attempts to trace the bug of the *xorg* system, caused me
> to switch to an earlier/forked version of the distribution; with the
> needed wastefull <re-setting all your preferences>. 
> It's worst than moving house!!
> 
> After settling in to the better system, I wanted to check something on
> the previous bad-display-system.  For booting I selected "vga=ask"
> and then selected one [that seemed familiar] from the menu of 
> vga/VESA.
> 
> Now I've been using it for 12 hours and the damned-thing won't
> go-wrong. So I fear that I MAY have chosen a *magic* vga/VESA
> selection, which avoids the original problem.
> 
> Of course I'd rather *understand* why/what's happening, but
> if that's not possible. I need to know which of a zillion vga/VESA
> choices displays without the complex/unsolved problem.
> 
> ls -l /etc/X11/xorg.conf*
>   shows that none of these was updated by the latest reboot.
>   
> Any help on this frustrating problem is much appreciated.
> 
> == TIA
> 
> PS. how do you easily set the RTC back by 7 minutes, 
> without decoding the absurd `man'?
> ===
OK, I'm wrong again. The disease is rampant again!
But it's interesting for anyone who knows a bit about 
color-mixing:

There's a color-circle, which shows the RGB color-spectrum.
I think the intensity of each "beam" [thinking of a 3 beam CRT]
goes from zero in the center to maximum at the perimeter.

Now, with the bad condition again: the inner 40% of the circle
is white, which is wrong. Also the 3 <mix colors> between the
RBG primary colors have bigger areas. 

My interpretation is that all 3 of R,B,G are leaking:
where R,B,G mix they produce white;
where any 2 adjacent mix [due to 'leaking'] they produce
the <extra large mixing area> decribed above.

This problem could be simulated on a 3-beam CRT display,
if eg. the beams where too-wide, and eg. the Red beam
overflowed to adjacent Green & Blue pixels.

But I don't see how such an explanation can apply to a HDMI
LED display, which doesn't work like a batsman trying to hit a
flying ball. AFAIK the HDMI is digital and not analogue.

WDYS?

But no, I'm wrong. Apart from the colour-circle, there's a 
pie-segment which is coloured from dark at the point,
[corresponding to the circle-middle] to white at the perimeter.

If the circle's intensity decreased towards the middle.
and reached zero; that would correspond to black.
As the Pie-sector suggests.

All programs that write in black are OK, but those that use 
grey are near invisisble.

[toc] | [prev] | [next] | [standalone]

#12433

On Thu, 23 Oct 2014 12:04:26 +0000, not.socialnetwork wrote:
> If the circle's intensity decreased towards the middle.
> and reached zero; that would correspond to black.
> As the Pie-sector suggests.
> 
> All programs that write in black are OK, but those that use grey are
> near invisisble.

Try adjusting brightness/contrast/color on the monitor.

[toc] | [prev] | [next] | [standalone]

#12438

In article <m2avjr$ntk$1@dont-email.me>, Joe Beanfish <joebeanfish@nospam.duh> wrote: 

> On Thu, 23 Oct 2014 12:04:26 +0000, not.socialnetwork wrote:
> > If the circle's intensity decreased towards the middle.
> > and reached zero; that would correspond to black.
> > As the Pie-sector suggests.
> > 
> > All programs that write in black are OK, but those that use grey are
> > near invisisble.
> 
> Try adjusting brightness/contrast/color on the monitor.
>
The HDMI has a difficult menu, activated by touching different parts of the
outer-frame. And testing the dozen nodes of the menu-sub-tree, and
scrolling the adjustments, from 100% to 50% didn't solve the problem.

Perhaps relevant: while it was OK, switching workspaces between those 
mainly-black & mainly-white, showed 2 secs of <changing brightness>.

Now in the BAD-state it doesn't do that.

==TIA.

[toc] | [prev] | [next] | [standalone]

#12435

In article <m2a5ur$e5b$1@dont-email.me>,  <not.socialnetwork@gmail.com> wrote:
> 
> PS. how do you easily set the RTC back by 7 minutes, 
> without decoding the absurd `man'?

/bin/date (aka busybox) on openelec on the Raspberry Pi provides this
helpful info:

,--
| Recognized TIME formats:
|        hh:mm[:ss]
|        [YYYY.]MM.DD-hh:mm[:ss]
|        YYYY-MM-DD hh:mm[:ss]
|        [[[[[YY]YY]MM]DD]hh]mm[.ss]
|        'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead
'--

I don't know how to do relative offsets directly, but GNU date 8.13
accepts times like

date -d "7 minutes ago"

so if you invoke date in such a way that it makes one of the accepted
formats, then do

date -s $(date +format "7 minutes ago")

that might work.

-- 
-eben    QebWenE01R@vTerYizUonI.nOetP    ebmanda.redirectme.net:81
LIBRA:  A big promotion is just around the corner for someone
much more talented than you.  Laughter is the very best medicine,
remember that when your appendix bursts next week.  -- Weird Al

[toc] | [prev] | [next] | [standalone]

#12439

["Followup-To:" header set to comp.os.linux.misc.]
On 2014-10-24, Hactar <ebenZEROONE@verizon.net> wrote:
> In article <m2a5ur$e5b$1@dont-email.me>,  <not.socialnetwork@gmail.com> wrote:
>> 
>> PS. how do you easily set the RTC back by 7 minutes, 
>> without decoding the absurd `man'?
>
> /bin/date (aka busybox) on openelec on the Raspberry Pi provides this
> helpful info:
>
> ,--
>| Recognized TIME formats:
>|        hh:mm[:ss]
>|        [YYYY.]MM.DD-hh:mm[:ss]
>|        YYYY-MM-DD hh:mm[:ss]
>|        [[[[[YY]YY]MM]DD]hh]mm[.ss]
>|        'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead
> '--
>
> I don't know how to do relative offsets directly, but GNU date 8.13
> accepts times like
>
> date -d "7 minutes ago"
>
> so if you invoke date in such a way that it makes one of the accepted
> formats, then do
>
> date -s $(date +format "7 minutes ago")


Neat, I didn't know about this!

(But note that date will only change the software clock, not the RTC.)

>
> that might work.
>


-- 
Nuno Silva (aka njsg)
Helsinki, Finland

[toc] | [prev] | [next] | [standalone]

#12484

On Thu, 23 Oct 2014 21:45:56 -0400, Hactar wrote:

> In article <m2a5ur$e5b$1@dont-email.me>,  <not.socialnetwork@gmail.com>
> wrote:
>> 
>> PS. how do you easily set the RTC back by 7 minutes, without decoding
>> the absurd `man'?
> 
> /bin/date (aka busybox) on openelec on the Raspberry Pi provides this
> helpful info:
> 
> ,--
> | Recognized TIME formats:
> |        hh:mm[:ss]
> |        [YYYY.]MM.DD-hh:mm[:ss]
> |        YYYY-MM-DD hh:mm[:ss]
> |        [[[[[YY]YY]MM]DD]hh]mm[.ss]
> |        'date TIME' form accepts MMDDhhmm[[YY]YY][.ss] instead '--
> 
> I don't know how to do relative offsets directly, but GNU date 8.13
> accepts times like
> 
> date -d "7 minutes ago"
> 
> so if you invoke date in such a way that it makes one of the accepted
> formats, then do
> 
> date -s $(date +format "7 minutes ago")
> 
> that might work.
=============
Thanks, I like your logic. And lets try to simplify even more.
To avoid reading about JuliusCeasr's wedding aniversary details in the
docos, to discover the syntax:
1=ask the simplest question to see A valid syntax: date
2=subtract 7 from minutes
3=<set date> via: date -s <the syntax of 2 above>

OH my, that fails.
So *STILL* since the 90's: boot to DOS to reset RTC on linux.

BTW: what VESA/vga *AM* I useing?
Since I oiginated this thread, I re-booted to my prefered distribution;
but after some hours of usage it 'lost focus' and stuff like xpdf
rendered fuzzy. So I've booted to the similar/earlier distrubution
which displays OK. I want to find out the 'good' xorg settings,
to use on the prefered distribution.

[toc] | [prev] | [next] | [standalone]

#12436

On Thu, 23 Oct 2014 06:07:23 +0000, not.socialnetwork wrote:

> PS. how do you easily set the RTC back by 7 minutes, 
> without decoding the absurd `man'?

Set the system clock correctly with the date command, then
run 'sudo hwclock -w', assuming TZ is set properly.

Read the rtc with 'cat /proc/driver/rtc|head -1' or something
similar on most linuxes.

One should always keep the hwclock in UTC. System time will
change with the rules for your local time zone, and computers
move, especially laptops. Most linuxes these days follow these
rules, except the gentoo family. Slackware gives you an
explicit choice at install--choose UTC. The BSDs I have tried
give no choice, they set the hwclock to localtime, that's dumb.

Localtime is crazy, the rules change and there are so many
strangenesses. (The world ends at midnite-12:30 Newfie time).
There is software to deal with that, and it works well if it
isn't bypassed by OSes that make poor choices.

[toc] | [prev] | [next] | [standalone]

#12437

"Chester A. Arthur" <deadprez@whitehouse.com> wrote:
>On Thu, 23 Oct 2014 06:07:23 +0000, not.socialnetwork wrote:
>
>> PS. how do you easily set the RTC back by 7 minutes,
>> without decoding the absurd `man'?
>
>Set the system clock correctly with the date command, then
>run 'sudo hwclock -w', assuming TZ is set properly.

/usr/sbin/ntpdate -b us.pool.ntp.org

>Read the rtc with 'cat /proc/driver/rtc|head -1' or something
>similar on most linuxes.

Why not just invoke the "date" command.

>One should always keep the hwclock in UTC. System time will
>change with the rules for your local time zone, and computers
>move, especially laptops. Most linuxes these days follow these
>rules, except the gentoo family. Slackware gives you an
>explicit choice at install--choose UTC. The BSDs I have tried
>give no choice, they set the hwclock to localtime, that's dumb.

Most people will be *far* better served setting the
hwclock to local time than to UTC.

>Localtime is crazy, the rules change and there are so many
>strangenesses. (The world ends at midnite-12:30 Newfie time).
>There is software to deal with that, and it works well if it
>isn't bypassed by OSes that make poor choices.

You're making life much more difficult than it need be.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12440

["Followup-To:" header set to comp.os.linux.misc.]
On 2014-10-24, Floyd L. Davidson <floyd@apaflo.com> wrote:
> "Chester A. Arthur" <deadprez@whitehouse.com> wrote:
>>On Thu, 23 Oct 2014 06:07:23 +0000, not.socialnetwork wrote:
>>
>>> PS. how do you easily set the RTC back by 7 minutes,
>>> without decoding the absurd `man'?
>>
>>Set the system clock correctly with the date command, then
>>run 'sudo hwclock -w', assuming TZ is set properly.
>
> /usr/sbin/ntpdate -b us.pool.ntp.org
>
>>Read the rtc with 'cat /proc/driver/rtc|head -1' or something
>>similar on most linuxes.
>
> Why not just invoke the "date" command.

Actually, at least on linux, date (software clock) and the RTC are
different things. In this case, Chester's answer was actually much
better than mine from yesterday: in this case, we're actually reading
the time from the RTC, and the question was "how do you [...] set the
RTC back by [...]".

>
>>One should always keep the hwclock in UTC. System time will
>>change with the rules for your local time zone, and computers
>>move, especially laptops. Most linuxes these days follow these
>>rules, except the gentoo family. Slackware gives you an
>>explicit choice at install--choose UTC. The BSDs I have tried
>>give no choice, they set the hwclock to localtime, that's dumb.

I actually don't know what's the default for Gentoo. This at least used
to be documented in the handbook. But I've got so used to the install
procedure that I just look it up and make sure that it's set to UTC.

>
> Most people will be *far* better served setting the
> hwclock to local time than to UTC.

Actually, if you live in a place where DST exists, for example, all of
the mainland european union, and at least some of the other EU
territories, and set the hwclock to local time, you open a pandora's box
of problems: How do you know in which timezone the RTC is the next time
you boot up after DST?

If you're dual booting with windows, although Microsoft has not
officially endorsed the option, you can set Windows to treat the RTC as
being UTC, thus getting rid of yet another problem (which operating
system changes the RTC to make up for DST, and when?).

The option is not officially endorsed because it has not been hard
tested and sometimes may have issues, but these are documented in
Microsoft's Knowledge Base. Microsoft Windows NT 6.1 (Windows 7 and
Server 2008 R2) and possibly older versions support this option.

Unless you have a strong reason not to keep the RTC in UTC, my humble
opinion is that you should leave it as UTC to avoid breakage: this way,
there's no ambiguity as to what the RTC time stands for.

>
>>Localtime is crazy, the rules change and there are so many
>>strangenesses. (The world ends at midnite-12:30 Newfie time).
>>There is software to deal with that, and it works well if it
>>isn't bypassed by OSes that make poor choices.
>
> You're making life much more difficult than it need be.
>


-- 
Nuno Silva (aka njsg)
Helsinki, Finland

[toc] | [prev] | [next] | [standalone]

#12441

"Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> wrote:
>["Followup-To:" header set to comp.os.linux.misc.]
>On 2014-10-24, Floyd L. Davidson <floyd@apaflo.com> wrote:
>> "Chester A. Arthur" <deadprez@whitehouse.com> wrote:
>>>On Thu, 23 Oct 2014 06:07:23 +0000, not.socialnetwork wrote:
>>>
>>>> PS. how do you easily set the RTC back by 7 minutes,
>>>> without decoding the absurd `man'?
>>>
>>>Set the system clock correctly with the date command, then
>>>run 'sudo hwclock -w', assuming TZ is set properly.
>>
>> /usr/sbin/ntpdate -b us.pool.ntp.org
>>
>>>Read the rtc with 'cat /proc/driver/rtc|head -1' or something
>>>similar on most linuxes.
>>
>> Why not just invoke the "date" command.
>
>Actually, at least on linux, date (software clock) and the RTC are
>different things. In this case, Chester's answer was actually much
>better than mine from yesterday: in this case, we're actually reading
>the time from the RTC, and the question was "how do you [...] set the
>RTC back by [...]".

The procedure recommended above syncronizes them first.

    /usr/sbin/ntpdate -b us.pool.ntp.org   # set the system clock
    hwclock -w                             # set the hardware clock
    date                                   # get the date

>>>One should always keep the hwclock in UTC. System time will
>>>change with the rules for your local time zone, and computers
>>>move, especially laptops. Most linuxes these days follow these
>>>rules, except the gentoo family. Slackware gives you an
>>>explicit choice at install--choose UTC. The BSDs I have tried
>>>give no choice, they set the hwclock to localtime, that's dumb.
>
>I actually don't know what's the default for Gentoo. This at least used
>to be documented in the handbook. But I've got so used to the install
>procedure that I just look it up and make sure that it's set to UTC.
>
>>
>> Most people will be *far* better served setting the
>> hwclock to local time than to UTC.
>
>Actually, if you live in a place where DST exists, for example, all of
>the mainland european union, and at least some of the other EU
>territories, and set the hwclock to local time, you open a pandora's box
>of problems: How do you know in which timezone the RTC is the next time
>you boot up after DST?

I've never lived anywhere that does not have DST, and
never had a problem with that.

I have a cron job that runs "ntbdate -b" regularly.  I
have another that runs "hwclock -w" regularly too.

>If you're dual booting with windows, although Microsoft has not
>officially endorsed the option, you can set Windows to treat the RTC as
>being UTC, thus getting rid of yet another problem (which operating
>system changes the RTC to make up for DST, and when?).
>
>The option is not officially endorsed because it has not been hard
>tested and sometimes may have issues, but these are documented in
>Microsoft's Knowledge Base. Microsoft Windows NT 6.1 (Windows 7 and
>Server 2008 R2) and possibly older versions support this option.
>
>Unless you have a strong reason not to keep the RTC in UTC, my humble
>opinion is that you should leave it as UTC to avoid breakage: this way,
>there's no ambiguity as to what the RTC time stands for.

There is no ambiguity.

>>>Localtime is crazy, the rules change and there are so many
>>>strangenesses. (The world ends at midnite-12:30 Newfie time).
>>>There is software to deal with that, and it works well if it
>>>isn't bypassed by OSes that make poor choices.
>>
>> You're making life much more difficult than it need be.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12442

In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
> "Chester A. Arthur" <deadprez@whitehouse.com> wrote:
> >One should always keep the hwclock in UTC. System time will change
> >with the rules for your local time zone, and computers move,
> >especially laptops. Most linuxes these days follow these rules,
> >except the gentoo family. Slackware gives you an explicit choice at
> >install--choose UTC. The BSDs I have tried give no choice, they set
> >the hwclock to localtime, that's dumb.

> Most people will be *far* better served setting the hwclock to local
> time than to UTC.

How so?  Unless they need to dual-boot windows, setting the hardware
clock to UTC will allow their computer to automatically shift back and
forth due to the idiot politicians desire to play with the clocks
(i.e., daylight savings time).

> >Localtime is crazy, the rules change and there are so many
> >strangenesses. (The world ends at midnite-12:30 Newfie time). There
> >is software to deal with that, and it works well if it isn't
> >bypassed by OSes that make poor choices.

> You're making life much more difficult than it need be.

And setting the hardware clock to UTC lets the system libs take care
of that crazyness, so that one's computer time automatically moves
forward at 2am in the spring, and automatically falls back at 2am in
the fall, with no effort on the users part.

That seems the very definition of "much easier" rather than more
difficult.  Let the computer do the work, both of remembering when, and
of how much to shift.

[toc] | [prev] | [next] | [standalone]

#12443

Rich <rich@example.invalid> wrote:
>In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
>> "Chester A. Arthur" <deadprez@whitehouse.com> wrote:
>> >One should always keep the hwclock in UTC. System time will change
>> >with the rules for your local time zone, and computers move,
>> >especially laptops. Most linuxes these days follow these rules,
>> >except the gentoo family. Slackware gives you an explicit choice at
>> >install--choose UTC. The BSDs I have tried give no choice, they set
>> >the hwclock to localtime, that's dumb.
>
>> Most people will be *far* better served setting the hwclock to local
>> time than to UTC.
>
>How so?  Unless they need to dual-boot windows, setting the hardware
>clock to UTC will allow their computer to automatically shift back and
>forth due to the idiot politicians desire to play with the clocks
>(i.e., daylight savings time).

All of mine have been shifting between AKDT and AKST
spring and fall every year for a very long time...

>> >Localtime is crazy, the rules change and there are so many
>> >strangenesses. (The world ends at midnite-12:30 Newfie time). There
>> >is software to deal with that, and it works well if it isn't
>> >bypassed by OSes that make poor choices.
>
>> You're making life much more difficult than it need be.
>
>And setting the hardware clock to UTC lets the system libs take care
>of that crazyness, so that one's computer time automatically moves
>forward at 2am in the spring, and automatically falls back at 2am in
>the fall, with no effort on the users part.

Setting to local time does not change that.

>That seems the very definition of "much easier" rather than more
>difficult.  Let the computer do the work, both of remembering when, and
>of how much to shift.

The only way I know when the switch takes place is when
I notice my computer is an hour different than my wall
clock.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12444

Floyd L. Davidson writes:
> The only way I know when the switch takes place is when I notice my
> computer is an hour different than my wall clock.

Same here with the BIOS clock set to UTC.  So what is the advantage of
setting it to local time and having to change it manually twice a year?
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#12445

John Hasler <jhasler@newsguy.com> wrote:
>Floyd L. Davidson writes:
>> The only way I know when the switch takes place is when I notice my
>> computer is an hour different than my wall clock.
>
>Same here with the BIOS clock set to UTC.  So what is the advantage of
>setting it to local time and having to change it manually twice a year?

So why would anyone manually change it?

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12448

Floyd L. Davidson writes:
> The only way I know when the switch takes place is when I notice my
> computer is an hour different than my wall clock.

I wrote:
> Same here with the BIOS clock set to UTC.  So what is the advantage of
> setting it to local time and having to change it manually twice a year?

Floyd L. Davidson writes:
> So why would anyone manually change it?

If you don't it will only be on local time part of the year.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#12449

John Hasler <jhasler@newsguy.com> wrote:
>Floyd L. Davidson writes:
>> The only way I know when the switch takes place is when I notice my
>> computer is an hour different than my wall clock.
>
>I wrote:
>> Same here with the BIOS clock set to UTC.  So what is the advantage of
>> setting it to local time and having to change it manually twice a year?
>
>Floyd L. Davidson writes:
>> So why would anyone manually change it?
>
>If you don't it will only be on local time part of the year.

I've had multiple systems set to local time since the
early 90's.  They all switch automatically.

A cron job sets the time with ntpdate.  Another cron job
sets the hardware clock from the system clock.  Both run
once an hour.

It's all automatic.

The big problem is my wall clock... I have to manually set it.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12450

Floyd L. Davidson writes:
> I've had multiple systems set to local time since the early 90's.
> They all switch automatically.

I've had multiple systems with the BIOS clock set to UTC since the early
90's.  They don't need to switch.  Everything just works.

-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#12451

John Hasler <jhasler@newsguy.com> wrote:
>Floyd L. Davidson writes:
>> I've had multiple systems set to local time since the early 90's.
>> They all switch automatically.
>
>I've had multiple systems with the BIOS clock set to UTC since the early
>90's.  They don't need to switch.  Everything just works.

If they don't "switch" then you wake up in the morning
and the all your neighbors have switched, and you aren't
on the same time they are.

Run the date command, and you'll see that in fact is
*has* switched.  In my case one day it says AKDT and the
next it says AKST.  Or the other way around.

"Switch" means go from one standard to the other.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web