[Simh] Packaging systems and simh (Was: Systems Engineering Labs (SEL) simh simulator available)

[David Brownlee]

On Thu, 27 Dec 2018 at 22:46, Clem Cole <clemc at ccc.com> wrote:

>
> On Wed, Dec 26, 2018 at 7:03 PM David Brownlee <abs at absd.org> wrote:
>
>> Well, Joyent also makes binary pkgsrc packages for SmartOS, macOS, and
>> CentOS/REL :) https://pkgsrc.joyent.com/
>>
>
> xkcd on standards <https://xkcd.com/927/>  sigh.....
>
> Note: I have lived this issue at Intel for +10 years BTW [we make a very
> slick set of development tools that are compatible across different
> OS's]....
>

(Apologies for continuing the thread another level - I've changed the
Subject to make it easier for people to just skip)

So I will step on top of Soap Box ....
>
> As I often have to remind some of our more our engineers at work *installs,
> particularly binary installs, must be socially compliant with the OS* - *i.e.
> what the customer expects.  This is the 'least astonishment principle.'*
>
> That means custom installers that are common for the tool, but different
> from the native OS are a no-no if you really want someone to use the tool
> as a binary. [And that's expensive and hard to do well BTW].
>
> Yup, custom installers makes it easier for >>you<< but not for the person
> doing the installs.   So if you make the choice to support an OS,
> particularly as a binary, then the install needs to be for that OS --- for
> winders its a different  installer than from DOS which is different than VMS.
>   For VMS its the DEC Installer.  For, the UNIX family Solaris is different
> from the loathsome DEC setld(8) of Ultrix and Tru64, which is different
> from IBM AIX which is different from HP-UX, etc....  Linux gets really
> strange on the binary front.   The good news is the commerical folks using
> Linux it is primarily rpm and there are tools the convert from tools that
> convert from rpm to yum/getapt etc., but generally Linux folks generally
> do not want a binary installer ;-)  But there are N different Linux package
> managers and each one is 'better' than the other?   If you have a binary
> distribution for your tool, which do you use?
>

Joyent's pkgsrc *is* the native OS installer for SmartOS, it also targets
RHEL as there are supported versions where the native packages are ancient
(Python 2.4 anyone) and any attempt to wholesale use current versions of
native packages usually results in a nightmare of tdark twisty passages,
none of which work. As for MacOS, well for unix tools the standard path is
a choice of non native package systems (or build your own).

Also quite a few people just use it as a framework to build and install
from source, managing their dependencies, letting them know when a useful
(FSVO useful) upgrade is available, etc.

In short - pkgsrc is the native package system on a couple of OSs, and a
generally useful tool on some others where the native system is deficient
in quality and/or quantity of packages, but for where a system has a rich
set of existing recent packages I definitely agree most people should Just
Use Them, (bar a few outliers like HPC folks who need to be able to keep
multiple entire trees around concurrently for reproducing earlier results)

That said ....
>
> simh is a wonderful tool and the fruits of the labor of many people.  But
> I see it as primarily a github (source) release.   When Mark graceously
> does make a binary, he seems to follow least astonishment.   But since he
> has made the sources available and some distro's have picked it up and
> created binaries of their own, many have done a poor job of following up
> with the source distribution.   Which of course, fails the least
> astonishment principle also (because it's easier for the distro maintainers
> of course).  They can claim they have 'simh' but because they made it
> eaiser for themselves, they are in effect an older (unmaintained) 'fork' or
> the tree.
>
> And this is the of course is a flaw in FOSS.   The economics don't
> follow.   Ecomonically, you want to make it as easy on the builder of the
> tool if your 'product' is the sources.  Which is what Mark does (an
> excellent job IMO as its pretty impressive the number of OS's that can
> build it).
>
> But if you take the sources and package it and create an installer ...
> well Mark and Bob should speak for themselves .... but I think that is you
> own problem; not simh's
>

Sorry, I'm... not entirely sure what problem I'm supposed to have? (not
trying to be pissy - I'm genuinely a little confused)

simh is in pkgsrc, which covers a subset of OS platforms, and a few people
keep it relatively up to date. This may well have resulted in some
additional people trying it who wouldn't have otherwise used it (plus made
it easier for people like me who *could* manage rebuilding every so often
and tracking SDL/pcre/png/pcap/dejavu-ttf/etc dependencies but prefers to
spend those cycles elsewhere).

(Also simh is used to run automated OS regression tests for some platforms,
which while its far from perfect in determining that the code works
perfectly on real hardware, is still a useful check, and definitely quite
handy at quickly picking up on some regressions - and for that you really
want defined versions installed from a packaging system)

Stepping down from Soap Box ...
>
> I will grant you that the users of simh are likely to be a tad more techie
> than 'the average bear.'   But to me that says, you can trust them to go to
> github, do a 'clone' and then build it themselves.
>

We have a wonderful world of choices - those building directly from github
take nothing away from those who want to use a system that manages
dependencies and updates (whether from binary and source)... and vice versa
:)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20181229/a2b1e37d/attachment-0001.html>