Nowadays, the easiest way to distribute binaries is to use containers. I made some containerised simh images (I’ve not upgraded them for a while though). Details in my blog http://ancientbits.blogspot.com/2016/05/containerizing-simh-bsd-in-box.html?m=1
Jordi Guillaumes Pons El 27 des 2018, a les 23:45, Clem Cole <[email protected]> va escriure: > > >> On Wed, Dec 26, 2018 at 7:03 PM David Brownlee <[email protected]> wrote: >> Well, Joyent also makes binary pkgsrc packages for SmartOS, macOS, and >> CentOS/REL :) https://pkgsrc.joyent.com/ > > xkcd on standards 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].... > > 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? > > 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 > > 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. > > My thinking at least .... > > Clem > ᐧ > _______________________________________________ > Simh mailing list > [email protected] > http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
