[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new feature for "hello"

From: Terence Kelly
Subject: Re: new feature for "hello"
Date: Wed, 10 Aug 2022 18:44:09 -0400 (EDT)
User-agent: Alpine 2.22 (DEB 394 2020-01-19)

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.


-- Terence

On Wed, 10 Aug 2022, Reuben Thomas wrote:

On Wed, 10 Aug 2022 at 15:11, Terence Kelly <tpkelly@eecs.umich.edu> wrote:


      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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]