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

Groups > linux.debian.user > #225533 > unrolled thread

BIOS time fine, Linux/Debian's isn't! ...

Back to article view | Back to linux.debian.user

Contents

  BIOS time fine, Linux/Debian's isn't! ... Albretch Mueller <lbrtchx@gmail.com> - 2020-07-30 13:20 +0200
    Re: BIOS time fine, Linux/Debian's isn't! ... Andrew Cater <amacater@gmail.com> - 2020-07-30 14:00 +0200
    Re: BIOS time fine, Linux/Debian's isn't! ... Brad Rogers <brad@fineby.me.uk> - 2020-07-30 14:10 +0200
      Re: BIOS time fine, Linux/Debian's isn't! ... Anssi Saari <as@sci.fi> - 2020-07-30 16:10 +0200
        Re: BIOS time fine, Linux/Debian's isn't! ... <tomas@tuxteam.de> - 2020-07-30 16:20 +0200
        Re: BIOS time fine, Linux/Debian's isn't! ... Brad Rogers <brad@fineby.me.uk> - 2020-07-30 17:00 +0200
          Re: BIOS time fine, Linux/Debian's isn't! ... <tomas@tuxteam.de> - 2020-07-30 18:00 +0200
            Re: BIOS time fine, Linux/Debian's isn't! ... Brad Rogers <brad@fineby.me.uk> - 2020-07-30 18:20 +0200
              Re: BIOS time fine, Linux/Debian's isn't! ... Andrei POPESCU <andreimpopescu@gmail.com> - 2020-07-31 08:00 +0200
                Signature [was: BIOS time fine, Linux/Debian's isn't! ...] <tomas@tuxteam.de> - 2020-07-31 11:30 +0200
                  Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] Brad Rogers <brad@fineby.me.uk> - 2020-07-31 12:00 +0200
                    Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-31 13:50 +0200
                      Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] Reco <recoverym4n@enotuniq.net> - 2020-07-31 14:40 +0200
                        Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] The Wanderer <wanderer@fastmail.fm> - 2020-07-31 14:50 +0200
                          Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] Reco <recoverym4n@enotuniq.net> - 2020-07-31 17:00 +0200
                            Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] The Wanderer <wanderer@fastmail.fm> - 2020-07-31 18:10 +0200
                  Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...] The Wanderer <wanderer@fastmail.fm> - 2020-07-31 13:20 +0200
                  Tomas has a signature which isn't a .sig Dan Ritter <dsr@randomstring.org> - 2020-07-31 17:50 +0200
                    Re: [OT] Lisp is back (was: Tomas has a signature which isn't a .sig) Reco <recoverym4n@enotuniq.net> - 2020-07-31 18:00 +0200
                      Re: [OT] Lisp is back Teemu Likonen <tlikonen@iki.fi> - 2020-07-31 18:30 +0200
                    Re: Tomas has a signature which isn't a .sig tomas@tuxteam.de - 2020-07-31 21:10 +0200
                      Re: Tomas has a signature which isn't a .sig The Wanderer <wanderer@fastmail.fm> - 2020-07-31 21:30 +0200
                        Re: Tomas has a signature which isn't a .sig Brian <ad44@cityscape.co.uk> - 2020-07-31 21:40 +0200
                      Re: Tomas has a signature which isn't a .sig Brian <ad44@cityscape.co.uk> - 2020-07-31 21:30 +0200
                        Re: Tomas has a signature which isn't a .sig <tomas@tuxteam.de> - 2020-07-31 21:50 +0200
                        Re: Tomas has a signature which isn't a .sig Charles Curley <charlescurley@charlescurley.com> - 2020-07-31 22:00 +0200
                Signature [was: BIOS time fine, Linux/Debian's isn't! ...] <tomas@tuxteam.de> - 2020-07-31 12:00 +0200
                Re: BIOS time fine, Linux/Debian's isn't! ... Brad Rogers <brad@fineby.me.uk> - 2020-07-31 12:00 +0200
                  Signature not working rhkramer@gmail.com - 2020-07-31 13:20 +0200
                    Re: Signature not working rhkramer@gmail.com - 2020-07-31 13:30 +0200
                    Re: Signature not working The Wanderer <wanderer@fastmail.fm> - 2020-07-31 13:30 +0200
                    Re: Signature not working Brad Rogers <brad@fineby.me.uk> - 2020-07-31 13:40 +0200
                      Re: Signature not working Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-31 15:00 +0200
                        Re: Signature not working Brad Rogers <brad@fineby.me.uk> - 2020-07-31 16:00 +0200
                          Re: Signature not working Brad Rogers <brad@fineby.me.uk> - 2020-07-31 17:10 +0200
                            Re: Signature not working Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-31 17:40 +0200
                              Re: Signature not working The Wanderer <wanderer@fastmail.fm> - 2020-07-31 18:10 +0200
                                Re: Signature not working Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-31 19:00 +0200
                            Re: Signature not working David Wright <deblis@lionunicorn.co.uk> - 2020-07-31 17:40 +0200
                              Re: Signature not working Brad Rogers <brad@fineby.me.uk> - 2020-07-31 18:00 +0200
                              Re: Signature not working The Wanderer <wanderer@fastmail.fm> - 2020-07-31 18:10 +0200
                                Re: Signature not working David Wright <deblis@lionunicorn.co.uk> - 2020-08-01 05:50 +0200
                                  Re: Signature not working Stefan Monnier <monnier@iro.umontreal.ca> - 2020-08-03 06:10 +0200
                          Re: Signature not working Reco <recoverym4n@enotuniq.net> - 2020-07-31 17:10 +0200
                          Re: Signature not working Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-31 17:30 +0200
    Re: BIOS time fine, Linux/Debian's isn't! ... Cindy Sue Causey <butterflybytes@gmail.com> - 2020-07-30 14:10 +0200
    Re: BIOS time fine, Linux/Debian's isn't! ... <tomas@tuxteam.de> - 2020-07-30 16:10 +0200
    Re: BIOS time fine, Linux/Debian's isn't! ... Albretch Mueller <lbrtchx@gmail.com> - 2020-07-31 14:00 +0200
      Re: BIOS time fine, Linux/Debian's isn't! ... <tomas@tuxteam.de> - 2020-07-31 15:20 +0200
        Re: BIOS time fine, Linux/Debian's isn't! ... Albretch Mueller <lbrtchx@gmail.com> - 2020-08-08 16:20 +0200
          Re: BIOS time fine, Linux/Debian's isn't! ... Andrew Cater <amacater@gmail.com> - 2020-08-08 16:40 +0200
            Re: BIOS time fine, Linux/Debian's isn't! ... Andrei POPESCU <andreimpopescu@gmail.com> - 2020-08-11 13:10 +0200

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

#225533 — BIOS time fine, Linux/Debian's isn't! ...

 I used the same laptop with another hard drive with a Windows
installation which shows the time correctly.

 How do you make Linux get the time from the BIOS at start time and
take it from there?

 lbrtchx

[toc] | [next] | [standalone]

#225537

[Multipart message — attachments visible in raw view] — view raw

hwclock --hctosys will do it - run a batch file?

Or have ntpdate run automatically as the system boots?

If you mean that Debian shows a different time to Windows consistently -
check that one OS isn't resetting the other's clock. You can persuade
Windows _not_ to reset the clock on daylight saving time changes, for
example - or you can make sure that they both run in the same timezone and
change at the same time.The Debian-specific command:

ntpdate-debian

will run to the ntp pool set by Debian so that you don't have to specify an
NTP server

On Thu, Jul 30, 2020 at 11:19 AM Albretch Mueller <lbrtchx@gmail.com> wrote:

>  I used the same laptop with another hard drive with a Windows
> installation which shows the time correctly.
>
>  How do you make Linux get the time from the BIOS at start time and
> take it from there?
>
>  lbrtchx
>
>

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

#225538

[Multipart message — attachments visible in raw view] — view raw

On Thu, 30 Jul 2020 07:19:12 -0400
Albretch Mueller <lbrtchx@gmail.com> wrote:

Hello Albretch,

> How do you make Linux get the time from the BIOS at start time and
>take it from there?

Linux *is* reading the RTC;  The problem is that Windows expects that
time to be in the local time zone, and sets it so, rather than to UTC,
which Debian (and most Linuxes) expects.  You have to tell Debian that is
the case, and all should be well.

See;
https://www.maketecheasier.com/fix-windows-linux-show-different-times/

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
The man in a tracksuit attacks me
I Predict A Riot - Kaiser Chiefs

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

#225551

Brad Rogers <brad@fineby.me.uk> writes:

> On Thu, 30 Jul 2020 07:19:12 -0400
> Albretch Mueller <lbrtchx@gmail.com> wrote:
>
> Hello Albretch,
>
>> How do you make Linux get the time from the BIOS at start time and
>>take it from there?
>
> Linux *is* reading the RTC;  The problem is that Windows expects that
> time to be in the local time zone, and sets it so, rather than to UTC,
> which Debian (and most Linuxes) expects.  You have to tell Debian that is
> the case, and all should be well.

Since Windows 7 it's possible to tell Windows that RTC is UTC. IMO,
setting RTC to UTC time is the right thing to do, messing around with
Debian settings to accommodate Windows is not.

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

#225553

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 30, 2020 at 05:08:19PM +0300, Anssi Saari wrote:

[...]

> Since Windows 7 it's possible to tell Windows that RTC is UTC.

Wow. They got it right. I'm dumbfounded.

>                                                                IMO,
> setting RTC to UTC time is the right thing to do, messing around with
> Debian settings to accommodate Windows is not.

Most definitel yes, thanks.

Cheers
-- t

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

#225560

[Multipart message — attachments visible in raw view] — view raw

On Thu, 30 Jul 2020 17:08:19 +0300
Anssi Saari <as@sci.fi> wrote:

Hello Anssi,

>Since Windows 7 it's possible to tell Windows that RTC is UTC. IMO,
>setting RTC to UTC time is the right thing to do, messing around with

Good to know(1).  O/P doesn't state which version of Windows they're
using, so I'll make no further assumptions.

>Debian settings to accommodate Windows is not.

I agree, but what with Microsoft and Windows being (almost) ubiquitous,
but swathes of companies developing on that platform conforming to
standards of their own, things aren't too rosy in that regard.

As another example, look at all the bending over backwards developers of
various MUAs go through just to accommodate google's (very) broken
interpretation of email.

Sometimes, whether we like it or not, *we* have to conform to a broken
world.   :-(

(1)  I've not used Windows (outside work) in 20 years.  At work, I do
all I'm required and no more - book holiday, mostly.  I have no interest
in what goes on under the lid.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
You only see me for the clothes that I wear
Public Image - Public Image Ltd

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

#225564

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 30, 2020 at 03:50:54PM +0100, Brad Rogers wrote:
> On Thu, 30 Jul 2020 17:08:19 +0300
> Anssi Saari <as@sci.fi> wrote:
> 
> Hello Anssi,
> 
> >Since Windows 7 it's possible to tell Windows that RTC is UTC. IMO,
> >setting RTC to UTC time is the right thing to do, messing around with
> 
> Good to know(1).  O/P doesn't state which version of Windows they're
> using, so I'll make no further assumptions.
> 
> >Debian settings to accommodate Windows is not.
> 
> I agree, but what with Microsoft and Windows being (almost) ubiquitous,

[...]

If you have been paying attention, you'd know why /in this case/ an UTC
clock makes just a lot of sense.

BTW, many moons ago (as of Windows 3.1, go figure), I was part of a
programming shop. Our boxes had dual boot, Linux and Windows.

To avoid all that stupid problems: among them files "magically"
changing their time stamp at each DST transition -- yes, really!
imagine the fun with Makefiles -- we set Windows to a time zone
on the Greenwich meridian and with no DST. I think it was Liberia
or something. We lived with Windows displaying a funny time.

But hey. Industry standard.

Cheers
-- t

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

#225565

[Multipart message — attachments visible in raw view] — view raw

On Thu, 30 Jul 2020 17:58:10 +0200
<tomas@tuxteam.de> wrote:

Hello tomas@tuxteam.de,

*PLEASE* fix your sig separator.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
Go away, come back, go away, come back
Leave Me Alone (I'm Lonely) - P!nk

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

#225587

[Multipart message — attachments visible in raw view] — view raw

On Jo, 30 iul 20, 17:13:18, Brad Rogers wrote:
> On Thu, 30 Jul 2020 17:58:10 +0200
> <tomas@tuxteam.de> wrote:
> 
> Hello tomas@tuxteam.de,
> 
> *PLEASE* fix your sig separator.

What difference does it make for a signature like his ("-- t")?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#225592 — Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 31, 2020 at 08:55:22AM +0300, Andrei POPESCU wrote:
> On Jo, 30 iul 20, 17:13:18, Brad Rogers wrote:
> > On Thu, 30 Jul 2020 17:58:10 +0200
> > <tomas@tuxteam.de> wrote:
> > 
> > Hello tomas@tuxteam.de,
> > 
> > *PLEASE* fix your sig separator.
> 
> What difference does it make for a signature like his ("-- t")?

(Thanks, Andrei :-)

And to the OP...

I know, I know. My signature is minimalistic: officially there SHOULD
be a newline after the space after the dash after the --uh-- dash.

I skip this newline. It's a quirk. I expect a teaspoon or two of
Postel's Principle [1] applied to me as I grant it to everyone else.

By the way, OP: "WHY DIDN'T YOU CHANGE THE MAIL'S SUBJECT LINE,
HEIN?"

Phew. Feels better now ;-P

(And please: take this all with a grain of salt).

Cheers

[1] I know... again. There are people who don't really like Postel's
   Principle. I do. I do not want to discuss with you.

-- t

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

#225596 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

[Multipart message — attachments visible in raw view] — view raw

On Fri, 31 Jul 2020 11:28:21 +0200
<tomas@tuxteam.de> wrote:

Hello tomas@tuxteam.de,

>I skip this newline. It's a quirk. I expect a teaspoon or two of

Quirks are fine, when things continue to work.  Your sig separator fails
completely.

-- 
 Regards  _
         / )           "The blindingly obvious is
        / _)rad        never immediately apparent"
It couldn't adapt so it couldn't survive
The Great British Mistake - The Adverts

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

#225608 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

On Fri, Jul 31, 2020 at 10:52:57AM +0100, Brad Rogers wrote:
> On Fri, 31 Jul 2020 11:28:21 +0200
> <tomas@tuxteam.de> wrote:
> 
> Hello tomas@tuxteam.de,
> 
> >I skip this newline. It's a quirk. I expect a teaspoon or two of
> 
> Quirks are fine, when things continue to work.  Your sig separator fails
> completely.

"Fails" in what way?  He doesn't actually have a "signature file".
He doesn't have a signature separator ("-- \n") followed by a signature
message.  He simply uses "-- t\n\n" at the end of each email.

You're not missing out on any content.

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

#225611 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

	Hi.

On Fri, Jul 31, 2020 at 07:45:57AM -0400, Greg Wooledge wrote:
> On Fri, Jul 31, 2020 at 10:52:57AM +0100, Brad Rogers wrote:
> > On Fri, 31 Jul 2020 11:28:21 +0200
> > <tomas@tuxteam.de> wrote:
> > 
> > Hello tomas@tuxteam.de,
> > 
> > >I skip this newline. It's a quirk. I expect a teaspoon or two of
> > 
> > Quirks are fine, when things continue to work.  Your sig separator fails
> > completely.
> 
> "Fails" in what way?  He doesn't actually have a "signature file".
> He doesn't have a signature separator ("-- \n") followed by a signature
> message.  He simply uses "-- t\n\n" at the end of each email.
> 
> You're not missing out on any content.

It's a kmail thing. mutt, being a superior MUA, is not affected.

Reco

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

#225613 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-31 at 08:37, Reco wrote:

> Hi.
> 
> On Fri, Jul 31, 2020 at 07:45:57AM -0400, Greg Wooledge wrote:
> 
>> On Fri, Jul 31, 2020 at 10:52:57AM +0100, Brad Rogers wrote:

>>> Quirks are fine, when things continue to work.  Your sig
>>> separator fails completely.
>> 
>> "Fails" in what way?  He doesn't actually have a "signature file". 
>> He doesn't have a signature separator ("-- \n") followed by a
>> signature message.  He simply uses "-- t\n\n" at the end of each
>> email.
>> 
>> You're not missing out on any content.
> 
> It's a kmail thing. mutt, being a superior MUA, is not affected.

Can you clarify both A: in what way this is kmail-specific, and B: what
behaviors you're seeing in respect to mutt that are relevant here?

I see failure on my end, with Thunderbird, which is similar to what I
understand the problem being complained about to be. It is my
understanding that the problem is rooted in (lack of) compliance with a
particular RFC, such that the resulting behavior will be basically
universal across all compliant mail clients.

If mutt is somehow managing to produce the behavior which I would would
be called for by the compliant delimiter, despite not seeing such a
delimiter, then I'm curious as to how.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#225623 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

On Fri, Jul 31, 2020 at 08:47:50AM -0400, The Wanderer wrote:
> On 2020-07-31 at 08:37, Reco wrote:
> >>> Quirks are fine, when things continue to work.  Your sig
> >>> separator fails completely.
> >> 
> >> "Fails" in what way?  He doesn't actually have a "signature file". 
> >> He doesn't have a signature separator ("-- \n") followed by a
> >> signature message.  He simply uses "-- t\n\n" at the end of each
> >> email.
> >> 
> >> You're not missing out on any content.
> > 
> > It's a kmail thing. mutt, being a superior MUA, is not affected.
> 
> Can you clarify both A: in what way this is kmail-specific,

kmail apparently mistakes '-- t' for the MIME-separator.

The "offending" e-mail actually look like this:

== cut ==

-- t

--gKMricLos+KVdGMg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

== cut ==

Where "-- t" is a signature and is contained inside of a MIME-part, and
"--gKMricLos+KVdGMg" is an actual RFC2045-compilant separator.


> and B: what behaviors you're seeing in respect to mutt that are
> relevant here?

The lack of aforementioned confusion. The signature shows as the author
intended, gpg validation happens as expected.


> I see failure on my end, with Thunderbird, which is similar to what I
> understand the problem being complained about to be. It is my
> understanding that the problem is rooted in (lack of) compliance with a
> particular RFC, such that the resulting behavior will be basically
> universal across all compliant mail clients.

RFC2045 is a standard, but we all know that certain proprietary MUA
which deliberately violates almost all standards if it comes to e-mail.
Apparently both KDE and Mozilla consider more important to be compatible
with this certain MUA than to follow actual standards closely.

Reco

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

#225636 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-31 at 10:58, Reco wrote:

> On Fri, Jul 31, 2020 at 08:47:50AM -0400, The Wanderer wrote:
> 
>> On 2020-07-31 at 08:37, Reco wrote:

>> > It's a kmail thing. mutt, being a superior MUA, is not affected.
>> 
>> Can you clarify both A: in what way this is kmail-specific,
> 
> kmail apparently mistakes '-- t' for the MIME-separator.
> 
> The "offending" e-mail actually look like this:
> 
> == cut ==
> 
> -- t
> 
> --gKMricLos+KVdGMg
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> 
> -----BEGIN PGP SIGNATURE-----
> 
> == cut ==
> 
> Where "-- t" is a signature and is contained inside of a MIME-part, and
> "--gKMricLos+KVdGMg" is an actual RFC2045-compilant separator.
> 
> 
>> and B: what behaviors you're seeing in respect to mutt that are 
>> relevant here?
> 
> The lack of aforementioned confusion. The signature shows as the
> author intended, gpg validation happens as expected.

That does indeed look like a kmail bug, as you say.

But it's not what I understand the problem being discussed to be.

>> I see failure on my end, with Thunderbird, which is similar to what
>> I understand the problem being complained about to be. It is my 
>> understanding that the problem is rooted in (lack of) compliance
>> with a particular RFC, such that the resulting behavior will be
>> basically universal across all compliant mail clients.
> 
> RFC2045 is a standard, but we all know that certain proprietary MUA
> which deliberately violates almost all standards if it comes to
> e-mail. Apparently both KDE and Mozilla consider more important to be
> compatible with this certain MUA than to follow actual standards
> closely.

As indicated in another mail, I consider the relevant RFC to be RFC3676,
specifically section 4.3. RFC2045 had not entered my scope here, never
mind the proprietary MUA you're probably referring to (which, for all I
know, may not actually respect RFC3676 either - I should probably test
that, actually, next time I have some downtime while on-shift).

The original objector has also said that GPG/PGP has nothing to do with
his objection, so I suspect that this kmail bug is an unrelated side
issue.

For what it may be worth, in defense of Mozilla and the people who
inherited Thunderbird from them, Tomas' mails validate fine in
Thunderbird for me.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#225600 — Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]

[Multipart message — attachments visible in raw view] — view raw

(There is a non-negligible chance that I will be so nervous about the
possible contents of replies to this mail that I will not end up ever
reading them. I am occasionally subject to bouts of unreasoning terror
about such things.)

On 2020-07-31 at 05:28, tomas@tuxteam.de wrote:

> I know, I know. My signature is minimalistic: officially there
> SHOULD be a newline after the space after the dash after the --uh--
> dash.
> 
> I skip this newline. It's a quirk. I expect a teaspoon or two of 
> Postel's Principle [1] applied to me as I grant it to everyone else.

> [1] I know... again. There are people who don't really like Postel's 
> Principle. I do. I do not want to discuss with you.

I too like Postel's Principle [1], and I generally apply it to scopes
within my control (including this one), or at least try to do so.
However, that principle has two halves, and the "send" side is no less
important than the "receive" side.

I have never heard of, much less am in a position to use, any mail /
etc. software which supports detecting and reacting appropriately to the
variant of signature delimiter which you are apparently choosing to use.
Not all of the software which I use, and potentially not any of it, is
something whose behavior is within my scope of control to change in this
regard.

(Plus, this delimiter is something which is considerably more likely to
appear in an actual message body than is the standard [2] delimiter,
such that adding support for it would be likely to break things.)

By choosing to use such a variant rather than the standard form, you are
(apparently deliberately) choosing to not be interoperable with existing
software. To me, that does not appear to be consistent with Postel's
Principle; you are not being conservative in what you emit. I find it
hard to see how "personal idiosyncrasy" (i.e., "quirk") can be enough to
excuse this.

The effect is very minor in this case, and no worse than the (numerous)
people who - whether by choice, by ignorance, or by software limitation
- do not use a signature delimiter at all (especially since part of the
boilerplate which should be considered the signature - the word
"Cheers" - is being placed *before* the delimiter, and so would have to
be deleted by hand from a reply anyway). Both the principle and the
minor real-world effect, however, remain.

I am posting not so much because of your signature delimiter itself or
because I can't "be liberal in what I accept" in this regard as because
I am genuinely startled by your position on this, and even more by your
apparent position in regard to discussing it and the whys of it and so
forth. Of all the people whom I have seen more than briefly active on
this mailing list in the last several years, you would have been
literally the *last* I would have expected to see behave like an asshole
other than by accident - even behind myself.

(And now I'm nervous about the possibility that this will somehow
escalate to the point of mods shutting down the subthread for being
offtopic and pushing the Code of Conduct, with the use of that word as
part of the reason meaning specific consequences - even if only a
reprimand - directed at me. This is probably overreaction, but it's
still true.)

> (And please: take this all with a grain of salt).

I'm honestly not sure what you mean by this, in this context. To take
something with a grain of salt is to keep in mind the possibility that
it might not actually be true, and in this context, that reads to me as
"don't take this seriously, I don't necessarily actually mean it" - but
everything else you're saying here seems to indicate that you *do* mean
it, so discounting it on that basis would seem inapplicable.

I've had to check the calendar at least twice in the course of writing
this mail, just to make sure that this wasn't somehow April Fool's Day
or some other joke-based reason why you might be doing this without
actually being serious about it, since that's the only reason I can
think of why you would advise to not believe what you're saying while
still bothering to actually stick with the position in this way.

If you genuinely are serious about this, then I have lost a level of the
respect I had for you.


[1] "Be conservative in what you do, be liberal in what you accept from
others." https://en.wikipedia.org/wiki/Robustness_principle

[2] "Standard" in this context as in, defined by RFC. In this case,
that's RFC 3676:
https://en.wikipedia.org/wiki/Signature_block#Standard_delimiter
https://tools.ietf.org/html/rfc3676#section-4.3

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#225631 — Tomas has a signature which isn't a .sig

tomas@tuxteam.de wrote: 
> On Fri, Jul 31, 2020 at 08:55:22AM +0300, Andrei POPESCU wrote:
> > On Jo, 30 iul 20, 17:13:18, Brad Rogers wrote:
> > > On Thu, 30 Jul 2020 17:58:10 +0200
> > > <tomas@tuxteam.de> wrote:
> > > 
> > > Hello tomas@tuxteam.de,
> > > 
> > > *PLEASE* fix your sig separator.
> > 
> > What difference does it make for a signature like his ("-- t")?
> 
> (Thanks, Andrei :-)
> 
> And to the OP...
> 
> I know, I know. My signature is minimalistic: officially there SHOULD
> be a newline after the space after the dash after the --uh-- dash.
> 
> -- t

Tomas --

[Hey everybody, stand back, I'm going to try something new.]

Would you please consider changing your customary signoff to include an
extra space or other character in the first two columns?

 -- t       # Looks nice, almost the same
- - t       # A little weird, but very distinctive
++t         # That looks like it could be a classic
==t         # Implies that you are your message
+=t         # The joke gets weirder
..t         # Maybe three would be better?
...t        # Too much trouble
t           # Authoritative, but not self-important
[t]         # A stamp of approval, like a chop
't          # LISP is back

It is apparently driving some people crazy because their MUAs
are slightly broken.

If not, well, I certainly understand.

-dsr-

-- 
https://randomstring.org/~dsr/eula.html is hereby incorporated by reference.
                there is no justice, there is just us

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

#225633 — Re: [OT] Lisp is back (was: Tomas has a signature which isn't a .sig)

On Fri, Jul 31, 2020 at 11:47:22AM -0400, Dan Ritter wrote:
> [Hey everybody, stand back, I'm going to try something new.]
> 
> Would you please consider changing your customary signoff to include an
> extra space or other character in the first two columns?

All these displayed perfectly:

>  -- t       # Looks nice, almost the same
> - - t       # A little weird, but very distinctive
> ++t         # That looks like it could be a classic
> ==t         # Implies that you are your message
> +=t         # The joke gets weirder
> ..t         # Maybe three would be better?
> ...t        # Too much trouble
> t           # Authoritative, but not self-important
> [t]         # A stamp of approval, like a chop

But this - this is an abomination:

> 't          # LISP is back

It's not a LISP unless it features round braces!

( Reco )

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

#225638 — Re: [OT] Lisp is back

[Multipart message — attachments visible in raw view] — view raw

* 2020-07-31 18:53:58+03, Reco wrote:

> On Fri, Jul 31, 2020 at 11:47:22AM -0400, Dan Ritter wrote:
>> 't          # LISP is back
>
> It's not a LISP unless it features round braces!

That statement is not quite true but there are actually hidden
parentheses in 't. There is reader macro ' and expression 't is expanded
to (quote t).

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

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

Back to top | Article view | linux.debian.user

csiph-web