Something Unix did that was different from most other OSes was, its system
clock kept time in UTC (or GMT, in pre-UTC days). Linux does the same.
When you use a command like “date” to see what the current date and time
is, it converts that UTC time to a local time in some specified timezone.
Changing the timezone is as easy as specifying a new value for the TZ
environment variable.

Windows, on the other hand, keeps its system clock in local time, in some
specific time zone that is assumed to apply systemwide.

This is a particularly dumb idea when you realize how much it complicates
things if your time zone has daylight saving time. We have seen this sort
of thing happen on Windows systems before, where they might forget to
adjust the clock to start/stop daylight saving, or even adjust it twice so
you end up being an hour off in the opposite direction.

This can’t happen on Linux systems, because there is no turning daylight
saving “on” or “off” as such: there is simply a table of local time
offsets (from the “tzdata” files), and the correct offset to apply depends
only on the actual UTC time value, not on the current setting of any
system flag.

This also makes it easy to convert between UTC and local times at any time
in the past, for any time zone.

On Sat, 28 Sep 2024 22:40:24 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <vda0ko$1e457$1@dont-email.me>:

> Something Unix did that was different from most other OSes was, its
> system clock kept time in UTC (or GMT, in pre-UTC days). Linux does the
> same.
> When you use a command like “date” to see what the current date and time
> is, it converts that UTC time to a local time in some specified
> timezone. Changing the timezone is as easy as specifying a new value for
> the TZ environment variable.
>
> Windows, on the other hand, keeps its system clock in local time, in
> some specific time zone that is assumed to apply systemwide.
>
> This is a particularly dumb idea when you realize how much it
> complicates things if your time zone has daylight saving time. We have
> seen this sort of thing happen on Windows systems before, where they
> might forget to adjust the clock to start/stop daylight saving, or even
> adjust it twice so you end up being an hour off in the opposite
> direction.
>
> This can’t happen on Linux systems, because there is no turning daylight
> saving “on” or “off” as such: there is simply a table of local time
> offsets (from the “tzdata” files), and the correct offset to apply
> depends only on the actual UTC time value, not on the current setting of
> any system flag.
>
> This also makes it easy to convert between UTC and local times at any
> time in the past, for any time zone.

$ echo $TZ

$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Jul 16 07:50 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles

--
-v

On 28 Sep 2024 23:21:43 GMT, vallor wrote:

> $ ls -l /etc/localtime
> lrwxrwxrwx 1 root root 39 Jul 16 07:50 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles

This is a “system default” timezone, which is not something that
really makes sense on Linux.

For example, syslog uses this system default for its timestamps, while
the systemd journal records timestamps in UTC, and will display them
in any timezone you like.

On 9/28/2024 6:40 PM, Lawrence D'Oliveiro wrote:
> Something Unix did that was different from most other OSes was, its system
> clock kept time in UTC (or GMT, in pre-UTC days). Linux does the same.
> When you use a command like “date” to see what the current date and time
> is, it converts that UTC time to a local time in some specified timezone.
> Changing the timezone is as easy as specifying a new value for the TZ
> environment variable.
>
> Windows, on the other hand, keeps its system clock in local time, in some
> specific time zone that is assumed to apply systemwide.
>
> This is a particularly dumb idea when you realize how much it complicates
> things if your time zone has daylight saving time. We have seen this sort
> of thing happen on Windows systems before, where they might forget to
> adjust the clock to start/stop daylight saving, or even adjust it twice so
> you end up being an hour off in the opposite direction.
>
> This can’t happen on Linux systems, because there is no turning daylight
> saving “on” or “off” as such: there is simply a table of local time
> offsets (from the “tzdata” files), and the correct offset to apply depends
> only on the actual UTC time value, not on the current setting of any
> system flag.
>
> This also makes it easy to convert between UTC and local times at any time
> in the past, for any time zone.

I NEVER trust Linux to keep time. I've encountered several occurrences
of it dropping 5-7 minutes over a 1-hour period.

* user error
* Linux is just the kernel
* RTFM newb
* Linux is perfect
* you're lying
* works for me
* you have the source code, fix it yourself

Le 29-09-2024, DFS <nospam@dfs.com> a écrit :
>
> I NEVER trust Linux to keep time. I've encountered several occurrences
> of it dropping 5-7 minutes over a 1-hour period.
>
> * Linux is just the kernel

OK, Linux is just the Kernel and doesn't keep time. The only thing it's
doing is relying on the clock of your computer to know the time.

Now, on a Linux system, you have ntp and it's pretty good to synchronize
your internal clock with available clocks on Internet. Of course, if you
are disconnected of Internet, well Linux, like Windows mind you, can't
do anything if the clock of your computer is buggy. It helps, but it
can't do miracle.

Except from LP/DG/NV/FR/whatever, I've never heard anyone having issues
with ntp. Every time I hear about people having issue with their clock,
they were using chrony. Seriously, I don't know why people are switching
from ntp to chrony as ntd works fine since years and chrony doesn't.

--
Si vous avez du temps à perdre :
https://scarpet42.gitlab.io

On 2024-09-29 2:59 p.m., DFS wrote:
> On 9/28/2024 6:40 PM, Lawrence D'Oliveiro wrote:
>> Something Unix did that was different from most other OSes was, its
>> system
>> clock kept time in UTC (or GMT, in pre-UTC days). Linux does the same.
>> When you use a command like “date” to see what the current date and time
>> is, it converts that UTC time to a local time in some specified timezone.
>> Changing the timezone is as easy as specifying a new value for the TZ
>> environment variable.
>>
>> Windows, on the other hand, keeps its system clock in local time, in some
>> specific time zone that is assumed to apply systemwide.
>>
>> This is a particularly dumb idea when you realize how much it complicates
>> things if your time zone has daylight saving time. We have seen this sort
>> of thing happen on Windows systems before, where they might forget to
>> adjust the clock to start/stop daylight saving, or even adjust it
>> twice so
>> you end up being an hour off in the opposite direction.
>>
>> This can’t happen on Linux systems, because there is no turning daylight
>> saving “on” or “off” as such: there is simply a table of local time
>> offsets (from the “tzdata” files), and the correct offset to apply
>> depends
>> only on the actual UTC time value, not on the current setting of any
>> system flag.
>>
>> This also makes it easy to convert between UTC and local times at any
>> time
>> in the past, for any time zone.
>
>
> I NEVER trust Linux to keep time.  I've encountered several occurrences
> of it dropping 5-7 minutes over a 1-hour period.
>
>
> * user error
> * Linux is just the kernel
> * RTFM newb
> * Linux is perfect
> * you're lying
> * works for me
> * you have the source code, fix it yourself

That's actually pretty sad if it was configured to synchronize with a
time server. I don't recall it ever happening to me, but stranger things
have happened.

--
CrudeSausage
Catholic, paleoconservative, Christ is king

On 2024-09-30, CrudeSausage <crude@sausa.ge> wrote:
> On 2024-09-29 2:59 p.m., DFS wrote:
>> On 9/28/2024 6:40 PM, Lawrence D'Oliveiro wrote:
>>> Something Unix did that was different from most other OSes was, its
>>> system
>>> clock kept time in UTC (or GMT, in pre-UTC days). Linux does the same.
>>> When you use a command like “date” to see what the current date and time
>>> is, it converts that UTC time to a local time in some specified timezone.
>>> Changing the timezone is as easy as specifying a new value for the TZ
>>> environment variable.
>>>
>>> Windows, on the other hand, keeps its system clock in local time, in some
>>> specific time zone that is assumed to apply systemwide.
>>>
>>> This is a particularly dumb idea when you realize how much it complicates
>>> things if your time zone has daylight saving time. We have seen this sort
>>> of thing happen on Windows systems before, where they might forget to
>>> adjust the clock to start/stop daylight saving, or even adjust it
>>> twice so
>>> you end up being an hour off in the opposite direction.
>>>
>>> This can’t happen on Linux systems, because there is no turning daylight
>>> saving “on” or “off” as such: there is simply a table of local time
>>> offsets (from the “tzdata” files), and the correct offset to apply
>>> depends
>>> only on the actual UTC time value, not on the current setting of any
>>> system flag.
>>>
>>> This also makes it easy to convert between UTC and local times at any
>>> time
>>> in the past, for any time zone.
>>
>>
>> I NEVER trust Linux to keep time.  I've encountered several occurrences
>> of it dropping 5-7 minutes over a 1-hour period.
>>
>>
>> * user error
>> * Linux is just the kernel
>> * RTFM newb
>> * Linux is perfect
>> * you're lying
>> * works for me
>> * you have the source code, fix it yourself
>
> That's actually pretty sad if it was configured to synchronize with a
> time server. I don't recall it ever happening to me, but stranger things
> have happened.

I've never had any issues with Linux keeping time, my Linux computers
automatically change on cue with my cell phones. But I just do the standard
install, I don't screw around with it. And it handles daylight savings time
changes on its own. Maybe DuFuS's choice of NTP servers suck. He seems to
have a lot of trouble with Linux that no one else ever has. You have to work
pretty hard on Linux to get it to NOT work. It looks like DuFuS puts in that
needed time.

--
“Evil is not able to create anything new, it can only distort and destroy
what has been invented or made by the forces of good.” —J.R.R. Tolkien

DFS wrote this copyrighted missive and expects royalties:

> I NEVER trust Linux to keep time. I've encountered several occurrences
> of it dropping 5-7 minutes over a 1-hour period.
>
> * user error
> * RTFM newb
> * you're lying

I'll go with those three in DFS's case :-D

--
History repeats itself -- the first time as a tragi-comedy, the second
time as bedroom farce.

On 2024-09-30 2:34 a.m., RonB wrote:
> On 2024-09-30, CrudeSausage <crude@sausa.ge> wrote:
>> On 2024-09-29 2:59 p.m., DFS wrote:
>>> On 9/28/2024 6:40 PM, Lawrence D'Oliveiro wrote:
>>>> Something Unix did that was different from most other OSes was, its
>>>> system
>>>> clock kept time in UTC (or GMT, in pre-UTC days). Linux does the same.
>>>> When you use a command like “date” to see what the current date and time
>>>> is, it converts that UTC time to a local time in some specified timezone.
>>>> Changing the timezone is as easy as specifying a new value for the TZ
>>>> environment variable.
>>>>
>>>> Windows, on the other hand, keeps its system clock in local time, in some
>>>> specific time zone that is assumed to apply systemwide.
>>>>
>>>> This is a particularly dumb idea when you realize how much it complicates
>>>> things if your time zone has daylight saving time. We have seen this sort
>>>> of thing happen on Windows systems before, where they might forget to
>>>> adjust the clock to start/stop daylight saving, or even adjust it
>>>> twice so
>>>> you end up being an hour off in the opposite direction.
>>>>
>>>> This can’t happen on Linux systems, because there is no turning daylight
>>>> saving “on” or “off” as such: there is simply a table of local time
>>>> offsets (from the “tzdata” files), and the correct offset to apply
>>>> depends
>>>> only on the actual UTC time value, not on the current setting of any
>>>> system flag.
>>>>
>>>> This also makes it easy to convert between UTC and local times at any
>>>> time
>>>> in the past, for any time zone.
>>>
>>>
>>> I NEVER trust Linux to keep time.  I've encountered several occurrences
>>> of it dropping 5-7 minutes over a 1-hour period.
>>>
>>>
>>> * user error
>>> * Linux is just the kernel
>>> * RTFM newb
>>> * Linux is perfect
>>> * you're lying
>>> * works for me
>>> * you have the source code, fix it yourself
>>
>> That's actually pretty sad if it was configured to synchronize with a
>> time server. I don't recall it ever happening to me, but stranger things
>> have happened.
>
> I've never had any issues with Linux keeping time, my Linux computers
> automatically change on cue with my cell phones. But I just do the standard
> install, I don't screw around with it. And it handles daylight savings time
> changes on its own. Maybe DuFuS's choice of NTP servers suck. He seems to
> have a lot of trouble with Linux that no one else ever has.

Not true, I have it too. I am reminded of how often Linux Mint and
Ubuntu froze during the last year on this machine to discourage me from
trying it again. At the same time, when I conveniently destroyed my
laptop's motherboard one day before the warranty ended and had it
replaced, there is a possibility that I might have replaced what was
causing the issue.

> You have to work
> pretty hard on Linux to get it to NOT work. It looks like DuFuS puts in that
> needed time.

I disagree. I've repeatedly decided to throw myself head first into an
experience that was solely Linux only to find out that there were going
to be certain issues. I had serious slowdowns and screen tearing in 2013
with gaming, I had random freezes in the last year, I've had
suspend/wake issues throughout and in the last year (the only machine I
owned which never had this problem with Linux is my 2006 Dell). Problems
aren't hard to find. One must really be dedicated to the idea of getting
rid of Windows to disregard them.

--
CrudeSausage
Catholic, paleoconservative, Christ is king

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 01:24 this Monday (GMT):
> On Sun, 29 Sep 2024 14:59:43 -0400, DFS wrote:
>
>> I NEVER trust Linux to keep time. I've encountered several occurrences
>> of it dropping 5-7 minutes over a 1-hour period.
>
> I haven’t. All my Linux machines maintain consistent time down to a
> fraction of a second.
>
> NTP actually has this feature where it learns about the drift
> characteristics of your hardware clock, and can keep it reasonably
> accurate even if it loses any connection to a time server for hours or
> days at a time.

That's pretty cool! Is it enabled by default?
--
user <candycane> is generated from /dev/urandom

On 2024-09-30, CrudeSausage <crude@sausa.ge> wrote:
> On 2024-09-30 2:34 a.m., RonB wrote:
>>
>> I've never had any issues with Linux keeping time, my Linux computers
>> automatically change on cue with my cell phones. But I just do the standard
>> install, I don't screw around with it. And it handles daylight savings time
>> changes on its own. Maybe DuFuS's choice of NTP servers suck. He seems to
>> have a lot of trouble with Linux that no one else ever has.
>
> Not true, I have it too. I am reminded of how often Linux Mint and
> Ubuntu froze during the last year on this machine to discourage me from
> trying it again. At the same time, when I conveniently destroyed my
> laptop's motherboard one day before the warranty ended and had it
> replaced, there is a possibility that I might have replaced what was
> causing the issue.

Yeah, but you're trying to play Windows video games in Wine, which adds a
whole new layer of complications. I, personally, don't recommend Linux for
people who play Windows video games. It seems to create a constant stream of
frustration for them.

>> You have to work
>> pretty hard on Linux to get it to NOT work. It looks like DuFuS puts in that
>> needed time.
>
> I disagree. I've repeatedly decided to throw myself head first into an
> experience that was solely Linux only to find out that there were going
> to be certain issues. I had serious slowdowns and screen tearing in 2013
> with gaming, I had random freezes in the last year, I've had
> suspend/wake issues throughout and in the last year (the only machine I
> owned which never had this problem with Linux is my 2006 Dell). Problems
> aren't hard to find. One must really be dedicated to the idea of getting
> rid of Windows to disregard them.

Problems are almost impossible for me to find in Linux. But I'm using
standard Dell business machines, running Intel GPUs and not poisoning my
Linux install with Windows Wine crap. So that may be why I have no trouble.

The only real trouble I've had with Linux, on any machine in the last couple
years, was trying to install Linux on an HP EliteBook 8640p with a
semi-locked BIOS (you can get to some of the features). My nephew found it
in a dumpster at work and sent it to me because... (I have no clue). Linux
Mint and Ubuntu install, but they won't boot. Strangely enough KDE Neon
installs and works without issue. So, if someone can explain that one to me,
I would be interested to hear why. If I could get into all the BIOS settings
I'm sure I could get it working on Linux Mint. So, in this case, I had to
work pretty hard to find a (crippled) laptop where Linux Mint wouldn't
install and work on.

And, BTW, the computer goes to sleep and wakes fine when opening and
closing, even in KDE Neon.

--
“Evil is not able to create anything new, it can only distort and destroy
what has been invented or made by the forces of good.” —J.R.R. Tolkien

Chris Ahlstrom wrote:

> some dumb fsck wrote:
>>
>> I NEVER trust Linux to keep time. I've encountered several occurrences
>> of it dropping 5-7 minutes over a 1-hour period.
>>
>> * user error
>> * RTFM newb
>> * you're lying
>
> I'll go with those three in DFS's case :-D

Don't forget "attention starved loser making a jackass of himself for
our amusement".

--
"You're an intellectually dishonest twat, like most of your cola
brethren. You idiots wrongly think you can redefine 'personal
computing' to include Android smart phones." - some dumb fsck,
every line a lie

DFS <nospam@dfs.com> wrote:
>On 9/28/2024 6:40 PM, Lawrence D'Oliveiro wrote:
>
>> Something Unix did that was different from most other OSes was, its system
>> clock kept time in UTC (or GMT, in pre-UTC days). Linux does the same.
>> When you use a command like “date” to see what the current date and time
>> is, it converts that UTC time to a local time in some specified timezone.
>> Changing the timezone is as easy as specifying a new value for the TZ
>> environment variable.
>>
>> Windows, on the other hand, keeps its system clock in local time, in some
>> specific time zone that is assumed to apply systemwide.
>>
>> This is a particularly dumb idea when you realize how much it complicates
>> things if your time zone has daylight saving time. We have seen this sort
>> of thing happen on Windows systems before, where they might forget to
>> adjust the clock to start/stop daylight saving, or even adjust it twice so
>> you end up being an hour off in the opposite direction.
>>
>> This can’t happen on Linux systems, because there is no turning daylight
>> saving “on” or “off” as such: there is simply a table of local time
>> offsets (from the “tzdata” files), and the correct offset to apply depends
>> only on the actual UTC time value, not on the current setting of any
>> system flag.
>>
>> This also makes it easy to convert between UTC and local times at any time
>> in the past, for any time zone.
>
>
>I NEVER trust Linux to keep time. I've encountered several occurrences
>of it dropping 5-7 minutes over a 1-hour period.
>
>
>* user error
>* Linux is just the kernel
>* RTFM newb
>* Linux is perfect
>* you're lying
>* works for me
>* you have the source code, fix it yourself

Why is something other than the hardware clock determining the system
time, on either OS?

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On 2024-10-01 1:19 a.m., RonB wrote:
> On 2024-09-30, CrudeSausage <crude@sausa.ge> wrote:
>> On 2024-09-30 2:34 a.m., RonB wrote:
>>>
>>> I've never had any issues with Linux keeping time, my Linux computers
>>> automatically change on cue with my cell phones. But I just do the standard
>>> install, I don't screw around with it. And it handles daylight savings time
>>> changes on its own. Maybe DuFuS's choice of NTP servers suck. He seems to
>>> have a lot of trouble with Linux that no one else ever has.
>>
>> Not true, I have it too. I am reminded of how often Linux Mint and
>> Ubuntu froze during the last year on this machine to discourage me from
>> trying it again. At the same time, when I conveniently destroyed my
>> laptop's motherboard one day before the warranty ended and had it
>> replaced, there is a possibility that I might have replaced what was
>> causing the issue.
>
> Yeah, but you're trying to play Windows video games in Wine, which adds a
> whole new layer of complications. I, personally, don't recommend Linux for
> people who play Windows video games. It seems to create a constant stream of
> frustration for them.

Games were only a serious issue in 2013. At this point, they run rather
well and I can live with a few FPS less. What I can't live with is the
computer suddenly freezing when I'm doing the most mundane of things. At
home, it's a mild nuisance; at work, freezes cause laughter from the
kids and being forced to find my way back to where I was because the
people developing Linux can't get their act together and prioritize
stability over gender theory becomes a serious problem. Since this
machine is both my home and work computer, I am not willing to take too
many chances.

>> You have to work>>> pretty hard on Linux to get it to NOT work. It
looks like DuFuS puts in that
>>> needed time.
>>
>> I disagree. I've repeatedly decided to throw myself head first into an
>> experience that was solely Linux only to find out that there were going
>> to be certain issues. I had serious slowdowns and screen tearing in 2013
>> with gaming, I had random freezes in the last year, I've had
>> suspend/wake issues throughout and in the last year (the only machine I
>> owned which never had this problem with Linux is my 2006 Dell). Problems
>> aren't hard to find. One must really be dedicated to the idea of getting
>> rid of Windows to disregard them.
>
> Problems are almost impossible for me to find in Linux. But I'm using
> standard Dell business machines, running Intel GPUs and not poisoning my
> Linux install with Windows Wine crap. So that may be why I have no trouble.
>
> The only real trouble I've had with Linux, on any machine in the last couple
> years, was trying to install Linux on an HP EliteBook 8640p with a
> semi-locked BIOS (you can get to some of the features). My nephew found it
> in a dumpster at work and sent it to me because... (I have no clue). Linux
> Mint and Ubuntu install, but they won't boot. Strangely enough KDE Neon
> installs and works without issue. So, if someone can explain that one to me,
> I would be interested to hear why. If I could get into all the BIOS settings
> I'm sure I could get it working on Linux Mint. So, in this case, I had to
> work pretty hard to find a (crippled) laptop where Linux Mint wouldn't
> install and work on.
>
> And, BTW, the computer goes to sleep and wakes fine when opening and
> closing, even in KDE Neon.

I have yet to own a machine other than the Dell I bought in 2006 that
didn't have suspend issues in Linux. I'm sure that I will eventually own
one, but it's becoming something of a needle in a haystack situation.

--
CrudeSausage
Catholic, paleoconservative, Christ is king

On Tue, 1 Oct 2024 08:58:44 -0400, CrudeSausage wrote:

> I have yet to own a machine other than the Dell I bought in 2006 that
> didn't have suspend issues in Linux. I'm sure that I will eventually own
> one, but it's becoming something of a needle in a haystack situation.

The only suspend issues I have encountered are on a Windows 11 laptop with
WSL active.

On Tue, 01 Oct 2024 08:26:51 -0400, Joel wrote:

> Why is something other than the hardware clock determining the system
> time, on either OS?

Because hardware clocks are seldom accurate?

On Tue, 1 Oct 2024 08:58:44 -0400, CrudeSausage wrote:

>>>
>>> I disagree. I've repeatedly decided to throw myself head first into an
>>> experience that was solely Linux only to find out that there were going
>>> to be certain issues. I had serious slowdowns and screen tearing in 2013
>>> with gaming, I had random freezes in the last year, I've had
>>> suspend/wake issues throughout and in the last year (the only machine I
>>> owned which never had this problem with Linux is my 2006 Dell). Problems
>>> aren't hard to find. One must really be dedicated to the idea of getting
>>> rid of Windows to disregard them.
>>

Fuck you, imbecile!

Millions use GNU/Linux and the only ones who have problems are the
brain-dead, retarded asshole like you.

Consequently, your PEBKAC experiences are only portrayals of your
own stupidity and nothing else. You are advised to keep them to your
stupid self.

Don't pollute Usenet with tales of your abysmal incompetence again.

Inferior idiot.

--
Systemd: solving all the problems that you never knew you had.

On 10/1/2024 2:51 PM, Farley Flud wrote:
> On Tue, 1 Oct 2024 08:58:44 -0400, CrudeSausage wrote:
>
>>>>
>>>> I disagree. I've repeatedly decided to throw myself head first into an
>>>> experience that was solely Linux only to find out that there were going
>>>> to be certain issues. I had serious slowdowns and screen tearing in 2013
>>>> with gaming, I had random freezes in the last year, I've had
>>>> suspend/wake issues throughout and in the last year (the only machine I
>>>> owned which never had this problem with Linux is my 2006 Dell). Problems
>>>> aren't hard to find. One must really be dedicated to the idea of getting
>>>> rid of Windows to disregard them.
>>>
>
> Fuck you, imbecile!
>
> Millions use GNU/Linux and the only ones who have problems are the
> brain-dead, retarded asshole like you.

"I have serious problems with GNU/Linux from time to time and it's
always a bit of a struggle trying to get things back on track."

Feeb, March 2018

> Consequently, your PEBKAC experiences are only portrayals of your
> own stupidity and nothing else. You are advised to keep them to your
> stupid self.
>
> Don't pollute Usenet with tales of your abysmal incompetence again.
>
> Inferior idiot.

"Anyone probably could beat me in a coding contest."
Feeb, Sep 2019

Both those admittances were back when you had the GuhNoo balls to tell
some truth.

rbowman <bowman@montana.com> wrote:

>> Why is something other than the hardware clock determining the system
>> time, on either OS?
>
>Because hardware clocks are seldom accurate?

What else is there ... ?

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On 2024-10-01 2:30 p.m., rbowman wrote:
> On Tue, 1 Oct 2024 08:58:44 -0400, CrudeSausage wrote:
>
>> I have yet to own a machine other than the Dell I bought in 2006 that
>> didn't have suspend issues in Linux. I'm sure that I will eventually own
>> one, but it's becoming something of a needle in a haystack situation.
>
> The only suspend issues I have encountered are on a Windows 11 laptop with
> WSL active.

I have literally not have issues with suspend on Linux since buying
pre-built machines. When I built my own, I had issues but the last
problem was in 2001 or so.

--
CrudeSausage
Catholic, paleoconservative, Christ is king

On 2024-10-01 4:40 p.m., DFS wrote:
> On 10/1/2024 2:51 PM, Farley Flud wrote:
>> On Tue, 1 Oct 2024 08:58:44 -0400, CrudeSausage wrote:
>>
>>>>>
>>>>> I disagree. I've repeatedly decided to throw myself head first into an
>>>>> experience that was solely Linux only to find out that there were
>>>>> going
>>>>> to be certain issues. I had serious slowdowns and screen tearing in
>>>>> 2013
>>>>> with gaming, I had random freezes in the last year, I've had
>>>>> suspend/wake issues throughout and in the last year (the only
>>>>> machine I
>>>>> owned which never had this problem with Linux is my 2006 Dell).
>>>>> Problems
>>>>> aren't hard to find. One must really be dedicated to the idea of
>>>>> getting
>>>>> rid of Windows to disregard them.
>>>>
>>
>> Fuck you, imbecile!
>>
>> Millions use GNU/Linux and the only ones who have problems are the
>> brain-dead, retarded asshole like you.
>
>
> "I have serious problems with GNU/Linux from time to time and it's
> always a bit of a struggle trying to get things back on track."
>
> Feeb, March 2018

I never expect Linux advocates to tell the truth. In Feeb's case, I
don't expect anything at all since all of his nyms are filtered. Wasting
even five seconds reading his garbage is too much.

--
CrudeSausage
Catholic, paleoconservative, Christ is king

On 1 Oct 2024 18:31:48 GMT, rbowman wrote:

> On Tue, 01 Oct 2024 08:26:51 -0400, Joel wrote:
>
>> Why is something other than the hardware clock determining the system
>> time, on either OS?
>
> Because hardware clocks are seldom accurate?

Linux has its own system clock which is run off timer interrupts. This is
initialized from the hardware clock at boot time, and its value is saved
back to the hardware clock at shutdown. The rest of the time, the kernel
doesn’t care about the hardware clock.

<https://manpages.debian.org/8/hwclock.8.en.html>

On Mon, 30 Sep 2024 10:05:56 -0400, CrudeSausage wrote:

> I had serious slowdowns and screen tearing in 2013
> with gaming, I had random freezes in the last year, I've had
> suspend/wake issues throughout and in the last year (the only machine I
> owned which never had this problem with Linux is my 2006 Dell). Problems
> aren't hard to find. One must really be dedicated to the idea of getting
> rid of Windows to disregard them.

Steam Deck buyers seem to be quite happy with their Linux-based gaming
experience.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On 1 Oct 2024 18:31:48 GMT, rbowman wrote:
>> On Tue, 01 Oct 2024 08:26:51 -0400, Joel wrote:
>>
>>> Why is something other than the hardware clock determining the system
>>> time, on either OS?
>>
>> Because hardware clocks are seldom accurate?
>
>Linux has its own system clock which is run off timer interrupts. This is
>initialized from the hardware clock at boot time, and its value is saved
>back to the hardware clock at shutdown. The rest of the time, the kernel
>doesn’t care about the hardware clock.
>
><https://manpages.debian.org/8/hwclock.8.en.html>

Good to know.

--
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent. States are
liable for denying needed abortions, e.g. TX.

On Tue, 01 Oct 2024 23:01:26 -0400, Joel wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On 1 Oct 2024 18:31:48 GMT, rbowman wrote:
>>> On Tue, 01 Oct 2024 08:26:51 -0400, Joel wrote:
>>>
>>>> Why is something other than the hardware clock determining the system
>>>> time, on either OS?
>>>
>>> Because hardware clocks are seldom accurate?
>>
>>Linux has its own system clock which is run off timer interrupts. This
>>is initialized from the hardware clock at boot time, and its value is
>>saved back to the hardware clock at shutdown. The rest of the time, the
>>kernel doesn’t care about the hardware clock.
>>
>><https://manpages.debian.org/8/hwclock.8.en.html>
>
>
> Good to know.

For today's humor:

"Some Linux distributions attempt to automatically calculate the System
Clock drift with adjtimex's compare operation. Trying to correct one
drifting clock by using another drifting clock as a reference is akin to a
dog trying to catch its own tail. Success may happen eventually, but great
effort and frustration will likely precede it. This automation may yield
an improvement over no configuration, but expecting optimum results would
be in error. A better choice for manual configuration would be adjtimex's
--log options.

It may be more effective to simply track the System Clock drift with sntp,
or date -Ins and a precision timepiece, and then calculate the correction
manually."