Here's a procedure for reading lines from the stdin. It implements the
handling of a POST command from NNTP. It seems to work, but it looks
like work from a beginner. I wonder if there's anything you can say to
illuminate me.

What does it do? A thread will kill the program if the user takes too
long. (Otherwise we kill the thread.) The reading ends gracefully if
the user types a ``.'' on a line by itself. Otherwise we append the
current line read onto the end of a LINES-SO-FAR list and repeat. (Yes,
if a ``..'' is on a line by itself, that's the user escaping the dot
that's not the end of input. I decided to implement this corner-case
with that /let/ before repeating.)

(define (read-with-timeout [lines-so-far '()] [timeout 60])
(define killer
(thread (lambda ()
(sleep timeout)
(displayln "Timeout on posting article.")
(flush-output)
(exit))))
(define ln (read-line (current-input-port) 'return-linefeed))
(kill-thread killer)
(cond
[(eof-object? ln)
(displayln "fatal: eof while reading article...")
(exit)]
[(string=? ln ".")
(string-join lines-so-far "\r\n")]
[else
(let ([ln (if (string=? ln "..") "." ln)])
(read-with-timeout (append lines-so-far (list ln))))]))

Any thoughts, comments? Help to be a better Lisp programmer.

On 2023-12-26, Julieta Shem <jshem@yaxenu.org> wrote:
> Here's a procedure for reading lines from the stdin. It implements the
> handling of a POST command from NNTP. It seems to work, but it looks
> like work from a beginner. I wonder if there's anything you can say to
> illuminate me.
>
> What does it do? A thread will kill the program if the user takes too
> long. (Otherwise we kill the thread.) The reading ends gracefully if
> the user types a ``.'' on a line by itself. Otherwise we append the
> current line read onto the end of a LINES-SO-FAR list and repeat. (Yes,
> if a ``..'' is on a line by itself, that's the user escaping the dot
> that's not the end of input. I decided to implement this corner-case
> with that /let/ before repeating.)
>
> (define (read-with-timeout [lines-so-far '()] [timeout 60])
> (define killer
> (thread (lambda ()
> (sleep timeout)
> (displayln "Timeout on posting article.")
> (flush-output)
> (exit))))
> (define ln (read-line (current-input-port) 'return-linefeed))
> (kill-thread killer)
> (cond
> [(eof-object? ln)
> (displayln "fatal: eof while reading article...")
> (exit)]
> [(string=? ln ".")
> (string-join lines-so-far "\r\n")]
> [else
> (let ([ln (if (string=? ln "..") "." ln)])
> (read-with-timeout (append lines-so-far (list ln))))]))
>
> Any thoughts, comments? Help to be a better Lisp programmer.

Using a thread just for timing out a read is ugly, like something you'd
do in a shell program, not in a serious application.

(And if the shell is Bash, you wouldn't have to; it has a timed out read!
Type "help read" in bash: you can see that read can read characters
up to a specified delimiter, with a timeout (-t)).

A proper Unix program uses select or poll, or else uses setsockopt
to set up read timeout (if the input is known to be a socket).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> On 2023-12-26, Julieta Shem <jshem@yaxenu.org> wrote:
>> Here's a procedure for reading lines from the stdin. It implements the
>> handling of a POST command from NNTP. It seems to work, but it looks
>> like work from a beginner. I wonder if there's anything you can say to
>> illuminate me.
>>
>> What does it do? A thread will kill the program if the user takes too
>> long. (Otherwise we kill the thread.) The reading ends gracefully if
>> the user types a ``.'' on a line by itself. Otherwise we append the
>> current line read onto the end of a LINES-SO-FAR list and repeat. (Yes,
>> if a ``..'' is on a line by itself, that's the user escaping the dot
>> that's not the end of input. I decided to implement this corner-case
>> with that /let/ before repeating.)
>>
>> (define (read-with-timeout [lines-so-far '()] [timeout 60])
>> (define killer
>> (thread (lambda ()
>> (sleep timeout)
>> (displayln "Timeout on posting article.")
>> (flush-output)
>> (exit))))
>> (define ln (read-line (current-input-port) 'return-linefeed))
>> (kill-thread killer)
>> (cond
>> [(eof-object? ln)
>> (displayln "fatal: eof while reading article...")
>> (exit)]
>> [(string=? ln ".")
>> (string-join lines-so-far "\r\n")]
>> [else
>> (let ([ln (if (string=? ln "..") "." ln)])
>> (read-with-timeout (append lines-so-far (list ln))))]))
>>
>> Any thoughts, comments? Help to be a better Lisp programmer.
>
> Using a thread just for timing out a read is ugly, like something you'd
> do in a shell program, not in a serious application.
>
> (And if the shell is Bash, you wouldn't have to; it has a timed out read!
> Type "help read" in bash: you can see that read can read characters
> up to a specified delimiter, with a timeout (-t)).
>
> A proper Unix program uses select or poll, or else uses setsockopt
> to set up read timeout (if the input is known to be a socket).

In C I would have used select. But how do I select in Racket? I found
Racket's sync/timeout, a procedure based on Racket's ``events''. The
reference dissertates briefly about events at

https://docs.racket-lang.org/reference/sync.html

and they cite

John H. Reppy, Concurrent Programming in ML, Cambridge University
Press, 1999. https://doi.org/10.1017/CBO9780511574962

as a reference. It's unclear to me that this is what I'm looking for,
but it might very well be.

--8<---------------cut here---------------start------------->8---
#lang racket/base
(define (read-line-timeout [timeout 60] [port (current-input-port)])
(define port-or-false
(sync/timeout timeout port))
(and port-or-false (read-line port-or-false)))

(define (interact-with-timeout timeout)
(define ln (read-line-timeout timeout))
(cond [(not ln)
(say "> God, you're slow.")]
[(eof-object? ln)
(say "> Okay, see you later.")]
[else
(say (format "< ~a" ln))
(say "> But why do you say that?")
(interact-with-timeout timeout)]))

(define (say s) (displayln s) (flush-output))

(module+ main
(say "> Hello. Say anything and press RET.")
(interact-with-timeout 3))
--8<---------------cut here---------------end--------------->8---

I see to see a complicated behavior of this program in Windows ``Command
Prompt'', but not in the GNU EMACS eshell. On the Command Prompt,
sometimes the timeout doesn't take effect. To make it easy to hit
reproduce, I reduce the timeout to 1. Here's an example. I took way
longer than 1 second to type that ``123''. The timeout only took effect
on the second wait. Weird.

c:\something>racket timezup.rkt
> Hello. Say anything and press RET.
123
< 123
> But why do you say that?
> God, you're slow.

Julieta Shem <jshem@yaxenu.org> writes:

[...]

> I see to see a complicated behavior of this program in Windows ``Command
> Prompt'', but not in the GNU EMACS eshell. On the Command Prompt,
> sometimes the timeout doesn't take effect. To make it easy to hit
> reproduce, I reduce the timeout to 1. Here's an example. I took way
> longer than 1 second to type that ``123''. The timeout only took effect
> on the second wait. Weird.
>
> c:\something>racket timezup.rkt
>> Hello. Say anything and press RET.
> 123
> < 123
>> But why do you say that?
>> God, you're slow.

Here's a better presentation. I set the timeout to 1 second. After
about ten seconds, I wrote ``No timeout'' and pressed RET.

--8<---------------cut here---------------start------------->8---
c:\something>c:/sys/emacs/usr/mingw/usr/bin/time.exe racket timezup.rkt
> Hello. Say anything and press RET.
No timeout.
< No timeout.
> But why do you say that?
> God, you're slow.
0.00user 0.00system 0:11.68elapsed 0%CPU (0avgtext+0avgdata 5228maxresident)k
0inputs+0outputs (1389major+0minor)pagefaults 0swaps
--8<---------------cut here---------------end--------------->8---

On Tue, 26 Dec 2023 12:25:11 -0300, Julieta Shem wrote:

> https://docs.racket-lang.org/reference/sync.html

I had a look at that. Why do languages feel they have to stack on thick
layers of extra abstraction on top of basic POSIX concepts?

I do more Python than Lisp, and look how thin Python’s standard-library
abstractions on top of select/poll are:
<https://docs.python.org/3/library/select.html>. Makes it so much easier
to figure out what’s going on.

I suppose Racket could be worse. It could be Java.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Tue, 26 Dec 2023 12:25:11 -0300, Julieta Shem wrote:
>
>> https://docs.racket-lang.org/reference/sync.html
>
> I had a look at that. Why do languages feel they have to stack on thick
> layers of extra abstraction on top of basic POSIX concepts?

That seems to be the wrong thing to do for people who know the POSIX
concepts. I believe the Racket people want to create their own world
from scratch.

> I do more Python than Lisp, and look how thin Python’s standard-library
> abstractions on top of select/poll are:
> <https://docs.python.org/3/library/select.html>. Makes it so much easier
> to figure out what’s going on.

True.

> I suppose Racket could be worse. It could be Java.

Yes! Way worse.

Julieta Shem <jshem@yaxenu.org> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
> [...]
>
>> I see to see a complicated behavior of this program in Windows ``Command
>> Prompt'', but not in the GNU EMACS eshell. On the Command Prompt,
>> sometimes the timeout doesn't take effect. To make it easy to hit
>> reproduce, I reduce the timeout to 1. Here's an example. I took way
>> longer than 1 second to type that ``123''. The timeout only took effect
>> on the second wait. Weird.
>>
>> c:\something>racket timezup.rkt
>>> Hello. Say anything and press RET.
>> 123
>> < 123
>>> But why do you say that?
>>> God, you're slow.
>
> Here's a better presentation. I set the timeout to 1 second. After
> about ten seconds, I wrote ``No timeout'' and pressed RET.
>
> c:\something>c:/sys/emacs/usr/mingw/usr/bin/time.exe racket timezup.rkt
>> Hello. Say anything and press RET.
> No timeout.
> < No timeout.
>> But why do you say that?
>> God, you're slow.
> 0.00user 0.00system 0:11.68elapsed 0%CPU (0avgtext+0avgdata 5228maxresident)k
> 0inputs+0outputs (1389major+0minor)pagefaults 0swaps

This happens to be a known problem on Windows.

https://github.com/racket/racket/issues/4728

On Fri, 29 Dec 2023 02:19:44 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Tue, 26 Dec 2023 12:25:11 -0300, Julieta Shem wrote:
>
>> https://docs.racket-lang.org/reference/sync.html
>
>I had a look at that. Why do languages feel they have to stack on thick
>layers of extra abstraction on top of basic POSIX concepts?

For one thing, because Windows is not POSIX compliant. Languages that
try to be cross-platform have to do *something* to hide the
differences.

Whether you like the choices made by the implementors is a different
matter. ;-)

>I do more Python than Lisp, and look how thin Python’s standard-library
>abstractions on top of select/poll are:
><https://docs.python.org/3/library/select.html>. Makes it so much easier
>to figure out what’s going on.

Agreed, Python does a better job of looking like POSIX. However, in
1989 Guido had the benefit of (at least) POSIX.1 when he began to
develop Python. And as "dictator for life", it was easy to add things
when he thought they were needed.

Although the Racket project technically began in 2015, it grew out of
"PLT Scheme" which began in 1994. Scheme itself goes back to 1973 -
far before POSIX to a time when things like GUIs, modular programming,
networking, asynchronous I/O, threading, etc. were much less
important.

As a Scheme, PLT was hampered by compatibility concerns with a
language from the 1970s.

That's part of the reason the PLT group began Racket. Racket actually
is not a Scheme but rather is a unique language that syntactically
resembles Scheme and has similar (but greater) functionality.

Racket, in fact, supports readers (as in Lisp) with more or less
arbitrary parsing ability. If you are ambitous, you can create your
own DSL language having any syntax you like ... as long as it can
compile to Racket, it can be intermixed with Racket or with code from
any of a number of other DSLs that are available.

The Racket group currently is developing a new surface syntax -
tentatively called "Rhombus" - which will be more conventional infix
syntax. However, it still will be Racket underneath, so Racket and
Rhombus code will be able to be intermixed.

>I suppose Racket could be worse. It could be Java.

As a technical matter the JVM isn't bad ... it's only the Java
language that sucks. But there are compilers for many languages that
target the JVM, and most can interface to Java code if necessary. You
can code for JVM in Lisp or Scheme if you want to.

But Racket handles cross-platform quite nicely. Programs have to be
recompiled with the native compiler of course, but as long as they
don't use any non-Racket C libraries, they will be 100% *source*
portable and almost everything will just work.
[Windows and Linux return different native error codes, and of course
there is the CR/LF problem, but Racket can identify the host system
and it is pretty easy to write portable code - including GUI code -
that will run on either system.]

Current versions of Racket actually are built on Chez Scheme, and
there is a (somewhat customized) Chez runtime underneath. Using
Racket's foreign function interface (FFI) you can drop into Chez, or
into C, or into any language that supports being called from C.

With some restrictions, Racket itself supports being called from C, so
it is possible for a C program to embed a Racket instance to use
Racket libraries or even run a whole Racket program (in parallel if
the Racket instance is executed in a C thread).

On Fri, 29 Dec 2023 00:50:32 -0500, George Neuner wrote:

> ... Windows is not POSIX compliant.

Wasn’t NT supposed to be POSIX-compliant in the beginning? Seems like that
whole part of the system has bitrotted away ...

So you have to ask yourself: is your return from supporting Windows users
worth the greatly increased expense?

On Fri, 29 Dec 2023 06:04:52 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

>On Fri, 29 Dec 2023 00:50:32 -0500, George Neuner wrote:
>
>> ... Windows is not POSIX compliant.
>
>Wasn’t NT supposed to be POSIX-compliant in the beginning? Seems like that
>whole part of the system has bitrotted away ...

Not exactly. NT's "POSIX support" was to add limited signal
capability. Adopting the POSIX function APIs was never even
considered.

>So you have to ask yourself: is your return from supporting Windows users
>worth the greatly increased expense?

More people directly use Windows than directly use Unix/Linux.

George Neuner <gneuner2@comcast.net> writes:

> On Fri, 29 Dec 2023 02:19:44 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>
>>On Tue, 26 Dec 2023 12:25:11 -0300, Julieta Shem wrote:
>>
>>> https://docs.racket-lang.org/reference/sync.html
>>
>>I had a look at that. Why do languages feel they have to stack on thick
>>layers of extra abstraction on top of basic POSIX concepts?
>
> For one thing, because Windows is not POSIX compliant.

Microsoft lawyers called me to say Microsoft supports ISO-IEC
9945-1:1990 --- and, having installed Cygwin, they could not distinguish
a POSIX compliant system from Microsoft Windows. I said our team would
get back to them.

On Fri, 29 Dec 2023 10:54:14 -0500, George Neuner wrote:

> On Fri, 29 Dec 2023 06:04:52 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>
>>So you have to ask yourself: is your return from supporting Windows
>>users worth the greatly increased expense?
>
> More people directly use Windows than directly use Unix/Linux.

If you are publishing an open-source project, then it’s not the number of
users that matters, but the level of contributions you get back from an
active community.

Bringing out a Windows build will almost certainly lead to a massive
increase in your user base and in numbers of bug reports and complaints
and general noise, without a concomitant increase in the level of
contributions back from those Windows users. Comparatively very few
Windows users have any idea about software development (or how to write
good bug reports), and the platform itself is inherently not very friendly
to open-source development.

On Fri, 29 Dec 2023 13:52:41 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

>George Neuner <gneuner2@comcast.net> writes:
>
>> On Fri, 29 Dec 2023 02:19:44 -0000 (UTC), Lawrence D'Oliveiro
>> <ldo@nz.invalid> wrote:
>>
>>>On Tue, 26 Dec 2023 12:25:11 -0300, Julieta Shem wrote:
>>>
>>>> https://docs.racket-lang.org/reference/sync.html
>>>
>>>I had a look at that. Why do languages feel they have to stack on thick
>>>layers of extra abstraction on top of basic POSIX concepts?
>>
>> For one thing, because Windows is not POSIX compliant.
>
>Microsoft lawyers called me to say Microsoft supports ISO-IEC
>9945-1:1990 --- and, having installed Cygwin, they could not distinguish
>a POSIX compliant system from Microsoft Windows. I said our team would
>get back to them.

The key part there is "after installing cygwin".

The Windows APIs are not POSIX, but for the most part they provide
equivalent functionality, so POSIX calls can be translated into
Windows call (with varying degrees of difficulty, the asynch stuff in
particular is completely different). This is what cygwin does.

cygwin, however, has its own problems ... it is known to be unstable.

Moreover, Windows supports only a handful of signals, so if you want
to use one it doesn't support, your're out of luck.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/signal?view=msvc-170
https://www.man7.org/linux/man-pages/man7/signal.7.html

On Sun, 31 Dec 2023 01:31:34 -0500, George Neuner wrote:

> The Windows APIs are not POSIX, but for the most part they provide
> equivalent functionality, so POSIX calls can be translated into Windows
> call (with varying degrees of difficulty, the asynch stuff in particular
> is completely different). This is what cygwin does.

Actually, Cygwin actually manages to do something a bit better than that.

Consider the select/poll calls
<https://docs.python.org/3/library/select.html>: note the caveat that, on
Windows, they only work on sockets, whereas on regular POSIX OSes they
work on other things, in particular pipes.

Cygwin manages to implement its select/poll calls on pipes, on Windows.

On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 01:31:34 -0500, George Neuner wrote:
>
>> The Windows APIs are not POSIX, but for the most part they provide
>> equivalent functionality, so POSIX calls can be translated into Windows
>> call (with varying degrees of difficulty, the asynch stuff in particular
>> is completely different). This is what cygwin does.
>
> Actually, Cygwin actually manages to do something a bit better than that.
>
> Consider the select/poll calls
><https://docs.python.org/3/library/select.html>: note the caveat that, on
> Windows, they only work on sockets, whereas on regular POSIX OSes they
> work on other things, in particular pipes.
>
> Cygwin manages to implement its select/poll calls on pipes, on Windows.

In 2016 I started a small project called Cygnal which turns the Cygwin
DLL into a "Native Windows" run-time library.

Since then, I've been using that as the basis of the Windows port of
the TXR language: that version that uses the executable installer.

You can compile a program under Cygwin, as a Cygwin program. Then
bundle it with the CYGWIN1.DLL from Cygnal, and ship it as a Cygnal
program.

As a Cygnal program, it enjoys a number of native-like conventions:

- native paths like C:\Users\bob\file.txt (no /cygdrive stuff).
- the otherwise POSIX chdir() function implements the DOS/Windows
"logged drive" concept.
- PATH is semicolon separated, once again.

- ... other things, all documented:

http://kylheku.com/cygnal

Cygnal is probably the best way to port a POSIX program to Windows.

(If there were a better way, I'd have used that instead of bothering
with making a Cygwin DLL fork.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sun, 31 Dec 2023 07:27:56 -0000 (UTC), Kaz Kylheku wrote:

> Cygnal is probably the best way to port a POSIX program to Windows.

There is a better way now, and that is WSL2.

On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 07:27:56 -0000 (UTC), Kaz Kylheku wrote:
>
>> Cygnal is probably the best way to port a POSIX program to Windows.
>
> There is a better way now, and that is WSL2.

I don't think so. With Cygnal, you deliver an .exe accompanied by
a DLL or two, and that's it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sun, 31 Dec 2023 17:20:16 -0000 (UTC), Kaz Kylheku wrote:

> On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Sun, 31 Dec 2023 07:27:56 -0000 (UTC), Kaz Kylheku wrote:
>>
>>> Cygnal is probably the best way to port a POSIX program to Windows.
>>
>> There is a better way now, and that is WSL2.
>
> I don't think so. With Cygnal, you deliver an .exe accompanied by a DLL
> or two, and that's it.

WSL2 at least lets you run a proper Linux distro, with proper package
management.

On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 17:20:16 -0000 (UTC), Kaz Kylheku wrote:
>
>> On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Sun, 31 Dec 2023 07:27:56 -0000 (UTC), Kaz Kylheku wrote:
>>>
>>>> Cygnal is probably the best way to port a POSIX program to Windows.
>>>
>>> There is a better way now, and that is WSL2.
>>
>> I don't think so. With Cygnal, you deliver an .exe accompanied by a DLL
>> or two, and that's it.
>
> WSL2 at least lets you run a proper Linux distro, with proper package
> management.

Frickin Windows as a host for Linux? That's a recipe for disaster
(MS Windows must die; thank you).

On Sun, 31 Dec 2023 21:30:18 -0000 (UTC), De ongekruisigde wrote:

> Frickin Windows as a host for Linux? That's a recipe for disaster (MS
> Windows must die; thank you).

Microsoft has no choice: it has to do something to stem the tide of
developers deserting Windows for Linux. Of course WSL2 is a kludge. But
then the whole history of Windows is of piling kludges on kludges, for
short-term profit-driven reasons.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sun, 31 Dec 2023 21:30:18 -0000 (UTC), De ongekruisigde wrote:
>
>> Frickin Windows as a host for Linux? That's a recipe for disaster (MS
>> Windows must die; thank you).
>
> Microsoft has no choice: it has to do something to stem the tide of
> developers deserting Windows for Linux. Of course WSL2 is a kludge. But
> then the whole history of Windows is of piling kludges on kludges, for
> short-term profit-driven reasons.

It's pretty useful.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sun, 31 Dec 2023 17:20:16 -0000 (UTC), Kaz Kylheku wrote:
>
>> On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Sun, 31 Dec 2023 07:27:56 -0000 (UTC), Kaz Kylheku wrote:
>>>
>>>> Cygnal is probably the best way to port a POSIX program to Windows.
>>>
>>> There is a better way now, and that is WSL2.
>>
>> I don't think so. With Cygnal, you deliver an .exe accompanied by a DLL
>> or two, and that's it.
>
> WSL2 at least lets you run a proper Linux distro, with proper package
> management.

Funny you say proper package management as if UNIX ever had this ---
before GNU Guix.

On Sun, 31 Dec 2023 21:48:06 -0300, Julieta Shem wrote:

> Funny you say proper package management as if UNIX ever had this ---
> before GNU Guix.

Where was there a “Unix” that had this? It was pretty much developed and
refined by Debian and Red Hat, from about 1993 onwards.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sun, 31 Dec 2023 21:48:06 -0300, Julieta Shem wrote:
>
>> Funny you say proper package management as if UNIX ever had this ---
>> before GNU Guix.
>
> Where was there a “Unix” that had this? It was pretty much developed and
> refined by Debian and Red Hat, from about 1993 onwards.

Funny you think that Debian and Red Hat ever had it. What they seem to
have done --- with all due respect --- is to compress files with
metadata. Pretty useful, but I think that /management/ should be
applied to GNU Guix, with due credit to Nix, the pioneer.

On Mon, 01 Jan 2024 00:02:57 -0300, Julieta Shem wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sun, 31 Dec 2023 21:48:06 -0300, Julieta Shem wrote:
>>
>>> Funny you say proper package management as if UNIX ever had this ---
>>> before GNU Guix.
>>
>> Where was there a “Unix” that had this? It was pretty much developed
>> and refined by Debian and Red Hat, from about 1993 onwards.
>
> Funny you think that Debian and Red Hat ever had it. What they seem to
> have done --- with all due respect --- is to compress files with
> metadata.

They do dependency management, which is a crucial capability. It allows
for code reuse, sharing one copy of a dependency among multiple client
packages, and one-stop upgradeability for everything installed.

No offence if you didn’t understand that. Seems most Windows users have
difficulty appreciating it.