Hi Rick, thanks for the feedback. > ..[snip].. > Answer: don't build with manual steps, use scripts (and test them, of > course). At large scale, orchestration systems do the same thing. > For instance, they sometimes have to install software that is not > pre-built in a canonical package repository.
Being a sys-admin/engineer and developer for many years I have used/do use many orchestration and provisioning systems, and written endless, endless scripts (for the in-house or boutique stuff not yet covered by a "system") already. One of the key points of packaging is to simplify, robustify and sometimes cut down on that, to regain some of the wasted cognitive load. > > barrier to entry for new users, > > But picolisp is for experienced programmers, a class of people who > have no problem building software. > > less exposure for Picolisp to potential users, etc. > > Maybe this is true, but also recall the point about experienced > programmers (who will be the potential users). "New users" (to picolisp) does not necessarily mean "inexperienced programmers". For example, for work I often have to interact with and create with upwards of 7 different languages - by necessity, not by choice - and always yearned to work with a single language that fits me personally (for similar reasons to what prompted Paul Graham's explorations with Arc), but I discovered picolisp in 2012, about a decade later than I would have liked to. This was after spending years (of very limited spare-time) wrangling various other languages, and never having the time to do more than dabble with beasts like Common Lisp, in a quest to find one that really "clicked". For example I submitted two core patches and two documentation patches to Newlisp while I was still trying to bend it to my interests (all were accepted without credit :-/ hence why I left it at only two). I found picolisp in 2012 by happy accident, mentioned deep in a Chinese infosec forum (via Google translate) in the most obscure side-reference within the most obscure issue, and was annoyed that after existing for so long it had been so far under my radar until then. Picolisp being in-tree wherever possible raises its exposure dramatically, and every bit helps. > > Also, due to the need for auditability and extreme scale with no > > maintenance-overhead my webhost would never agree to manually > > compile/install Picolisp to their public systems from upstream > > source (and definitely not repeatedly for each new release). > > But didn't you mention earlier that they allowed you to build picolisp > ("it is what I presently do on my webhost")? If so, that's an option. > And you can script your installs and builds for the large(r) scale. I already compile/use/maintain it in my homedir on my personal webhost (and have various scripts for automating that), but maintaining different toolsets that way doesn't scale (mentally or computationally) the way it could if things were in-tree. I am talking about getting FreeBSD to take that load off the users so FreeBSD-based (web/cloud)hosts can install to *their* system. On a Debian GNU/Linux VM I can do: ssh "myhost" sh -c 'sudo -n apt-get -y install picolisp && picolisp -"prinl \"Hello world!\"" -bye' On FreeBSD I can't yet do that. > > They would only consider installing a stable package from the "Ports > > tree", hence why I am looking for that. > > If they wouldn't let you build picolisp and other software for your > site, you might consider another web hosting service. Seriously. That's why I moved *to* my present webhost :-) > For all the conveniences and other upsides of ports/packages, they > still have to have maintainers who commit to stay on top of updating > the port. Sometimes that's a lot to ask of someone (who is of course > doing it on a volunteer basis). That's why I put the feelers out about that exact issue (to get an idea about the potential load before embarking on packaging). Having created/maintained a package for Debian (didn't get into Official due to mentor-disinterest with the non-standard upstream licensing), created in-house .debs, helped maintainers with other official packages there, as well as maintaining some in-house ebuilds for Gentoo back in the day, I am no stranger to that burden, hence asking around before jumping in like a n00b. > I've never been a port maintainer myself, but being on the other side, when > ports *don't* > get updated, I've had to nag the maintainer (and nobody likes that) and when > that > doesn't get the port updated (not an uncommon case btw), I have to do the > build myself > anyway. :( So in the worst-case we fall back on what we would otherwise have to do anyway, no net-loss. > ..[snip].. > 0. For instance, I myself, on all my platforms -- be they desktop, > laptop, server, it doesn't matter -- use scripts (actually one script > in this case) to install even something as "small" as picolisp: > https://github.com/cryptorick/pilot. Even though the standard > picolisp build is freakin' dead easy, I have other configuration > tweaks that I require to be accomplished pre- and post-build/install, > and I have assurance that "my bases are covered" if I use a script. > So, I'm not telling you to do something that I don't do myself. ;) I have also had to get my hands way too dirty with such things, like "auto-rebasing patches on upstream applications and deploying to live servers" (https://github.com/rowanthorpe/quintain), "auto installing/configuring an IXP Manager" (https://github.com/rowanthorpe/ixpm-autoinstall), "configurable Heroku-style server provision & deployment on arbitrary cloud providers" (in-house, haven't made it public yet), and auto-installing/upgrading OpenResty stack & Kong on a bare VM (another in-house thing I will make public soon). I am deeply interested in me and others gaining the freedom to do less of such things, especially when it involves reinventing wheels. Every bit (especially packaging) helps reduce that load. > ..[snip].. > 2. NFSN is (a FreeBSD-based) one that allows the user to build/install > their own software; there are probably others. That is my (personal) webhost since 2010 :-) Best webhosts ever. One reason I want to get picolisp in-tree, and to convince them to officially support picolisp, is to then convince them to support it with their NFGI script-acceleration, to eliminate the interpreter-per-request situation entirely. Also, regarding the sub-thread about "barrier to entry": I wasn't thinking as much about barriers due to lack of knowledge or experience. I was primarily (but not exclusively) referring to barriers due to lack of time - which is usually *more* the issue for experienced programmers than for the inexperienced ones. Cheers, -- Rowan Thorpe PGP fingerprint: BB0A 0787 C0EE BDD8 7F97 3D30 49F2 13A5 265D CCBD ---- "A riot is the language of the unheard." - Dr. Martin Luther King "There is a great difference between worry and concern. A worried person sees a problem, and a concerned person solves a problem." - Harold Stephens "Ignorance requires no apologies when it presents questions rather than assertions." - Michael Sierchio (OpenSSL mailing list) "What we need more than an end to wars is an end to the beginning of all wars." - Franklin Roosevelt -- UNSUBSCRIBE: mailto:email@example.com?subject=Unsubscribe