Re: Development Speed

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01968.html
From: Po Lu
Date: Tue, 21 Dec 2021 09:06:40 +0800

> It's not much more modular than what we have in Emacs. The only real
> difference is that it runs in a separate process, which I think also
> poses freedom issues. AFAIK there is at least one proprietary frontend
> for neovim.

I don't know if it is more or much more, but credit where credit is due.
This does help them receive more contributions than both Vim and Emacs.
Structuring the code with respect to software freedom is a whole different
subject, (which I support) but current ifdef toolkit jungle is not that.

> Details, please. We want to fix any bugs that crop up anywhere, and I
> don't think we're missing out on any features.

I cannot see the future or what could've been, this is highly opinionated
but I do believe following latest C standard as early as possible is good
for an open source project.

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

>> It's not much more modular than what we have in Emacs. The only real
>> difference is that it runs in a separate process, which I think also
>> poses freedom issues. AFAIK there is at least one proprietary frontend
>> for neovim.

> I don't know if it is more or much more, but credit where credit is due.

I don't see any reason why that credit due.

> This does help them receive more contributions than both Vim and Emacs.

How so?

> Structuring the code with respect to software freedom is a whole different
> subject, (which I support) but current ifdef toolkit jungle is not that.

The "ifdef toolkit jungle" is restricted to the X-Windows code, and X is
so complicated to program for that every significant program using X
works that way.

> I cannot see the future or what could've been, this is highly opinionated
> but I do believe following latest C standard as early as possible is good
> for an open source project.

It's not possible in the first place.

Thanks.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01991.html
From: Po Lu
Date: Tue, 21 Dec 2021 19:05:43 +0800

>> This does help them receive more contributions than both Vim and Emacs.
> How so?

I also wonder why, and this subject might need it's own thread.  My first
guess is that their code is more approachable, whatever all that entails.

> The "ifdef toolkit jungle" is restricted to the X-Windows code, and X is
> so complicated to program for that every significant program using X
> works that way.

I plan to ask about this topic again when I am more knowledgeable, if that
is okay. Thanks for your insight.

> It's not possible in the first place.

Why not, assuming it is at some point considered to be beneficial
by maintainers?

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I also wonder why, and this subject might need it's own thread.  My first
> guess is that their code is more approachable, whatever all that entails.

I was asking for evidence that Neovim has more contributions than Emacs,
and that it will last.

> I plan to ask about this topic again when I am more knowledgeable, if that
> is okay. Thanks for your insight.

Thanks.  A word of advice is to not trust every article posted on an
internet blog or social media about the internals of Emacs.  I find much
of that content to be plain misinformation.

> Why not, assuming it is at some point considered to be beneficial by
> maintainers?

Right now it's not, I think.  Even C11 would require dropping many
platforms that are currently supported, not to mention C17.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01994.html
From:	Po Lu
Subject: Re: Development Speed
Date:	Tue, 21 Dec 2021 19:37:57 +0800

> I was asking for evidence that Neovim has more contributions than Emacs,

In total I suspect Emacs would win since it is much older.  If we compare
recent and look at it's main repo and GUI projects it looks ahead.
We could collect github (which has built in statistics) and/or other
links and calculate but is it worth the effort?

> and that it will last.

It has been growing for a couple of years now, but who knows what will
happen...

> Thanks.  A word of advice is to not trust every article posted on an
> internet blog or social media about the internals of Emacs.  I find much
> of that content to be plain misinformation.

I intend have an article up called something like "Emacs: Facts and
Myths" and regularly link those then refute.  It could even be a github
repo for everyone to add.  I'm ok if someone beats me to it. :)

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I intend have an article up called something like "Emacs: Facts and
> Myths" and regularly link those then refute.  It could even be a github
> repo for everyone to add.  I'm ok if someone beats me to it. :)

Please don't use GitHub!  While the situation is not as grave as it was
many years ago when GitHub was actively spreading disinformation about
free software licensing, it's still a service that essentially requires
users to run non-free JavaScript.

You can choose a better forge from this list:
https://www.gnu.org/software/repo-criteria-evaluation.en.html.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02084.html
From: Po Lu
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 08:56:49 +0800

> Please don't use GitHub! While the situation is not as grave as it was
> many years ago when GitHub was actively spreading disinformation about
> free software licensing, it's still a service that essentially requires
> users to run non-free JavaScript.

I mentioned that site precisely because the kind of people that needs
to see the article only dwell on there.  If they are self aware enough
to understand harm of non-free sites like GitHub, chances are they're not
very misinformed about Emacs. :)

Re: Development Speed

[Stefan Kangas]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I also wonder why, and this subject might need it's own thread.  My first
> guess is that their code is more approachable, whatever all that entails.

If there is a lack of contributors, I guess code quality can contribute
to that.  But I'd strongly suspect that instead of looking for a fix at
the source code level, there are social and cultural reasons why many
find it hard to contribute to Emacs.

However, I don't really think it's correct to say that we have a lack of
contributors:

    https://lars.ingebrigtsen.no/wp-content/uploads/2021/08/2021-08-13.png

What I observe instead is that we have many people who should be in a
position to contribute to Emacs core, but for one reason or another
choose not to.  Instead, they develop third-party packages on MELPA (or,
more recently, NonGNU ELPA).

One thing we have discussed over and over is moving to sourcehut, but
AFAIK no one is working seriously on that.  I really hope that someone
will take on that task soon.  Maybe Lars or Eli would like to put it at
the top of etc/TODO (on the emacs-28 branch) on the off chance that it
helps.

Re: Development Speed

[Theodor Thornhill]

>
> One thing we have discussed over and over is moving to sourcehut, but
> AFAIK no one is working seriously on that.  I really hope that someone
> will take on that task soon.  Maybe Lars or Eli would like to put it at
> the top of etc/TODO (on the emacs-28 branch) on the off chance that it
> helps.


IIRC there are some issues with sourcehut still, like sending patches as
attachment, keeping us from migrating.  I guess contributions to
sourcehut need to happen first.  Maybe we should collect an exhausive
list of what features are needed before we can migrate?  I don't
remember right now what else was missing.

Theo

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01995.html
From:	Stefan Kangas
Subject: Re: Development Speed
Date:	Tue, 21 Dec 2021 04:05:32 -0800

> If there is a lack of contributors, I guess code quality can contribute
> to that.  But I'd strongly suspect that instead of looking for a fix at
> the source code level, there are social and cultural reasons why many
> find it hard to contribute to Emacs.

FWIW my impression is also that sociocultural reasons are a much more
significant reason on Emacs' case than code quality. Misinformation is
real.  I simply imagine the latter something simpler to tackle.

Re: Development Speed

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 11:52:26 +0100 (CET)
> Cc: Emacs Devel <emacs-devel@gnu.org>
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> I do believe following latest C standard as early as possible is good
> for an open source project.

Why is that?  We are talking about a project most of whose codebase is
extremely stable and proven by many years of use.  What could possibly
new compilers give us except destabilize the code (due to bugs in
early implementations of new standards)?

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

  > I cannot see the future or what could've been, this is highly opinionated
  > but I do believe following latest C standard as early as possible is good
  > for an ...

As has been pointed out, we support lots of platforms, including old
platforms, and some of them don't have fresh new compilers.  If we
wanted to be quick to tell users "tough, your platform is no longer
supported," we could assume everyone has the latest GCC to use.
But those platforms are important.

Some of those old platforms are among the most important ones
because they allow operation without the Intel Management Engine
(or AMD's counterpart to that).

Our principles say we must do our best to encourage people to use a
free compiler if that is at all possible.  If the only C17 compiler
for a platform is nonfree, we must support using GCC instead.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > I cannot see the future or what could've been, this is highly opinionated
>   > but I do believe following latest C standard as early as possible is good
>   > for an ...
>
> As has been pointed out, we support lots of platforms, including old
> platforms, and some of them don't have fresh new compilers.  If we
> wanted to be quick to tell users "tough, your platform is no longer
> supported," we could assume everyone has the latest GCC to use.

This is not about having the latest GCC, this is about having a GCC
that's less than 10 years old.

> But those platforms are important.
>
> Some of those old platforms are among the most important ones
> because they allow operation without the Intel Management Engine
> (or AMD's counterpart to that).

Aren't there modern machines without this? Machines that are much more
performant, reliable and secure than those old ones, which usually are
tied to an unsupported OS full of security defects?

I sincerely don't get the stance of clinging to decades-old software and
hardware but when it comes to Emacs it must be the latest and shiniest.
As if emacs version N would cease to work the very moment emacs version
N+1 is released.

Have we checked lately if those machines that we purport to support are
able to run anything more complex than `emacs -Q'?

> Our principles say we must do our best to encourage people to use a
> free compiler if that is at all possible.  If the only C17 compiler
> for a platform is nonfree, we must support using GCC instead.

Nobody suggested using anything else than GCC.

I'm having the feeling that a good chunk of participants on this ml are
unwittingly but firmly commited to confine Emacs to the same
retro-computing world they live in.

The amount of tension and obstructionism that emerges every time that
someone suggests implementing some technology less than 20 years old is
overwhelming.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> This is not about having the latest GCC, this is about having a GCC
> that's less than 10 years old.

Simple example: GCC 3.4.x does not support C17, and it's recommended for
building the MS-DOS port, which doesn't only run on MS-DOS, but also
builds and runs on its free and actively developed replacement FreeDOS,
and also MS-Windows.

> Aren't there modern machines without this? Machines that are much more
> performant, reliable and secure than those old ones, which usually are
> tied to an unsupported OS full of security defects?

There are no others that are easy to obtain.  We don't want to just make
it possible for people to use Emacs with free software, but we also want
to make it easy.

> I sincerely don't get the stance of clinging to decades-old software and
> hardware but when it comes to Emacs it must be the latest and shiniest.

Why is that?

> As if emacs version N would cease to work the very moment emacs version
> N+1 is released.

Indeed, aside from Tramp and a few other packages, code remaining
compatible with older versions of Emacs is a rarity nowadays.

> Have we checked lately if those machines that we purport to support are
> able to run anything more complex than `emacs -Q'?

Yes.  For example, I tried quite a few things with the MS-DOS port, and
thanks to that, it works on Emacs 28 now.

The same situation exists with Windows 9x.  At work, we have a 9x system
for running legacy applications, and having Emacs 27 installed on that
system is really convenient.  And yes, that Emacs installation is
regularly used.

> The amount of tension and obstructionism that emerges every time that
> someone suggests implementing some technology less than 20 years old is
> overwhelming.

We already use the features of C11 and C17 where they are available.
That doesn't mean we have to go out of our way to break the build on
C99, which is regularly tested.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

>> Have we checked lately if those machines that we purport to support are
>> able to run anything more complex than `emacs -Q'?
>
> Yes.  For example, I tried quite a few things with the MS-DOS port, and
> thanks to that, it works on Emacs 28 now.
>
> The same situation exists with Windows 9x.  At work, we have a 9x system
> for running legacy applications, and having Emacs 27 installed on that
> system is really convenient.  And yes, that Emacs installation is
> regularly used.

How much RAM that machine has? Do you think it is justified to keep
Windows-9X support on Emacs for just a few anecdotal uses? If your
answer is that the extra work it adds is negligible and that you will
keep the maintenance burden, don't you think that keeping a separate
branch for Windows-9X (or any retro-computing platform, for that matter)
would be more adequate, instead of forcing everyone else to go over that
code when they read the sources?

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> How much RAM that machine has?

That machine is a Pentium 4 with 768 MB of RAM.  It is perfectly suited
to running Emacs with some customizations written for it to fill out
forms that need to be printed.

> Do you think it is justified to keep Windows-9X support on Emacs for
> just a few anecdotal uses?

Yes I do, because there is no reason to break it.

> If your answer is that the extra work it adds is negligible and that
> you will keep the maintenance burden, don't you think that keeping a
> separate branch for Windows-9X (or any retro-computing platform, for
> that matter) would be more adequate, instead of forcing everyone else
> to go over that code when they read the sources?

Not many people have to go through that code when reading the sources.
grep for `is_windows_9x', and you will see that we only test for Windows
9x in a few places.  It's also not a "retro computing platform" when
people are relying on it for real work, as opposed to play.

Eli being the MS-Windows expert here, I think he can explain further.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 11:38:43 +0100
> 
> don't you think that keeping a separate branch for Windows-9X (or
> any retro-computing platform, for that matter) would be more
> adequate, instead of forcing everyone else to go over that code when
> they read the sources?

No, I don't.  The Windows 9X support is confined to a small number of
well-defined places.  Maintaining a VCS branch is a much larger
hurdle.

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

  > How much RAM that machine has? Do you think it is justified to keep
  > Windows-9X support on Emacs for just a few anecdotal uses?

We do.  You are free to disagree, but you're not going to convince us
by raging.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > How much RAM that machine has? Do you think it is justified to keep
>   > Windows-9X support on Emacs for just a few anecdotal uses?
>
> We do.

So you insist on supporting an obsolete, bug-ridden, unsecure and
*proprietary* OS with Emacs users numbers that probably range on the
single digits because... why?

Do you think that the reasons about availability of cheap used machines
on underprivileged communities that were valid 20 years ago maybe need
an update?

> You are free to disagree,

You are so gracious, thank you.

> but you're not going to convince us by raging.

Here we go again, misrepresenting and insulting people who don't align
with your view.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> So you insist on supporting an obsolete, bug-ridden, unsecure and
> *proprietary* OS with Emacs users numbers that probably range on the
> single digits because... why?

I doubt I rank among the "single digits".

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So you insist on supporting an obsolete, bug-ridden, unsecure and
>> *proprietary* OS with Emacs users numbers that probably range on the
>> single digits because... why?
>
> I doubt I rank among the "single digits".

Well, you need 9 more to prove me wrong ;-)

Seriously, part of my point is that if keeping Windows-9X support on
Emacs is helping people to keep using that OS, GNU is doing them a
disservice, both on technical and moral principles.

Re: Development Speed

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So you insist on supporting an obsolete, bug-ridden, unsecure and
>> *proprietary* OS with Emacs users numbers that probably range on the
>> single digits because... why?
>
> I doubt I rank among the "single digits".
Unless  you have different personailites and they all count as different users?
:-)

Sorry, just a joke; but on serious side, what is a good use of Windows 9x
these days? Other than just testing Emacs builds of course. It was a bad OS when
it came out, I can hardly imagine it got better nowadays.

Anyway, I doubt there are many users of Windows 9x left, even with you counted,
but I don't think there is much in Emacs sources targeting specifically Windows
9x either. Is it?

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

  > > So you insist on supporting an obsolete, bug-ridden, unsecure and
  > > *proprietary* OS with Emacs users numbers that probably range on the
  > > single digits because... why?

  > I doubt I rank among the "single digits".

I will refrain from suggesting that we respond with a single digit ;-}.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

To clarify the situation, it is Eli who thinks Windows 9 is worth
spending his time on.

The GNU Project attaches no particular importance to supporting
Windows (whatever version), but he's welcome to support it if he wants
to.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Dmitry Gutov]

On 22.12.2021 13:22, Po Lu wrote:
> aside from Tramp and a few other packages, code remaining
> compatible with older versions of Emacs is a rarity nowadays.

Very untrue.

Almost all notable third-party packages keep compatibility with Emacs 25 
(released 5 years ago).

Some exceptions (like lsp-mode and eglot) require Emacs 26 (released 3.5 
years ago).

And a fair number of packages work with Emacs 24 and older still.

Re: Development Speed

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Very untrue.

At least that was my opinion gained from years of watching people trying
to stay with Emacs 23.4.

Re: Development Speed

[Dmitry Gutov]

On 23.12.2021 04:00, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> Very untrue.
> At least that was my opinion gained from years of watching people trying
> to stay with Emacs 23.4.

There is a vast distance between the last version and 23.4 (released a 
decade ago).

Re: Development Speed

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> There is a vast distance between the last version and 23.4 (released a
> decade ago).

In another 9 years, Emacs 27.2 will have been "released a decade ago" as
well.

Re: Development Speed

[dick]

PL> In another 9 years, Emacs 27.2 will have been "released a decade
PL> ago" as well.

Are you okay?  You appear to be having a seizure preventing you from
grasping the notion of a moving window in time.

Re: Development Speed

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 21:18:10 -0500
> 
> PL> In another 9 years, Emacs 27.2 will have been "released a decade
> PL> ago" as well.
> 
> Are you okay?  You appear to be having a seizure preventing you from
> grasping the notion of a moving window in time.

Please stop these senseless ad-hominem attacks on people here.  You
are dangerously close to crossing the proverbial red line.  Whatever
you want to say, please say it without calling people names.

Re: Development Speed

[Dmitry Gutov]

On 23.12.2021 04:07, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> There is a vast distance between the last version and 23.4 (released a
>> decade ago).
> In another 9 years, Emacs 27.2 will have been "released a decade ago" as
> well.

We should really hope that even people who are forced to use use 
outdated/cheap hardware, will be using *different* cheap hardware in 9 
years' time.

Re: Development Speed

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 23.12.2021 04:07, Po Lu wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> There is a vast distance between the last version and 23.4 (released a
>>> decade ago).
>> In another 9 years, Emacs 27.2 will have been "released a decade ago" as
>> well.
>
> We should really hope that even people who are forced to use use outdated/cheap
> hardware, will be using *different* cheap hardware in 9 years' time.

That hardware will probably be warned out and not avialable in next 10 years.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 11:09:09 +0100
> 
> The amount of tension and obstructionism that emerges every time that
> someone suggests implementing some technology less than 20 years old is
> overwhelming.

Generalizations are almost always risking losing accuracy, but this
one does that with a vengeance.  I think it's not only inaccurate
(when talking about Emacs development), but also simply unfair.  E.g.,
some of the recent developments in Emacs use technology that is much
newer than "20 years", and I challenge you to come up with examples
that could back up your generalization, or even come close.

Re: Development Speed

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 11:09:09 +0100
>> 
>> The amount of tension and obstructionism that emerges every time that
>> someone suggests implementing some technology less than 20 years old is
>> overwhelming.
>
> Generalizations are almost always risking losing accuracy, but this
> one does that with a vengeance.  I think it's not only inaccurate
> (when talking about Emacs development), but also simply unfair.  E.g.,
> some of the recent developments in Emacs use technology that is much
> newer than "20 years", and I challenge you to come up with examples
> that could back up your generalization, or even come close.

Example: the painful road from CVS to a modern VC system (first bzr and
then Git when was clear that bzr was inadequate at several levels, as
some warned before it was adopted.) And then many contributors didn't
bother to adapt to the distributed workflow and keep using Git as if it
were CVS, which makes the VC history hard to follow and of diminished
value.

Another example: the mailing list used as a bug tracker. We went from no
tracker at all to a big hack that happens to accommodate the personal
preferences of a few contributors while making things harder for
everyone else. Basic things like subscribing to a bug are too advanced:
you either monitor the mailing list or out of touch.

Another example: the amount of old cruft and hacks that pervades the
source code, prominently the C part.

The motif port was re-enabled with the excuse of two users saying that
they use it (two users! which actually didn't actually said that they
use the port, just that they build it.)

A the same time someone suggested experimenting with a new approach to
display and he was shunned ("We tried with such a library, many eons
ago. It was named lwlib, and you can judge for yourself how successful
it is.") Right, because if it failed many eons ago, trying again is
doomed to fail for sure, as technologies in software change as often as
in medieval masonry; and what the OP was suggesting is not what lwlib
does, IIUC.

So we maintain old code because two people "complain" (they didn't) and
meet with... let's say skepticism, proposals that seem to require
significant changes on the source base but with a high impact on
improving Emacs' potential. Lots of features and fixes are made trying
to not change the "stable" code, that's why we end having functions over
1000 lines long sprinkled with #ifdefs, which not only make any
substantial change very difficult, but are a big red sign saying "here
be dragons."

Emacs' architecture favors plug-in components, in the form of Elisp
packages, external processes and C libraries exposed to Elisp. That's
what keeps Emacs somewhat competitive, often thanks to heroic efforts.
But working on certain key parts of the core is very hard, both
technically and socially. You are concerned about the lack of C
contributors, but I think your worries are not well focused: there are
still plenty of C hackers around, but do they see our C core as
something they would enjoy contributing to?

Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Alan Mackenzie]

Hello, Óscar.

On Wed, Dec 22, 2021 at 16:51:41 +0100, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Wed, 22 Dec 2021 11:09:09 +0100

> >> The amount of tension and obstructionism that emerges every time that
> >> someone suggests implementing some technology less than 20 years old is
> >> overwhelming.

> > Generalizations are almost always risking losing accuracy, but this
> > one does that with a vengeance.  I think it's not only inaccurate
> > (when talking about Emacs development), but also simply unfair.  E.g.,
> > some of the recent developments in Emacs use technology that is much
> > newer than "20 years", and I challenge you to come up with examples
> > that could back up your generalization, or even come close.

Your last post comes over as one big moan.  You moan about perfectly
valid decisions, some of which didn't turn out optimally.  You moan about
perfectly valid decisions, full stop.  You or somebody else could have
moaned about the opposite decisions, had they been so taken, equally
well.

The main point of my post is that Eli is having to deal with a lot of
negative posting at the moment, and this is a Bad Thing.  He could do
with a break.

We're approaching what is in large swathes of the world the "season of
goodwill".  Why don't we reflect that in our posts to emacs-devel, in
particular to those directed at Eli?

I'm not going to respond to your points in detail; that would just lead
to more interminable arguments.  Suffice it to say that I disagree with
most of them as well as disliking the tone they were expressed in.

A happy Christmas to you!

> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

> A the same time someone suggested experimenting with a new approach to
> display and he was shunned ("We tried with such a library, many eons
> ago. It was named lwlib, and you can judge for yourself how successful
> it is.") Right, because if it failed many eons ago, trying again is
> doomed to fail for sure, as technologies in software change as often as
> in medieval masonry; and what the OP was suggesting is not what lwlib
> does, IIUC.

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

> Emacs' architecture favors plug-in components, in the form of Elisp
> packages, external processes and C libraries exposed to Elisp. That's
> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
> But working on certain key parts of the core is very hard, both
> technically and socially. You are concerned about the lack of C
> contributors, but I think your worries are not well focused: there are
> still plenty of C hackers around, but do they see our C core as
> something they would enjoy contributing to?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Your last post comes over as one big moan.  You moan about perfectly
> valid decisions, some of which didn't turn out optimally.  You moan about
> perfectly valid decisions, full stop.

That's your opinion. It's understandable that you talk about "perfectly
valid decisions", since you were strongly vocal when those decisions
were made and had a significant impact on them. Which is fine.

> The main point of my post is that Eli is having to deal with a lot of
> negative posting at the moment,

I'm pretty sure that Eli:

1. knows how much I appreciate his work.

2. is quite capable of speaking for himself.

3. any observation on my messages is not addressed to him personally,
   but to the project as a whole, since a long time before he was the
   maintainer. BTW, I energetically lobbied for using bzr over git at
   the time and thought that debbugs were better than nothing. I was as
   wrong as the wrongest (non-)participant on those discussions.

> We're approaching what is in large swathes of the world the "season of
> goodwill".

I'll refrain from expressing my opinion about the concept of seasonal
goodwill.

Finally, I will say that you are not the only one who feels entitled to
moan and rant on emacs-devel :-)

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[dick]

AM> He could do with a break.

You make it sound as if he doesn't relish the convo.

Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
the usual suspects from this list take the bait.  And why wouldn't they?
It's much easier and more gratifying putting these unheralded
know-it-all's in their place, than writing code and fixing bugs.

I wonder if our maintainer wears a toga.  He's really nailed down the
Hippocratic Oath of "first, do no harm" (the corollary of which is
"don't move fast and don't break things"), and his Socratic approach to
answering questions by asking five more is masterful.

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 12:12:39 -0500
> 
> Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
> the usual suspects from this list take the bait.  And why wouldn't they?
> It's much easier and more gratifying putting these unheralded
> know-it-all's in their place, than writing code and fixing bugs.

I consider it part of my job to participate in discussions related to
Emacs development where I think I have something potentially useful to
say.

But thank you so much for you kind offer of managing my time and
tasks.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 16:51:41 +0100
> 
> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

That's a lopsided view of what happened, with denigrating epithets
("painful", "inadequate") to season it.  The switch to bzr was no more
painful than any switch from a centralized VCS to a dVCS could be
expected to be.  At the time we switched, bzr was a viable
alternative, used by several other projects (some of which kept using
it long after we switched to Git).  And how the problem with
contributors' mindsets is any evidence in favor of your argument is a
mystery to me.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

Another lopsided view: we are looking for a better system for quite
some time, and until now none was found to satisfy our basic
requirements.  Hopefully, sourcehut will.

For a more balanced view, try to find a project that is happy with its
bug tracker.  I'm still looking.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

Really?  Like what?

And how is this a "technology" problem?  Or would you like us to
rewrite Emacs in Rust?

Come on, get real!  This is supposed to be a serious discussion, not a
mud-throwing match.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

And how is this any evidence that we procrastinate in our acceptance
of new technology?  Does Motif support disallow any such advances?

> A the same time someone suggested experimenting with a new approach to
> display and he was shunned ("We tried with such a library, many eons
> ago. It was named lwlib, and you can judge for yourself how successful
> it is.") Right, because if it failed many eons ago, trying again is
> doomed to fail for sure, as technologies in software change as often as
> in medieval masonry; and what the OP was suggesting is not what lwlib
> does, IIUC.

Maybe you misunderstood what the OP was suggesting.  Or maybe you have
some different suggestion in mind, because what he was suggesting
makes no sense to me.  Do we have to accept any suggestion whatsoever,
no matter if it does or doesn't make sense, lest Óscar will accuse us
of being backward?

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

No, we maintain old code because it works and because we decide not to
break it.  It's a decision which has reasons, you just choose to
ignore them because you want to make a point in an argument.

And how is this any evidence of (not) accepting new technologies,
anyway?  Or are we changing the subject now to something like "all I
hated in Emacs development but was afraid to say out loud"?

> Emacs' architecture favors plug-in components, in the form of Elisp
> packages, external processes and C libraries exposed to Elisp. That's
> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
> But working on certain key parts of the core is very hard, both
> technically and socially. You are concerned about the lack of C
> contributors, but I think your worries are not well focused: there are
> still plenty of C hackers around, but do they see our C core as
> something they would enjoy contributing to?

That is against any reasonable experience and facts on so many levels
that I don't know where to start.  Here's several items, as food for
thought:

  . Emacs extensibility via Lisp can only go so far, sooner or later
    it hits a wall.  Some extensions and major developments need
    changes in C, and any attempt to kludge^H^H^H^H^H^Hplug them in
    with Lisp is bound to fail.  Evidence: linum vs native line
    numbers.  Evidence: bidirectional editing (which originally had a
    Lisp implementation which went nowhere).  Evidence: HarfBuzz vs
    "ligatures" via prettify-symbols-mode.
  . Working on the C level requires certain efforts, but is far from
    being impossible for novices.  Evidence: face-extension feature
    and display-fill-column-indicator-mode feature that was coded by
    someone who started from almost zero knowledge of the display
    code.  Evidence: several people who started working on the C code
    just recently (see Git logs).
  . Reasons why "plenty of C hackers", if they indeed exist (and IME
    the jury is still out on that one), need serious investigation.
    I have my guesses about that, but they will remain unsaid at this
    point.

Bottom line: I find that Emacs recently picks up quite a few new
technologies, and for an old and stable program such as Emacs we
should be proud of what we accomplished.

Re: Development Speed

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

I'm skipping over several things to keep this short and to the point.

>> A the same time someone suggested experimenting with a new approach to
>> display and he was shunned ("We tried with such a library, many eons
>> ago. It was named lwlib, and you can judge for yourself how successful
>> it is.") Right, because if it failed many eons ago, trying again is
>> doomed to fail for sure, as technologies in software change as often as
>> in medieval masonry; and what the OP was suggesting is not what lwlib
>> does, IIUC.
>
> Maybe you misunderstood what the OP was suggesting.

I don't think so, the few doubts I had vanished after reading his recent
messages.

> Or maybe you have
> some different suggestion in mind, because what he was suggesting
> makes no sense to me.

Maybe asking for clarification? I can expand on the proposal, but
somebody else already did. I can answer specifics about that topic if
necessary.

> Do we have to accept any suggestion whatsoever,
> no matter if it does or doesn't make sense, lest Óscar will accuse us
> of being backward?

Well, that's a glaring example of what I said about not internalizing
the social implications of our "new" tools :-) If you have doubts about
his suggestion, you could just say "I don't get what you are proposing
but if you think it is good for Emacs then sure, go ahead and I'll
examine your work when you have something to show." Then the OP goes to
work on his personal repo. That has almost zero cost to you, both on
effort and risk. It's not like the old times when you had to give write
permissions to the project's repo and destabilizing WIP usually happened
on the main branch because merges on CVS are a pain.

>> Emacs' architecture favors plug-in components, in the form of Elisp
>> packages, external processes and C libraries exposed to Elisp. That's
>> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
>> But working on certain key parts of the core is very hard, both
>> technically and socially. You are concerned about the lack of C
>> contributors, but I think your worries are not well focused: there are
>> still plenty of C hackers around, but do they see our C core as
>> something they would enjoy contributing to?
>
> That is against any reasonable experience and facts on so many levels
> that I don't know where to start.  Here's several items, as food for
> thought:
>
>   . Emacs extensibility via Lisp can only go so far, sooner or later
>     it hits a wall.  Some extensions and major developments need
>     changes in C, and any attempt to kludge^H^H^H^H^H^Hplug them in
>     with Lisp is bound to fail.  Evidence: linum vs native line
>     numbers.  Evidence: bidirectional editing (which originally had a
>     Lisp implementation which went nowhere).  Evidence: HarfBuzz vs
>     "ligatures" via prettify-symbols-mode.

Very true, but I don't see how this contradicts what I wrote. The
occasional new feature on core base happens, but extensions (Elisp,
interfaces to external processes and, more recently, modules) makes the
bulk of Emacs' user-perceptible improvements, much more so if we count
external packages.

>   . Working on the C level requires certain efforts, but is far from
>     being impossible for novices.  Evidence: face-extension feature
>     and display-fill-column-indicator-mode feature that was coded by
>     someone who started from almost zero knowledge of the display
>     code.  Evidence: several people who started working on the C code
>     just recently (see Git logs).

I'm convinced that there is a strong survival bias at play here.

> Bottom line: I find that Emacs recently picks up quite a few new
> technologies, and for an old and stable program such as Emacs we
> should be proud of what we accomplished.

This definitely agree with.

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

  > > Some of those old platforms are among the most important ones
  > > because they allow operation without the Intel Management Engine
  > > (or AMD's counterpart to that).

  > Aren't there modern machines without this? Machines that are much more
  > performant, reliable and secure than those old ones, which usually are
  > tied to an unsupported OS full of security defects?

Not that I've heard of.  Every so often I check whether there has been
progress.

  > Have we checked lately if those machines that we purport to support are
  > able to run anything more complex than `emacs -Q'?

I check this all day, every day.

  > > Our principles say we must do our best to encourage people to use a
  > > free compiler if that is at all possible.  If the only C17 compiler
  > > for a platform is nonfree, we must support using GCC instead.

  > Nobody suggested using anything else than GCC.

Your general demand would, under some circumstances, imply that.

  > I'm having the feeling that a good chunk of participants on this ml are
  > unwittingly but firmly commited to confine Emacs to the same
  > retro-computing world they live in.

Your verbal aggression is very unkind, and makes discussing with you
unpleasant.  We don't need your approval or agreement, so the aggression
won't win you anything.

Please try to follow the GNU Kind Communication Guidelines,
https://gnu.org/philosophy/kind-communication.html.  Cooperating,
to whatever extent we have goals in common, will be much easier
if you do that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > > Some of those old platforms are among the most important ones
>   > > because they allow operation without the Intel Management Engine
>   > > (or AMD's counterpart to that).
>
>   > Aren't there modern machines without this? Machines that are much more
>   > performant, reliable and secure than those old ones, which usually are
>   > tied to an unsupported OS full of security defects?
>
> Not that I've heard of.  Every so often I check whether there has been
> progress.

AFAIK there are multiple machines that offer more computing power (on
terms of CPU, RAM, storage, etc) than the typical medium-range PC from
15 years ago. AFAIK a humble Raspberry Pi fits that description and it
has a fraction of the propietary firmware most of those old PCs have.

Then we have some vendors that specialize on providing PCs with as few
binary blobs as possible, with IME and its equivalents disabled.

I agree that it is difficult to acquire a new computer which is
completely Free, but it is fairly easy to get a new computer which
contains far less proprietary elements than the typical PC sold before
IME became a thing.

>   > > Our principles say we must do our best to encourage people to use a
>   > > free compiler if that is at all possible.  If the only C17 compiler
>   > > for a platform is nonfree, we must support using GCC instead.
>
>   > Nobody suggested using anything else than GCC.
>
> Your general demand would, under some circumstances, imply that.

I can't imagine those circunstances, since Gcc is the most ubiquitous
compiler out there.

>   > I'm having the feeling that a good chunk of participants on this ml are
>   > unwittingly but firmly commited to confine Emacs to the same
>   > retro-computing world they live in.
>
> Your verbal aggression is very unkind,

What you call verbal aggression I call speaking own's mind. It is not
like as if I throwed that paragraph out of the blue, there is a lot of
context.

> and makes discussing with you unpleasant.
>
> We don't need your approval or agreement, so the aggression
> won't win you anything.
>
> Please try to follow the GNU Kind Communication Guidelines,
> https://gnu.org/philosophy/kind-communication.html.  Cooperating,
> to whatever extent we have goals in common, will be much easier
> if you do that.

The very first guideline is:

   Please assume other participants are posting in good faith, even if
   you disagree with what they say.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> AFAIK there are multiple machines that offer more computing power (on
> terms of CPU, RAM, storage, etc) than the typical medium-range PC from
> 15 years ago. AFAIK a humble Raspberry Pi fits that description and it
> has a fraction of the propietary firmware most of those old PCs have.

Raspberry Pis cannot run usably with 100% free firmware, while the old
PCs RMS was referring to can.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> AFAIK there are multiple machines that offer more computing power (on
>> terms of CPU, RAM, storage, etc) than the typical medium-range PC from
>> 15 years ago. AFAIK a humble Raspberry Pi fits that description and it
>> has a fraction of the propietary firmware most of those old PCs have.
>
> Raspberry Pis cannot run usably with 100% free firmware, while the old
> PCs RMS was referring to can.

Are you implying that it is possible to turn regular PCs from before IME
into systems with 100% free firmware?

There are multiple components on a typical system that use their own
firmware, many of them are not writable.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Raspberry Pis cannot run usably with 100% free firmware, while the old
>> PCs RMS was referring to can.

> Are you implying that it is possible to turn regular PCs from before IME
> into systems with 100% free firmware?

Yes.  In fact, some small businesses buy those PCs and install the free
software and firmware onto them.

> There are multiple components on a typical system that use their own
> firmware, many of them are not writable.

If they are not writeable, they are not free or nonfree, for the same
reason hardware is not free or nonfree.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> Raspberry Pis cannot run usably with 100% free firmware, while the old
>>> PCs RMS was referring to can.
>
>> Are you implying that it is possible to turn regular PCs from before IME
>> into systems with 100% free firmware?
>
> Yes.  In fact, some small businesses buy those PCs and install the free
> software and firmware onto them.

Installing GNU/Linux and a Free BIOS does not make a machine 100% Free.

>> There are multiple components on a typical system that use their own
>> firmware, many of them are not writable.
>
> If they are not writeable, they are not free or nonfree, for the same
> reason hardware is not free or nonfree.

Then if the BIOS/UEFI/IME were read-only the FSF would be fine with them
being proprietary? I don't think so.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Yes.  In fact, some small businesses buy those PCs and install the free
>> software and firmware onto them.

> Installing GNU/Linux and a Free BIOS does not make a machine 100% Free.

Indeed it doesn't, but the devices Richard referred to are 100% free
with the free firmware and software installed.

> Then if the BIOS/UEFI/IME were read-only the FSF would be fine with them
> being proprietary?

Yes.  The ME is undesirable for other reasons, but if the firmware and
ME were read-only they would not pose freedom issues, as they would be
indistinguishable from hardware.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> Yes.  In fact, some small businesses buy those PCs and install the free
>>> software and firmware onto them.
>
>> Installing GNU/Linux and a Free BIOS does not make a machine 100% Free.
>
> Indeed it doesn't, but the devices Richard referred to are 100% free
> with the free firmware and software installed.

And those are off-the-shelf x86(_64) PCs? Or are machines with special
hardware?

>> Then if the BIOS/UEFI/IME were read-only the FSF would be fine with them
>> being proprietary?
>
> Yes.  The ME is undesirable for other reasons, but if the firmware and
> ME were read-only they would not pose freedom issues, as they would be
> indistinguishable from hardware.

Then I'm more of a Free Software purist than the FSF.

I'm interested on what rms says about this.

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

  > Raspberry Pis cannot run usably with 100% free firmware, while the old
  > PCs RMS was referring to can.

For more details, see fsf.org/resources/hw/single-board-computers.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

  > The very first guideline is:

  >    Please assume other participants are posting in good faith, even if
  >    you disagree with what they say.

That's right.  And I'm glad to say that I did not impute bad faith to
your words.  What I said is that you were raging, speaking with
aggression, and that that is unkind.

  > > Your verbal aggression is very unkind,
  ...  
  > > and makes discussing with you unpleasant.

  > > We don't need your approval or agreement, so the aggression
  > > won't win you anything.

  > > Please try to follow the GNU Kind Communication Guidelines,
  > > https://gnu.org/philosophy/kind-communication.html.  Cooperating,
  > > to whatever extent we have goals in common, will be much easier
  > > if you do that.

Following these guidelines is not always easy.  Even while making an effort,
one can fail to do it well.  Talking with someone that engages in verbal
aggression is stressful, and stress makes one more likely to make mistakes
oneself.

That's part of the reason it is important for you to make an effort 
to stop your aggression.

  > What you call verbal aggression I call speaking own's mind. It is not
  > like as if I throwed that paragraph out of the blue, there is a lot of
  > context.

What matters to this discussion is that it's verbal aggression and it
causes stress for the rest of us.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > Some of those old platforms are among the most important ones
>   > > because they allow operation without the Intel Management Engine
>   > > (or AMD's counterpart to that).
>
>   > Aren't there modern machines without this? Machines that are much more
>   > performant, reliable and secure than those old ones, which usually are
>   > tied to an unsupported OS full of security defects?
>
> Not that I've heard of.  Every so often I check whether there has been
> progress.

There are not, and there probably will not be. I think it is a decision
enforced by the goverment of a certain world power. Maybe if you used CPUs
produced in some other country for some other market, but do you really trust a
hardware produced in maybe even less free country where everything is under
control of one party? Getting rid of such features in modern hardware can be
only done in political way, but the wide masses are not aware of the problems of
mass surviliance so political solution is probably not possible at this time. As
of current using old CPUs without such hardware is the only solution, but that
is not a sustainable solution. Eventually the world will run out of old CPUs,
and the majority of population already can not obtain one such CPU.

Re: Development Speed

[Richard Stallman]

[[[ 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. ]]]

I was talking about the need for nonfree software in the software load
to make the computer work.

You've changed to a different issue: whether the hardware itself
is malicious.

There IS known malicious hardware in our computers.  The Management
Engine (and its AMD counterpart).  HDCP.  TPM.  Other DRM hardware.
Malicious hardware is as bad as malicious software -- it's the
same issue.

But hardware and software are different issues in other respects.

See https://gnu.org/philosophy/free-hardware-designs.html for the GNU
Project stand on hardware.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02094.html
From: Richard Stallman
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 23:16:24 -0500

I just noticed that I used the term open source there and not free
software; a bad habit I am getting over. :)

> Some of those old platforms are among the most important ones
> because they allow operation without the Intel Management Engine
> (or AMD's counterpart to that).

This a very critical point I forgot to consider, good to bring it up.

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02123.html
From: Óscar Fuentes
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 11:09:09 +0100

>> ... without the Intel Management Engine
>> (or AMD's counterpart to that).
> Aren't there modern machines without this? Machines that are much more
> performant, reliable and secure than those old ones, which usually are
> tied to an unsupported OS full of security defects?

Are there recent, powerful amd64 cores without built-in surveillance out
there?  Accessibility outside of first-world is also important, I'd be
interested to know those if you care to help.

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[xenodasein--- via Emacs development discussions.]

Hello to you too, broseph.  I suppose it takes a special kind of
grey matter to consider asking questions being a know-it-all. :)

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[xenodasein--- via Emacs development discussions.]

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02223.html
From: dick.r.chiang@gmail.com

> You make it sound as if he doesn't relish the convo.

> Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
> the usual suspects from this list take the bait.  And why wouldn't they?
> It's much easier and more gratifying putting these unheralded
> know-it-all's in their place, than writing code and fixing bugs.

> I wonder if our maintainer wears a toga.  He's really nailed down the
> Hippocratic Oath of "first, do no harm" (the corollary of which is
> "don't move fast and don't break things"), and his Socratic approach to
> answering questions by asking five more is masterful.