Re: new feature for "hello"

[Terence Kelly]

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 <tpkelly@eecs.umich.edu> 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