Merry GNUsmas, friends!

[Kaz Kylheku]

Oh crap, that reads "Samsung" backwards. 

Sorry, never mind ...

Re: New utility for output monitoring: pw ("PipeWatch")

[Kaz Kylheku]

On 2022-05-29 02:50, Alfred M. Szmidt wrote:
> How is this different from the pv command that is quite standard on
> GNU/Linux systems?

It's quite different in that pv is interposed between programs,
and provides some progress indication and throughput measurement,
which are updated on the TTY as the data moves across.
Whereas pw is at the end of the pipeline as a consumer, and
actually displays the content itself (which is expected to be text),
with interactive features.

It's particularly good for drilling in on repeating patterns,
kind of like an "oscilloscope for text". (Digital) scopes capture
signal samples through some internal buffer, and sample it on the
screen, with triggers that can make periodic patterns stabilize,
and pw kind of does that sort of thing with lines of text.

A few weeks ago I posted a new 7 minute demo/tutorial to Vimeo,
which is narrated; I do various things and indicate what commands
I'm using and what is going on.

https://vimeo.com/710155314

Cheers ...

New utility for output monitoring: pw ("PipeWatch")

[Kaz Kylheku]

Hi All, 

I put together a new interactive tool for monitoring program output,
particularly the output of programs which run indefinitely and continuously
produce output. 

https://www.kylheku.com/cgit/pw/about/ (you can see a couple of videos here) 

pw continuously reads its standard input and pumps it through an internal
line-oriented FIFO, which is sampled to produce display on your terminal. Some
nice features are built around that basic idea. 

pw is integrated with POSIX job control. It knows when it is in the background
process group, and in that state it keeps reading and processing without
updating the display. The upshot of this is that you can easily juggle multiple
long-running programs that produce output, if you redirect all of them to to
different backgrounded instances of pw. Any time you want to know what is going
on with any one of them, just bring it into the foreground to look at the pw
display; then Ctrl-Z it into the background and let it run again with "bg".

The whole thing is under 2000 lines of C in one source file, BSD-licensed.
Since it doesn't retain the bulk of the data passing through it, it runs in
a small amount of memory. 

Cheers ..

Re: cURL author receives rude LogJ4 security inquiry

[Kaz Kylheku (gnu-misc-discuss)]

On 2022-02-25 00:45, Jean Louis wrote:

* Alfred M. Szmidt  [2022-02-25 10:47]:

Please stop thinking you know what someone misunderstood or not,
specially when they are not on this list and can respond.


Allow me to think what I think as I have went through the book, and it
is my impression founded on very clear statements of Linus. That is my
review of the book as related to what he was thinking of operating
system. You may find it wrong and thanks for your insights. Though I
will keep thinking... 珞


We do say things like "the free function doesn't necessarily
return memory to the OS, though under some circumstances it may."

In that nuance, malloc isn't part of the operating system, and
neither is the program which is calling it (even if it happens to
be the init daemon or something).

Re: cURL author receives rude LogJ4 security inquiry

[Kaz Kylheku (gnu-misc-discuss)]

On 2022-02-24 21:02, Richard Stallman wrote:

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That Linus Torvalds had serious misunderstandings on what 
"operating

  > > system" is ...

  > is vanishingly improbable.

Linux is a kernel, but many people think that it is an operating
system.  Perhaps Jean Louis was referring to that.  I am not sure
"misunderstanding" was the right word for it, though.


It seems pretty clear that Linus Torvalds was engaged in an activity
which he believed was headed in the direction of making a Unix-like
operating system, along the lines of Minix or Coherent or what have
you.  The GNU project was also replacing a Unix (including working
on a kernel), so the comparison to GNU makes sense in that light.

One short term goal was self-hosting: to stop compiling that
system under Minix, but do that under itself: so he wasn't just running
some regression test cases under the new kernel, but he had a system
with Bash and GCC.

He likely didn't suspect that the result of this activity would
be a decades-long project that is limited to producing a kernel
(and some utilities specific to it which depend on a third party
C library). Let alone that it would be a popular kernel that
people would turn into operating systems by combining it with other 
pieces,

and that they would still persist in calling every such a system
"Linux", informally. Let alone that it would be the kernel that
effectively ties together the GNU system and gets it into the
hands of large numbers of users on consumer-grade hardware.

At that time, it would have made sense for Torvalds to believe he
was working on an operating system project; there is no evidence
to support the belief that he had no idea what "operating system"
means.

Re: cURL author receives rude LogJ4 security inquiry

[Kaz Kylheku (gnu-misc-discuss)]

On 2022-01-30 20:32, Akira Urushibata wrote:

LogJ4 Security Inquiry - Response Required
https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquiry-response-required/

  On Friday January 21, 2022 I received this email. I tweeted about it
  and it took off like crazy.

  The email comes from a fortune-500 multi-billion dollar company that
  apparently might be using a product that contains my code, or maybe
  they have customers who do. Who knows?


It really looks to me like the "Information Security" people of that
company are just ignorant. It seems they really thought they are
sending this inquiry (which is just a questionnaire) to a supplier
company. Someone handed them a list of contacts to which they were
instructed to send some spam letter about the issue (perhaps the
composition of that letter being left up to them). Somehow Haxx contact
info was in the list.

The number one rule of Internet participation these days is, perhaps:
refuse to be outraged.

Never attribute to malice what can be easily explained by ignorance.

Do not feed the internet outrage machine, on any topic.

The letter doesn't ask anyone to work on any fix;  is simply
asking whether the recipients use Log4j in anything that ends
up in  products and such, or whether the supplier had any
incidents revealing info about . Additionally, what steps  
should

take in addition to what had been done on the supplier's side.

The assumption is that there is a relationship; that Haxxe are
suppliers who have customer management people who would know all that
stuff: like which  products use what pieces supplied by Haxxe.

The letter more or less makes sense if sent to that type of vendor.

Re: Judge declares zoom of iPhone image unacceptable in court

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-11-15 13:36, Akira Urushibata wrote:

I work on image processing software.  I may, one day, be summoned to
court to testify on the technology in use here.  Software that
enlarges images add pixels, but generally this is done by
interpolation.  A new pixel between an existing red pixel and a yellow
pixel is colored orange.  By this method, high-contrast details do not
emerge from the void.


There is the rub. Since high-contrast details do not emerge from the
void, there is no point in doing such an enlargement in the first place.

Anyone trying to convince a court of something using some enlarged 
digital

image can be assumed to be inventing some pixels. Without those, nothing
new will be seen that the naked eye cannot see by looking closely at the
original image: closely enough to see the original pixels individually.

This has nothing to do with closed source. Even if the implementation
of the enhancing algorithm is free, it has to be validated to be
correctly based on some reference mathematics, and that the algorithm
isn't being misused to show something that really isn't there.

All of that is entirely outside of the scope of a murder trial. You
are talking about bringing in a lot of signal processing expertise
into the case, all for a topic that doesn't directly pertain to the 
case,

but which rather pertains to one party's insistence on being allowed to
use some particular kind of image enhancement algorithm to manipulate
the evidence.

The judge is basically right to toss this out, without a solid
system in place for dealing with claims of that type.

We are probably going to see a lot of this going forward.

It seems that a potentially good solution would be for the justice
system itself to provide certain signal processing tools, such that
only those tools may be used, and only in certain ways.

For instance, if you want to draw the jury's attention to, say, the
high frequency content in some image, then you just use the software
provided by the court, in specific ways. The result is then admissible
as bona fide high frequency content in the original evidence, and
whatever it makes more easily perceived is ruled as being real.

That software could be free; anyone should be able to obtain it in
source form. But only a certain fork of the software, built in a certain
way, run on a certain system, would be approved for manipulating
evidence such that the results are admissible in the courtroom.

For that matter, specific forensic staff would do the manipulating,
not the lawyers, defendants or plaintiffs or agents hired by them.
The original material would be submitted to the court formally,
with instructions on what is to be cropped, enlarged, enhanced or
whatever else. The deliverables from that would then formally come back
and get attached to the case. Or some workflow of that nature.

It's no different from any other forensics. For instance why and how is
DNA evidence admissible? It must be based on following very specific 
procedures
in handling and processing the evidence. You can't come to the court 
room
and, "Oh, Your Honor, I analyzed this piece of fabric from the crime 
scene

with a DNA munging system I ordered off Alibaba ...". Surely, that must
be done professionally.

Re: "Freedom" is really the wrong word

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-11-04 17:31, dick wrote:

Got it.  Companies aren't upfront about their motives.

Got it.  Companies maneuver to eliminate competitors, free or 
otherwise.


Heaven forbid capitalist entities should resort to that kind of 
unconscionable
gamesmanship.  Dale Carnegie, you've been put on notice.  In the 
meantime,
I'll continue leveraging Google's search and Github's hosting to 
improve GNU

Emacs.


I was pretty excited by the YouTube video of your PowerPoint 
presentation

about retargetting Emacs Lisp to compile for the .net CLR, supporting
binary-only application delivery. Finally elispers can get paid.

Can you add me to your Slack channel? (Or was that Discord?)

I had a bit of trouble opening your documentation with Adobe Acrobat DC;
can you put the original .docx file into your Google Drive and share it?

Thx.

Long live fr^H^Hopen source!

Re: "Freedom" is really the wrong word

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-11-04 10:06, dick wrote:

There is nothing insidious with such a paint


And yet, free software rhetoric emphatically characterizes nonfree as 
"causing
harm in a way that is gradual or not easily noticed," which is 
Merriam-Webster's

definition of "insidious."


The paint in the example would only be insidious if, say, it appeared to 
mix
correctly initially and looked fine upon application to the surface, and 
then

the surface turned pitch black several months or years later.

It's not insidious if the mixture turns black right in the paint pot.

Particularly so if the data sheet for either paint warns against it.

If there is no warning, and there is a delayed reaction, then it more or 
less meets

the definition of insidious.

Re: Continuation of my previous mail

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-05-04 00:06, Rohit Dutt via General GNU project and free 
software discussions wrote:

Just to get things straight and end the matter, what exactly is this
"joke about _abortion_"??!! I don't find abortion anything to joke 
about.

Someone tell me please.


There was never any joke about abortion in the GNU C library manual.

There was a satirical remark protesting legislation that prohibits 
talking

about abortion.

That remark, under the description of the C abort function, made its 
point

without mentioning the word "abortion" at al.

"Future Change Warning: Proposed Federal censorship regulations may 
prohibit us
from giving you information about the possibility of calling this 
function. We
would be required to say that this is not an acceptable way of 
terminating a

program."

Though there is humor in it, it is serious and not simply a joke. It is 
no more
a joke than Jonathan Swift's "A Modest Proposal" is a joke about poor 
people,

or about eating children.

Framing the remark as a joke about abortion is not a well-reasoned,
intellectual stance. It's merely a populist narrative intended to obtain
agreement in support of the remark's removal.

The remark opposes censorship in connection with talking about abortion. 
 That
censorship harms women who are in a situation where one of their options 
may
be to have an abortion, by curtailing their choices. Therefore, the 
remark

can be interpreted as supporting those women.

(Notably, the remark can also be interpreted as a clear instance in 
which

Richard Stallman, stood up for women.)

Not a joke about abortion at all, the remark says that practitioners 
should

be free to talk about abortion and offer it as a choice.

Obviously, the remark would not have sat well with members of certain
demographic groups who oppose such freedom and support the gag 
legislation.

Bad actor knowingly submitting incorrect kernel patches pulls "intimidating" and "unwelcome" rhetoric.

[Kaz Kylheku]

Would you believe it?

"I will not be sending any more patches due to the attitude
that is not only unwelcome but also intimidating to newbies
and non experts."

Quoted in archived message here:

https://www.spinics.net/lists/netdev/msg737156.html

also here:

https://lore.kernel.org/linux-nfs/yh%2ffm%2ftsbmczz...@kroah.com/

(Unfortunately, the message from which that is quoted is not
available in the archives. I suspect that the list in question
rejected it or didn't get it for some reason, but Greg got it
directly via CC.)

Re: police report against the petition mob

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-03-28 17:49, Jacob Bachmeyer wrote:

Daniel Pocock wrote:
: host eggs.gnu.org[209.51.188.92] said: 550 bad domain - 
email

sysad...@fsf.org for details (in reply to RCPT TO command)


: host eggs.gnu.org[209.51.188.92] said: 550 
bad

domain - email sysad...@fsf.org for details (in reply to RCPT TO
command)


Those messages say "bad domain" ... either someone has very
specifically rigged the mail server to specifically reject your email
with a bogus error, or there was a very unfortunately timed
configuration error that caused a GNU MX to be unaware that gnu.org
exists.  Considering that the former would require specially modified
code, while the latter could be the result of an innocent typo in a
configuration file, I would suspect the latter to be more likely.


Can we tell from that diagnostic which domain is the "bad domain";

To be confident, I would need inside information: what the mail 
exchanger

is and how it is configured.

It is in response to a "RCPT TO" command, but that doesn't mean it
pertains only to the content of that command.

A mail exchanger can collect both the MAIL FROM and RCPT TO commands,
and then subject the SMTP connection to numerous checks that include
validating the sender's domain (given in MAIL FROM).

Re: Truth matters when writing software and selecting leaders

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-03-25 18:57, Jacob Bachmeyer wrote:

Kaz Kylheku (gnu-misc-discuss) wrote:

On 2021-03-24 19:55, Jacob Bachmeyer wrote:
Does there appear to be some form of hidden coordination behind these 
articles?


As I understand, RMS always thought that proprietary software
companies would make some kind of large legal attack on the GNU
project, so he was very particular about setting up the FSF and
arranging for copyrights on many GNU packages to be held by the FSF.
If we interpret the SCO mess as that attack, the strategy seems to
have worked:  SCO did not attack GNU, but instead attempted to attack
the Linux kernel project.  Ultimately, they failed but I now wonder 
if

we may be seeing a different angle of an attack on the GNU project
that RMS did not anticipate.


I also have similar suspicions. If you can replace the stewards of
free software with meek, emotional weaklings, or fools, you can easily
manipulate those projects in whatever direction you see fit.

"You must accept this backdoor patch because it's written by a
member of a vulnerable, disadvantaged group."

If you don't think that's coming, just sit back and watch.


I have vague memories of similar incidents having already occurred,
although I do not recall exactly what they were.  I think they were
actually demands for direct commit access, on the grounds that none of
the active developers were [insert FOOBAR group name here].  I want to
say that the attempts failed, but I am not certain.

As a maintainer of a package that I did not write, I expect that I
would react very badly to anyone trying to push an obviously defective
patch on grounds of personal identity.


Those incidents could have been "innocent" in the sense that
the person was really just working on their own and actually member
of [FOOBAR group], just with a really oboxious personality and
way of thinking.

The conspiracy-like theory of mine that I'm referring to is that the
submitter is not actually a member of any [FOOBAR group]. The claim is 
fake,

used by some nefarious agency to push rogue commits.

To make it crystal clear, I am not in any way "FOOBAR-phobic" or
whatever.

That strategy will easily work if the project leaders have been
replaced by mental/emotional weaklings, by some coup in which the 
original

leaders were displaced for faintly smelling of being resistant
to unconditional "inclusivity".

I'm not even saying anything like that the new project leaders are
moles.  Basically everyone involved, up to that point, had just been
a pawn being played.

Let me articulate the crazy conspiracy theory more precisely:
some nefarious agencies are injecting animosity into free software
communities in order to create disruption which will have the result
of bringing changes into projects, such that the leadership of those
projects becomes more docile and pliable in the face of pressure from
those nefarious agencies. Nefarious agencies could be corporations,
governments (local and foreign), you name it.

The disruption is what causes certain social activists to take notice
of free software and become attracted to free software projects
in the first place.

"Hey there is this world of free software which is really great
and powers most of the Internet. But I hear stories about how it's
run by volunteers some of whom are bad people. Racists, trans-phobics,
defenders of pedophilia and sex trafficking. That's how I even heard
about this stuff in the first place, sadly! Well, we can fix that.
Gosh, darn it, I'm gonna join one of these projects and do something
about it!"

Think of the analogy of smearing something with blood to attract
predators.

I think the most level-headed attitude to have is represented in that
"no code of conduct". https://nocodeofconduct.com/

Projects must put up a barrier against allowing manipulation via
irrelevant politics. All decisions must be purely technical. Nobody
must be allowed to manipulate technical decisions, like what software
changes are approved, by means of gender identity politics, race or
anything else. This is necessary for software security and the survival
of free software as such.

Re: Truth matters when writing software and selecting leaders

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-03-24 19:55, Jacob Bachmeyer wrote:
Does there appear to be some form of hidden coordination behind these 
articles?


As I understand, RMS always thought that proprietary software
companies would make some kind of large legal attack on the GNU
project, so he was very particular about setting up the FSF and
arranging for copyrights on many GNU packages to be held by the FSF.
If we interpret the SCO mess as that attack, the strategy seems to
have worked:  SCO did not attack GNU, but instead attempted to attack
the Linux kernel project.  Ultimately, they failed but I now wonder if
we may be seeing a different angle of an attack on the GNU project
that RMS did not anticipate.


I also have similar suspicions. If you can replace the stewards of
free software with meek, emotional weaklings, or fools, you can easily
manipulate those projects in whatever direction you see fit.

"You must accept this backdoor patch because it's written by a
member of a vulnerable, disadvantaged group."

If you don't think that's coming, just sit back and watch.

Re: Truth matters when writing software and selecting leaders

[Kaz Kylheku (gnu-misc-discuss)]

On 2021-03-24 19:13, Akira Urushibata wrote:

Richard Stallman recently announced at LibrePlanet that he would
return to the FSF board.  Soon after this announcement, many articles
appeared online stating strong objection to his return.

I have read several of them and I do not like what I see.


I see lies. For instance:

"RMS has spent years on a campaign against using people’s correct
 pronouns. This is poorly disguised transphobia. [...]
 The main page on his web site includes the statement that
 “‘They’ is plural — for singular antecedents, use singular
 gender-neutral pronouns.”"

 [https://rms-open-letter.github.io/appendix]

But the references given completely contradict this claim.
Did they not read the material, one has to wonder.

RMS didn't like "they" used as a singular, due to issues such
as a ambiguities of reference (is the antecedent the two people
mentioned, or just the latter?) He invented gender-neutral pronouns
and uses them. Those pronouns carry no indication of someone's
biological gender or sexual identity.

This shows that RMS cares about the issue and has put in more effort
into respectful communication than many an editor of a random
LGBTQ newsletter.

The individuals and organizations who signed the petitition added
their names under a letter that contains or references
bare-faced lies.

I don't understand why anyone would do that, even if they support
the removal for some other reasons which seem valid to per.

One's name is a very important asset; when you sign it under
a document which contains lies, without being deceived or coerced,
you severely tarnish that asset.

Re: It is not easy to tell people about freedom

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-11-07 14:49, Akira Urushibata wrote:

Interesting story.


Thank you.



Does the current translation of www.gnu.org show anywhere
inconsistencies in that context?



https://www.gnu.org/home.ja.html


The current Japanese translations of GNU documents uses "jiyuu"
throughout.  The changes were made when Mr. Yutaka Niibe (widely known
as "gNiibe") took over as maintainer.

Sadly, the damage has been done.  The change came too late.  People
who say "jiyuu sofutouea" is a small minority.  It his hard to change
this for the Japanese in general do not like to break with the status
quo.


It seems it might be hard to convince people not to use "furii 
sofutouea"

when all they have to do is look at English-language materials and see
that "free software" is being used. Won't some people thing, "why must 
we

shun 'furii sofutouea' in Japanese, when English speakers call it
'free software'?"

The word jiyuu is not free (pun intended) from subversion. An entire
discount clothing chain in Japan is called GU (gee-yu, get it?).
It provides a shopping experience and products that resemble Uniqlo,
but at lower prices.

https://en.wikipedia.org/wiki/GU_(retailer)

Quote:

 "[GU] is fully owned by the company Fast Retailing, which is better
 known as the owner of the retail chain Uniqlo. The name is a pun of
 the word jiyū (自由, free), meaning free from high cost clothing."
^

The company themselves dress this up (pun intended) in some glibly
vague marketing spin about the connection between improving oneself
and donning some new rags:

https://www.gu-global.com/jp/ja/corp/company/

Quote (manual transcription from image):

 YOUR FREEDOM
 自分を新しくするを。
 ちょっと服を変えるだけで、自分が変わる。
 前向きな自分、なりたかった自分、見たことない自分。
 誰だって、まいにち新しい自分に出会える。
 旬で、心地よい服を。今の気分で、もっと自由に。
 GUは、自由。

Which says something like:

 YOUR FREEDOM
 The freedom to renew yourself.
 Just by changing clothes a little, you change.
 The forward-looking you, that you you wanted to become,
 a never-before-seen you.
 Each day, we all encounter a new version of ourselves.
 Comfortable clothes in fresh styles. In the current mood,
 only more freely.
 GU is freedom.

We shouldn't pin too much hope on the power of one word.

Why it's not easy to tell people about freedom is that most
people don't have the background to understand how software
is built using compiled languages, or the background in copyright.

Even when they understand that "free" is "as in speech", that
does not inform them. However, it could inspire curiosity in
some people, to ask the question: how can a program be free
as in speech? So for that, it's helpful to have a precise word
in the first place, so those people's curiosity is unfailingly
connected with the right concept.

Re: Gow, Cygwin alternative refers to GNU programs as open source UNIX tools

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-10-27 14:24, Tobias Geerinckx-Rice wrote:

Jean Louis 写道：

I did not notice it. There are no sources on Github, just binaries


They take some effort to miss:
.


The situation here is that

- gow-utilities-src-0.8.0.tar contains the source code archives of
  the bundled utilities, but no build scripts or documentation.
  There is not even a hint as to what toolchain is required; we can
  guess from .dll files bundled with the executables that this
  that this project just extends MSYS (the run-time system for MinGW)
  and thus probably uses the environment with which that is built.

- The download links to a "Source code" .zip and .tar.gz file
  actually lead to archived snapshots of the git repository
  with the all the .exe files and no source code.

These issues are just simple omissions that can be easily rectified.
I suspect that the author thinks he has met the obligations by putting
out that big aggregate tar file containing the utility source tarballs.

In fact, there is actually no need to provide that, since those programs
have upstream repositories which have those.

Nowadays, distributions don't ship copies of the tarballs; the 
mainstream

practice is for build scripts to download tarballs from the original
upstream locations, or else mirrors, and then cache them locally.

Even if the build script doesn't do any downloading, if it is obvious
from its source code that it requires, say, sed-4.2.1-src, then the
user can manually procure that exact program.

What's troubling about the source code archive is that it contains .zip
files and not original tarballs.

$ tar tvf gow-utilities-src-0.8.0.tar
drwxrwxrwx 0/0   0 2014-02-15 10:30 gow-utilities-src-0.8.0/
-rwxrwxrwx 0/0  368562 2012-09-09 20:08 
gow-utilities-src-0.8.0/bc-1.06-2-src.zip
-rwxrwxrwx 0/0 3796772 2012-09-09 20:09 
gow-utilities-src-0.8.0/bison-2.4.1-src.zip
-rwxrwxrwx 0/0  416587 2012-09-09 20:10 
gow-utilities-src-0.8.0/bzip2-1.0.5-src.zip
-rwxrwxrwx 0/0 9371720 2012-09-10 06:48 
gow-utilities-src-0.8.0/coreutils-5.3.0-src.zip
-rwxrwxrwx 0/0 4007401 2012-09-10 07:13 
gow-utilities-src-0.8.0/curl-7.27.0-src.zip
-rwxrwxrwx 0/0 1482028 2012-09-10 06:45 
gow-utilities-src-0.8.0/diffutils-2.8.7-1-src.zip

[ ... ]

So in other words, the sources are repackaged, leading to the suspicion
that there are alterations. Distributions should use the original
sources: either pull from the real upstream git repositories or what
have you or use the official release tarballs.

Let's dig into this deeper, using Bison as our focus.  What we find 
inside
bison-2.4.1-src.zip is not just the Bison sources, but a tree structure 
containing

a build directory and other superfluous materials.

The Bison source is buried in this tree, at the relative path

   src/bison/2.4.1/bison-2.4.1-src

This is not identical to GNU Bison 2.4.1.

   $ diff -urN bison-2.4.1 
gow-bison-2.4.1/src/bison/2.4.1/bison-2.4.1-src | wc

   141896  509172 4155393

The diff exceeds four megabytes!  Some of the changes are due to line 
ending
differences: the files have been altered with carriage return 
characters.
However, this is not the bulk of it. If we suppress whitespace with -w, 
the

diff size is still about the same:

   $ diff -urNw bison-2.4.1 
gow-bison-2.4.1/src/bison/2.4.1/bison-2.4.1-src | wc

   141757  508598 4150945

Below is a small samples of the differences, which are serious. What is 
being called

bison-2.4.1 is certainly not bison-2.4.1:



--- bison-2.4.1/doc/bison.1 2008-12-11 14:07:25.0 -0800
+++ gow-bison-2.4.1/src/bison/2.4.1/bison-2.4.1-src/doc/bison.1 
2008-12-14 04:03:25.0 -0800

@@ -3,7 +3,7 @@
 .SH NAME
 bison \- GNU Project parser generator (yacc replacement)
 .SH SYNOPSIS
-.B bison
+.B j:\Devel\bison\2.4.1\bison-2.4.1\src\bison.exe
 [\fIOPTION\fR]... \fIFILE\fR
 .SH DESCRIPTION
 .I Bison
@@ -60,9 +60,12 @@
 .PP
 Generate LALR(1) and GLR parsers.
 .PP
+
 Mandatory arguments to long options are mandatory for short options 
too.

 The same is true for optional arguments.
-.SS "Operation modes:"
+.PP
+
+Operation modes:
 .TP
 \fB\-h\fR, \fB\-\-help\fR
 display this help and exit




diff -urNw bison-2.4.1/src/main.c 
gow-bison-2.4.1/src/bison/2.4.1/bison-2.4.1-src/src/main.c

--- bison-2.4.1/src/main.c  2008-11-19 08:57:30.0 -0800
+++ gow-bison-2.4.1/src/bison/2.4.1/bison-2.4.1-src/src/main.c  
2008-12-14 04:03:00.0 -0800

@@ -55,7 +55,7 @@
 int
 main (int argc, char *argv[])
 {
-  program_name = argv[0];
+  set_program_name (argv[0]);
   setlocale (LC_ALL, "");
   (void) bindtextdomain (PACKAGE, LOCALEDIR);
   (void) bindtextdomain ("bison-runtime", LOCALEDIR);





diff -urNw bison-2.4.1/src/Makefile.in 
gow-bison-2.4.1/src/bison/2.4.1/bison-2.4.1-src/src/Makefile.in

--- bison-2.4.1/src/Makefile.in 2008-12-11 14:05:55.0 -0800
+++ 

Re: Gow, Cygwin alternative refers to GNU programs as open source UNIX tools

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-10-27 12:43, Jean Louis wrote:
* Kaz Kylheku (gnu-misc-discuss) <936-846-2...@kylheku.com> [2020-10-27 
22:13]:

On 2020-10-27 07:43, Jean Louis wrote:
> On this page accessible with LibreJS turned on:
> https://github.com/bmatzelle/gow/wiki
>
> There is useful tool Gow that runs GNU programs on Windows, quote:
>
> Gow - The lightweight alternative to Cygwin

There is a case to be made here that the project is GPL violating;
it's shipping compiled GNU programs without any clue as to how
the user can re-build that from scratch.

I see only compiled binaries in the Gow repo; I don't see any build
scripts or instructions how rebuild it from scratch: how the
binaries were obtained.

It seems to be shipping MSYS DLL's, so it appears to be a MinGW
derivative.


I did not notice it. There are no sources on Github, just binaries and
there is Gow license which is contradictory to GPL license making it
unclear that it is majority GNU programs and GPL license:
https://github.com/bmatzelle/gow/blob/master/licenses/Gow-License.txt


Moreover, some wording in the documentation (FAQ list and Contributing)
are insinuating that if the user wants some utility included, the way to
do that is to create a ticket and wait for upstream to spin a new binary
release, using the unreleased build system. In other words, the user is
dependent on the author of this package.

I'm suspecting that this is being cobbed together using manual steps.
So that is to say, the author massages a program into building, and\
then adds the .exe file into version control.

Even so, then the documentation should describe the exact build
environment, and document the steps, no?

From the GPLv3:

"The “Corresponding Source” for a work in object code form means
all the source code needed to generate, install, and (for an
executable work) run the object code and to modify the work,
including scripts to control those activities. "

But what if the build procedure is not completely scripted, relying
on manual steps?

I think that to comply with this in situations when there are manual
steps, the redistributor has to document those exact steps. Basically,
the user who gets binaries must be able to closely reproduce those 
binaries.

Re: Gow, Cygwin alternative refers to GNU programs as open source UNIX tools

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-10-27 07:43, Jean Louis wrote:

On this page accessible with LibreJS turned on:
https://github.com/bmatzelle/gow/wiki

There is useful tool Gow that runs GNU programs on Windows, quote:

Gow - The lightweight alternative to Cygwin


There is a case to be made here that the project is GPL violating;
it's shipping compiled GNU programs without any clue as to how
the user can re-build that from scratch.

I see only compiled binaries in the Gow repo; I don't see any build
scripts or instructions how rebuild it from scratch: how the
binaries were obtained.

It seems to be shipping MSYS DLL's, so it appears to be a MinGW
derivative.

Re: Concerns about GNU Bison maintenance.

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-08-06 13:20, a...@gnu.org wrote:

The GNU system, and GNU project is entierly volunteer based, and it is
up to each maintainer to decide what features to work on and include.


Though that seems like a nice abstraction, what if a situation arises
that nobody wants to package newer versions of a project, opting to
stick with the last known good version? That version is soon one
year old, then three, then five, ten.

Would that be acceptable to GNU: that something is maintained in a way
that is rejected by the community, just to serve the whims of the
maintainer?

I can't imagine that the GNU project is really "do whatever the
heck you want" to this strawman degree, and the reason is that
maintainers are somehow selected who do not want to do ridiculous
things with the projects. So then, when they do what they want,
that can be trusted not to cause problems.

I like to refer to this:

http://www.skeeve.com/fork-my-code.html

This was written by some GNU maintainers. It spells out exactly
that they are volunteers who have no obligations to anyone,
which is entirely reasonable, and jives with what you say above.

Yet, they feel bound to protect compatibility, as spelled out
in their section 2.

It contains wording like "we are not free to make gratuitous changes"
and "The user base has come to rely on our programs and how they 
behave".


WOW! Now these authors understand what I'm talking about.

And that is why I can rely on their tool when writing a Makefile
recipe to work around the problems caused by a tool that breaks.

That tool may break, but the workaround recipe won't.


Or how they decide what to keep or remove.  They have no obligations
other than some fundamental corner stones of the GNU project and
themselves.

You mention many different tangets, I'm not really able to follow them
all...


It was a time-consuming write, as was the my original post.


I think calling the software we work on for radioactive is very harsh
which is why I'm not replying to the rest of the email


Anyway, I'm glad you found a convenient exit. The matter probably
doesn't concern you much personally so going into all those tangents
wouldn't do anything for you.

I actually do not have any cycles to burn on this matter. I've pretty
much said my piece; maybe it will make some sort of difference,
maybe not.

Re: Concerns about GNU Bison maintenance.

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-08-06 01:35, a...@gnu.org wrote:

What Jose mentioned, but also -- this all reads as if the GNU Bison
maintainer is doing an excellent job adding new features and moving


Where can I see a "product management roadmap" of Bison features: who
are the stakeholders? Who is asking for what feature?

When new features are just items that pop into the maintainer's
head, that's a personal research project.

I don't think you can take that attitude with respect to a mature
piece of the GNU system.


Bison forward.  There is no obligation in keeping backward
comptability for ever -- indeed, the directive has been marked
obsolete for over 10 years!


OK, so keeping things working is an example of what is not an
obligation. What are examples of what obligations are, and which ones of
them are in conflict with keeping things working and compatible (even
if that itself is not an obligation)? Is there an obligation to
keep pumping out new features, and to whom is that owed?

The %pure-parser directive is just a spelling; it could be internally
translated to the new spelling at the AST, token or even character
level, so then the rest of Bison just internally deals with the new
representation of the syntax. I don't agree that there is a difficulty
in maintaining it, and for a parser generator maintainer to assert
such at hing is particularly ironic; that should be someone who snaps
his or her fingers, and the tokens and the trees sit up and beg.

It's not acceptable to declare it obsolescent; certainly not when
at least another Yacc implementation has a compatible extension with
same directive. There is a concept of language at play here.

Look, "egrep" has been obsolescent for 30 years; we still have it.

Backtick syntax for shell command substitution is obsolescent; we still
have it, and it obligingly executes without generating warnings about
obsolescence. (In spite of there being no "obligation" to support
it).

I can write code in the ISO C90 dialect today, if I'm so inclined,
and it works fine.

Code with K function declarations and definitions can be built
today with a GNU toolchain.

GNU stands for excellent backward compatibility, in my mind,
and situations like the Bison project stand in stark contrast to that.

I think what we are going to need is a "bison wrapper" tool.
Here is how I envision it: the wrapper tool understands a stable,
conservative version of the Bison input language. It interrogates
the build environment to determine what version if Bison is installed,
and then generates a version of the grammar file adjusted for that
dialect. It then runs Bison, and then post-processes Bison's outputs
to make further necessary adjustments to get something buildable.


If you are required to use a 10 year old version of Bison, then the
best thing to do is to commit the generated files into VCS -- this is
really no different than for GNU Autoconf/Automake.


Distros still have old versions of Bison (easily as far as ten years),
possibly because they have discovered that Bison upgrades are
radioactive.

Committing derived objects into version control is an anti-pattern
in configuration management; it must be done only when absolutely
necessary (like solving a chicken-and-egg problem for the users,
when the derived objects are built with the program that the project
provides.)

I'm absolutely not required to use a ten-year-old version of Bison,
except by the circumstances whereby the current one breaks my code.
Ideally, I just want to use whatever the distro provides, and have
everything work.

By and large I don't have anything like this problem with compilers,
libraries, and other utilities.

In any case, my git history is done. I can't go back ten years and
wish that the code had a checked-in version of the Yacc
output which had been produced then. The ten year old commit doesn't
have it, and that's that.

I do have the ten-year-old executables.

Speaking of which, GNU/Linux systems will run those executables!


It also seems that the maintainer is _very_ quick to fix issues, it


I'm also very quick to fix issues, and likely so are you.

The restaurant down the street is quick to give you a new bowl
of soup if you find a fly, and not charge you for anything.

I fix issues quickly if I caused them, because I'm embarrassed.

If you don't cause issues, then you don't have to be tap-dancing
to convince people that you actually do have a good attitude.

Fixing issues in Bison upstream doesn't fix the installations.
Even if the fix is quick at the head of the stream, the user
isn't going to get it until the distro updates the tool,
which could take years.


would be an impossible task to ask maintainers to test every single
version released on every single GNU/Linux system.


What you can do is actually get in contact with some of the
downstream maintainers of the package. Are they picking up the
pre-release version at all?

Because testing is such a big challenge with a lot of unknowns, maybe
the thing 

Concerns about GNU Bison maintenance.

[Kaz Kylheku (gnu-misc-discuss)]

Hello everyone,

Without a doubt, GNU Bison is an a cornerstone piece of the GNU system,
relied upon by many programs.

Developers rely on Bison to be stable. What I mean by this is that a
project which has a mature Bison grammar file that changes very little
or not at all over a long period of time should not have to do anything
to the code because of changes in the Bison upstream.

For example, it should be possible to check out a ten-year-old version
of the code (say during a "git bisect" operation, in uncovering the
commit which caused a bug) and build it without problems with the
whatever Bison is installed.

Some developers write the grammar file such that it works with multiple
implementations. That doesn't necessarily mean adhering to the POSIX
Yacc specification. For instance, Berkeley Yacc has some GNU features
like %pure-parser. This works fine with GNU Flex, just like the same
feature in GNU Bison.

However, over some years now there has been an unsettling trend in the
development of Bison which can be summarized as the current maintainer
treating it as a personal research project.

Features are being introduced that are nice, but that nobody requires
from GNU Bison. Tautologically, no existing code depends on a new
feature. (So where are these requirements coming from? Who is
gate-keeping them? What is the "product management" for Bison?) At the
same time, stability and compatibility are showing the hairline cracks
of fracture.

Most recently, Bison 3.7 was just announced. I first saw the posting in
the comp.compilers newsgroup, then in the Bison mailing list.  Not soon
afterward, the GNU Awk maintainer reported that it doesn't even
build on Ubuntu 18.04, which is almost a poster child for "popular
GNU/Linux distro". A storm of mailing list posts has ensued.

Here is a problem I ran into fairly recently, after upgrading my
environment to a newer GNU/Linux distribution with a newer Bison.

Once upon a time, Bison introduced an extension to the language for
making a re-entrant parser; it was keyed to the directive
"%pure-parser". This went on to be adopted by other Yacc-like
implementations such as Berkeley Yacc.

The Bison maintainer believes that Bison "owns" this language feature
and is free to deprecate it. Note that deprecating doesn't mean removing
the *feature* of re-entrant parsing; just the *spelling* of the
"%pure-parser" directive. As of some 3.x version, Bison now warns now
that it's deprecated, and that one should use a different spelling
for it.

In a mailing list response, I was told that my "problem" is that I'm
trying to write code that works with Byacc and Bison.  (Writing code
targeting multiple implementations is a problem?  Now what are the odds
that someone who thinks that way would end up breaking stuff?)

The maintainer doesn't seem to understand that if I have to switch for
some new spelling for an old feature to avoid the deprecation warning
(and to anticipate the outright removal of the old spelling), the code
then not only then doesn't work on Byacc, but it also doesn't work in
older Bisons. The software no longer builds in operating system
installations that have not updated to the latest Bison.

Moreover, if Bison actually drops support for the spelling, then old
baselines of my code will not build. Thus, for instance, I will not be
easily able to do a "git bisect" to find where a bug was introduced. The
old versions won't build unless I patch every commit I visit, or use a
parallel installation of old Bison for the old baselines.

Bison makes careless changes to the skeletons and other generated
material. For instance, in Bison 3, a declaration of yyparse was
introduced to "y.tab.h".  I had to add a sed command into the makefile
build recipe to filter it out textually.

What is the problem with declaring yyparse in "y.tab.h"? The problem is
that if you're using a re-entrant parser, the signature of yyparse
contains custom types. For instance suppose we have this in the .y
grammar file:

  %pure-parser
  %parse-param{scanner_t *scnr}
  %parse-param{parser_t *parser}

The declaration of yyparse is this:

  int yyparse(scanner_t *scnr, parser_t *parser);

It's not just something innocuous like:

  int yyparse(void);

If the former is suddenly plonked into "y.tab.h" by the parser
generator, it means that whoever is including that header now has to
provide declarations of scanner_t and parser_t before the header.

yyparse is not necessarily treated as a public function; programs can be
written such that all the calls to yyparse occur in the same file.

POSIX doesn't say anything abuot yyparse being declared in "y.tab.h".
It says this:

  The header file shall contain #define statements that associate the
  token numbers with the token names. This allows source files other
  than the code file to access the token codes. If a %union declaration
  is used, the declaration for YYSTYPE and an extern YYSTYPE yylval
  declaration shall also be included in this file.

The 

Re: Bandwidth-hungry services burden the internet

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-05-26 22:33, a...@gnu.org wrote:

I have been through some strange experiences recently.  Certain web
   pages take seconds to load.  In some instances the communication
   fails with a time-out.

This sounds like an issue with your ISP -- and not a general issue.


Could be an issue with the ISP of those websites, or something else,
like a reverse-proxy, if they use one (e.g. CloudFare). If you're
originating from a network which the reverse-proxy thinks is attacking
the client website, it will throttle you.

In that case, you will have a problem with multiple websites that use
the same provider of that.


   Pages that Google had ranked top in search result lists last year
   are for some reason gone when the same search is conducted.

This seems like a different issue though.  Google is not you friend,
and you should not trust them.


It is fairly well-known that Google ranks newer material above older
material.  Historic areas of the web are basically in a black hole as
far as the Google search is concerned.

And since many people reach for the Google search engine without
even thinking there might be alternatives, those areas of the web
basically don't exist.

Except, of course, old stuff that is manipulated by SEO into fooling
Google into thinking that it's new. You know; junk blog article written
in 2006, but somehow appearing in a page updated in May 2020 ...

とても腹立たしくてとんでもないもんだよな～。

Re: one-paragraph comments on s/w freedom being more important than tech niftiness

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-05-08 17:40, Mark Galassi wrote:

Dear GNU folk,

Long ago I had a conversation with a fellow long-time GNU developer.  
We

were talking about how we had come upon free software in the 1980s and
early 1990s.

We were discussing how sometimes we had felt exhilerated by, for
example, the coming of gcc, or gcc-2, which were so technically
excellent.

And then we both commented that we had eventually reached the 
conclusion

that the usefulness of gcc, or the linux kernel, or other great
products, had come mostly because of the freedom that comes with s/w,
rather than the fact that at the moment it is the coolest s/w around.

Years latere we then noticed that, for example, gcc had played leapfrog
with various proprietary compilers, passing in and out of the top
performance slot (that's not true anymore).


Other technical matters are important in compilers, like the safety
of the code, quality of diagnostics, integration with tools, compilation
speed, arch support, ease of retargetting, reliability, 
version-over-version

stability, standard conformance: just to name a few things.

In dev tools, being proprietary is not just an ideological issue.
It is actually a technical disadvantage, like an important missing 
feature.


Anyway, nobody in their right mind pays licenses for proprietary tools
any more except in super niche areas.


But sticking with depending
on tools that offer freedom turns out to be both ethical and deeply
strategic in the long run.


However, using proprietary tools also isn't inherently unethical.

(Also, if you're using tools to produce proprietary software (which
free tools cheerfully allow), the debate of which tools it is ethical
to *use* kind of goes out the window.)

Re: Shannon Dosemagen and the FSF

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-03-02 11:01, Leo Famulari wrote:

I am familiar with the Public Lab (2 words) and I think their work
will be quite interesting to free software hackers.


I don't have a shred of interest in it; I must not be a free
software hacker.


collaborations, not just over email. It makes sense to me to exclude
people who would find their Code of Conduct off-putting.


But the Code of Conduct is supposed to exclude those who violate
it, not those who find it off-putting.

Plenty of perfectly good people find that sort of thing
off-putting, and you will find plenty of those sorts of free
thinkers in the realm of free software hacking.

Check this out:

https://nocodeofconduct.com/

Re: GNU/Guix

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-27 17:25, I wrote:

On 2020-02-27 13:46, a...@gnu.org wrote:

I was wondering if it would be better to call GUIX GNU/GUIX.
I was
   reading the wikipediea page of GUIX and there is a large dispute
   over its naming in the project.


Are you saying that this dispute is described in the wikipedia page?

I'm looking at this, the English one:

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

I can't seem to find anything about the naming dispute in that,
or its Talk page.


Okay, I think I found an external link pointing to mailing list
discussions. And also a key subtlety is missing in this thread:

Quote:

"The development of GNU Guix is intertwined with Guix System
(until Guix 1.0: Guix System Distribution [GuixSD])[7], a complete
installable GNU system using the Linux-libre kernel and
GNU Shepherd init system).[8][9]"

This reveals a subtlety that is not emphasized in ams's
original message above.

Namely, there is Guix, the program, whose full name is
GNU Guix, and then there is the system distribution built with it
which is being called Guix System.

But that also seems to go by the name "GNU Guix System"
if you search around; where is the problem?

[7] gives an external link to a January 2015 mailing list
discussion about naming. The discussion seems mostly
rational and productive.

In the mailing list debate, "GNU Software Distribution" was proposed.
Courtès immediately liked it, showing that he's not attached
to the word "Guix".

Stallman chimed in with the obvious objection (not his only one):
there isn't necessarily just one GNU distribution.

Courtès then makes a bizarre reply to Stallman:

  RMS > * It implies this is the one and only "software distribution"
  RMS > that is connected with GNU.

  LC> That is not true.  When we say “GNU Guile”, we
  LC> specify that Guile is developed by the GNU project;
  LC> the same holds here.

???

The word "software" (incredibly vast category of stuff made of bits)
and "Guile" (one specific Scheme implementation) are not comparable!

When we say "GNU Guile" we do in fact refer to exactly one thing;
there is no other "GNU Guile". It is not "a GNU Guile",
and it is not a GNU version of a Guile language that exists
in other versions like a BSD Guile or POSIX Guile or something.

A term like "GNU Software Distribution" is in interpreted
the same way as "GNU Guile": there is just one.

When Stallman, a native English speaker, brilliant hacker and
cogent thinker starts off a sentence with "It implies this
is ...", and you think that "This is not true" is a suitable
reply, maybe you should think again.

Re: GNU/Guix

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-27 13:46, a...@gnu.org wrote:

I was wondering if it would be better to call GUIX GNU/GUIX.


Why is that? The GUIX home page has "GNU Guix" plastered all over
the place. Is that not good enough with the space instead
the slash? People usually don't pronounce the slash in
GNU/Linux anyway; they just say it like GNU Linux rather
than GNU on Linux or GNU over Linux.

If it is sometimes called GUIX, that's just the same as GNU Bash
sometimes being called Bash, GNU Bison sometimes being called Bison.

GNU/GUIX is not like GNU/Linux, where there are GNU programs on
top of a non-GNU kernel; GUIX isn't a kernel in the first place,
but a packaging system.

Suppose GNU Tar were used to package a system, and the result
were called the GNU Tarball distro. Would it make sense to tell
people, "You can't call it Tarball when writing about it;
please use GNU/Tarball." :)


I was
   reading the wikipediea page of GUIX and there is a large dispute
   over its naming in the project.


Are you saying that this dispute is described in the wikipedia page?

I'm looking at this, the English one:

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

I can't seem to find anything about the naming dispute in that,
or its Talk page.

  Wouldn't this all be solved if

   they called GUIX GNU/GUIX or even better, GNU.Hurd and to kill off
   the Guix name.


GUIX doesn't exlusively use the Hurd kernel. The page says that it
was ported to Hurd in 2015, and that it uses either Linux-libre or
Hurd.

A build of GUIX with Linux is an example of GNU/Linux. The GNU part
of that includes GNU GUIX, like it includes GNU Bash and whatever else.

There is a GNU/Hurd usage out there for the category of systems
that are GNU userspace on GNU Hurd, like 
https://www.debian.org/ports/hurd/

A Hurd port of GUIX seems to fit that category; it is *a* GNU/Hurd.

To me, GNU/Hurd being a distro category and GNU Hurd being just
the kernel is pointlessly confusing. The whole slash thing is
only required when there is a non-GNU kernel underneath the GNU system,
and when that kernel's name is a popular metonymy for that entire 
system,

failing to give credit to the GNU project.

Re: Why the "social contract" should not be endorsed

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-24 19:36, Alexandre François Garreau wrote:

Le samedi 22 février 2020, 20:48:43 CET Andreas Enge a écrit :

If anything, this message shows how much a code of conduct is needed.


I’ve just read https://wiki.gnu.tools/wiki:code-of-conduct


Note that there has been no initiative to promote that code of conduct
for the GNU project. All the noise has been about the social
contract.

There is no "GNU" on it, and it states that it pertains only to that
site.

Members of that site are deliberately not drawing attention to it.

If they have their way, they will try to sneak that into the 
organization

"under the radar" somehow.

It's like a magic trick. You're supposed to keep your eyes on the hand
which is waving the (relatively harmless) social contract, while
the other hand is doing something sinister (being the left hand).

PS: there’s the added issue that while this CoC talks about 
“community”,
it also does about “professional settings” (which to me is antagonist 
to

“community”, and the very reason why the “community” word is so used
nowadays (to include unpaid/unemployed people)), while this wiki is not
professional, and GNU is not a professional organization, nor even
withstand “professionalism” (I recall that being stated along with
recalling GNU’s name itself is a joke anyway).


You have to read between the lines.

The world of global business has come to rely on an infrastructure made 
of

free software for business-critical roles.

This is particularly so of large, multi-national tech giants.

What these corporations want is nothing more than for projects
like GNU to just be servants, doing their bidding. Whatever you
depend on, you want to *control*, and that is particularly true
in business.

To do that they have to dismantle the projects from within.

With everyone's hands and souls tied up in social contracts and
codes of conduct, there will be no room left to reject bad software
changes from the Googles, Amazons and Microsofts of this world.

Make no mistake, this is a corporate dismantling and take down:
an attack on free software.

Some of the language in these documents is straight out of the HR
manual of a Fortune 500 firm. That's what those organizations use
use to keep employees and contractors in line.

The part about projects having to welcome low-experience participants
also plays into this. Corporations will use that to promote
people into free software projects who will then unwittingly
do their bidding. They will not only be too afraid of being rude
(due to all the codes of conduct) to reject bad changes, but also
lack the technical confidence for taking a stand: a double whammy,
one-two knockout.

These days, some people who work on free software are doing so
as part of their jobs. They were hired to do that and end up
producing some work that their employer then wants upstreamed.
Problem is, the work is shoddy because those people didn't quite
have the experience to do it right. Or, worse, it outright contains
objectionable changes that cannot be accepted no matter what.

Thus, the curmudgeons who control the upstream project want
want nothing to do with the changes.

Solution? Infiltrate those projects; get your people into
decision-making positions to displace the curmudgeons.

But first, you have to disarm those projects with codes of
conduct and social contracts which are worded such that your
people have to be "welcome".

Why, the free project can be regarded as just another department
in your company. Copy and paste something out of the HR manual
and make them follow that, and it's pretty much like you're their
boss! And they work for free, to boot.

Re: ru...@mrbrklyn.com: Please remove me from your hang...@nylxs.com or vill...@mrbrklyn.com mailing lists

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-24 17:34, J.B. Nicholson wrote:

Alexandre François Garreau wrote:

It was, and it is not “tolerated”, this is bad faith: it is simply
impossible to do anything about that.


gnu-misc-discuss@gnu.org list owners could remove ru...@mrbrklyn.com
from the list and make it clear that he won't be allowed back until he
has stopped sending unsolicited email to those who don't want it.


It's not that technically simple.

Firstly, certain e-mail addresses have already been harvested.
The proverbial "horse has left the barn". The culprit can manually
re-subscribe those addresses to his mailing list, without any
connection to this mailing list.

With those addresses, he has similar powers to those who peddle
phishing scams or fake Rolex watches.

The existing tools and infrastructure for dealing with that
problem is also appropriate here. What that means is that the
individual targets of the unsolicited messages have to apply
local countermeasures.

The list cannot possibly help with traffic that doesn't
pass through it.

Secondly, removals from mailing lists and other forms of blocking
can be circumvented. There are ways to obtain new network
identifiers such as e-mail addresses, domains and IP addresses.

I've taken care of the problem locally; I don't see those NYLXS
postings any more.  I've done that without intending to filter
out Ruben himself, I think. I can certainly see his
gnu-misc-discuss postings. No sure about direct mail: that depends
on to what extent it is co-located with the mailing list. If
that's sent from the same host, then, oops! That's what you get
for co-locating your mail identity with your spammy mailing list.


There is something that can be done. Apparently
gnu-misc-discuss@gnu.org owners have chosen to do nothing about it and
therefore it is fair to say that ru...@mrbrklyn.com's behavior is
tolerated.


With the way the discussion has heated up, the moderators are
already busy just going through the messages.

As a mere participant who doesn't read everything, this already
sucked up so much of my precious little free time this past
weekend that I didn't write a single line of code.

If the moderators start spending their free time tuning
and debugging main infrastructure components in an escalating
battle of countermeasures against unsolicited mail
(all without being able to put a dent in any of it which doesn't
go through the list), the moderation will either fall behind,
so that complainers will start kvetching about their
posts appearing late, or else decline in quality, so that some
blatant kind communication guideline violations will get through.

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-25 06:22, Andreas Enge wrote:

On Tue, Feb 25, 2020 at 08:56:24AM -0500, Alfred M. Szmidt wrote:

The text circulated is not a text by or for the GNU project, so this
is indeed not the best place for discussion of it


Quite on the contrary, it is a text by members of the GNU Project for 
the

GNU Project.


That's different from a text *of* the GNU Project, which is what it is 
being presented as.


It's the same way that a memo put together by some disgruntled
Google employees isn't a Google document. They can't just print
that on Google letterhead, call it a new Google policy and get
employees to sign off on it.

Re: Endorsing the GNU social contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-23 01:34, Han-Wen Nienhuys wrote:

Per the request offered by email, I am offering my support for the GNU
social contract.

I, maintainer of package LilyPond, endorse version 1.0 of the GNU
Social Contract, available at 
https://wiki.gnu.tools/gnu:social-contract.


Did you read it carefully?

Also, do you endorse this one:  
https://wiki.gnu.tools/wiki:code-of-conduct

Re: Why the "social contract" should not be endorsed

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 18:58, Amin Bandali wrote:

"Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> writes:

[...]


You are sick.


I urge you to consider the GNU Kind Communications Guidelines [0] when
posting to GNU lists, as well as keeping this list's guidelines [1] in
mind when posting here.


I sincerely believe that the code of conduct document published
on the gnu.tools is the product of a sick mind.

Make no mistake: this is not name-calling; I stand by it.

Re: lese majeste

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-23 00:32, Jan Nieuwenhuizen wrote:

John Darrington writes:

Hello John,

On Sat, Feb 22, 2020 at 07:14:44PM +0100, Alexandre Fran?ois Garreau 
wrote:

Le samedi 22 f??vrier 2020, 18:41:48 CET Ludovic Court??s a ??crit :

> PS: It???s telling that yet another insulting message passed moderation!

Wait it was criticizing but where were the insults?



Now we see


Could you please use thet word "I" when speaking for yourself, as you 
do

here?  Using this sort of language is unnecessarily intimidating, and
certainly not kind.


Why should anyone be kind and meek in the face of fascists?

That's not what our forefathers did.


When making the cross-over from facts to interpretation of those facts,
what you or I see is the inside of our heads.  That can colour facts to
be good, or it can colour facts to be bad, depending on what we believe
and the mindset or attitude we have at the time.


That e-mail was approved for list redistribution by the moderator in
spite of using "we". You might be able to convince the moderator that
it had been a lapse in judgment,

Coloring the facts with interpretation is Jon Darrington's privilege,
in an e-mail that bears a "From: Jon Darrington" header.

Coloring facts is representative of what happens in western 
civilization's

courtrooms, parliament houses, political campaigns, newsrooms, as well
as textbooks and classrooms.

Coloring the facts with interpretation is necessary for persuasion.

If Bob wants to persuade Alice that some situation is detrimental, he
must present that color, not the raw facts that Alice already knows.

Re: Why the "social contract" should not be endorsed

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 19:38, Mike Gerwitz wrote:

On Sat, Feb 22, 2020 at 20:48:43 +0100, Andreas Enge wrote:
On Sat, Feb 22, 2020 at 10:26:22AM -0800, Kaz Kylheku 
(gnu-misc-discuss) wrote:

On 2020-02-22 01:22, Andreas Enge wrote:
> And another ad-hominem attack. Can you substantiate the claim of us
> being
> powermongers?

https://wiki.gnu.tools/wiki:code-of-conduct
"Enforcement", "Ban", "Correction", "Warning" 
You are sick.


Could I kindly ask for this person to be put on moderation? I find it
difficult to interpret the last statement as anything but a gratuitous 
insult
(following a message that was not even directed at them). Notice that 
there

is a pattern of overly aggressive messages by Kaz Kylheku.


I think we can handle this without having to resort to blocking a
person's messages.

Kaz, please avoid use of subjective terms like "powermonger" and focus


Everything you see here has passed moderation.

If you don't think I should be able to include quotes of someone
else's text that contains "powermonger", take it up with the moderator.


  https://www.gnu.org/philosophy/kind-communication.html


I think that is useful for communication within projects themselves.
I don't think that should be blindly followed in a self-defeating way
by remaining meek when the project is under attack.

Re: The General Public Licence (GPL) as the basic governance tool

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-21 13:40, Mark Wielaard wrote:

These are good questions and my apologies we didn't make this more
clear. The GNU Social Contract is important because it defines what the
GNU project stands for.


How can you say that, when the GNU project has issued official
statements disavowing it?

It stands for precisely poppycock and fiddlesticks.

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 12:43, Samuel Thibault wrote:
Kaz Kylheku (gnu-misc-discuss), le sam. 22 févr. 2020 10:22:55 -0800, a 
ecrit:

But does it? If inexperienced people are a protected class, then it
doesn't matter how the blocking is done. The blocking violates the 
social

contract and that's that.


Could you avoid interpreting everything either pure black or pure 
white?


The point is that if you codify things in documents, you *have* to
'debug' those documents through a black and white interpretation,
because that interpretation will happen.

What you're asking for is like, "can you just test what my program is
supposed to do with just the intended inputs?"

You have to think about the unintended consequences.


The text is
saying "It welcomes all contributors". That doesn't mean committing
everything that gets submitted.


Someone who cannot get *anything* submitted will get upset and cry
foul about not-welcoming behavior, and so it goes.

In what industrialized nation can you not reject job applicants for 
low
experience, due to that being discrimination against a 
constitutionally

protected class?


The protection is against harassment, not about getting changes
commited.


I don't see wording to that effect, though; that's just what you think.

Re: Why the "social contract" should not be endorsed

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 12:31, Federico Leva (Nemo) wrote:

Andreas Enge, 22/02/20 21:48:

If anything, this message shows how much a code of conduct is needed.


Or maybe it shows there's a language barrier. Let's not rush to judge
non-native English speakers, especially after having admitted that the
meaning of their message is unclear.


I'm a native-level English speaker.


I think their contribution can be rephrased as: what kind of message
do you think a document focused on matters like "Enforcement", "Ban",
"Correction", "Warning" gives? Is it the intended message? If not,
what could be done?


No, my contribution cannot be rephrased like that. A better
approximation of the semantics of my message that the document
is the product of a mental sickness that underlies authoritarian
personalities.

What could be done? Printing it out and burning it, by my estimation.

Re: Why the "social contract" should not be endorsed

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 11:48, Andreas Enge wrote:
On Sat, Feb 22, 2020 at 10:26:22AM -0800, Kaz Kylheku 
(gnu-misc-discuss) wrote:

On 2020-02-22 01:22, Andreas Enge wrote:
> And another ad-hominem attack. Can you substantiate the claim of us
> being
> powermongers?

https://wiki.gnu.tools/wiki:code-of-conduct
"Enforcement", "Ban", "Correction", "Warning" 
You are sick.


Could I kindly ask for this person to be put on moderation?


Actually, no you can't; however, you do have the option of asking for
this person to be put on moderation.


I find it
difficult to interpret the last statement as anything but a gratuitous 
insult

(following a message that was not even directed at them).


People should mind their business and not fret about what is not
directed at them.


If anything, this message shows how much a code of conduct is needed.


Why, nothing better shows that a code of conduct is needed than
opposition to the code of conduct!

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 01:50, Samuel Thibault wrote:

Really, not including the next generations in a project is running the
risk of the project just dying with its leaders.


Project "liveness" is not the ultimate value. If nobody is found who
will maintain it the way it ought to be, then let it die.

If I leave behind some program that so few are interested in that
the best talent willing to maintain it is not very good, then
so be it.

It doesn't have to be forced on me while I'm still able to shake a fist.

I suspect that these initiatives to have inclusion of regardless
experience are driven by project zeal, and envy of popular projects.

The idea is to bring in people to generate activity. Any people.
Just warm bodies to stimulate project liveness.

Re: Why the "social contract" should not be endorsed

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 01:22, Andreas Enge wrote:
And another ad-hominem attack. Can you substantiate the claim of us 
being

powermongers?


You have a Code of Conduct, the bulk of which is about how people will 
be kicked

out.

https://wiki.gnu.tools/wiki:code-of-conduct

"Enforcement", "Ban", "Correction", "Warning" 

You are sick.

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-22 01:50, Samuel Thibault wrote:
Kaz Kylheku (gnu-misc-discuss), le jeu. 20 févr. 2020 13:55:37 -0800, a 
ecrit:

On 2020-02-20 11:42, Andreas R. wrote:
> On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote:
> > > On the flip side, an argument is made that your initiative might make GNU
> > > more exclusionary because of the extra conditions on what it takes to be a
> > > part of it.
> >
> > At some point you have to exclude some people in order to include
> > other
> > people, yes.  We can see that in various communities:

One group whose inclusion is being specifically promoted by the
proposed social contract is people with a low level of experience.


Not "promoted" but "protected".


The exact rhetoric is that people must be included regardless of
their level of experience, which can only possibly mean
regardless of how low is their level of experience.


Yes. Which doesn't mean they should immediately be given commit power
etc. But at the very least be helped to improve and acquire experience.


I strongly disagreee; people should come to freeware projects
as "self starters" with some meaningful combination of decent
industry experience and talent.

Simply put nobody has the time to tutor you.

You have all the code; you can study it. There are books,
tutorials, and other resources.

Changes from outsiders should be merged based on the merit
of those changes. (And that has been my experience; I've never
been challenged to provide a resume detailing my level of
experience!)

I think that someone who keeps sending bad changes may come to
be routinely ignored as an optimization; there has to be room
for associating bad changes with a person or online account,
for expediency.

Lastly, who have commit powers have nobody above them; they must
themselves be experienced. The GNU project should not take on
dabbling amateurs as maintainers and should never have any
sort of document which suggests otherwise.

GNU programs and components are production code relied upon by
the world in "mission-critical" deployments.

I'm all for mentoring. Maybe there should be a dedicated GNU
or FSF initiative for that, "GNU Bootcamp" or something.
Where would the resources come from.


So, if people have to be excluded to bring about inclusion,
let us ask: whom do you have to exclude in order to include
people with a low level of experience?

I suspect that the answer is: some experienced people,
who would block their bad work.


That wholy depends how "block" is done.


But does it? If inexperienced people are a protected class, then it
doesn't matter how the blocking is done. The blocking violates the 
social

contract and that's that.

Analogy: you can't refuse patrons from your restaurant, on the basis
of their race, no matter how politely you behave.

Basically, equating inexperience with attributes like race is completely
unacceptable, insane nonsense that's not practiced anywhere.

In what industrialized nation can you not reject job applicants for low
experience, due to that being discrimination against a constitutionally
protected class?


If the blocking is just "this is
bullshit" mail without explanation, and stick with such behavior, that


That's just a straight violation of the kind communication guidelines.


Older people are politically insensitive, and too smart to accept crap
software changes.


I'm not saying to accept crap software changes.


*You* may not be, but that "social contract" appears to be.
It supports that interpretation.


I'm saying to explain why they are crap without calling them names.


There can be situations when you just have tobe done explaining
and that's that. As a volunteer, you don't owe anyone anything,
including detailed explanations which amount to tutoring someone about
why their change proposal cannot be merged.

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-20 10:06, a...@gnu.org wrote:

I'm not saying that GNU will necessarily stop growing and decline. What
   I'm afraid is that it might just become insignificant compared to
   others, and thus its voice for the 4 freedoms become less and less
   heard.

I think everyone would agree that we do not want the four freedoms to
become irrelevant, or that the GNU project be forgotten.  And I think
everyone can also agree that there are groups that are working against
it (see e.g. the whole idea of "ethical" licenses).


There are more issues than four freedoms.

For instance, the software developed under the GNU license, conforming
to all the required freedoms, can easily be the platform for a weapons
system used to strike non-military targets in contravention of the
UN Charter.

The suffering caused by users not having the right to build from
source, modify and share the programs they use is rather one
of these:

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

Don't you think?

Debates that are hinged to First World Problems get so heated
precisely because the stakes are so small.

It's just a bourgeoise thing. Look, I have a good
tech job in a safe country, my belly is full. What to do? I know,
I will get pissed off at proprietary software!

Fast forward a few decades, and Microsoft is making in boatloads
of money running a cloud business on GNU/Linux.

Don't get me wrong; there are important issues this Digital Age.

Unfortunately, most of them are not fixable simply via copyright.

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-20 11:42, Andreas R. wrote:

On Thu, Feb 20, 2020 at 02:45:02PM +0100, Samuel Thibault wrote:


> On the flip side, an argument is made that your initiative might make GNU
> more exclusionary because of the extra conditions on what it takes to be a
> part of it.

At some point you have to exclude some people in order to include 
other

people, yes.  We can see that in various communities:


One group whose inclusion is being specifically promoted by the
proposed social contract is people with a low level of experience.
The exact rhetoric is that people must be included regardless of
their level of experience, which can only possibly mean
regardless of how low is their level of experience.

So, if people have to be excluded to bring about inclusion,
let us ask: whom do you have to exclude in order to include
people with a low level of experience?

I suspect that the answer is: some experienced people,
who would block their bad work.

I smell age discrimination in disguise: experienced
people tend to be old farts.

Why not just make a simpler social contract: people are to be
retired out of GNU on their 50th birthday.

Older people are politically insensitive, and too smart to
accept crap software changes. These factors work together to
create an environment which prevents snowflakes from
contributing to the GNU project.

Am I getting warmer?

Some examples of those communities and their problems might be helpful 
here

to see if these communities can provide a useful parallel with GNU.


Screw examples! Let's see the actuals.

Under the proposed governance:

- who is going to be included who currently isn't included?

- who is going to be kicked out?

Because ... that's obviously what this must be about, right?

Or, if there are no such specifics, then this initiative is then
simply about being able to wield that power. To wave it people's
faces, and from time to time, use it.

Re: The General Public Licence (GPL) as the basic governance tool

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-20 02:07, Dmitry Gutov wrote:

On 20.02.2020 11:47, Ludovic Courtès wrote:
I think it’s important for GNU hackers as a group to be able to 
reflect

on the project’s procedures and discuss whether/how to improve them.


So what GNU hackers who disagree with you lot on this or other
subjects are supposed to do?

I don't see the opposing viewpoints reflected in your documentation
anywhere. You have formed a subgroup, discussed your views in private,
and are now soliciting positive feedback within the project, while
largely ignoring negative one. And you're misrepresenting yourselves
as a project-wide official initiative. "We are GNU, and here are our
values".


There is something important that these "gnu.tools" reprobates
are deliberately hiding.

They want to change the GNU governance in such ways that people can
be excluded from the GNU project.

What they are hiding is the list of people they would kick out
if they were to have their way.

They know that if you publish such specifics, it's harder to obtain
endorsement, because even gullible people who are duped by political
rhetoric can comprehend the meaning of a concrete list of names.

Re: Endorsement of the Social Contract 1.0

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-20 05:43, Ludovic Courtès wrote:

Hello,

I, co-maintainer of GNU Guix, GNU Guile, the GNU Shepherd, and
GNU Guile-RPC, and a contributor to other GNU packages, endorse
version 1.0 of the GNU Social Contract, available at:

  https://wiki.gnu.tools/gnu:social-contract

This endorsement means that I believe in the values stated in the
document and that I’m willing to uphold them as part of my GNU
maintainer role.


That's nice. I know of a GNU maintainer who believes in Buddhism,
and upholds those values as part of his maintainer role (and
any other role).

Good thing it's not required of everyone, isn't it!


I’m looking forward to more fellow maintainers judging the document on
what it actually says and taking this opportunity to express a firm
commitment to GNU and free software.


... plus two other other clauses not having a darn thing to do with
freedom, and one that is just PC inclusivity rhetoric with a twist:
no minimum level of experience required!

Re: State of the GNUnion 2020

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-17 12:37, Andy Wingo wrote:

Thought experiment: what would GNU be if all of its packages stopped
developing?  Dead, right?


The immediate effect would become more of a stable base for the vast
amount of material that depends on it.

Nothing that depends on GNU Anything would experience a breakage
due to a newer version of GNU This or GNU-That.

The world would converge on a single version of GNU Autotools, and so
then people could just have that one version installed in order
to update ./configure script images with minimal diffs, instead
of having half a dozen versions installed and using the closest
matching one.

Re: The General Public Licence (GPL) as the basic governance tool

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-18 04:55, Ludovic Courtès wrote:

As a GNU user, you may not know it but GNU maintainers do not currently
agree to uphold the free software values that we care about; they 
merely


This is misleading. The situation is that GNU maintainers can *think*
whatever they want, but in the end, the software remains copylefted.

A GNU maintainer is free to think that programmers should make boatloads
of money from binary-only, proprietary software or SaaS or what have 
you,

and drive Porsches.

That is neither here nor there, because at the end of the day, the
GNU package remains copylefted.

Not telling people what they should think is a good thing.

...

Or, so you would think. But look where that laxness has brought us.

Now a bunch of ragamuffins have gone as far as to create a fake
GNU website and are trying to stage some political takeover.

Maybe GNU maintainers should be subject to a background check,
and to pledge an oath of loyalty to prevent future recurrences of
this sort of embarrassing dog and pony show.


The Social Contract is a way for interested GNU maintainers to state
their will to uphold these core values.


This is a lie. Only the first clause of this document deals with free
software values.

The last clause is a piece of PC rhetoric that is not related in any
way, shape or form to free software.

Re: Endorsing the GNU Social Contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-16 11:28, Jan Nieuwenhuizen wrote:

The goal of the GNU Social Contract is to state the core values GNU
maintainers who have endorsed it are committed to uphold.  It is both
an agreement among us, GNU contributors, and a pledge to the broader
free software community.


Thank you all for working on this.


That's not working; working is writing code, debugging, documenting,
reviewing.

This monkey business of social contracts is just political sport.

People working on copylefted software need not share any "core values"
other than that copylefted software.

Someone working on the compiler front end can be a communist, whereas
the type checker could be hacked on by (necessarily) a fascist.

There is no need to have the same political views, listen to the same 
music

or anything else.

Re: Richard Stallman should be reinstated to President of the FSF

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-16 11:42, Ruben Safir wrote:

Richard Stallman was bullied from his position at MIT and FSF and the
FSF should take the couragous move of reinstating Richard as President
of the FSF


The FSF minus Stallman is a rotten organization; simply adding Stallman
back is not enough. It could use a good old-fashioned house-cleaning.

Everyone behind that heinous, cowardly move should in fact be ousted.

It actually boggles the mind how such leftist nonsense is tolerated in
country that elected Trump, on a platform consisting of material such
as "grab `em by the pussy", against the reproaches of which throngs of 
people

chanted "we don't care", and who might just give him a second term.

The average American will absolutely not condemn Stallman for some 
remarks

made in defense of Minsky (perfectly understandable and well within his
right), or some comments he wrote on mailing lists on this topic or that
that were actually well-reasoned and rationally defensible.

That's definitely a double standard. You can be as odious as you want, 
if

you have money and power that buy you the attention and support of the
populace, otherwise you can't even breathe the wrong word.

Re: [Hangout - NYLXS] duplicated messages and NYLXS cross-posting

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-16 05:20, Alexandre François Garreau wrote:

Le dimanche 16 février 2020, 10:43:44 CET Alfred M. Szmidt a écrit :

   Is FSF censoring gnu-misc-discuss and other GNU lists and are these
   other things an attempt to circumvent that?

The FSF is not handling moderation of GNU project mailing lists, nor
is there any censorship going on here anymore.  The list _is_
moderated but that is to get rid of very nasty and obvious garbage --


How isn’t moderation censorship?  That it’s useful or even good is not 
a

sufficient reason not to call it censorship.


How moderation isn't censorship is that it isn't a state-imposed ban
that curtails your freedom to express ideas within your entire country.

Re: [Hangout - NYLXS] duplicated messages and NYLXS cross-posting

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-16 05:29, Alexandre François Garreau wrote:

Le dimanche 16 février 2020, 12:20:07 CET Daniel Pocock a écrit :

Users who control their own mail servers probably have tactical
solutions they can use, e.g. /etc/postfix/access


Overkill, it’s not made for that, you’d better use client-side stuff, 
or

antispam tools.


A system should filter unwanted events as early in the pipeline as it 
can.


That is more efficient.

I don't want my mail server receiving and delivering stuff that is going
to be certainly deleted later; it wastes bandwidth and cycles.

It's also very simple to implement "drop connections from this
mail host" not to mention simpler to convince yourself that the rule
is correct.

Plus: what if I don't want to get *anything* from that server, list or 
not?

Re: GNU Social Contract 1.0: "level of experience" rhetoric

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-14 15:58, Phil Maker wrote:

Ludovic, ...,

Re the Social Contract I'm sure greater minds than mine have looked at
it but I feel obliged to make some sort of response of which the next 
paragraph is the only

important one.


Here is a problem:

  "[The GNU Project] welcomes all contributors, regardless of their 
gender,
   ethnicity, sexual orientation, level of experience, or any other 
personal

   ^^^
  characteristics."

Firstly, as a consumer of GNU programs, I expect that software to be
developed and maintained by experts who have a high level of experience.

I've never been employed in any software organization in which anyone
could just walk in from the street and start coding. Commercial software
shops don't just take anyone; why would a free software project be
any different?

The GNU project is not an appropriate vehicle for inexperienced people
who are trying to stuff their resumes.  Also, it is not some sort of 
coding

asylum for industry rejects.

Secondly, where is the problem? Are there documented instances where
someone submitted a quality patch to a GNU project, but was instead
interrogated about their level of experience and consequently rejected?

However, whereas that is fine for patches coming in from outsiders,
the gatekeepers who control what goes in better have some combination
of talent and experience.

People with no talent or experience are not a protected class; it's
not discrimination to keep them out of projects.

This kind of "regardless of level of experience" nonsense has no place
anywhere in an organization like GNU.

Re: avoiding the bias in vocabulary

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-15 09:56, Daniel Pocock wrote:

There are a lot of words used in various discussions today that have
some bias.

For example, the word /ban/ is quite disparaging to the victim.  Simply
using the word continues the bias.


Note that this word is quite central in the "Code of Conduct" proposed 
on the

disruptive, deceptive "gnu.tools" site.

There's gonna be witch hunts if these brown shirt scoundrels have their 
way.

Re: GNU Social Contract 1.0 - doubts

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-15 10:10, Andreas Enge wrote:
thanks for thinking about the options and sharing your opinion! 
Speaking

strictly logically, a third option is not possible


"If you're not with us, you're against us, comrade."

You may wanna brush up on logic, there, buddy.

It's quite a broad field, you know; there is a lot more
to it than first order predicates that have only
true and false values.

Re: Endorsing version 1.0 of the GNU Social Contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-14 17:33, Mark Wielaard wrote:

The goal of the GNU Social Contract is to state the core values
GNU maintainers who have endorsed it are committed to uphold. It
is both an agreement among us, GNU contributors, and a pledge to
the broader free software community.


You and your cohorts are not adequately explaining this:

What is the difference between this document and the content of the
GNU licenses (and numerous other materials that speak to user freedoms),
GNU Coding Standards and the GNU Kind Communication Guidelines?

If someone endorses the document, what from the above are they
rejecting, if anything?


Additionally, we think it can be a first step towards formalizing
a transparent and collective governance of the GNU Project.


How so? What sentences in the the document speak to governance?

If your goal is to replace the governance, then why doen't your
website say that, and have documents that address themselves to
specific proposals regarding governance?

Document your proposed org chart, detailing who is to be responsible
foir what, and the flow of decision making and so on.

Instead of some half-assed indirection through some social contract
nonsense.

If you want transparency, start by being transparent.


This initiative is not supported by Richard Stallman.


Why would anyone support an unnecessary initiative?

Re: [Hangout - NYLXS] security alert... worth noting

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-13 20:52, Marcel wrote:

Hello Ruben,

Yesterday I received a couple of hundred repeat emails similar to the
one I am responding to (sometimes twice each, when I had already
received another original from the gnu-misc-discuss list). All of them
bear the [Hangout - NYLXS] label.


When this involuntary subscription started happening, I noted
the password I had been given and unsubscribed. The maling list
manager for NYLXS Hangout informed me that this operation was
successful.

Next morning, the messages started coming again. I repeated the
unsubscribe request, but I was informed that the password is
incorrect. In other words, I had been given a new involuntary
subscription with a different password.

At that point it became obvious that the next course of action was
to reject connections from that server at the SMTP level.

Not everyone has that control over their mail, unfortunately.

Re: GSC 1.0 endorsement

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-12 15:19, I wrote:

The GNU project should also critically evaluate externally
imposed requirements and reject bad ones, including ones
coming from standards bodies like ISO and IEE.


Turns out, this is basically covered in the GNU Coding Standards.

https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html#Non_002dGNU-Standards

"The GNU Project regards standards published by other
organizations as suggestions, not orders. We consider those
standards, but we do not “obey” them. In developing a GNU program,
you should implement an outside standard’s specifications when that
makes the GNU system better overall in an objective sense. When it
doesn’t, you shouldn’t."

Re: Endorsing version 1.0 of the GNU Social Contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-13 13:26, Daniel Pocock wrote:

I, Frederic Y. Bois, maintainer of package GNU MCSim, endorse version
1.0 of the GNU Social Contract, available at
.


By the way, I'm offended by the sexual innuendo in this domain
name.

It's not okay to use that language, even if invoked
in deprecating self-reference.

Cheers ...

Re: Endorsing version 1.0 of the GNU Social Contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-14 02:04, John Darrington wrote:

On Thu, Feb 13, 2020 at 09:26:03PM +, Daniel Pocock wrote:

Could it be better to work from the ground up, to document the points
which almost everybody agrees on before talking about the points that
are controversial?


We have already done that.

It was discussed at length between all interested maintainers, and the 
result

has been formally codified here:

 https://www.gnu.org/philosophy/kind-communication.html


Okay, so:

1. The first clause of the proposed "contract", dealing with freedoms,
   is entirely redundant in the face of the bulk of the software
   using some version of the GNU Public License.

2. The remaining technically oriented clauses are flawed.
   - not every GNU project needs to collaborate with non-GNU projects
   - consistency is a nice requirement but can actually conflict with
 conformance to external standards and such.
   Also, this area is basically already covered in a long and detailed
   GNU document:

   https://www.gnu.org/prep/standards/

   (Hey, it even has something for me: I just noticed the words about
   the GNU projects not having to following external standards if they
   are bad.)

3. The last clause can be effectively replaced by a link to
   the above kind communication guidelines, which are better developed
   and make more specific recommendation about behaviors without
   promoting the unconditional inclusion of people based on their
   tribalistic traits regardless of how those people actually behave.

Thus, the entire document is redundant and pointless.

I'm leaning toward agreeing with Mr. Safir: this site and the document
are a sham set up as a pretext for some sort of bizarre takeover attempt
which will not work.

Re: GSC 1.0 endorsement

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-10 13:13, Ludovic Courtès wrote:

Hi Werner,

Werner Koch  skribis:


I, maintainer of the packages GnuPG and Libgcrypt,
endorse version 1.0 of the GNU Social Contract,
available at .


There no such thing "GNU Social Contract" as of today.

What there is is a Social Contract proposal that a faction
of people (who happen to do GNU programming) would *like*,
in some revision, the GNU Project to adopt. Should that happen,
there will then be a GNU Social Contract (if that's what the
document ends up being called).

Putting up a document titled GNU Social Contract on
a website with gnu in its domain name, bearing the GNU logo,
is very misleading.

I would say, dirty and underhanded.

What's the point of respecting people's differences, like
sexual orientation, race or whatever, if your actions are
dirty and underhanded.

Most of this Social Contract is bad other than the part
about software that respect's users' freedoms.

Regarding:

  "GNU package developers work together to ensure
   consistency across packages."

Incorporating these requirements is not always feasible.
Sometimes GNU programs conform to external standards,
which are inconsistent, both internally and with regard
to other standards. Two different GNU programs implementing
different, competing standards can't be expected to be
consistent. Basically, this is a technical requirement that
has to be taken on a case by case basis.

  "The GNU Project collaborates with the broader free
   software community"

Maybe some projects do, maybe some don't? What does it mean?

People working on a project are generally focused on
that project. If they are collaborating with some other
people from some other project, then they are doing something
other than working on their own project.

If people want to collaborate in the development of some
GNU package, they join the development of that package.

If people have a problem with the way a GNU package is
being maintained, they can raise bugs or whatever.

Now, let me talk about something else. GNU provides some
fundamental pieces. It's good if those don't gratuitously
break. Now *that* is something to include in the social
contract. How about this:

  Proposed text: "The GNU Project provides some important
  programs which are critical, fundamental dependencies
  (build-time and run-time) of very large quantity of software,
  which includes other GNU software, non-GNU free software,
  and even non-free software.

  The GNU Project maintainers strive to the utmost to make
  changes to these programs in such a way that new versions
  of programs can be deployed in place of existing versions
  without breaking the user, so that the GNU Project gains
  and retains respect as a bastion of stability.

The GNU project should also critically evaluate externally
imposed requirements and reject bad ones, including ones
coming from standards bodies like ISO and IEE.

  Proposed text: "The GNU Project reviews external requirements,
  and forms its own opinion about their technical and
  non-technical merit. The GNU Project rejects requirements
  which it deems to be technically deficient or otherwise
  deleterious, even if they come from major standards bodies.
  Rejecting a requirement ranges from not adopting and implementing
  it at all, to making the implementation of that requirement
  hidden by default such that it must be explicitly enabled by
  the user.

Sometimes changes in standards are terrible. They happen because
a particular vendor is involved and gets their way due to having
clout or whatever. For instance, as a recent example, in my opinion
no C library function should implement the useless function fopen_s
that Microsoft successfully foisted unto ISO C11.

Note that the spirit of the above reflects that of "POSIX_ME_HARDER",
which should never have been renamed.

Re: Endorsing version 1.0 of the GNU Social Contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-10 07:32, Mark Wielaard wrote:

There were several pieces of feedback that were either not sent to the
public list, or are still held up in moderation.


Maybe that contract should include a few clauses about not engaging
in deceptive and illegal behavior.

You should not be using the GNU logo in that website or the word "gnu"
in the domain name.

Maintaining some packages for the GNU project doesn't entitle
you to register domains with "gnu" in it, or use the GNU logo in
websites hosted at those domains any more than, say, working for Walmart
entitles you to register some *.walmart.* domain and use the Walmart 
logo.

Re: Endorsing version 1.0 of the GNU Social Contract

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-06 09:32, Andrej Shadura wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/02/2020 13:39, fredomatic wrote:

I, Frederic Y. Bois, maintainer of package GNU MCSim, endorse version
1.0 of the GNU Social Contract, available at
.

Thanks!

As the maintainer of GNU indent, I also fully agree with and endorse 
the

proposed GNU Social Contract. It’s time the GNU project followed the
lead of other free software projects and adopted one.


If were to examine, on every major project hosting site, every
project that has any sort of free software license file (GPL, MIT,
BSD, ...) in the root directory, I strongly suspect that the vast
majority of such repositories would be found without any
"social contract" document.

Therefore, if following the lead is what is important, perhaps the
project wielding these social contracts ought to be dropping them.

Re: about the GNU promise

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-02-03 07:28, Benno Schulenberg wrote:
The second sentence says: "The GNU Project provides a software 
system..."
The word "system" is both too vague and too all-encompassing; it sounds 
as


It's just missing "operating" in front of it.

if it wants to be a single, massive block of software.  I would say 
that
the GNU project "provides software packages...".  The second section 
then

nicely elaborates a bit on this.


The GNU project's goal is in fact to provide a complete operating 
system;

that's been that way from the beginning.

If the GNU project provides some ad hoc "packages", that implies that
there is some non-GNU system where they have to be installed to be used.

Perhaps a non-free system (where GNU packages can be used due to the GPL
exception for system libraries).

See where that is going?

The third section begins: "Free software extends beyond the GNU 
Project..."
Huh?  Vague.  Does this want to say that there is also free software 
that
is not part of the GNU project?  If yes, then say so.  It continues: 
"which
works with companion free software projects that develop key components 
of
the GNU System".  Oof...  Who are those "companion free software 
projects"?


This is basically just taking a mile-wide detour around saying "Linux". 
:)


The kernel is a key component of the GNU system, an the most popular 
kernel
that everyone is using with GNU stuff on it is not part of the GNU 
project.


Another example: the X Window system.

Another: Apache.

How can such projects "that develop key components of the GNU System" 
not

be part of the GNU project itself?


Lift up a corner of your glibc, and look underneath.


And then: "The GNU Project aims to extend the reach of free software to
new fields."  Huh?  What new "fields"?  Again: what is the promise 
here?

Is it that we intend to assimilate everything?


Machine learning, social networking, crytptocurrency, bioinformatics, 
...

Re: A summary of some open discussions

[Kaz Kylheku (gnu-misc-discuss)]

On 2020-01-11 21:52, Jean Louis wrote:

* Thompson, David  [2020-01-10 10:53]:


The problem is that when he chooses to step in, GNU is worse off
because of it.  See the glibc abort "joke", "kind communication
guidelines" vs. code of conduct, etc.

- Dave


It is not abort joke, it never was "abort" joke. Media with you
included is twisting it and as media has certain keywords to pick up
and earn money on it, you think it is justified to blame anybody for a
joke? LOL.

It is censorship joke:
https://www.gnu.org/software/libc/manual/html_node/Aborting-a-Program.html


More than a censorship joke, it obviously uses metaphor of an imagined
censorship about the abort function as government-imposed prohibitions
on abortion.

It's not a joke at all, but a coded political statement that stands in
favor of women's right to choose, against conservative policies.

Re: A GNU “social contract”?

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-15 11:20, a...@gnu.org wrote:

All in all, this should first be discussed with RMS before brought to

   > public discourse.

   It has been discussed with him and he has been told that these kind 
of

   discussions and decisions need to be made in public.

I haven't seen you CC RMS, and infact -- it seems that you are trying
to evade any kind of input from him completely.


Pardon me; why would anyone in a mailing list debate extend the Cc: list
in this manner?

Furthermore, I would assume that RMS keeps tabs on "gnu-misc-discuss".

(If not via an actual subscription, then at least by monitoring the 
archives,

which are public for anyone to browse.)

Re: A GNU “social contract”?

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-10 08:40, Ludovic Courtès wrote:

Hello,

"Kaz Kylheku (gnu-misc-discuss)" <936-846-2...@kylheku.com> skribis:


By the way, "contract" seems like a misnomer, because a contract is
a signed-off agreement between two parties (or more) in which they
exchange something of value; the contract requires a contribution
from at least two parties.


I found Andreas’ explanation of what is meant by “social contract” and
how it differs from a civil law contract to be clear.


My point isn't that it just differs from civil law. The word "contract"
in all other uses derives the basic concept from the civil law usage.

For instance "interface contract" between program modules: mutual
requirements are imposed on caller and callee.


From WordNet:

  Overview of noun social_contract

  The noun social contract has 1 sense (first 1 from tagged texts)

  1. (2) social contract -- (an implicit agreement among people that
  results in the organization of society; individual surrenders liberty
  in return for protection)


According to that definition, these documents don't look like social
contracts. They are promises to behave in some way to a "community"
that isn't itself agreeing to the social contract. It includes users
who are not members of the project and just run the programs without
so much as reading the social contract. If they don't redistribute 
anything,

they don't even have to read the license.


“Pledge” is also a good word, though my understanding is that it does
not capture the social commitment that “social contract” entails.


Well, "social pledge" would do that, probably.

Re: Why "GNU/Linux" is not accepted: an observation

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-09 11:10, Alexandre François Garreau wrote:
Actually a lot of “high-level” user-end utilities are indeed not GNU… 
now even
more so as Gnome is not anymore (and doesn’t want to be associated to) 
GNU.


An unfortunate thing is that GNU project lacks indeed any full-featured
server.  There are some minimal servers in inetutils and mailutils, 
there are
stuff like MyServer…  But not much really that good or known in the 
end.


Furthermore, most of really high-level GNU software are something quite
essential but “hidden” in computing: languages implementation 
(essentially
lisp, but also ed, sed, awk, bison, make, smalltalk, gs, prolog, mhtml, 
forth,
gnash, eiffel, etc.), and package managers (stow, swbis, 
source-install, gsrc,
guix, etc.) which most non-developer users won’t know about (and 
developers

won’t necessarily think about it’s GNU).


The GNU project can't do everything. It would be unfortunate if
everything came from GNU; it would mean that nobody wants to do free
software outside of GNU.

Then, it's not reasonable to expect every project to join GNU.

Some use more permissive licenses.

Not every author wants to assign their copyright to some organization,
however benevolent. They may do so as contributors to an existing work,
but not for their own from-scratch major project.

Not every author wants to join their project to some organization
which sets its own rules in how projects are run; they wrote the code
and want to be "boss".

In a typical freeware distro, we find plenty of pieces that are solo 
work,

not part of any project. This is fine.

Re: Why "GNU/Linux" is not accepted: an observation

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-08 00:29, Marcel wrote:

On 11/8/19 3:01 PM, Kaz Kylheku (gnu-misc-discuss) wrote:

A typical GNU/Linux distribution include more than just GNU userland
on top of Linux. It can be argued that the name GNU/Linux is 
incomplete

and excludes contributions from other sources, the same way that
Linux alone excludes GNU.


A similar and arguably even less fair situation arises with some
distributions, to the point that some people come to associate the 
whole

system with the name of the distribution.

In the case of GNU, as I read it from the GNU website[^1], the concern
seems to be less for the appreciation or accolades of receiving credit,
and more for keeping alive the underpinning Free Software philosophy.

[^1] https://www.gnu.org/gnu/gnu-users-never-heard-of-gnu.html


If the users never heard of GNU, it could be that because in spite
of 20% (or whatever) of their distro's base installation image being 
GNU,

they don't use any of it.

They actually use the Linux part of the system, whenever that system
is powered up and running. They're aware that something boots calling
itself Linux, with reams of console messages.

There are "low GNU" systems out there. E.g. embedded Linux-based systems
with a non-GNU C library, BusyBox instead of Coreutils or Bash, and 
whatnot.
Neither OpenSSH nor Dropbear are GNU. systemd isn't GNU. Various 
networking

utilities aren't GNU. "util-linux" isn't GNU.

How about servers? Apache isn't GNU; node.js isn't GNU; Perl, Python,
Ruby, PHP, ... not GNU again. PostgreSQL: not GNU.

A lot of the *payload* stuff that actually powers what people are doing
in a visible way to them isn't GNU, unfortunately. And, secondarily,
some of the GNU stuff is commoditized, which is partly due t 
implementing

standards. Instead of Bison you can use Berkeley Yacc; instead of bash,
you can use zsh, dash, and others. GCC has alternatives now. GNU libc
also, and so it goes.

Here is something ironic: the uname program is from  GNU Coreutils.
(Or *a* uname command that is commonly installed, anyway):

  $ uname --version | head -2
  uname (GNU coreutils) 8.28
  Copyright (C) 2017 Free Software Foundation, Inc.

Yet, the content comes from the kernel system call:

  $ uname -a
  Linux box 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 
2018 x86_64 x86_64 x86_64 GNU/Linux


This reinforces to the users that they are in something called Linux.

Maybe uname should check that the sysname member of struct utsname
starts with "Linux" and add "GNU/" to the output.

(And then, why not just do it unconditionally! GNU/SunOS could be
printed on Solaris. Hey, if you're running GNU uname, your system
must be GNU/something.)

Re: Why "GNU/Linux" is not accepted: an observation

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-07 14:36, Akira Urushibata wrote:

The ordinary computer user who has been educated through Microsoft's
marketing propaganda is likely to see the operating system as one
entity.


Note that the ordinary computer user of some BSD Unix variant also been
thus "indoctrinated". The user space and kernel come from the same shop.

In fact, the whole darn thing coming from one house is rather the
rule than the exception, if we look at any computing era, any operating
system. Everything from Multics to TempleOS. :)

A typical GNU/Linux distribution include more than just GNU userland
on top of Linux. It can be argued that the name GNU/Linux is incomplete
and excludes contributions from other sources, the same way that
Linux alone excludes GNU.


I notice that even among IT specialists who write books and
magazine articles for popular consumption there are people who hold
this view.

The problem with the term "GNU/Linux" is that it requires the
understanding that the operation system is not one single program but
rather a collection of programs with distinct functions.


Of course even just a mildly sophisticated computer user knows that
a web browser or text editor isn't part of a single monolithic system
program, even if the pieces are all from Microsoft; users know that
there are numerous programs that are bundled together, which sit in
files and can be run independently.

What some users perhaps don't understand is that in the case of
GNU/Linux, the pieces come from all corners of the world, and are
connected to different groups of people, some of whom don't necessarily
identify so much with GNU/Linux. Their stuff is just used by 
distributions.


Ideally, everyone should be credited, but that can't all fit into the
name.

Re: Will RMS be back to Programming now?

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-07 22:58, Jean Louis wrote:

Dear Nala,

Greetings to China. I am eating here with chopsticks...

* Nala Ginrut  [2019-11-07 15:03]:


Hi Jean!

Yes, I totally agreed. And I actually meant RMS's health status,
personally I don't think the fame was hurt by the recent comments
misinterpretation or even the previous personal activity years ago.
If his health status is permitted, then maybe he can do some 
advocating

work by simple coding work, it's kind of advertisement. ;-)


His programming was significant for the inception of GNU operating
system, as there were not many people to do it except of RMS.


There is a lot more to RMS than just GNU.

RMS was involved in Common Lisp; he was part of the initial Common Lisp
group:[1]

In the 1970's, he evidently developed a Lisp dialect in which 0 was
false and the empty list, rather than the symbol nil.[2]
This might have helped inoculate Stallman against later having allergic
reactions to C, which was adopted in a major way by GNU.

RMS invented something called phantom stacks[3]; I can recommend this 
paper

for the writing quality alone. Any Lisp-head will appreciate it.

RMS co-authored some papers in the 1970's with Sussman and Steele.

  "He was special," recalls Gerald Sussman, an MIT faculty member and 
former

  AI Lab researcher. Describing Stallman as a "clear thinker and a clear
  designer," Sussman employed Stallman as a research-project assistant
  beginning in 1975. The project was complex, involving the creation of 
an
  AI program that could analyze circuit diagrams. Not only did it 
involve

  an expert's command of Lisp, a programming language built specifically
  for AI applications, but it also required an understanding of how a 
human

  might approach the same task."[4]

---
[1] https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf, P. 39
[2] https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf, P. 63
[3] https://dspace.mit.edu/handle/1721.1/6331
[4] "Free as in Freedom", Chapter 6, 
https://www.oreilly.com/openbook/freedom/ch06.html

Re: A GNU “social contract”?

[Kaz Kylheku (gnu-misc-discuss)]

By the way, "contract" seems like a misnomer, because a contract is
a signed-off agreement between two parties (or more) in which they
exchange something of value; the contract requires a contribution
from at least two parties.

A statement of promises to behave in some ways toward some
group (such as a "community"), who makes no reciprocal promises and
isn't a party to the document is rather a "pledge", or
"solemn promise" or such.

The requirement to make a pledge can be a contract clause,
of course.

Re: list moderation

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-11-05 02:59, Ludovic Courtès wrote:
A bit more than 24 hours later, two things have become clear to me: 
that
Mark and Carlos were indeed doing a good moderation job, and that by 
not

doing any moderation, you’ve opened the flood gates and silenced the
rest of us.


Funny though, I'm somehow reading you loud and clear at this end.

Maybe I'm stranded in some remaining pocket of moderation?

In that time we got ~100 messages, the majority of which were written 
by
the same 3 people.  Worse, many of those messages were personal 
attacks,

and many others were off-topic for this list.


Well, since we aren't throwing away the baby or the bathwater, there
is bathwater. Is that a surprise?

Local filtering options have not been taken away.

If most of the messages you don't want are from the same three people.
you can filter them out based on the From: header.

If most of the unwanted messages are in the same thread, you can use a
threaded mail reader which folds all of them into a single UI item that
can be selected and deleted in one stroke.

You can set up a rule that turfs messages based on Subject: line.

Re: Women and GNU and RMS (was Re: something else)

[Kaz Kylheku (gnu-misc-discuss)]

In light of the changing shape of the list's moderation,
the following is a re-post of a message that was previously
rejected as being flamey or whatever.

Well, is it?

There is no hot temper behind it; I had it in draft form
overnight, mulled over and reworded some things the next day.

If anyone thinks it should have been rejected, I welcome any
comment to that effect and am grateful for any justifications
and explanations.

Text in sequare brackets is an annotation I'm adding now.

On 2019-10-30 16:22, Sandra Loosemore wrote:

IMO, to regain control of our public image, I think we have to take
some explicit and public steps to disassociate the GNU project from
RMS's comments.


Hi Sandra,

Outside observer here.

I'm afraid I don't agree. Firstly, anyone who is grown up and halfway
intelligent already knows that those comments don't have anything
to do with the GNU project; and that there is a lot more to
GNU than just one person.

  [Hopefully is it clear here that I'm not saying anything like
   that the person I'm replying to herself isn't halfway intelligent
   or grown up, which would be nonsensical to say the least.
   I agree with the basic need for organizations to be dissociated
   from the personal views of individual members. But such legal
   disclaimers are mainly for the dimwitted.]

In other words, GNU and the FSF are not currently "associated" with
those comments in any way (not in any way that is fair and reasonable),
so there is nothing to undo.

So that is to say, "dissociate from the comments" is a phrase that
doesn't refer to any concrete action in the world, just some words
to try to persuade some people who allegedly hold some false belief.

More importantly, *explicit* steps, as you say, to dissociate from
anything involve *mentioning* what you're dissociating from.
That just dredges up the matter and draws attention to it, delaying
it from being laid to rest.

This is closely related to the 
https://en.wikipedia.org/wiki/Streisand_effect


The best way is to stop talking about the whole matter, and just
take a reactive strategy toward any loose ends. If some outsider brings
up some views such as that GNU or FSF are tarnished by some past events
involving individual behavior, it may be appropriate to react to that 
swiftly.


Basically, take an evidence-based, empirical approach: if you see
concrete evidence that someone is harboring or promoting a false view
about the organization, then take some explicit steps. If nobody seems
to be doing that, then there is no actual problem; focus your
attention somewhere else.

It's like bug fixing.

Don't make up some angel-on-pin's-head scenario in your head based on 
what
some ISO or IEEE document says or does not say and go off making 
changes.

Insist on a repro test case.

And, of course, not bringing up a matter doesn't imply that anyone is
taking a particular side in the matter. Yes, of course someone usually
benefits to some extent when some matter isn't discussed; but that 
doesn't

mean that the reticence is intended for their benefit.

Re: A GNU “social contract”?

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-10-28 13:06, Ruben Safir wrote:

On 10/28/19 2:41 PM, Samuel Thibault wrote:

Jean Louis, le lun. 28 oct. 2019 21:54:00 +0530, a ecrit:

Virgin joke is a joke

Now that I have read about it, I can definitely say that it is a
completely inappropriate "joke". Sure, it'll get a lot of people 
laugh.

But it'll also get some people not at ease / ashamed, etc., which is
just in line with that I wrote:


No it wouldn't.  The implication of any reference to human sexuality is
offensive and that is CRAP.  Growups have no trouble with this.

Show does it shame to talk about Emacs virginity?  NO ONE... no one
human anyway.


Tread with care upon the virgin snow, for it is an accumulation of 
snowflakes.

Re: Turning GNU into a bottom-up organization

[Kaz Kylheku (gnu-misc-discuss)]

On 2019-10-21 08:08, Mark Wielaard wrote:

Hi,

In practice GNU already is mostly a bottom-up organization, where the
GNU hackers that do the actual work shape the project, but it would be
nice to make it more formally so.


That instinctively has me wondering what a "recursive descent"
organization might be like; but I don't like the sound of it,
let me tell you.


___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

New Lisp dialect: TXR Lisp.

[Kaz Kylheku (gnu-misc-discuss)]

Hi Gnumancers,

Since around August 2009, I've been developing a language called TXR 
which consists of:


* a pattern language (the TXR Pattern Language) for matching whole text 
documents/streams and scraping their contents.


* an original Lisp dialect called TXR Lisp.

page: https://www.nongnu.org/txr/index.html
doc:  https://www.nongnu.org/txr/txr-manpage.html
git   http://www.kylheku.com/cgit/txr/

TXR is offered under the two-clause BSD license.

A few days ago, I put out version 195, which is what it looks like it 
means: the one hundred ninety-fifth public release. (Semantic 
versioning!)


Originally, TXR was just the pattern language. It sprouted the Lisp 
dialect, and much of the development has been in that area.


TXR Lisp's basic "political alignment" is with ancient tradition: lists 
are terminated by the symbol nil, which is also Boolean false. It is a 
Lisp-2. However, it supports Lisp-1-style evaluation also under the dwim 
operator, which sugared by [ ... ] notation. This shift to an 
alternative evaluation is deeply integrated into the expander.


TXR Lisp has various goodies such as: exception handling, an OOP system 
(not CLOS-like; single dispatch, single inheritance), syntactic places, 
reasonably rich I/O with a format function, string interpolation, 
built-in lazy lists, buffers, delimited continuations, a Lisp-ified 
implementation of Awk, a package system, and a really great FFI.  
Numerous POSIX interfaces are included in the library.


There is an interactive listener, with command persistent command 
history, decent editing (visual copy and paste, undo) with a great 
multi-line mode.


Recently I developed a virtual machine and compiler for TXR Lisp.

TXR Lisp makes list operations generic over vectors, strings and 
user-defined sequences. For instance (car "abc") returns #\a, and (cdr 
"z") yields nil.


It has numerous primitives for working with lazy lists. There are lazy 
strings and The OOP system supports lazy objects.


There are nice ways to index sequences. For instance (swap [a 2..5] [b 
10..19]) will do what it looks like: exchange the given sub-ranges of 
sequences a and b in place, even though they are of different length.


Objects other than functions are callable, with useful semantics.

The OOP system supports a mechanism called "equivalence substitution" 
which allows objects to be used as custom hash keys without the 
programmer having to write a hashing function.


TXR is documented by a thorough user manual which takes the form of one 
giant man page that converts to about a 640 page PDF as well as a 
hyper-linked HTML document hosted online.


Cheers ...


___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

New Lisp dialect: TXR Lisp.

[Kaz Kylheku]

Hi Gnumancers,

Since around August 2009, I've been developing a language called TXR 
which consists of:


* a pattern language (the TXR Pattern Language) for matching whole text 
documents/streams and scraping their contents.


* an original Lisp dialect called TXR Lisp.

page: https://www.nongnu.org/txr/index.html
doc:  https://www.nongnu.org/txr/txr-manpage.html
git   http://www.kylheku.com/cgit/txr/

TXR is offered under the two-clause BSD license.

A few days ago, I put out version 195, which is what it looks like it 
means: the one hundred ninety-fifth public release. (Semantic 
versioning!)


Originally, TXR was just the pattern language. It sprouted the Lisp 
dialect, and much of the development has been in that area.


TXR Lisp's basic political alignment is with ancient tradition: lists 
are terminated by the symbol nil, which is also Boolean false. It is a 
Lisp-2. However, it supports Lisp-1-style evaluation also under the dwim 
operator, which sugared by [ ... ] notation. This shift to an 
alternative evaluation is deeply integrated into the expander.


TXR Lisp has various goodies such as: exception handling, an OOP system 
(not CLOS-like; single dispatch, single inheritance), syntactic places, 
reasonably rich I/O with a format function, string interpolation, 
built-in lazy lists, buffers, delimited continuations, a Lisp-ified 
implementation of Awk, a package system, and a really great FFI.  
Numerous POSIX interfaces are included in the library.


There is an interactive listener, with command persistent command 
history, decent editing (visual copy and paste, undo) with a great 
multi-line mode.


Recently I developed a virtual machine and compiler for TXR Lisp.

TXR Lisp makes list operations generic over vectors, strings and 
user-defined sequences. For instance (car "abc") returns #\a, and (cdr 
"z") yields nil.


It has numerous primitives for working with lazy lists. There are lazy 
strings and The OOP system supports lazy objects.


There are nice ways to index sequences. For instance (swap [a 2..5] [b 
10..19]) will do what it looks like: exchange the given sub-ranges of 
sequences a and b in place, even though they are of different length.


Objects other than functions are callable, with useful semantics.

The OOP system supports a mechanism called "equivalence substitution" 
which allows objects to be used as custom hash keys without the 
programmer having to write a hashing function.


TXR is documented by a thorough user manual which takes the form of one 
giant man page that converts to about a 640 page PDF as well as a 
hyper-linked HTML document hosted online.


Cheers ...

___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Re: grep is screwed on Debian, Ubuntu and others ...

[Kaz Kylheku]

On 2012-05-04, Wolfram Gloger wm...@dent.med.uni-muenchen.de wrote:
 Kaz Kylheku k...@kylheku.com writes:

 Watch this:
 
 $ echo a | grep '[A-B]'
 a

 I can't reproduce this on Debian.  Neither in lenny nor in squeeze,
 not even in etch.  (C and de_DE.UTF-8 locales tested)

Me neither; I was mistaken about that. Sorry!
___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

grep is screwed on Debian, Ubuntu and others ...

[Kaz Kylheku]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655293

I ran into this doing a simple grep job that needed to match upper
case characters, and so I started Googling.  This was only reported in January.

But the Red Hat people knew about what looks like the same bug two years ago.
Oops, they didn't share!

https://bugzilla.redhat.com/show_bug.cgi?id=583011

(So much for the spirit of collaboration in open source. My distro, my
patches, screw you!)

Watch this:

$ echo a | grep '[A-B]'
a
$ echo b | grep '[A-B]'
$ echo b | grep '[:upper:]'
$ echo B | grep '[:upper:]'
$ echo E | grep '[:upper:]'
$ echo e | grep '[:upper:]'
e

Ooops! Someone doesn't have a regression test suite, or at least not one
that is worth a damn.
___
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss