Hi Reuben,
Thanks for the quick and detailed reply. Perhaps my original e-mail
wasn't clear. Let me try again.
I'm wondering if "hello" is open to innovations intended to be exemplary
for other GNU packages. In other words, new features/functionality to be
recommended, via the example of "hello", as best practices.
My specific suggestion is easy and, I believe, would be valuable for many,
many software packages.
In the context of "hello" it works like this when we invoke an executable
on the command line:
$ hello --dump-tgz
causes the hello executable to emit on stdout the tarball of source code
from which it was compiled.
(If it's not obvious how to make this possible I can explain; it's easy
for compiled C/C++ code.)
I call this feature "literate executables" in homage to Knuth's "literate
programming": binaries such as executables and libraries (.so) compiled
from C/C++ can emit their own source code on demand.
The pervasive, thorny problem that this feature solves is that, in
practice on widely used GNU/Linux distributions today, it is very
difficult even for experienced users to pinpoint with high confidence the
source code that was used to generate the executables they run and the
libraries they link with.
Try it yourself: Find the source code underlying the grep program that's
first in your $PATH. Now prove, to yourself and to a skeptical observer,
that the source you found is indeed *exactly* the source behind your grep.
This is no easy task for every experienced user/programmer with whom I've
discussed the matter. They range from old timers who were at Bell Labs
when grep was invented to sophisticated veteran Silicon Valley developers
to sharp young students.
The solution is for packages to follow a simple and easy custom: When a
binary (executable or library) is built, i.e., when "make" is run, a copy
of the tarball from which the binary was created is embedded in the
binary. If the tarball is the egg and the binary is the chicken, we're
empowering the chicken to lay its own egg on demand.
Just as "literate programming" keeps source and documentation in the same
files, "literate executables" similarly binds binaries to source.
This is important so that security-sensitive code is easy to audit, and
it's valuable when an assertion fails, yielding a filename & line number
that would otherwise be difficult to track down. Most imporantly, it
makes it easy to pracice the fundamental Software Freedoms that Stallman
articulated long ago, which requires easy access to source code.
Let me know if you're interested. I can prototype this in "hello". It's
easy.
Thanks.
-- Terence
On Wed, 10 Aug 2022, Reuben Thomas wrote:
On Wed, 10 Aug 2022 at 15:11, Terence Kelly <[email protected]> wrote:
Hi,
Is the "hello" team open to suggestions for new features?
I think the short answer is "no": we have removed functionality from hello
in the past. GNU hello is meant to be a demonstrator project for the GNU
Coding Standards and as a demonstration GNU package.
So, any extra functionality in the program should illustrate some element of
GNU packages. For example: hello is translated into different languages,
illustrating the use of gettext.
A similar example comes to mind: using GNU gengetopt to generate the
command-line parser. But that would not be new functionality.
I hope that explains the scope of new functionality that would make sense,
and the reasoning behind it.
You are of course welcome to make your own version of hello; for example, if
you wanted to make a fancier greeting program (a frivolous example, perhaps,
but who says we can only write serious programs?). In that case, hello's own
history might give some inspiration, as hello used to support multiple
greetings styles.
One idea that might be worth having in hello itself would be collaboration
with other GNU programs, for example, outputting greetings in other formats,
such as PostScript (you could use GNU a2ps), or even in other media (as a
radio transmission?). The practical benefit here would be illustrating
techniques of interfacing to other programs.
--
https://rrt.sc3d.org
