nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] Starting the final call for features for 1.7


From: bergman
Subject: Re: [Nmh-workers] Starting the final call for features for 1.7
Date: Mon, 26 Sep 2016 12:58:00 -0400

In the message dated: Mon, 26 Sep 2016 12:01:22 +0100,
The pithy ruminations from Ralph Corderoy on 
<Re: [Nmh-workers] Starting the final call for features for 1.7> were:
=> Hi Ken,
=> 
=> > I kind of think that the days of nmh being installed on centrally
=> > managed systems is slowly coming to an end.

Installed prior to user requests, installed because the admins themselves
use [n]mh?  Sure, I'd agree with that.

=> 
=> If it's a simple package install then I'm not too surprised.  I often
=> find myself on others' machines without root access and put in a request
=> for a raft of useful packages.  The local admins skim through the list,
=> see they're all straightforward command-line stuff, e.g. dstat, and run
=> the apt-get, pacman, etc.

I'm confused...didn't you just give an example of the case where nmh is
installed on a centrally managed system?

I'd say that we should broaden our idea of 'centrally managed' to include
binary packages available through an OS distribution's package management
system.  Perhaps that will change the way that some configuration choices
are made (ie., run-time vs compile time).

>From the point of view of an end-user of nmh, I think there are really
only 2 installation models:

        1. personal configure/build/install
                ie., everything from scratch, selection of build &
                configure options, possibly including building dev
                branch, etc.

        2. managed install
                end-user is given access to nmh that's been built & configured
                by someone else, whether that 'someone' is a local sysadmin or
                someone creating the package for 
CentOS/Fedora/RedHat/Debian/Ubuntu.

Particularly if the binaries are coming from a pre-compiled package,
there's very little chance of the end-user being able to select
alternative compile-time options, so run-time choices are preferred.

Mark


=> 
=> -- 
=> Cheers, Ralph.
=> https://plus.google.com/+RalphCorderoy
=> 



reply via email to

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