Re: Core files on Debian Trixie

[Thomas Pircher]

Thomas Pircher wrote:

I wanted to ask what the recommended way is
nowadays to disable corefiles globally.


The latest update for systemd has answered this:

| apt-listchanges: News
| -
|
| systemd (256~rc3-3) unstable; urgency=medium
|
|   - coredumps are now disabled by default via configuration files rather than
| an out-of-tree patch (installing the optional systemd-coredump package
| will enable them as before). As always, overriding via local drop-ins is
| possible if desired. The configuration files that respectively affect
| the system systemd instance, the user systemd instances and PAM sessions
| are:
|
| /usr/lib/systemd/system.conf.d/10-coredump-debian.conf
| /usr/lib/systemd/user.conf.d/10-coredump-debian.conf
| /usr/lib/sysctl.d/10-coredump-debian.conf
| /etc/security/limits.d/10-coredump-debian.conf

Thomas

[SOLVED] Re: config files - newline possible?

[Hans]

Hi Greg,
ah, I wasn't aware of this. This is really great news! And it will help me 
much. 

You made my day! Thank you very much.

Best regards

Hans 
> On Thu, Apr 11, 2024 at 08:42:20PM +0200, Hans wrote:
> > in my case it is the config freom from bootcdwrite, which is
> > bootcdwrite.conf.
> 
> says:
> 
> This file will be sourced as shell file.
> 
> So, you may use any valid "shell" (presumably sh) syntax, including
> backslash-newline for continuation.

Re: config files - newline possible?

[Greg Wooledge]

On Thu, Apr 11, 2024 at 08:42:20PM +0200, Hans wrote:
> in my case it is the config freom from bootcdwrite, which is bootcdwrite.conf.


says:

This file will be sourced as shell file.

So, you may use any valid "shell" (presumably sh) syntax, including
backslash-newline for continuation.

Re: config files - newline possible?

[Hans]

Hi Tomas,

in my case it is the config freom from bootcdwrite, which is bootcdwrite.conf.

The parm is NOT_TO_CD and as there are many and partly long pathnames, the 
line has increased rather long. So I want to shorten it.

But as it was said: there is no general way for this. So I just try some 
things out for this, and the next time again.

Thought I have something missed, but does not look so.

Thanks for all the help, I think this case caqn be closed. I will wait for one 
or two days and then mark this case as closed.

Cheers

Hans

> As Nicolas George says, "config-file" is too generic a term.
> If the above is a variable assignment, then you can escape the
> newlines with a backslash, like so
> 
> Do_not_write="path1/subfolder \
>   path1/subfolder2 \
>   ..."
> 
> Note that the backslash has to be the last character in the
> line. No extra whitespace after that (this is somewhat
> fragile). I prefer to put such things in here docs:
> 
> read -d '' Do_not_write <<"__END"
> this
> that
> the other
> __END
> 
> echo "Do_not_write"
> =>
> this
> that
> the other
> 
> Put attention to the quotes. In bash, type "help read" to learn
> about the options (it is a builtin, it has to).
> 
> Cheers

Re: config files - newline possible?

[tomas]

On Thu, Apr 11, 2024 at 05:56:05PM +0200, Hans wrote:
> Hi folks, 
> 
> O know in shell scripts it is possible, to seperate a looong line of commands 
> into several short lines.
> 
> But can this be done in config-files, too?
> 
> I have a files with the syntax like this:
> 
> Do_not_write="/path1/subfolder /path1/subfolder2 ... /pathX/subfolderX"

As Nicolas George says, "config-file" is too generic a term.
If the above is a variable assignment, then you can escape the
newlines with a backslash, like so

Do_not_write="path1/subfolder \
  path1/subfolder2 \
  ..."

Note that the backslash has to be the last character in the
line. No extra whitespace after that (this is somewhat
fragile). I prefer to put such things in here docs:

read -d '' Do_not_write <<"__END"
this
that
the other
__END

echo "Do_not_write"
=>
this
that
the other

Put attention to the quotes. In bash, type "help read" to learn
about the options (it is a builtin, it has to).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: config files - newline possible?

[Nicolas George]

Hans (12024-04-11):
> But can this be done in config-files, too?

Depends entirely on the software reading the config file. Some will use
\, some will use something else, some will offer no solution.

Regards,

-- 
  Nicolas George

Re: unzip files bigger than 4 GB

[Mike Castle]

Nvm, confused 2G with 4G.

Sorry for the noise.

On Wed, Jun 14, 2023 at 12:21 PM Mike Castle  wrote:
>
> It seems like it should.  I haven't upgraded my system yet:
>
> $ unzip -v | grep -e 6 -e LARGE
> UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
> USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
> LARGE_FILE_SUPPORT (large files over 2 GiB supported)
> ZIP64_SUPPORT (archives using Zip64 for large files supported)
> USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019)
>
> On Wed, Jun 14, 2023 at 11:19 AM Van Snyder  wrote:
> >
> > unzip v 6.0 (the version delivered with Debian 10) doesn't work with files 
> > bigger than 2^32 bytes.
> >
> > Is there an alternative program to do it?
> >

Re: unzip files bigger than 4 GB

[Mike Castle]

It seems like it should.  I haven't upgraded my system yet:

$ unzip -v | grep -e 6 -e LARGE
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
LARGE_FILE_SUPPORT (large files over 2 GiB supported)
ZIP64_SUPPORT (archives using Zip64 for large files supported)
USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.8, 13-Jul-2019)

On Wed, Jun 14, 2023 at 11:19 AM Van Snyder  wrote:
>
> unzip v 6.0 (the version delivered with Debian 10) doesn't work with files 
> bigger than 2^32 bytes.
>
> Is there an alternative program to do it?
>

Re: unzip files bigger than 4 GB

[Alexander V. Makartsev]

On 14.06.2023 23:19, Van Snyder wrote:
unzip v 6.0 (the version delivered with Debian 10) doesn't work with 
files bigger than 2^32 bytes.


Is there an alternative program to do it?


"7zip" is the best. It supports multiple formats and cross-platform.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: archive files

[Jonathan Dowland]

On Fri, May 05, 2023 at 12:07:09AM -0700, David Christensen wrote:

How does cpio(1) compare?
How about dump(8) and restore(8)?


I'd note that these (like tar) are both very old tools, and there are
many more modern ones perhaps worthy of consideration too. (which; is
left as an exercise for the reader)


AIUI dd(1) produces identical backup/ restore results.  Do you know
otherwise?


It does so by cloning the device underneath the filesystem, and thus,
the filesystem on top (and all the 'gaps' between); so yes, using dd(1)
can preserve any metadata that you care about. But the result is very
unwieldy to store or access, and you have to be sure the filesystem is
in a ready state to be cloned or information that has not hit the disk
(in data structures in memory or buffer cache) could be lost, so it's
not generally recommended as a tool to produce a file archive.

--
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[ellanios82]

On 12/2/20 6:39 AM, Kenneth Parker wrote:


> LINUX-LINUX or it is better to use SAMBA for everything_



 - maybe , it's practical to run windows as a Virtual Machine ?


.

 regards

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[Linux-Fan]

Kenneth Parker writes:

On Tue, Dec 1, 2020, 9:10 AM Anssi Saari a...@sci.fi>  
wrote:

   Kanito 73 kanit...@hotmail.com> writes:

   > At first I thought to use both SAMBA for LINUX-WINDOWS and maybe NFS for
   LINUX-LINUX but I used NFS long time
   > ago and it was slow as a turtle. Is there another networking service
   available that runs faster only for
   > LINUX-LINUX or it is better to use SAMBA for everything_

   Personally I don't bother with Samba for file sharing on my home network
   since Microsoft's seen the light and Windows 10 (Pro) includes NFS
   support. And no, NFS is not slow as a turtle.


[...]

Can you provide a Microsoft (or related) link to the Windows NFS Support? (On  
this List. You do not need to cc me). 


The straight-forward explanation:
https://graspingtech.com/mount-nfs-share-windows-10/

The official documentation:
https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview

I have not used NFS support on Windows yet :)

HTH
Linux-Fan

öö


pgpp1yvxfvejb.pgp
Description: PGP signature

Re: 780 files in /usr/share/zoneinfo/

[Andrei POPESCU]

On Ma, 01 dec 20, 08:11:01, Robert Tonkavich wrote:
> I am very sorry for my Input.

What is there to be sorry about?

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


signature.asc
Description: PGP signature

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[Kenneth Parker]

On Tue, Dec 1, 2020, 9:10 AM Anssi Saari  wrote:

> Kanito 73  writes:
>
> > At first I thought to use both SAMBA for LINUX-WINDOWS and maybe NFS for
> LINUX-LINUX but I used NFS long time
> > ago and it was slow as a turtle. Is there another networking service
> available that runs faster only for
> > LINUX-LINUX or it is better to use SAMBA for everything_
>
> Personally I don't bother with Samba for file sharing on my home network
> since Microsoft's seen the light and Windows 10 (Pro) includes NFS
> support. And no, NFS is not slow as a turtle.
>

Hello Anssi,

I am helping a friend make Windows 10 Pro talk to a variation of Debian
(Linux Mint 20).  Separately, I am running Windows 8.1, under QEMU-KVM on
Bullseye.

Can you provide a Microsoft (or related) link to the Windows NFS Support?
(On this List. You do not need to cc me).

Thanks!

Kenneth Parker

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[Anssi Saari]

Kanito 73  writes:

> At first I thought to use both SAMBA for LINUX-WINDOWS and maybe NFS for 
> LINUX-LINUX but I used NFS long time
> ago and it was slow as a turtle. Is there another networking service 
> available that runs faster only for
> LINUX-LINUX or it is better to use SAMBA for everything_

Personally I don't bother with Samba for file sharing on my home network
since Microsoft's seen the light and Windows 10 (Pro) includes NFS
support. And no, NFS is not slow as a turtle.

Re: 780 files in /usr/share/zoneinfo/

[Robert Tonkavich]

I am very sorry for my Input.


On Tue, Dec 1, 2020 at 12:28 AM David Wright 
wrote:

> On Mon 30 Nov 2020 at 18:25:00 (-0600), John Hasler wrote:
> > Stefan writes:
> > > Is there leap-second information in the zoneinfo files?
> >
> > No, but that is where is should be.
>
> It appears to be present, at least in the difference between the
> "posix" and "right" trees; and its history can be demonstrated:
>
> $ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"0401.00 "$j-apr"
> ; done
> $ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"1001.00 "$j-oct"
> ; done
> $ TZ=right/UTC dirr-time-in-full -Gg
> .:
> total 0
> -rw-r- 1 0 1971-04-01 00:00:00.0 + 1971-apr
> -rw-r- 1 0 1971-10-01 00:00:00.0 + 1971-oct
> -rw-r- 1 0 1972-04-01 00:00:00.0 + 1972-apr
> -rw-r- 1 0 1972-09-30 23:59:59.0 + 1972-oct
> -rw-r- 1 0 1973-03-31 23:59:58.0 + 1973-apr
> -rw-r- 1 0 1973-09-30 23:59:58.0 + 1973-oct
> -rw-r- 1 0 1974-03-31 23:59:57.0 + 1974-apr
> -rw-r- 1 0 1974-09-30 23:59:57.0 + 1974-oct
> -rw-r- 1 0 1975-03-31 23:59:56.0 + 1975-apr
> -rw-r- 1 0 1975-09-30 23:59:56.0 + 1975-oct
> -rw-r- 1 0 1976-03-31 23:59:55.0 + 1976-apr
> -rw-r- 1 0 1976-09-30 23:59:55.0 + 1976-oct
> -rw-r- 1 0 1977-03-31 23:59:54.0 + 1977-apr
> -rw-r- 1 0 1977-09-30 23:59:54.0 + 1977-oct
> -rw-r- 1 0 1978-03-31 23:59:53.0 + 1978-apr
> -rw-r- 1 0 1978-09-30 23:59:53.0 + 1978-oct
> -rw-r- 1 0 1979-03-31 23:59:52.0 + 1979-apr
> -rw-r- 1 0 1979-09-30 23:59:52.0 + 1979-oct
> -rw-r- 1 0 1980-03-31 23:59:51.0 + 1980-apr
> -rw-r- 1 0 1980-09-30 23:59:51.0 + 1980-oct
> -rw-r- 1 0 1981-03-31 23:59:51.0 + 1981-apr
> -rw-r- 1 0 1981-09-30 23:59:50.0 + 1981-oct
> -rw-r- 1 0 1982-03-31 23:59:50.0 + 1982-apr
> -rw-r- 1 0 1982-09-30 23:59:49.0 + 1982-oct
> -rw-r- 1 0 1983-03-31 23:59:49.0 + 1983-apr
> -rw-r- 1 0 1983-09-30 23:59:48.0 + 1983-oct
> -rw-r- 1 0 1984-03-31 23:59:48.0 + 1984-apr
> -rw-r- 1 0 1984-09-30 23:59:48.0 + 1984-oct
> -rw-r- 1 0 1985-03-31 23:59:48.0 + 1985-apr
> -rw-r- 1 0 1985-09-30 23:59:47.0 + 1985-oct
> -rw-r- 1 0 1986-03-31 23:59:47.0 + 1986-apr
> -rw-r- 1 0 1986-09-30 23:59:47.0 + 1986-oct
> -rw-r- 1 0 1987-03-31 23:59:47.0 + 1987-apr
> -rw-r- 1 0 1987-09-30 23:59:47.0 + 1987-oct
> -rw-r- 1 0 1988-03-31 23:59:46.0 + 1988-apr
> -rw-r- 1 0 1988-09-30 23:59:46.0 + 1988-oct
> -rw-r- 1 0 1989-03-31 23:59:46.0 + 1989-apr
> -rw-r- 1 0 1989-09-30 23:59:46.0 + 1989-oct
> -rw-r- 1 0 1990-03-31 23:59:45.0 + 1990-apr
> -rw-r- 1 0 1990-09-30 23:59:45.0 + 1990-oct
> -rw-r- 1 0 1991-03-31 23:59:44.0 + 1991-apr
> -rw-r- 1 0 1991-09-30 23:59:44.0 + 1991-oct
> -rw-r- 1 0 1992-03-31 23:59:44.0 + 1992-apr
> -rw-r- 1 0 1992-09-30 23:59:43.0 + 1992-oct
> -rw-r- 1 0 1993-03-31 23:59:43.0 + 1993-apr
> -rw-r- 1 0 1993-09-30 23:59:42.0 + 1993-oct
> -rw-r- 1 0 1994-03-31 23:59:42.0 + 1994-apr
> -rw-r- 1 0 1994-09-30 23:59:41.0 + 1994-oct
> -rw-r- 1 0 1995-03-31 23:59:41.0 + 1995-apr
> -rw-r- 1 0 1995-09-30 23:59:41.0 + 1995-oct
> -rw-r- 1 0 1996-03-31 23:59:40.0 + 1996-apr
> -rw-r- 1 0 1996-09-30 23:59:40.0 + 1996-oct
> -rw-r- 1 0 1997-03-31 23:59:40.0 + 1997-apr
> -rw-r- 1 0 1997-09-30 23:59:39.0 + 1997-oct
> -rw-r- 1 0 1998-03-31 23:59:39.0 + 1998-apr
> -rw-r- 1 0 1998-09-30 23:59:39.0 + 1998-oct
> -rw-r- 1 0 1999-03-31 23:59:38.0 + 1999-apr
> -rw-r- 1 0 1999-09-30 23:59:38.0 + 1999-oct
> -rw-r- 1 0 2000-03-31 23:59:38.0 + 2000-apr
> -rw-r- 1 0 2000-09-30 23:59:38.0 + 2000-oct
> -rw-r- 1 0 2001-03-31 23:59:38.0 + 2001-apr
> -rw-r- 1 0 2001-09-30 23:59:38.0 + 2001-oct
> -rw-r- 1 0 2002-03-31 23:59:38.0 + 2002-apr
> -rw-r- 1 0 2002-09-30 23:59:38.0 + 2002-oct
> -rw-r- 1 0 2003-03-31 23:59:38.0 + 2003-apr
> -rw-r- 1 0 2003-09-30 23:59:38.0 + 2003-oct
> -rw-r- 1 0 2004-03-31 23:59:38.0 + 2004-apr
> -rw-r- 1 0 2004-09-30 23:59:38.0 + 2004-oct
> -rw-r- 1 0 2005-03-31 23:59:38.0 + 2005-apr
> -rw-r- 1 0 2005-09-30 23:59:38.0 + 2005-oct
> -rw-r- 1 0 

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 30 Nov 2020 at 18:25:00 (-0600), John Hasler wrote:
> Stefan writes:
> > Is there leap-second information in the zoneinfo files?
> 
> No, but that is where is should be.

It appears to be present, at least in the difference between the
"posix" and "right" trees; and its history can be demonstrated:

$ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"0401.00 "$j-apr" ; done
$ for j in $(seq 1971 2020) ; do TZ=UTC touch -t "$j"1001.00 "$j-oct" ; done
$ TZ=right/UTC dirr-time-in-full -Gg
.:
total 0
-rw-r- 1 0 1971-04-01 00:00:00.0 + 1971-apr
-rw-r- 1 0 1971-10-01 00:00:00.0 + 1971-oct
-rw-r- 1 0 1972-04-01 00:00:00.0 + 1972-apr
-rw-r- 1 0 1972-09-30 23:59:59.0 + 1972-oct
-rw-r- 1 0 1973-03-31 23:59:58.0 + 1973-apr
-rw-r- 1 0 1973-09-30 23:59:58.0 + 1973-oct
-rw-r- 1 0 1974-03-31 23:59:57.0 + 1974-apr
-rw-r- 1 0 1974-09-30 23:59:57.0 + 1974-oct
-rw-r- 1 0 1975-03-31 23:59:56.0 + 1975-apr
-rw-r- 1 0 1975-09-30 23:59:56.0 + 1975-oct
-rw-r- 1 0 1976-03-31 23:59:55.0 + 1976-apr
-rw-r- 1 0 1976-09-30 23:59:55.0 + 1976-oct
-rw-r- 1 0 1977-03-31 23:59:54.0 + 1977-apr
-rw-r- 1 0 1977-09-30 23:59:54.0 + 1977-oct
-rw-r- 1 0 1978-03-31 23:59:53.0 + 1978-apr
-rw-r- 1 0 1978-09-30 23:59:53.0 + 1978-oct
-rw-r- 1 0 1979-03-31 23:59:52.0 + 1979-apr
-rw-r- 1 0 1979-09-30 23:59:52.0 + 1979-oct
-rw-r- 1 0 1980-03-31 23:59:51.0 + 1980-apr
-rw-r- 1 0 1980-09-30 23:59:51.0 + 1980-oct
-rw-r- 1 0 1981-03-31 23:59:51.0 + 1981-apr
-rw-r- 1 0 1981-09-30 23:59:50.0 + 1981-oct
-rw-r- 1 0 1982-03-31 23:59:50.0 + 1982-apr
-rw-r- 1 0 1982-09-30 23:59:49.0 + 1982-oct
-rw-r- 1 0 1983-03-31 23:59:49.0 + 1983-apr
-rw-r- 1 0 1983-09-30 23:59:48.0 + 1983-oct
-rw-r- 1 0 1984-03-31 23:59:48.0 + 1984-apr
-rw-r- 1 0 1984-09-30 23:59:48.0 + 1984-oct
-rw-r- 1 0 1985-03-31 23:59:48.0 + 1985-apr
-rw-r- 1 0 1985-09-30 23:59:47.0 + 1985-oct
-rw-r- 1 0 1986-03-31 23:59:47.0 + 1986-apr
-rw-r- 1 0 1986-09-30 23:59:47.0 + 1986-oct
-rw-r- 1 0 1987-03-31 23:59:47.0 + 1987-apr
-rw-r- 1 0 1987-09-30 23:59:47.0 + 1987-oct
-rw-r- 1 0 1988-03-31 23:59:46.0 + 1988-apr
-rw-r- 1 0 1988-09-30 23:59:46.0 + 1988-oct
-rw-r- 1 0 1989-03-31 23:59:46.0 + 1989-apr
-rw-r- 1 0 1989-09-30 23:59:46.0 + 1989-oct
-rw-r- 1 0 1990-03-31 23:59:45.0 + 1990-apr
-rw-r- 1 0 1990-09-30 23:59:45.0 + 1990-oct
-rw-r- 1 0 1991-03-31 23:59:44.0 + 1991-apr
-rw-r- 1 0 1991-09-30 23:59:44.0 + 1991-oct
-rw-r- 1 0 1992-03-31 23:59:44.0 + 1992-apr
-rw-r- 1 0 1992-09-30 23:59:43.0 + 1992-oct
-rw-r- 1 0 1993-03-31 23:59:43.0 + 1993-apr
-rw-r- 1 0 1993-09-30 23:59:42.0 + 1993-oct
-rw-r- 1 0 1994-03-31 23:59:42.0 + 1994-apr
-rw-r- 1 0 1994-09-30 23:59:41.0 + 1994-oct
-rw-r- 1 0 1995-03-31 23:59:41.0 + 1995-apr
-rw-r- 1 0 1995-09-30 23:59:41.0 + 1995-oct
-rw-r- 1 0 1996-03-31 23:59:40.0 + 1996-apr
-rw-r- 1 0 1996-09-30 23:59:40.0 + 1996-oct
-rw-r- 1 0 1997-03-31 23:59:40.0 + 1997-apr
-rw-r- 1 0 1997-09-30 23:59:39.0 + 1997-oct
-rw-r- 1 0 1998-03-31 23:59:39.0 + 1998-apr
-rw-r- 1 0 1998-09-30 23:59:39.0 + 1998-oct
-rw-r- 1 0 1999-03-31 23:59:38.0 + 1999-apr
-rw-r- 1 0 1999-09-30 23:59:38.0 + 1999-oct
-rw-r- 1 0 2000-03-31 23:59:38.0 + 2000-apr
-rw-r- 1 0 2000-09-30 23:59:38.0 + 2000-oct
-rw-r- 1 0 2001-03-31 23:59:38.0 + 2001-apr
-rw-r- 1 0 2001-09-30 23:59:38.0 + 2001-oct
-rw-r- 1 0 2002-03-31 23:59:38.0 + 2002-apr
-rw-r- 1 0 2002-09-30 23:59:38.0 + 2002-oct
-rw-r- 1 0 2003-03-31 23:59:38.0 + 2003-apr
-rw-r- 1 0 2003-09-30 23:59:38.0 + 2003-oct
-rw-r- 1 0 2004-03-31 23:59:38.0 + 2004-apr
-rw-r- 1 0 2004-09-30 23:59:38.0 + 2004-oct
-rw-r- 1 0 2005-03-31 23:59:38.0 + 2005-apr
-rw-r- 1 0 2005-09-30 23:59:38.0 + 2005-oct
-rw-r- 1 0 2006-03-31 23:59:37.0 + 2006-apr
-rw-r- 1 0 2006-09-30 23:59:37.0 + 2006-oct
-rw-r- 1 0 2007-03-31 23:59:37.0 + 2007-apr
-rw-r- 1 0 2007-09-30 23:59:37.0 + 2007-oct
-rw-r- 1 0 2008-03-31 

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 30 Nov 2020 at 17:28:50 (-0500), Stefan Monnier wrote:
> > Finally, competing with the politicians, the scientists have
> > complicated things with their atomic time and leap seconds.
> 
> Is there leap-second information in the zoneinfo files?
> Isn't this info "global" (i.e. not specific to particular time zones)?
> 
> 
> Stefan "who for some reason presumed it's kept elsewhere but
> couldn't say why"

AIUI:

$ TZ=posix/America/Chicago date; TZ=right/America/Chicago date
Mon Nov 30 18:45:34 CST 2020
Mon Nov 30 18:45:07 CST 2020
$ 

I don't know whether their history is encoded somewhere. I only
recall the first leap second because IIRC the BBC changed the
pips about the same time (making the sixth pip longer).

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

Stefan writes:
> Is there leap-second information in the zoneinfo files?

No, but that is where is should be.

> Isn't this info "global" (i.e. not specific to particular time zones)?

It is specific to a particular *time*.  
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[Stefan Monnier]

> Finally, competing with the politicians, the scientists have
> complicated things with their atomic time and leap seconds.

Is there leap-second information in the zoneinfo files?
Isn't this info "global" (i.e. not specific to particular time zones)?


Stefan "who for some reason presumed it's kept elsewhere but
couldn't say why"

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 30 Nov 2020 at 13:13:27 (-0500), Robert Tonkavich wrote:
> 
> There are only 24 Time Zones that Encompass the Earth. Is 780 files
> overboard?
> 
> I think Yes.

You might like to read this take on the complexity of time zones as
actually observed. As you can read there, even countries and states
are not sufficient to express the granularity, so many of the links
provided into the dataset are at the level of cities, islands, etc.

https://qz.com/357697/time-zone-deviants-part-i-the-strangest-time-zones-in-the-world/

You can also observe how far most people live from there own solar
time by googling   solar time vs local time   and selecting "images".

Another complication that you seem unaware of is that the dataset
also expresses the history of timezone regions, and you can observe
some of the workload in refining this data by perusing the
/usr/share/doc/tzdata/changelog.gz file.

You need this historical information to be able to correctly interpret
any records kept in local time. This fragment shows how local time
lurched around in early wartime Britain:

$ zdump -V -c 1939,1943 GB
GB  Sun Apr 16 01:59:59 1939 UT = Sun Apr 16 01:59:59 1939 GMT isdst=0 gmtoff=0
GB  Sun Apr 16 02:00:00 1939 UT = Sun Apr 16 03:00:00 1939 BST isdst=1 
gmtoff=3600
GB  Sun Nov 19 01:59:59 1939 UT = Sun Nov 19 02:59:59 1939 BST isdst=1 
gmtoff=3600
GB  Sun Nov 19 02:00:00 1939 UT = Sun Nov 19 02:00:00 1939 GMT isdst=0 gmtoff=0
GB  Sun Feb 25 01:59:59 1940 UT = Sun Feb 25 01:59:59 1940 GMT isdst=0 gmtoff=0
GB  Sun Feb 25 02:00:00 1940 UT = Sun Feb 25 03:00:00 1940 BST isdst=1 
gmtoff=3600
GB  Sun May  4 00:59:59 1941 UT = Sun May  4 01:59:59 1941 BST isdst=1 
gmtoff=3600
GB  Sun May  4 01:00:00 1941 UT = Sun May  4 03:00:00 1941 BDST isdst=1 
gmtoff=7200
GB  Sun Aug 10 00:59:59 1941 UT = Sun Aug 10 02:59:59 1941 BDST isdst=1 
gmtoff=7200
GB  Sun Aug 10 01:00:00 1941 UT = Sun Aug 10 02:00:00 1941 BST isdst=1 
gmtoff=3600
GB  Sun Apr  5 00:59:59 1942 UT = Sun Apr  5 01:59:59 1942 BST isdst=1 
gmtoff=3600
GB  Sun Apr  5 01:00:00 1942 UT = Sun Apr  5 03:00:00 1942 BDST isdst=1 
gmtoff=7200
GB  Sun Aug  9 00:59:59 1942 UT = Sun Aug  9 02:59:59 1942 BDST isdst=1 
gmtoff=7200
GB  Sun Aug  9 01:00:00 1942 UT = Sun Aug  9 02:00:00 1942 BST isdst=1 
gmtoff=3600
$ 

Finally, competing with the politicians, the scientists have
complicated things with their atomic time and leap seconds.

> On Mon, Nov 30, 2020 at 1:00 PM Charlie Gibbs  wrote:
> > On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick" wrote:
> >
> >  > If you aren't in to trying to modify some sort of
> >  > embedded system to do something it wasn't originally designed to
> >  > do then ram and storage are getting cheaper by the day and some
> >  > things just aren't worth worrying about.
> >
> > To a great extent that's true, although there is the danger
> > of falling into the attitude that abundance justifies waste.
> > (This can once again make things worth worrying about,
> > well before it might be necessary if you do things efficiently.)
> >
> > However, there's another consideration: the KISS principle.
> > A system that needs 780 files is going to be a lot more complex
> > and difficult to understand than one that gets by with one or two.
> > This can have serious impacts on reliability and maintainability.
> >
> > I'm seeing more and more cases of systems falling apart because
> > they're becoming too complex to administer.  Some of this is because
> > they "just grew", without proper planning and pruning.  Some of it
> > is due to that effect described by Blaise Pascal, who once apologized
> > for the length of the letter he was writing because he didn't have
> > time to make it shorter.  And some, I'm sad to say, are a deliberate
> > effort at obfuscation: an old trick long used by politicians to keep
> > the electorate blissfully ignorant of their shenanigans, and now
> > adopted by some equally nefarious system designers.

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[deloptes]

Greg Wooledge wrote:

> This is completely inaccurate.  Time zones were not devised by drawing
> equally-spaced meridian lines along the globe.  They were invented
> by political entities.  They aren't static, either -- they change
> from time to time, as political regimes change.
> 
> Time zones are not tied to the geography of the earth, nor even to
> political boundaries.  There are places that have two competing time
> zones, one time zone for some of the people living there, and another
> for the rest of the people living there.
> 
> Time zones aren't guaranteed to deviate from UTC by an integral number
> of hours.  There are some that are off by a fraction of an hour.
> 
> There are time zones pairings that differ from each other part of the
> year, and concide with each other the rest of the year.
> 
> Try to think of the strangest, most obtuse, most ridiculous rules you
> can -- real time zones are WORSE than that.

It is a total mess - if it wasn't those files, it were be chaos.

In fact I admire people 3000y ago could manage time better than we do.

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

Robert Tonkavich writes:
> There are only 24 Time Zones that Encompass the Earth.

It's far more complicated than that.  There are 24 geographic time zones
but zoneinfo has to deal with local civil time as regulated, often
rather capriciously, by national, regional, and local governments.
Examples: Do you know how many versions of DST/Summer Time there are?
Did you know that some jurisdictions set their clocks 1/2 hour away from
what their geographic time zone indicates?  That many jurisdictions
ignore their geographic time zone and use a politically convenient one?
That some countries have "moved" across the international date line?
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[Michael Stone]

On Mon, Nov 30, 2020 at 09:44:13AM -0800, Charlie Gibbs wrote:

However, there's another consideration: the KISS principle.
A system that needs 780 files is going to be a lot more complex
and difficult to understand than one that gets by with one or two.


Actually, it's a lot more straightforward and reliant on simple 
principles than one big file with hundreds of special cases. 

Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

On Mon, Nov 30, 2020 at 01:13:27PM -0500, Robert Tonkavich wrote:
> There are only 24 Time Zones that Encompass the Earth. Is 780 files
> overboard?
> 
> I think Yes.

This is completely inaccurate.  Time zones were not devised by drawing
equally-spaced meridian lines along the globe.  They were invented
by political entities.  They aren't static, either -- they change
from time to time, as political regimes change.

Time zones are not tied to the geography of the earth, nor even to
political boundaries.  There are places that have two competing time
zones, one time zone for some of the people living there, and another
for the rest of the people living there.

Time zones aren't guaranteed to deviate from UTC by an integral number
of hours.  There are some that are off by a fraction of an hour.

There are time zones pairings that differ from each other part of the
year, and concide with each other the rest of the year.

Try to think of the strangest, most obtuse, most ridiculous rules you
can -- real time zones are WORSE than that.

Re: 780 files in /usr/share/zoneinfo/

[Robert Tonkavich]

All,

There are only 24 Time Zones that Encompass the Earth. Is 780 files
overboard?

I think Yes.

Robert Tonkavich

On Mon, Nov 30, 2020 at 1:00 PM Charlie Gibbs  wrote:

> On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick"
>  wrote:
>
>  > If you aren't in to trying to modify some sort of
>  > embedded system to do something it wasn't originally designed to
>  > do then ram and storage are getting cheaper by the day and some
>  > things just aren't worth worrying about.
>
> To a great extent that's true, although there is the danger
> of falling into the attitude that abundance justifies waste.
> (This can once again make things worth worrying about,
> well before it might be necessary if you do things efficiently.)
>
> However, there's another consideration: the KISS principle.
> A system that needs 780 files is going to be a lot more complex
> and difficult to understand than one that gets by with one or two.
> This can have serious impacts on reliability and maintainability.
>
> I'm seeing more and more cases of systems falling apart because
> they're becoming too complex to administer.  Some of this is because
> they "just grew", without proper planning and pruning.  Some of it
> is due to that effect described by Blaise Pascal, who once apologized
> for the length of the letter he was writing because he didn't have
> time to make it shorter.  And some, I'm sad to say, are a deliberate
> effort at obfuscation: an old trick long used by politicians to keep
> the electorate blissfully ignorant of their shenanigans, and now
> adopted by some equally nefarious system designers.
>
> --
> /~\  Charlie Gibbs  |  Microsoft is a dictatorship.
> \ /|  Apple is a cult.
>   X   I'm really at ac.dekanfrus |  Linux is anarchy.
> / \  if you read it the right way.  |  Pick your poison.
>
>

-- 
Thank You

Robert M Tonkavich
989-205-2683

Re: 780 files in /usr/share/zoneinfo/

[Charlie Gibbs]

On Mon, 30 Nov 2020 14:10:02 +0100 "Martin McCormick" 
 wrote:


> If you aren't in to trying to modify some sort of
> embedded system to do something it wasn't originally designed to
> do then ram and storage are getting cheaper by the day and some
> things just aren't worth worrying about.

To a great extent that's true, although there is the danger
of falling into the attitude that abundance justifies waste.
(This can once again make things worth worrying about,
well before it might be necessary if you do things efficiently.)

However, there's another consideration: the KISS principle.
A system that needs 780 files is going to be a lot more complex
and difficult to understand than one that gets by with one or two.
This can have serious impacts on reliability and maintainability.

I'm seeing more and more cases of systems falling apart because
they're becoming too complex to administer.  Some of this is because
they "just grew", without proper planning and pruning.  Some of it
is due to that effect described by Blaise Pascal, who once apologized
for the length of the letter he was writing because he didn't have
time to make it shorter.  And some, I'm sad to say, are a deliberate
effort at obfuscation: an old trick long used by politicians to keep
the electorate blissfully ignorant of their shenanigans, and now
adopted by some equally nefarious system designers.

--
/~\  Charlie Gibbs  |  Microsoft is a dictatorship.
\ /|  Apple is a cult.
 X   I'm really at ac.dekanfrus |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

Michael Stone  writes:
> The kernel, compressed, is larger than that. The initrd needed to boot the
> kernel is also typically larger than that. A modern system has more CPU
> cache than that. At some point trying to save bytes is a waste of 
> developer
> and administrator effort, and 3.5MB in 2020 is well past that point. If 
> you
> want a minimal system, debian isn't for you. Instead, you'll need to hand
> craft every file to make sure it isn't "wasting space". If that's your
> thing, great. But it's just not a focus for debian.

About the only place one still needs to think this way is
with embedded systems where the computer is there to manage a
machine of some kind, anything from a lathe to a food processor
to a cement mixer, whatever .  

General-purpose computers are optimized to have as many
resources as one can cram in to a higher and higher-density box
so a few MB here or there aren't noticed but embedded systems are
optimized with different priorities and one may discover that
this box may be lightning fast but a bit skimpy on data storage.

I am thinking of things such as cable TV boxes and
dedicated audio-visual appliances that use DSP to emulate complex
and expensive hardware by using mathematical algorithms that
cause the system to decode digital TV signals or route internet
traffic rapidly.

If you aren't in to trying to modify some sort of
embedded system to do something it wasn't originally designed to
do then ram and storage are getting cheaper by the day and some
things just aren't worth worrying about.

Martin McCormick

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

Andy Smith  writes:
> Hi Martin,
> 
> On Sat, Nov 21, 2020 at 08:48:51PM -0600, Martin McCormick wrote:
> > find . -name "*" -exec ls -l {} \;  \
> > |grep -F / \
> > | awk ' { total += $5 } END { print total }'
> >
> >   That usually just adds the sizes of all the files it can
> > find all the way through the tree.
> >
> >   If this is not an accurate way to determine how many
> > bytes there are in a directory then that would be the reason for
> > the discrepancy.
> 
> The same file can be reached by multiple names. So by doing this you
> end up, in this case, with a ~256x amplification.
> 
> A simple "du -sh" does a better job here!
> 
> > cron only works in the time zone for wherever the TZ for the
> > system is set.
> 
> Ah, I see. I've never tried it but I believe that systemd timers can
> have a time spec that includes time zone, so you can set timers that
> fire on a different time zone to that used by the rest of the system.
> 
> $ systemd-analyze calendar '11:00 Europe/London'
>   Original form: 11:00 Europe/London
> Normalized form: *-*-* 11:00:00 Europe/London
> Next elapse: Sun 2020-11-22 11:00:00 UTC
>From now: 6h left
> 
> Cheers,

I do appreciate being corrected, here.  What we really want to
know, here, is how much precious disk space is occupied by
whatever data base we are interested in.  Links make copies of
files appear to exist when the data were only written once even

Martin

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[mick crane]

On 2020-11-28 03:08, Kanito 73 wrote:

Hello

I have up and running two dual boot LINUX (Debian 10) and WINDOWS 10
machines and want to connect them to be able to work without spending
time copying files from/to on a usb device, have multiple copies of a
same file, etc.


You can use WinSCP to to and fro from the windows side using ssh with 
keys.

Can probably have a ssh server on Windows but never fancied that.

mick
--
Key ID4BFEBB31

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[deloptes]

Kanito 73 wrote:

> At first I thought to use both SAMBA for LINUX-WINDOWS and maybe NFS for
> LINUX-LINUX but I used NFS long time ago and it was slow as a turtle. Is
> there another networking service available that runs faster only for
> LINUX-LINUX or it is better to use SAMBA for everything_

I do not know why it should be "slow as a turtle" it usually depends on the
network and mostly on the drive speed.
I use NFS for Linux and Samba for Windows for more than 15y already. If NFS
is too slow use the SAMBA in Linux too.
I split my setup of two machines into a server and desktop. I can execute
tasks on the server too, start VMs there or whatever - same for the PC. It
works very good.

Re: Sharing files LINUX-LINUX / LINUX-WINDOWS / WINDOWS-WINDOWS

[Joe]

On Sat, 28 Nov 2020 03:08:41 +
Kanito 73  wrote:

> Hello
> 
> I have up and running two dual boot LINUX (Debian 10) and WINDOWS 10
> machines and want to connect them to be able to work without spending
> time copying files from/to on a usb device, have multiple copies of a
> same file, etc.
> 
> I may need to copy from Linux to Windows, sometimes from Windows to
> Linux, other ones from Linux to Linux, and so... Would you recommend
> me to use SAMBA for all of that? All data partitions are NTFS and
> there's no need to set permissions since all data are audio, video,
> image and document files and the only user is me.
> 
> At first I thought to use both SAMBA for LINUX-WINDOWS and maybe NFS
> for LINUX-LINUX but I used NFS long time ago and it was slow as a
> turtle. Is there another networking service available that runs
> faster only for LINUX-LINUX or it is better to use SAMBA for
> everything_
> 
> Good nite all 

The general rule is that if Windows is involved, use Samba for
everything. It can be a bit tricky to get more than one version of
Windows working with the same Samba configuration, but you don't have
that problem.

-- 
Joe

Re: 780 files in /usr/share/zoneinfo/

[Michael Stone]

On Tue, Nov 24, 2020 at 01:07:10PM -0500, Greg Wooledge wrote:

As I said, figuring out the valid TZ strings for a given location on
our planet is a challenge.  Unfortunately, the ... fine people ... who
devised the standards for this sort of thing thought it would be really
super clever to treat ALL unknown TZ strings as if they were "UTC0".


It's the result of a layering of standards. The old pre-TZ-file way of 
doing things parsed the TZ string to create the rule. You can call your 
timezones anything you want (you're making the rule!) and the degenerate 
case has a zero offset.



unicorn:~$ TZ=PST date ; TZ=PST8PDT date ; TZ=America/Los_Angeles date
Tue Nov 24 17:56:16 PST 2020
Tue Nov 24 09:56:16 PST 2020
Tue Nov 24 09:56:16 PST 2020

To add insult to injury, the string that date(1) gives you as OUTPUT
(in this case, "PST") is not accepted by the very same program as INPUT.
In fact, I don't know of any way to get date(1) to give an output string
that you can use as a valid TZ input string.



date ; date --iso=seconds ; date --iso=seconds -d `date --iso=seconds`

Tue 24 Nov 2020 08:50:29 PM EST
2020-11-24T20:50:29-05:00
2020-11-24T20:50:29-05:00

Just use numeric timezone offsets for anything being done 
programatically. It's not possible to use human-friendly timezone names 
for that because they're ambiguous. 


And use ISO8601 format for everything. Seriously, everything.


Outside of the USA, you'll probably need to go with the "nearest big
city" names that are the current vogue.  The best way to use those is
probably "ls /usr/share/zoneinfo", choose your continent, and then
(for example) "ls /usr/share/zoneinfo/Asia".  Then pick a city from
the resulting set, and pray.

If there's a better way, I don't know it.


most people just configuring their time zone using their gui 
configuration manager. if you choose not to do it that way then yeah, 
you'll have to do some research. also, as suggested upthread, most 
people do this at install time and never touch it again.

Re: 780 files in /usr/share/zoneinfo/

[Mike McClain]

On Tue, Nov 24, 2020 at 02:48:12PM +0100, Kamil Jo?ca wrote:
> Mike McClain  writes:
>
> [...]
> > Locale is another area where there is a lot of data that the
> > average user, I suspect, has no use for and localepurge in Debian, at
> > least, is hamstrung by the packagers, hooking it to dpkg and
> I disagree.
> Even quite small enterprises work internationally now.
> And it  is important to me if my coworker from Bangalore has working
> time or is in bed before calling him :)
> So "TZ=Asia/Kolkata date" is your friend :)
>
>
> KJ
> --
> http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

I'm quite sure you're right for businesses.
I wonder if there is any way to tell how many Linux installations are
being used by businesses versus are used by people like me who use it
as a home computer with no business in mind?
Be well,
Mike
--
Telling pious lies to trusting children is a form of abuse,
plain and simple. - Daniel Dennett, 2010-01-12

Re: 780 files in /usr/share/zoneinfo/

[Kamil Jońca]

rhkra...@gmail.com writes:

> On Tuesday, November 24, 2020 01:07:10 PM Greg Wooledge wrote:
>> As I said, figuring out the valid TZ strings for a given location on
>> our planet is a challenge.  Unfortunately, the ... fine people ... who
>> devised the standards for this sort of thing thought it would be really
>> super clever to treat ALL unknown TZ strings as if they were "UTC0".
>
> ...
>
>> Outside of the USA, you'll probably need to go with the "nearest big
>> city" names that are the current vogue.  The best way to use those is
>> probably "ls /usr/share/zoneinfo", choose your continent, and then
>> (for example) "ls /usr/share/zoneinfo/Asia".  Then pick a city from
>> the resulting set, and pray.
>> 
>> If there's a better way, I don't know it.
>
> Just google [time in ] (e.g., time in China).  No need to find 
> a 
> TZ string.

Heh. OP concers about 3.5 MB of locale tz data and you want to install
browser which is usually much bigger?
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Mon 23 Nov 2020 at 22:16:47 (-0600), Mike McClain wrote:
> On Mon, Nov 23, 2020 at 07:51:09AM -0500, Greg Wooledge wrote:
> > On Sat, Nov 21, 2020 at 01:20:39PM -0600, Martin McCormick wrote:
> > >   I just cd'd to that directory and it looks like there's
> > > about 1 GB there.
> >
> > unicorn:~$ du -sh /usr/share/zoneinfo
> > 3.5M/usr/share/zoneinfo
> > unicorn:~$ find /usr/share/zoneinfo -type f | wc -l
> > 780
> >
> > Either something's wrong on your system -- in which case you should try
> > to figure out what it is -- or something's wrong with your interpretation
> > of what you're seeing.
> >
> > (And yes, I know find | wc -l isn't an accurate way to count files if
> > their names are unrestricted.  Here I'm assuming there aren't a huge
> > number of filenames in /usr/share/zoneinfo/ with newlines.)
> 
> Since I'm the one that started this discussion, I'd like to say
> "Thank You" to all that offered their insight.
> I guess I'm just a little old fashioned. My first computer had
> no storage and my first hard drive was 20M so having a directory
> taking up 3.5MB when all I'm using there is less than 10KB just
> doesn't sit well with me.

Well, it would be interesting to compare the functionality provided by
that computer with what's under your fingertips now.

After pruning all the stuff that "doubles" disk size, and the
unnecessary anti-virus and backup software etc, the entire
DOS6.22 OS comes in at under 3MB. But there's no comparison.

> In over 20 years running Linux I've never found a use for that
> extra 3.5MB data and I wonder how many do. I'm curious Greg, how often
> have you used that data?

Well, you seem to use it, judging by your emails when you send them
under this persona. For example, you appear to have observed DST
during the summer, and relocated some aspect of your life in the fall.

> Locale is another area where there is a lot of data that the
> average user, I suspect, has no use for and localepurge in Debian, at
> least, is hamstrung by the packagers, hooking it to dpkg and
> disableing it for any other use. Running localepurge on the CL is a
> noop but doesn't tell you so, look at the code.

I'm not sure how you calculate an average locale from the variety
of users worldwide. A mode might be possible.

> Sorry I didn't mean to rant.
> Thanks again for the input.

Pleasure. For the quiet life, I'd recommend to let sleeping dogs lie.

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Tue 24 Nov 2020 at 13:07:10 (-0500), Greg Wooledge wrote:
> On Tue, Nov 24, 2020 at 04:45:53PM +, Curt wrote:
> > I have a problem:
> > 
> > curty@einstein:~$ TZ=EST date
> > Tue Nov 24 11:43:42 EST 2020
> > curty@einstein:~$ TZ=PST date
> > Tue Nov 24 16:43:54 PST 2020
> 
> As I said, figuring out the valid TZ strings for a given location on
> our planet is a challenge.  Unfortunately, the ... fine people ... who
> devised the standards for this sort of thing thought it would be really
> super clever to treat ALL unknown TZ strings as if they were "UTC0".
> 
> unicorn:~$ date -u ; TZ=UTC0 date ; TZ=Imaginary/Neverland date
> Tue Nov 24 17:54:28 UTC 2020
> Tue Nov 24 17:54:28 UTC 2020
> Tue Nov 24 17:54:28 Imaginary 2020
> 
> TZ=PST is yet another unknown TZ string, so it's treated as "UTC0", or
> the Coordinated Universal Time zone, and you don't even get a WARNING
> that this is the case.  It just silently gives you a wrong answer.
> 
> I've been personally bitten by this, and it sucks.  So much.
> 
> unicorn:~$ TZ=PST date ; TZ=PST8PDT date ; TZ=America/Los_Angeles date
> Tue Nov 24 17:56:16 PST 2020
> Tue Nov 24 09:56:16 PST 2020
> Tue Nov 24 09:56:16 PST 2020
> 
> To add insult to injury, the string that date(1) gives you as OUTPUT
> (in this case, "PST") is not accepted by the very same program as INPUT.
> In fact, I don't know of any way to get date(1) to give an output string
> that you can use as a valid TZ input string.  You have to discover these
> values yourself, using out-of-band means.
> 
> One of the ways to generate a valid TZ name, if your target happens to
> be in the United States, is to construct one of the old school Unix time
> zone names:
> 
> EST5EDT
> CST6CDT
> MST7MDT
> PST8PDT
> 
> If you can remember "Eastern Central Mountain Pacific", and if you can
> remember the numeric offset for any single one of them, then you can
> derive the full set.
> 
> Another set of TZ labels that works for the USA is the transitional
> set that was popular 10-20 years ago:
> 
> US/Eastern
> US/Central
> US/Mountain
> US/Pacific
> 
> Those are even easier to derive than the "EST5EDT" style ones, albeit
> slightly more characters to type.
> 
> Outside of the USA, you'll probably need to go with the "nearest big
> city" names that are the current vogue.  The best way to use those is
> probably "ls /usr/share/zoneinfo", choose your continent, and then
> (for example) "ls /usr/share/zoneinfo/Asia".  Then pick a city from
> the resulting set, and pray.
> 
> If there's a better way, I don't know it.

I wrote this a while back; it probably needs another bout of tidying up.

$ type whattime 
whattime is a function
whattime () 
{ 
[ -z "$1" ] && printf '%s\n' "Usage:${FUNCNAME[0]} there [where]
prints the time in where or where/there or there/where.
Note that the result has to be Region/Place with a /." 1>&2 && return 1;
local Wherea="${1,,}" Whereb="${1,,}";
[ -n "$2" ] && Wherea="${1,,}/${2,,}" && Whereb="${2,,}/${1,,}";
local Unique1="$(mktemp "${Uniquetrash:-/tmp}/${FUNCNAME[0]}"-"$(date 
+%s)"-)";
local Unique2="$(mktemp "${Uniquetrash:-/tmp}/${FUNCNAME[0]}"-"$(date 
+%s)"-)";
( cd /usr/share/zoneinfo || return 9;
ls -1 */* >> "$Unique1";
grep -i -e "${Wherea// /_}" "$Unique1" >> "$Unique2";
grep -i -e "${Whereb// /_}" "$Unique1" >> "$Unique2";
local Nmatches="$(grep -e '/' "$Unique2" | LC_ALL=C sort -u | tee 
"$Unique1" | wc -l)";
[ "$Nmatches" = "1" ] && TZ=$(cat "$Unique1") && printf '%s ' "$TZ" && date 
'+%Y-%m-%d %T %z %A' )
}
$ whattime pari
Europe/Paris 2020-11-24 20:38:35 +0100 Tuesday
$ 

It should work on any single partial match, as demonstrated.
Of course, it helps to know the names of a few major cities.

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[rhkramer]

On Tuesday, November 24, 2020 01:07:10 PM Greg Wooledge wrote:
> As I said, figuring out the valid TZ strings for a given location on
> our planet is a challenge.  Unfortunately, the ... fine people ... who
> devised the standards for this sort of thing thought it would be really
> super clever to treat ALL unknown TZ strings as if they were "UTC0".

...

> Outside of the USA, you'll probably need to go with the "nearest big
> city" names that are the current vogue.  The best way to use those is
> probably "ls /usr/share/zoneinfo", choose your continent, and then
> (for example) "ls /usr/share/zoneinfo/Asia".  Then pick a city from
> the resulting set, and pray.
> 
> If there's a better way, I don't know it.

Just google [time in ] (e.g., time in China).  No need to find a 
TZ string.

Re: 780 files in /usr/share/zoneinfo/

[Kamil Jońca]

Mike McClain  writes:

[...]
> Locale is another area where there is a lot of data that the
> average user, I suspect, has no use for and localepurge in Debian, at
> least, is hamstrung by the packagers, hooking it to dpkg and
I disagree.
Even quite small enterprises work internationally now.
And it  is important to me if my coworker from Bangalore has working
time or is in bed before calling him :)
So "TZ=Asia/Kolkata date" is your friend :)


KJ
-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

On Tue, Nov 24, 2020 at 04:45:53PM +, Curt wrote:
> I have a problem:
> 
> curty@einstein:~$ TZ=EST date
> Tue Nov 24 11:43:42 EST 2020
> curty@einstein:~$ TZ=PST date
> Tue Nov 24 16:43:54 PST 2020

As I said, figuring out the valid TZ strings for a given location on
our planet is a challenge.  Unfortunately, the ... fine people ... who
devised the standards for this sort of thing thought it would be really
super clever to treat ALL unknown TZ strings as if they were "UTC0".

unicorn:~$ date -u ; TZ=UTC0 date ; TZ=Imaginary/Neverland date
Tue Nov 24 17:54:28 UTC 2020
Tue Nov 24 17:54:28 UTC 2020
Tue Nov 24 17:54:28 Imaginary 2020

TZ=PST is yet another unknown TZ string, so it's treated as "UTC0", or
the Coordinated Universal Time zone, and you don't even get a WARNING
that this is the case.  It just silently gives you a wrong answer.

I've been personally bitten by this, and it sucks.  So much.

unicorn:~$ TZ=PST date ; TZ=PST8PDT date ; TZ=America/Los_Angeles date
Tue Nov 24 17:56:16 PST 2020
Tue Nov 24 09:56:16 PST 2020
Tue Nov 24 09:56:16 PST 2020

To add insult to injury, the string that date(1) gives you as OUTPUT
(in this case, "PST") is not accepted by the very same program as INPUT.
In fact, I don't know of any way to get date(1) to give an output string
that you can use as a valid TZ input string.  You have to discover these
values yourself, using out-of-band means.

One of the ways to generate a valid TZ name, if your target happens to
be in the United States, is to construct one of the old school Unix time
zone names:

EST5EDT
CST6CDT
MST7MDT
PST8PDT

If you can remember "Eastern Central Mountain Pacific", and if you can
remember the numeric offset for any single one of them, then you can
derive the full set.

Another set of TZ labels that works for the USA is the transitional
set that was popular 10-20 years ago:

US/Eastern
US/Central
US/Mountain
US/Pacific

Those are even easier to derive than the "EST5EDT" style ones, albeit
slightly more characters to type.

Outside of the USA, you'll probably need to go with the "nearest big
city" names that are the current vogue.  The best way to use those is
probably "ls /usr/share/zoneinfo", choose your continent, and then
(for example) "ls /usr/share/zoneinfo/Asia".  Then pick a city from
the resulting set, and pray.

If there's a better way, I don't know it.

Re: 780 files in /usr/share/zoneinfo/

[Gene Heskett]

On Tuesday 24 November 2020 11:18:00 John Hasler wrote:

> Mike McClain writes:
> > I guess I'm just a little old fashioned. My first computer had
> > no storage
>
> Likewise.
>
> > ...and my first hard drive was 20M...
>
> Likewise.
>
> > ...so having a directory taking up 3.5MB when all I'm using there is
> > less than 10KB just doesn't sit well with me.
>
> I have 278GB of unused disk space on this machine.  3.5MB "wasted"
> does not bother me at all.  Back when I was coding in hex for the RCA
> 1802 and using audio cassettes for storage I worried about single
> bytes. Times have changed.

Now that brings back very OLD memories from about 1979 John, when I wrote 
a commercial tv production aid to run on a CosMac Super Elf. That tv 
station was still using it several times a day 15 years later, and I 
have a broadcast cart with several copies of it, and a paper copy bagged 
up for posterity on a library shelf above me. First useful program I 
ever wrote and I still have fond memories for the weird architecture, 
and that architectures capabilities, of the 1802. Every byte counted, 
and dead stable despite using quite a bit of self-modifying code.

But you are right, times have changed. Now I'm 86 yo, and am writing 
gcode to carve metal parts I need to make things. 5 linux machines 
running full time here, this one has 32gigs of dram, not the 4k of 
static ram I built from a $400 kit way back then, on an S-100 board.
Keeps me out of the bars don'tcha know.

Thanks for the memory tickle, John.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: 780 files in /usr/share/zoneinfo/

[Curt]

On 2020-11-24, John Hasler  wrote:
> rhkramer writes:
>> To find out the time in some other time zone, I find it convenient to
>> just google [time in ] (e.g., time in China).
>
> "TZ= date" is quicker.  "date -d 'time and date in other timezone'"
> converts a given time and date to local time and date. 

I have a problem:

curty@einstein:~$ TZ=EST date
Tue Nov 24 11:43:42 EST 2020
curty@einstein:~$ TZ=PST date
Tue Nov 24 16:43:54 PST 2020

However,

curty@einstein:~$ TZ=":America/Los_Angeles" date
Tue Nov 24 08:40:42 PST 2020

And yet,

curty@einstein:~$ TZ=":America/San_Francisco" date
Tue Nov 24 16:42:03 America 2020

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

rhkramer writes:
> To find out the time in some other time zone, I find it convenient to
> just google [time in ] (e.g., time in China).

"TZ= date" is quicker.  "date -d 'time and date in other timezone'"
converts a given time and date to local time and date. 
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

Mike McClain writes:
> I guess I'm just a little old fashioned. My first computer had
> no storage

Likewise.

> ...and my first hard drive was 20M...

Likewise.

> ...so having a directory taking up 3.5MB when all I'm using there is
> less than 10KB just doesn't sit well with me.

I have 278GB of unused disk space on this machine.  3.5MB "wasted" does
not bother me at all.  Back when I was coding in hex for the RCA 1802
and using audio cassettes for storage I worried about single bytes.
Times have changed.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[rhkramer]

On Tuesday, November 24, 2020 08:09:16 AM Greg Wooledge wrote:
> A few times a year, at most.  For others, it will depend on how often
> you travel to other time zones, or interact with people in other time
> zones, or would simply like to know what time it is in .

To find out the time in some other time zone, I find it convenient to just 
google [time in ] (e.g., time in China).

Re: Re: 780 files in /usr/share/zoneinfo/

[Michael Stone]

On Mon, Nov 23, 2020 at 10:16:47PM -0600, Mike McClain wrote:

   I guess I'm just a little old fashioned. My first computer had
no storage and my first hard drive was 20M so having a directory
taking up 3.5MB when all I'm using there is less than 10KB just
doesn't sit well with me.


The kernel, compressed, is larger than that. The initrd needed to boot 
the kernel is also typically larger than that. A modern system has more 
CPU cache than that. At some point trying to save bytes is a waste of 
developer and administrator effort, and 3.5MB in 2020 is well past that 
point. If you want a minimal system, debian isn't for you. Instead, 
you'll need to hand craft every file to make sure it isn't "wasting 
space". If that's your thing, great. But it's just not a focus for 
debian.

Re: 780 files in /usr/share/zoneinfo/

[Stefan Monnier]

> I guess I'm just a little old fashioned. My first computer had
> no storage and my first hard drive was 20M so having a directory
> taking up 3.5MB when all I'm using there is less than 10KB just
> doesn't sit well with me.

I can related to that.

Note that you can also remove all of that directory and use a TZ setting
using the old convention like 'EST5EDT,M3.2.0,M11.1.0'.

Also tar+lzip of that directory reduces it for me from 5.1MB to ~143kB.
`libc` doesn't know how to use it once compressed this way, but you could
manually extract the few files you need from it if/when you need them.


Stefan

Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

On Mon, Nov 23, 2020 at 10:16:47PM -0600, Mike McClain wrote:
> In over 20 years running Linux I've never found a use for that
> extra 3.5MB data and I wonder how many do. I'm curious Greg, how often
> have you used that data?

A few times a year, at most.  For others, it will depend on how often
you travel to other time zones, or interact with people in other time
zones, or would simply like to know what time it is in .

unicorn:~$ date ; TZ=Asia/Hong_Kong date
Tue Nov 24 08:07:53 EST 2020
Tue Nov 24 21:07:53 HKT 2020

Then again, just figuring out the *name* of the target time zone is a
challenge in and of itself.

Re: Re: 780 files in /usr/share/zoneinfo/

[Mike McClain]

On Mon, Nov 23, 2020 at 07:51:09AM -0500, Greg Wooledge wrote:
> On Sat, Nov 21, 2020 at 01:20:39PM -0600, Martin McCormick wrote:
> > I just cd'd to that directory and it looks like there's
> > about 1 GB there.
>
> unicorn:~$ du -sh /usr/share/zoneinfo
> 3.5M  /usr/share/zoneinfo
> unicorn:~$ find /usr/share/zoneinfo -type f | wc -l
> 780
>
> Either something's wrong on your system -- in which case you should try
> to figure out what it is -- or something's wrong with your interpretation
> of what you're seeing.
>
> (And yes, I know find | wc -l isn't an accurate way to count files if
> their names are unrestricted.  Here I'm assuming there aren't a huge
> number of filenames in /usr/share/zoneinfo/ with newlines.)

Since I'm the one that started this discussion, I'd like to say
"Thank You" to all that offered their insight.
I guess I'm just a little old fashioned. My first computer had
no storage and my first hard drive was 20M so having a directory
taking up 3.5MB when all I'm using there is less than 10KB just
doesn't sit well with me.
In over 20 years running Linux I've never found a use for that
extra 3.5MB data and I wonder how many do. I'm curious Greg, how often
have you used that data?
Locale is another area where there is a lot of data that the
average user, I suspect, has no use for and localepurge in Debian, at
least, is hamstrung by the packagers, hooking it to dpkg and
disableing it for any other use. Running localepurge on the CL is a
noop but doesn't tell you so, look at the code.
Sorry I didn't mean to rant.
Thanks again for the input.
Be well,
Mike
--
"At birth, men are by nature of good heart."
- _Young_Fu_Elizabeth F. Lewis

Re: 780 files in /usr/share/zoneinfo/

[Charles Curley]

On Mon, 23 Nov 2020 07:51:09 -0500
Greg Wooledge  wrote:

> (And yes, I know find | wc -l isn't an accurate way to count files if
> their names are unrestricted.  Here I'm assuming there aren't a huge
> number of filenames in /usr/share/zoneinfo/ with newlines.)

You are also assuming that there are no hard links. In this case, the
assumption is correct.

root@jhegaala:~# find /usr/share/zoneinfo -type f | xargs ls -i | cut -f1 -d' ' 
| sort -n | wc -l
780
root@jhegaala:~# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Re: 780 files in /usr/share/zoneinfo/

[Greg Wooledge]

On Sat, Nov 21, 2020 at 01:20:39PM -0600, Martin McCormick wrote:
>   I just cd'd to that directory and it looks like there's
> about 1 GB there.

unicorn:~$ du -sh /usr/share/zoneinfo
3.5M/usr/share/zoneinfo
unicorn:~$ find /usr/share/zoneinfo -type f | wc -l
780

Either something's wrong on your system -- in which case you should try
to figure out what it is -- or something's wrong with your interpretation
of what you're seeing.

(And yes, I know find | wc -l isn't an accurate way to count files if
their names are unrestricted.  Here I'm assuming there aren't a huge
number of filenames in /usr/share/zoneinfo/ with newlines.)

Re: 780 files in /usr/share/zoneinfo/

[Andy Smith]

Hi Martin,

On Sat, Nov 21, 2020 at 08:48:51PM -0600, Martin McCormick wrote:
> find . -name "*" -exec ls -l {} \;  \
> |grep -F / \
> | awk ' { total += $5 } END { print total }'
> 
>   That usually just adds the sizes of all the files it can
> find all the way through the tree.
> 
>   If this is not an accurate way to determine how many
> bytes there are in a directory then that would be the reason for
> the discrepancy.

The same file can be reached by multiple names. So by doing this you
end up, in this case, with a ~256x amplification.

A simple "du -sh" does a better job here!

> cron only works in the time zone for wherever the TZ for the
> system is set.

Ah, I see. I've never tried it but I believe that systemd timers can
have a time spec that includes time zone, so you can set timers that
fire on a different time zone to that used by the rest of the system.

$ systemd-analyze calendar '11:00 Europe/London'
  Original form: 11:00 Europe/London
Normalized form: *-*-* 11:00:00 Europe/London
Next elapse: Sun 2020-11-22 11:00:00 UTC
   From now: 6h left

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

Andy Smith  writes:
> Hi Martin,
> 
> Are you sure about this? There is no Debian or Ubuntu host I have
> access to that has a /usr/share/zoneinfo/ that contains more than
> 4MiB of data. For yours to have 256 times this much is quite an
> aberration. What did you type to determine that your
> /usr/share/zoneinfo/ has 1GiB of data in it?

find . -name "*" -exec ls -l {} \;  \
|grep -F / \
| awk ' { total += $5 } END { print total }'

That usually just adds the sizes of all the files it can
find all the way through the tree.

If this is not an accurate way to determine how many
bytes there are in a directory then that would be the reason for
the discrepancy.

> 
> >   I've wished one could just set certain parts of the
> > computer to other times but I can also understand why this could
> > be a problem.
> 
> You can set any process to have a different time zone by use of
> environment variables.
> 
> $ date
> Sat 21 Nov 21:34:55 UTC 2020
> $ TZ=America/Los_Angeles date
> Sat 21 Nov 13:35:04 PST 2020

That is very true but cron only works in the time zone
for wherever the TZ for the system is set.

On the system I have set to British time, my local login
shell has TZ=America/Chicago so I read Central Standard Time for
file time stamps but if I set a cron job, it runs on either
British Summer Time or British standard time which is the same as
UTC during Winter.


> Cheers,
> Andy

Re: 780 files in /usr/share/zoneinfo/

[David Wright]

On Sat 21 Nov 2020 at 02:30:08 (+), mike.junk...@att.net wrote:
> Of the 780 files in /usr/share/zoneinfo/ America/Chicago and CST6CDT are the 
> only two that might apply to me. Are the rest of any use to me at all? If so 
> how? And, yes, I understand that they need to be supplied for every zone in 
> the world initially but am curious if there is any use for them after one's 
> own time zone is set.

Compared with the language files discussed around
https://lists.debian.org/debian-user/2020/10/msg00290.html
I would say this is small fry:

$ find /usr/share/zoneinfo/ -type f -exec cat {} + | wc -c
1192831
$ 

(I imagine most of the disk usage is directories, links,
and dead space at the end of all those little files.)

Ironically, you seem to have lost your email's time zone,
assuming you're still on this continent.

Cheers,
David.

Re: 780 files in /usr/share/zoneinfo/

[Charles Curley]

On Sat, 21 Nov 2020 13:20:39 -0600
"Martin McCormick"  wrote:

> I just cd'd to that directory and it looks like there's
> about 1 GB there.

Show us what you did. As in, copy and paste from a terminal. E.g.:

root@hawk:/usr/share/zoneinfo# du -hs
3.5M.
root@hawk:/usr/share/zoneinfo# uname -r
4.19.0-6-amd64
root@hawk:/usr/share/zoneinfo# pre tzdata
tzdata  2020d-0+deb10u1 all
root@hawk:/usr/share/zoneinfo# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: 780 files in /usr/share/zoneinfo/

[Stefan Monnier]

> Are you sure about this? There is no Debian or Ubuntu host I have
> access to that has a /usr/share/zoneinfo/ that contains more than
> 4MiB of data.

FWIW:

% du -sh /usr/share/zoneinfo/.
5.1M/usr/share/zoneinfo/.
0%

This is on a "bog standard" Debian i386 testing (with incremental
updates for the last 17 years or so).

> For yours to have 256 times this much is quite an aberration.

Quite definitely.


Stefan

Re: 780 files in /usr/share/zoneinfo/

[Andy Smith]

Hi Martin,

On Sat, Nov 21, 2020 at 01:20:39PM -0600, Martin McCormick wrote:
>   I just cd'd to that directory and it looks like there's
> about 1 GB there.

Are you sure about this? There is no Debian or Ubuntu host I have
access to that has a /usr/share/zoneinfo/ that contains more than
4MiB of data. For yours to have 256 times this much is quite an
aberration. What did you type to determine that your
/usr/share/zoneinfo/ has 1GiB of data in it?

>   I've wished one could just set certain parts of the
> computer to other times but I can also understand why this could
> be a problem.

You can set any process to have a different time zone by use of
environment variables.

$ date
Sat 21 Nov 21:34:55 UTC 2020
$ TZ=America/Los_Angeles date
Sat 21 Nov 13:35:04 PST 2020

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: 780 files in /usr/share/zoneinfo/

[Martin McCormick]

 writes:
> Suppose a hacker logs into your computer from far, far away, say
> from somewhere in Nepal.
> 
> Surely you'd want this person to see the time adapted to their
> locale? That's the least courtesy you can be expected to provide?
> 
> ;-P
> 
> Now putting my tongue out of my cheek again: in Unix, a computer
> "has" no time zone or language -- people have those. And since,
> again in Unix, several people can be logged in [1] at the same time,
> it's up to the user's environment [2] to decide on time zone,
> language, etc.
> 
> This concept is surprising at first coming from other cultures,
> where Microsoft was happy to sell you another complete version
> of Windows if you wanted your computer to talk to you, e.g.
> Portuguese (and yet another for Brazilian Portuguese, greedy as
> they are).
> 
> Of course, Microsoft has caught up (they are trying since the
> mid-90s), but not without some spectacular messups. Remember that
> one where (I think it was Windows 95), while trying to automate
> the spring DST transition were spotted dithering endlessly between
> 2AM and 3AM?
> 
> Unix has had this abstraction always: there's the internal time,
> and there's the time shown to the user, which depends on the user.
> 
> There's the error itself, and there's the error message shown to
> the user. And so on.
> 
> Cheers

I just cd'd to that directory and it looks like there's
about 1 GB there.  I think it is cool to have all that info and I
even configured a linux system for BST so cron would record shows
I was interested in from the BBC.

It works perfectly when we go from Summer time to
standard time in Winter because North America and the UK don't
switch at the same time but it all works.

I've wished one could just set certain parts of the
computer to other times but I can also understand why this could
be a problem.

By the way, I have never been outside the United States
but am an amateur radio operator and learned at a very young age
to appreciate those time zones if one wants to know when to
listen for interesting things.

Martin

Re: 780 files in /usr/share/zoneinfo/

[tomas]

On Sat, Nov 21, 2020 at 02:30:08AM +, mike.junk...@att.net wrote:
> Of the 780 files in /usr/share/zoneinfo/ America/Chicago and
> CST6CDT are the only two that might apply to me [...]
> [...] if there is any use for them after one's own time zone is set.

Suppose a hacker logs into your computer from far, far away, say
from somewhere in Nepal.

Surely you'd want this person to see the time adapted to their
locale? That's the least courtesy you can be expected to provide?

;-P

Now putting my tongue out of my cheek again: in Unix, a computer
"has" no time zone or language -- people have those. And since,
again in Unix, several people can be logged in [1] at the same time,
it's up to the user's environment [2] to decide on time zone,
language, etc.

This concept is surprising at first coming from other cultures,
where Microsoft was happy to sell you another complete version
of Windows if you wanted your computer to talk to you, e.g.
Portuguese (and yet another for Brazilian Portuguese, greedy as
they are).

Of course, Microsoft has caught up (they are trying since the
mid-90s), but not without some spectacular messups. Remember that
one where (I think it was Windows 95), while trying to automate
the spring DST transition were spotted dithering endlessly between
2AM and 3AM?

Unix has had this abstraction always: there's the internal time,
and there's the time shown to the user, which depends on the user.

There's the error itself, and there's the error message shown to
the user. And so on.

Cheers

[1] This concept extends to other remote communication things,
   like http.
[2] See man 7 locale for the gory details

 - t


signature.asc
Description: Digital signature

Re: 780 files in /usr/share/zoneinfo/

[Paul Johnson]

On Fri, Nov 20, 2020 at 9:18 PM John Hasler  wrote:

> Mike writes:
> > Of the 780 files in /usr/share/zoneinfo/ America/Chicago and CST6CDT
> > are the only two that might apply to me. Are the rest of any use to me
> > at all?  If so how?
>
> Do you ever need to convert the time and date in some distant time zone
> to your local time or vice versa?  The "date" command can do that for
> you using that database.
>
> Also, the database is updated (even in Stable) when jurisdictions make
> changes such as moving the start and end dates for daylight savings
> time.
>
> It's tiny and useful.  leave it alone.
>

 I concur.  And it's only going to get more useful with each update as the
world's time gets more complicated.  Especially if you happen to be in the
northwestern US, where half of the Boise and Portland metro areas will now
be off the other half by an hour half the year...

Re: 780 files in /usr/share/zoneinfo/

[John Hasler]

Mike writes:
> Of the 780 files in /usr/share/zoneinfo/ America/Chicago and CST6CDT
> are the only two that might apply to me. Are the rest of any use to me
> at all?  If so how?

Do you ever need to convert the time and date in some distant time zone
to your local time or vice versa?  The "date" command can do that for
you using that database.

Also, the database is updated (even in Stable) when jurisdictions make
changes such as moving the start and end dates for daylight savings
time.

It's tiny and useful.  leave it alone.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: 780 files in /usr/share/zoneinfo/

[Andy Smith]

Hi Mike,

On Sat, Nov 21, 2020 at 02:30:08AM +, mike.junk...@att.net wrote:
> Of the 780 files in /usr/share/zoneinfo/ America/Chicago and
> CST6CDT are the only two that might apply to me. Are the rest of
> any use to me at all? If so how? And, yes, I understand that they
> need to be supplied for every zone in the world initially but am
> curious if there is any use for them after one's own time zone is
> set.

It's the Olson database, needed for any application that will want
to know the time in another time zone, or parse such.

https://en.wikipedia.org/wiki/Tz_database

The files are tiny. It's not worth removing them IMHO. It's 3½MiB of
space on my system.

Cheers,
Andy

Re: AppImage files (was: clipgrab as alternative to youtube-dl)

[Marc Shapiro]

On 11/18/20 6:07 AM, Fred wrote:

On 11/17/20 11:47 PM, Anssi Saari wrote:

Fred  writes:


There is a binary for Linux available for download as a AppImage
file. What is an AppImage file and what does one do with it. The
program was probably compiled for Ubuntu.  Is it likely to also run on
Debian?


AppImage files are a kind of package that contain an app and all its
dependencies so yes, it's very likely it'll run on Debian. All you have
to do is make the AppImage file executable and run it. I recently got
into these since I have a problem with the Firefox Debian bundles but
someone maintains a current Firefox build as AppImage.



Hi,
Thanks for your answer.  I was able to get clipgrab to compile but the 
AppImage file is a later version and may be a better choice if it will 
run on Debian.


I am using it on a Ddevuan system and it works just fine.

Marc

Re: Encrypt files on Linux, decrypt on Windows

[Hornet]

Just use keepass. It installs everywhere and uses decent crypto.

On Wed, Aug 26, 2020, 5:30 AM Jonathan Dowland 
wrote:

> On Fri, Aug 21, 2020 at 08:10:50PM -0400, rhkra...@gmail.com wrote:
> >Shouldn't this be just the opposite -- local10 should encrypt the file
> with his
> >recipient's public key, and then his recipient can unencrypt it with his
> (the
> >recipient's) private key?
>
> You can perform symmetric encryption with GnuPG too, and not require
> public/private keypairs, just a shared passphrase.
>
> --
> Please do not CC me, I am subscribed to the list.
>
> Jonathan Dowland
> ✎j...@debian.org
>   https://jmtd.net
>
>

Re: Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows

[Celejar]

On Wed, 26 Aug 2020 09:29:06 +0300
Andrei POPESCU  wrote:

> On Ma, 25 aug 20, 14:17:26, Celejar wrote:
> > 
> > I do use Signal on mobile, and I want to like it, but there are a few
> > things about it that just really bother me (these may not be relevant
> > to the OPs situation):
> 
> I never claimed it's perfect, just that it's not a "black box". See also 

I know - I just took advantage of your comment to take the opportunity
to vent some of my frustration with Signal.

> this comment in one of the discussions you linked that appears to be 
> more balanced:
> 
> https://github.com/privacytools/privacytools.io/issues/779#issuecomment-471687384

More balanced, perhaps - there is considerable debate in that thread -
but I still side with the naysayers (the following quotes are from
that comment, not you):

> For instance, we showed that users can simply register a random phone

I agree that we shouldn't discourage Signal, and certainly not
encourage the vastly less free alternatives to it. But we also
shouldn't give it a free pass on what I consider to be its somewhat
anti-FLOSS / user hostile attitudes.

> services since the developer buys from Amazon, drinks Coca-Cola, or
> runs Windows 10 isn't about the actual service but about political
> beliefs.

These is a plain silly analogy. I don't care much about what *the
developer* uses in his personal life, and I don't even care that much
about what he uses to develop and host the software. I *do* care about
what he makes (or strongly encourages) users use, such as the Play
Store, Google Accounts, reCAPTCHAS, etc., as mentioned by the OP in
that thread.

[Back to quoting Andrei.]

> As far as I can tell Signal is still miles ahead of WhatsApp, Telegram, 

Certainly.

> Snapchat, etc. and it's still challenging to get others to use it[1].

> One might find that with the "perfect" communication tool there is no 
> one to communicate with :) 

;)

> [1] I basically had to "blackmail" my close family and friends by 
> refusing to install WhatsApp on my private phone.

I refuse to install WhatsApp as well - but that just means that I miss
some stuff, and have to trouble people to manually email me other
stuff ...

> Kind regards,

Celejar

Re: Encrypt files on Linux, decrypt on Windows

[Jonathan Dowland]

On Fri, Aug 21, 2020 at 08:10:50PM -0400, rhkra...@gmail.com wrote:

Shouldn't this be just the opposite -- local10 should encrypt the file with his
recipient's public key, and then his recipient can unencrypt it with his (the
recipient's) private key?


You can perform symmetric encryption with GnuPG too, and not require
public/private keypairs, just a shared passphrase.

--
Please do not CC me, I am subscribed to the list.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows

[Andrei POPESCU]

On Ma, 25 aug 20, 14:17:26, Celejar wrote:
> 
> I do use Signal on mobile, and I want to like it, but there are a few
> things about it that just really bother me (these may not be relevant
> to the OPs situation):

I never claimed it's perfect, just that it's not a "black box". See also 
this comment in one of the discussions you linked that appears to be 
more balanced:

https://github.com/privacytools/privacytools.io/issues/779#issuecomment-471687384

As far as I can tell Signal is still miles ahead of WhatsApp, Telegram, 
Snapchat, etc. and it's still challenging to get others to use it[1].

One might find that with the "perfect" communication tool there is no 
one to communicate with :) 


[1] I basically had to "blackmail" my close family and friends by 
refusing to install WhatsApp on my private phone.

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


signature.asc
Description: PGP signature

Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows

[Celejar]

On Sun, 23 Aug 2020 14:03:21 +0300
Andrei POPESCU  wrote:

> On Vi, 21 aug 20, 13:07:56, Charles Curley wrote:
> > On Fri, 21 Aug 2020 13:31:00 -0500
> > Paul Johnson  wrote:
> > 
> > > GnuPG.  It's in Debian, there's Windows versions on its website, and
> > > it's not some mystery box like Signal.
> > 
> > ++
> > 
> > It also has the advantage that the cryptext will stay encrypted on any
> > intermediate servers. WhatsApp and Signal claim their traffic is, but
> > one must take their word for it.
> 
> Signal is free and open source software.
> 
> Please do feel free to inspect the source code for potential back doors 
> or vulnerabilities.

I do use Signal on mobile, and I want to like it, but there are a few
things about it that just really bother me (these may not be relevant
to the OPs situation):

1) The requirement of associating accounts with (real, working) phone
numbers.

2) The (current) refusal [1] to provide an option to export messages
into a format easily accessible by the user. (I know, I can read and
try to understand Signal's code, and then write my own decryptor -
thanks, Signal).

3) The strong encouragement of the use of Google's Play Store to install
the mobile app, and the strong discouragement of other, FLOSS
compatible, methods of installation. [2]

Discussion of these and many other issues with Signal: [3]

I'm just a user, and not a very advanced one at that, but I can't get
away from the feeling that Signal is somewhat user-hostile, with an
attitude of "Trust us - Moxie is a legend, our code is great (and
FLOSS), and we really care." All true, to be sure, but still.

[1] https://github.com/signalapp/Signal-Android/issues/7586
[2] https://signal.org/android/apk/
[3] https://github.com/privacytools/privacytools.io/issues/779

Celejar

Re: Encrypt files on Linux, decrypt on Windows

[Matthew Graybosch]

On Sat, 22 Aug 2020 09:30:09 +0200
 wrote:

> I always thought it should be banned by the Geneva Convention, but
> OSHA would be fine by me, too.

I think the US stopped honoring the Geneva Conventions during the Dubya
administration. Of course, that doesn't leave much hope for OSHA
enforcement either.

Besides, if we're going to put Microsoft on trial in the Hague for
crimes against humanity, we'll need to do the rest of GAFAM too (not to
mention Disney, Nestlé, Bayer, and a great many others).

-- 
Matthew Graybosch   https://matthewgraybosch.com
#include  gemini://starbreaker.org
gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

Re: Encrypt files on Linux, decrypt on Windows

[Charles Curley]

On Sun, 23 Aug 2020 14:03:21 +0300
Andrei POPESCU  wrote:

> Signal is free and open source software.
> 
> Please do feel free to inspect the source code for potential back
> doors or vulnerabilities.

Thank you for the correction. https://signal.org

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/


pgp32KIC1JLk1.pgp
Description: OpenPGP digital signature

Re: Encrypt files on Linux, decrypt on Windows

[Andrei POPESCU]

On Vi, 21 aug 20, 13:07:56, Charles Curley wrote:
> On Fri, 21 Aug 2020 13:31:00 -0500
> Paul Johnson  wrote:
> 
> > GnuPG.  It's in Debian, there's Windows versions on its website, and
> > it's not some mystery box like Signal.
> 
> ++
> 
> It also has the advantage that the cryptext will stay encrypted on any
> intermediate servers. WhatsApp and Signal claim their traffic is, but
> one must take their word for it.

Signal is free and open source software.

Please do feel free to inspect the source code for potential back doors 
or vulnerabilities.

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


signature.asc
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[tomas]

On Sun, Aug 23, 2020 at 11:01:34AM +0200, Marek Mosiewicz wrote:

[...]

> Not to mention that GPG can be used for asymmetric cryptography.

Yeah, but it's a "Windows user" at the other end, and (s)he's "too
dumb to install software". And "gpg is too hard".

I must say, this theme, which came up here and there tends to make
me furious. It's condescending (we know nothing about the user in
question. Heck. the original poster has thrown in a query, and for
all I can see has disappeared). And it has the potential to become
a self-fulfilling prophecy.

I stand by: recommend GPG. Come here, if you need help. Learn something
along the way. Your life will be more interesting :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Encrypt files on Linux, decrypt on Windows

[Marek Mosiewicz]

W dniu pią, 21.08.2020 o godzinie 13∶07 -0600, użytkownik Charles
Curley napisał:
> On Fri, 21 Aug 2020 13:31:00 -0500
> Paul Johnson  wrote:
> 
> > GnuPG.  It's in Debian, there's Windows versions on its website,
> > and
> > it's not some mystery box like Signal.
> 
> ++
> 
> It also has the advantage that the cryptext will stay encrypted on
> any
> intermediate servers. WhatsApp and Signal claim their traffic is, but
> one must take their word for it.
Not to mention that GPG can be used for asymmetric cryptography.
> 

Re: Encrypt files on Linux, decrypt on Windows

[Joe]

On Sat, 22 Aug 2020 15:43:56 -0500
Greg Marks  wrote:

> One cross-platform encryption method would be to use OpenSSL
> (https://www.openssl.org/).  The Linux user might use the following
> commands.
> 
> Encryption:
>   openssl aes-256-cbc -pbkdf2 -iter 100 -in plaintext.txt -out
> ciphertext.txt Decryption:
>   openssl aes-256-cbc -pbkdf2 -iter 100 -d -in ciphertext.txt
> -out plaintext.txt
> 
> I think the two commands will be the same on a Windows machine.
> Assuming both sides have agreed on a decent password, this should be
> very secure.  The main difficulty for a non-technical Windows user
> would probably be installing OpenSSL; the easiest way might be via a
> trusted third-party binary distribution.
> 
> I'm assuming the OP is content with a symmetric cipher (he or she 
> didn't say).
>

I think the whole thread hinges on the OP not telling us what threats
the encryption should protect against: is he trying to hide something
from the FBI/MI5/Mossad or from his nosy big sister? If the latter, a
passworded zip file is probably sufficient, and all currently supported
versions of Windows do zip natively.

-- 
Joe

Re: Encrypt files on Linux, decrypt on Windows

[Greg Marks]

One cross-platform encryption method would be to use OpenSSL
(https://www.openssl.org/).  The Linux user might use the following
commands.

Encryption:
  openssl aes-256-cbc -pbkdf2 -iter 100 -in plaintext.txt -out 
ciphertext.txt
Decryption:
  openssl aes-256-cbc -pbkdf2 -iter 100 -d -in ciphertext.txt -out 
plaintext.txt

I think the two commands will be the same on a Windows machine.
Assuming both sides have agreed on a decent password, this should be
very secure.  The main difficulty for a non-technical Windows user
would probably be installing OpenSSL; the easiest way might be via a
trusted third-party binary distribution.

I'm assuming the OP is content with a symmetric cipher (he or she 
didn't say).

Best regards,
Greg Marks


signature.asc
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[mick crane]

On 2020-08-21 18:46, local10 wrote:

Hi,

What would be a reasonably secure and simple way to encrypt files on
Linux and then send them to a  non-technical Windows user so she would
be able decrypt and read them?

Any ideas? Thanks


If these are documents what's wrong with open office protected with 
passphrase ?


mick
--
Key ID4BFEBB31

Re: Encrypt files on Linux, decrypt on Windows

[deloptes]

Darac Marjal wrote:

> Signal (signal.org)
> 
> Signal is an instant messaging application. It uses a well respected
> end-to-end encryption protocol (meaning that the messages are encrypted
> by the client and sent over the internet before being decrypted by the
> recipient's client).

OP asking for file encryption, you answering about messages.
Please try to understand the question first.
Sure you can send also files with Signal, but it is not exactly what was
asked.

Re: Encrypt files on Linux, decrypt on Windows

[tomas]

On Fri, Aug 21, 2020 at 09:28:02PM -0400, Matthew Graybosch wrote:
> On Fri, 21 Aug 2020 20:10:50 -0400
> rhkra...@gmail.com wrote:

[...]

> You're right. Please consider my last email proof that exposure to
> Windows causes brain damage and that its use in the corporate workplace
> should be considered an OSHA violation.

+1 :)

I always thought it should be banned by the Geneva Convention, but
OSHA would be fine by me, too.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Encrypt files on Linux, decrypt on Windows

[Matthew Graybosch]

On Fri, 21 Aug 2020 20:10:50 -0400
rhkra...@gmail.com wrote:

> On Friday, August 21, 2020 04:11:19 PM Matthew Graybosch wrote:
> > I don't disagree, but how likely is it that local10's intended
> > recipient will...
> > 
> > 1. Have GnuPG installed on their Windows machine?
> > 2. Know how to use it to decrypt files using local10's public key?  
> 
> Shouldn't this be just the opposite -- local10 should encrypt the
> file with his recipient's public key, and then his recipient can
> unencrypt it with his (the recipient's) private key?

You're right. Please consider my last email proof that exposure to
Windows causes brain damage and that its use in the corporate workplace
should be considered an OSHA violation.

-- 
Matthew Graybosch   https://matthewgraybosch.com
#include  gemini://starbreaker.org
gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

Re: Encrypt files on Linux, decrypt on Windows

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 22/8/20 3:46 am, local10 wrote:
> What would be a reasonably secure and simple way to encrypt files on Linux 
> and then send them to a  non-technical Windows user so she would be able 
> decrypt and read them?
>
> Any ideas? Thanks

Lots of ideas

Just some to consider besides the other options given.


https://onionshare.org/
 - the tool encrypts files and the receiver decrypts them via Tor Browser 
Bundle (automatically)


https://emailselfdefense.fsf.org/en/windows.html
 - a little learning required and things are changing (or have changed, 
depending on version) with Thunderbird (built-in vs enigmail)
  - uses gpg4win, which is an implementation of GNUPG for Windows

Run a Nextcloud instance and provide a read only share for them; or read/write 
if it is to be both ways and they can drag and drop files for you.

One of the "easiest" options /may/ have been https://send.firefox.com/ -- but 
who know if or when that "service" will be available again (it was apparently 
taken down due to abuse)
.

Kind Regards
AndrewM
-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQTJAoMHtC6YydLfjUOoFmvLt+/i+wUCX0BvuwAKCRCoFmvLt+/i
+65CAP4rGHX8s+JMpVZwMMLiJxu97bal6rvvQv0mV7REgtA/eAEAntUxolL6P8b9
yMiZn1oBnHwcuvYABLdYKNzqYAb57mM=
=R+9r
-END PGP SIGNATURE-

Re: Encrypt files on Linux, decrypt on Windows

[rhkramer]

On Friday, August 21, 2020 04:11:19 PM Matthew Graybosch wrote:
> I don't disagree, but how likely is it that local10's intended
> recipient will...
> 
> 1. Have GnuPG installed on their Windows machine?
> 2. Know how to use it to decrypt files using local10's public key?

Shouldn't this be just the opposite -- local10 should encrypt the file with his 
recipient's public key, and then his recipient can unencrypt it with his (the 
recipient's) private key?

The way you described would be for use as a signature, to prove that local10 
actually sent the file -- anybody with the public key can unencrypt 
demonstrating that local10 inititated the file.

[OT] Linux-Fan's bad signatures (Re: Encrypt files on Linux, decrypt on Windows)

[Linux-Fan]

Teemu Likonen writes:


* 2020-08-21 20:24:29+02, Linux-Fan wrote:

> GPG should also run on Windows, but is a little harder to use IMHO.

GnuPG it is pretty hard everywhere. Your recent signatures are reported
as "bad" (at least by Notmuch and Mutt). The signed data (message)
doesn't match with the signature.


[...]

The copy I receive from the list does not verify correctly here, either.
It seems somewhere along the path the e-mails content is actually mangled.
-- some additional newlines are introduced compared to my local copy from
the "Sent" folder which verifies correctly.

Attached are `sent.txt` (and `sent.eml`) and `received.txt` -- the very same
e-mail as seen in my Sent folder and Inbox respectively... Interestingly, if
I split out the signatures and message contents, I get bad signature for
both variatns despite the fact that the e-mail client can somehow verify the
sent e-mail...

???
Linux-Fan
--=_pte5-5038-1598034269-0003
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

local10 writes:

> Hi,
>
> What would be a reasonably secure and simple way to encrypt files on Linux
> and then send them to a  non-technical Windows user so she would be able
> decrypt and read them?
>
> Any ideas? Thanks

Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:
$ 7z a -ptestwort -mhe=on secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z

Alternatively, you could also use aescrypt
(https://www.aescrypt.com/). It is not in Debian but supports a variety of
operating systems including Linux and Windows. GPG should also run on
Windows, but is a little harder to use IMHO.

HTH
Linux-Fan

--=_pte5-5038-1598034269-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEkKMBOo1F/f2B6jfK+Elw7bKeCLUFAl9AEV0ACgkQ+Elw7bKe
CLVNqxAApb5c8ugSou22vmSwpZzfSmpBQINEmHY/uc0S6vjKYcjEUeJ2a4n3EeMh
SP5goYmgKiCay/mORoFj8+Kgejv+g4x/JgpNVw8yJh+/PI9xPyRNNwuKcXTNsH1J
aw2ZX8s21vzM/oYAJRecLnxY8VAOF7nUB0K3SrHZwl18GcrUbE83IY80V8jSBEp7
A8IrKe48kLslYNzkfGmh+HiBfMrP7whyjlV73pjPQ2DL/5j2TemGHQxHzbfub2Qs
BSekIPy482+VN3jAf7N8HPIs6f6qNId9+O6W4iDdfHpATipuS8Js/KWsVZeCJi0s
c50MBMwScEtDJlnI2cmESdG5eBb/RIgVxk0yhoWEchJyRUf9O+6Px4zOVJ6wOH1l
7je8JHGnuExHm0hHbt3RVW02y/ZKzSAvcmIKufAHEQlEGe4W0mOZXeDn7AsT//HE
pXWJRuZDvh6+d2rRrUiY+tGSoSeIri4kGQqMJA/AQcJ+Zed7AF/8thPjWSP6fRvS
ajiB2ZNIuEjk3LOR0Pdl3zavIQBC78MmSnDvlEfmjoMrrWcYnzZDdDVFUWk2fAHG
2zxgRytPiTqFMxAqwLQGAun8umsm/7vK6kMGJaCXIOUab406cjzUs+F8uNkzairn
oP+eSw09jrZLrGiICcGYZM8iX+kgCQk3H/xDJ3HuBKA+7LgYsgg=
=exWf
-END PGP SIGNATURE-

--=_pte5-5038-1598034269-0003--
--=_pte5-5038-1598034269-0003
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

local10 writes:

> Hi,
>
> What would be a reasonably secure and simple way to encrypt files on Lin=
ux
> and then send them to a  non-technical Windows user so she would be able
> decrypt and read them?
>
> Any ideas? Thanks

Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:
$ 7z a -ptestwort -mhe=3Don secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z

Alternatively, you could also use aescrypt
(https://www.aescrypt.com/). It is not in Debian but supports a variety of
operating systems including Linux and Windows. GPG should also run on
Windows, but is a little harder to use IMHO.

HTH
Linux-Fan

--=_pte5-5038-1598034269-0003
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEkKMBOo1F/f2B6jfK+Elw7bKeCLUFAl9AEV0ACgkQ+Elw7bKe
CLVNqxAApb5c8ugSou22vmSwpZzfSmpBQINEmHY/uc0S6vjKYcjEUeJ2a4n3EeMh
SP5goYmgKiCay/mORoFj8+Kgejv+g4x/JgpNVw8yJh+/PI9xPyRNNwuKcXTNsH1J
aw2ZX8s21vzM/oYAJRecLnxY8VAOF7nUB0K3SrHZwl18GcrUbE83IY80V8jSBEp7
A8IrKe48kLslYNzkfGmh+HiBfMrP7whyjlV73pjPQ2DL/5j2TemGHQxHzbfub2Qs
BSekIPy482+VN3jAf7N8HPIs6f6qNId9+O6W4iDdfHpATipuS8Js/KWsVZeCJi0s
c50MBMwScEtDJlnI2cmESdG5eBb/RIgVxk0yhoWEchJyRUf9O+6Px4zOVJ6wOH1l
7je8JHGnuExHm0hHbt3RVW02y/ZKzSAvcmIKufAHEQlEGe4W0mOZXeDn7AsT//HE
pXWJRuZDvh6+d2rRrUiY+tGSoSeIri4kGQqMJA/AQcJ+Zed7AF/8thPjWSP6fRvS
ajiB2ZNIuEjk3LOR0Pdl3zavIQBC78MmSnDvlEfmjoMrrWcYnzZDdDVFUWk2fAHG
2zxgRytPiTqFMxAqwLQGAun8umsm/7vK6kMGJaCXIOUab406cjzUs+F8uNkzairn
oP+eSw09jrZLrGiICcGYZM8iX+kgCQk3H/xDJ3HuBKA+7LgYsgg=
=exWf
-END PGP SIGNATURE-

--=_pte5-5038-1598034269-0003--
--- Begin Message ---

local10 writes:


Hi,

What would be a reasonably secure and simple way to encrypt files on Linux
and then send them to a  non-technical Windows user so she would be able
decrypt and read them?

Any ideas? Thanks


Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:

Re: Encrypt files on Linux, decrypt on Windows

[Teemu Likonen]

* 2020-08-21 20:24:29+02, Linux-Fan wrote:

> GPG should also run on Windows, but is a little harder to use IMHO.

GnuPG it is pretty hard everywhere. Your recent signatures are reported
as "bad" (at least by Notmuch and Mutt). The signed data (message)
doesn't match with the signature.

About this thread's subject: If the original requirement for "reasonable
security" means also data integrity (the content is untouched) or
authentication (the sender is verified) then this all starts to point to
digital signatures, thus OpenPGP (like GnuPG).

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


signature.asc
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[Hans]

Am Freitag, 21. August 2020, 22:24:48 CEST schrieb Hans:
Additional info:

Just see here
https://stackoverflow.com/questions/19943903/build-windows-7z-self-extracting-installer-on-linux-server-how-to-change-exe-ic[1]
 

Good luck!

Hans

> Am Freitag, 21. August 2020, 19:46:13 CEST schrieb local10:
> Don't know, how stupid the user is. Try to use a selfexttracting form, like
> blapacked.exe. I suppose, to make a double click on this file, he will most
> likely be able to manage.
> 
> Installing software, huh, much too hard for most windows guys
> 
> Best
> 
> Hans
> 
> > Hi,
> > 
> > What would be a reasonably secure and simple way to encrypt files on Linux
> > and then send them to a  non-technical Windows user so she would be able
> > decrypt and read them?
> > 
> > Any ideas? Thanks




[1] 
https://stackoverflow.com/questions/19943903/build-windows-7z-self-extracting-installer-on-linux-server-how-to-change-exe-ic


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

Re: Encrypt files on Linux, decrypt on Windows

[Hans]

Am Freitag, 21. August 2020, 19:46:13 CEST schrieb local10:
Don't know, how stupid the user is. Try to use a selfexttracting form, like 
blapacked.exe. I suppose, to make a double click on this file, he will most 
likely be able to manage.

Installing software, huh, much too hard for most windows guys

Best

Hans

> Hi,
> 
> What would be a reasonably secure and simple way to encrypt files on Linux
> and then send them to a  non-technical Windows user so she would be able
> decrypt and read them?
> 
> Any ideas? Thanks



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

Re: Encrypt files on Linux, decrypt on Windows

[Matthew Graybosch]

On Fri, 21 Aug 2020 21:59:15 +0200
 wrote:

> If you are somewhat serious about security, you better don't use this:
> 
>   "ZIP supports a simple password-based symmetric encryption
>system generally known as ZipCrypto. It is documented in
>the ZIP specification, and known to be seriously flawed." [1]
> 
> 7z is reportedly better (and it does compress better, too). But I
> concur with the others: GnuPG is the gold standard here.

I don't disagree, but how likely is it that local10's intended
recipient will...

1. Have GnuPG installed on their Windows machine?
2. Know how to use it to decrypt files using local10's public key?

-- 
Matthew Graybosch   https://matthewgraybosch.com
#include  gemini://starbreaker.org
gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

Re: Encrypt files on Linux, decrypt on Windows

[tomas]

On Fri, Aug 21, 2020 at 02:42:23PM -0400, Matthew Graybosch wrote:
> On Fri, 21 Aug 2020 19:46:13 +0200 (CEST)
> local10  wrote:
> 
> > Hi,
> > 
> > What would be a reasonably secure and simple way to encrypt files on
> > Linux and then send them to a  non-technical Windows user so she
> > would be able decrypt and read them?
> 
> The "zip" command has an "--encrypt" option. As long as your recipient
> has WinZip (paid or trialware), you should be able to do the following:

If you are somewhat serious about security, you better don't use this:

  "ZIP supports a simple password-based symmetric encryption
   system generally known as ZipCrypto. It is documented in
   the ZIP specification, and known to be seriously flawed." [1]

7z is reportedly better (and it does compress better, too). But I concur
with the others: GnuPG is the gold standard here.

Cheers

[1] https://en.wikipedia.org/wiki/ZIP_(file_format)#Encryption
 - t


signature.asc
Description: Digital signature

Re: Encrypt files on Linux, decrypt on Windows

[Linux-Fan]

john doe writes:


On 8/21/2020 9:11 PM, David Christensen wrote:

On 2020-08-21 11:24, Linux-Fan wrote:


[...]


Encrypt on Linux:
$ 7z a -ptestwort -mhe=on secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z



So, the recipient must install 7-Zip on their Windows computer?


In that example: Yes or use a 7z.exe obtained from the website without
installation.

[...]


To the OP, look at creating a self extracting archive (not sure if it
works from Linux to Windows though).


It works from Linux to Windows, but it is trickier than I had imagined:

On Linux:

* Go to https://www.7-zip.org/download.html and download 64-bit x64

* Extract file 7z1900-x64.exe with 7z.

  $ mkdir sub
  $ 7z x -osub 7z1900-x64.exe

* Copy 7z.sfx from the extracted installer

  $ cp sub/7z.sfx .

* Create SFX archive for Windows

  $ 7z a -mhe=on -ptestwort -sfx7z.sfx mysfx.exe secret.txt

* Send file `mysfx.exe` to the Windows user

On Windows:

* Run `mysfx.exe` -- it prompts for the password (`testwort`).

I nowdays prefer the portable/installed version over SFX archives because
uncommon executables are often rejected by antivirus software (especially
.exe attachments to e-mails are prone to being deleted for security
reasons...). Although most scanners seem to be fine with a generated SFX
archive at the moment:

https://www.virustotal.com/gui/file/e2dd36862c27e1551916ed3e773a55ecedf2b35e658522fa982369cc90eaf488/detection

[...]

HTH
Linux-Fan


pgp4xXvGrbdSD.pgp
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[David Christensen]

On 2020-08-21 12:10, Teemu Likonen wrote:


I forgot to say that the file names are not encrypted in Zip archives.
They can be seen without password. To protect against that use Zip
twice: the inner layer is unencrypted archive for all the files and
outer layer encrypts the inner Zip file.


PeaZip has an option to encrypt the file names, and with a 
self-extracting archive *.exe the receipt does not need to install any 
software.



David

Re: Encrypt files on Linux, decrypt on Windows

[john doe]

On 8/21/2020 9:11 PM, David Christensen wrote:

On 2020-08-21 11:24, Linux-Fan wrote:

local10 writes:


Hi,

What would be a reasonably secure and simple way to encrypt files on
Linux
and then send them to a  non-technical Windows user so she would be able
decrypt and read them?

Any ideas? Thanks


Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:
$ 7z a -ptestwort -mhe=on secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z



So, the recipient must install 7-Zip on their Windows computer?


David



There is a portable version for Windows, if I recall correctly.

To the OP, look at creating a self extracting archive (not sure if it
works from Linux to Windows though).

--
John Doe

Re: Encrypt files on Linux, decrypt on Windows

[David Christensen]

On 2020-08-21 11:24, Linux-Fan wrote:

local10 writes:


Hi,

What would be a reasonably secure and simple way to encrypt files on 
Linux

and then send them to a  non-technical Windows user so she would be able
decrypt and read them?

Any ideas? Thanks


Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:
$ 7z a -ptestwort -mhe=on secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z



So, the recipient must install 7-Zip on their Windows computer?


David

Re: Encrypt files on Linux, decrypt on Windows

[Teemu Likonen]

* 2020-08-21 22:00:45+03, Teemu Likonen wrote:

> If your security is just about confidentiality (other's can't have the
> content) and you don't have really serious hackers targeting you then
> probably encrypted Zip archives are good enough. Obviously a good enough
> password is needed and secure ways for exchanging the password.

I forgot to say that the file names are not encrypted in Zip archives.
They can be seen without password. To protect against that use Zip
twice: the inner layer is unencrypted archive for all the files and
outer layer encrypts the inner Zip file.

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


signature.asc
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[David Christensen]

On 2020-08-21 10:46, local10 wrote:

Hi,

What would be a reasonably secure and simple way to encrypt files on Linux and 
then send them to a  non-technical Windows user so she would be able decrypt 
and read them?

Any ideas? Thanks



I maintain a working Windows installation for use-cases like this and 
have installed PeaZip:


https://peazip.en.softonic.com/


I use PeaZip to create a self-extracting encrypted 7z archive -- an 
*.exe file -- and send the archive by e-mail or Dropbox.



Once the receipt figures out how to obtain the archive -- anti-spyware 
and e-mail clients tend to block *.exe files -- they can run the 
archive, enter the password in a pop-up dialog, and extract the files 
via a small GUI.



David

Re: Encrypt files on Linux, decrypt on Windows

[Charles Curley]

On Fri, 21 Aug 2020 13:31:00 -0500
Paul Johnson  wrote:

> GnuPG.  It's in Debian, there's Windows versions on its website, and
> it's not some mystery box like Signal.

++

It also has the advantage that the cryptext will stay encrypted on any
intermediate servers. WhatsApp and Signal claim their traffic is, but
one must take their word for it.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Encrypt files on Linux, decrypt on Windows

[Teemu Likonen]

* 2020-08-21 19:46:13+02, local wrote:

> What would be a reasonably secure and simple way to encrypt files on
> Linux and then send them to a non-technical Windows user so she would
> be able decrypt and read them?

If your security is just about confidentiality (other's can't have the
content) and you don't have really serious hackers targeting you then
probably encrypted Zip archives are good enough. Obviously a good enough
password is needed and secure ways for exchanging the password.

I would like to suggest OpenPGP as we crypto nerds like to use only the
best available options which work with operations against evil state
enemies. But most people don't have such serious enemies. Any password
will stop almost all third parties.

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


signature.asc
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[Matthew Graybosch]

On Fri, 21 Aug 2020 19:46:13 +0200 (CEST)
local10  wrote:

> Hi,
> 
> What would be a reasonably secure and simple way to encrypt files on
> Linux and then send them to a  non-technical Windows user so she
> would be able decrypt and read them?

The "zip" command has an "--encrypt" option. As long as your recipient
has WinZip (paid or trialware), you should be able to do the following:

1. Use "zip --encrypt" to create an archive.
2. Send the archive.
3. Send the password in a separate email.

I do this at my day job at least once a week, and haven't had a problem
yet.

The zip(1) man page will provide additional details. Good luck.

-- 
Matthew Graybosch   https://matthewgraybosch.com
#include  gemini://starbreaker.org
gemini://tanelorn.city
"Out of order?! Even in the future nothing works."

Re: Encrypt files on Linux, decrypt on Windows

[Paul Johnson]

On Fri, Aug 21, 2020 at 12:46 PM local10  wrote:

> What would be a reasonably secure and simple way to encrypt files on Linux
> and then send them to a  non-technical Windows user so she would be able
> decrypt and read them?
>

GnuPG.  It's in Debian, there's Windows versions on its website, and it's
not some mystery box like Signal.

Re: Encrypt files on Linux, decrypt on Windows

[Linux-Fan]

local10 writes:


Hi,

What would be a reasonably secure and simple way to encrypt files on Linux
and then send them to a  non-technical Windows user so she would be able
decrypt and read them?

Any ideas? Thanks


Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:
$ 7z a -ptestwort -mhe=on secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z

Alternatively, you could also use aescrypt
(https://www.aescrypt.com/). It is not in Debian but supports a variety of
operating systems including Linux and Windows. GPG should also run on
Windows, but is a little harder to use IMHO.

HTH
Linux-Fan


pgpejwqiOkOJG.pgp
Description: PGP signature

Re: Encrypt files on Linux, decrypt on Windows

[john doe]

On 8/21/2020 7:46 PM, local10 wrote:

Hi,

What would be a reasonably secure and simple way to encrypt files on Linux and 
then send them to a  non-technical Windows user so she would be able decrypt 
and read them?

Any ideas? Thanks



Veracrypt could be one option.


--
John Doe

Re: Encrypt files on Linux, decrypt on Windows

[Darac Marjal]

On 21/08/2020 18:46, local10 wrote:
> Hi,
>
> What would be a reasonably secure and simple way to encrypt files on Linux 
> and then send them to a  non-technical Windows user so she would be able 
> decrypt and read them?

Signal (signal.org)

Signal is an instant messaging application. It uses a well respected
end-to-end encryption protocol (meaning that the messages are encrypted
by the client and sent over the internet before being decrypted by the
recipient's client).


>
> Any ideas? Thanks
>



signature.asc
Description: OpenPGP digital signature