Hi Rick, thanks for the feedback.
> ..[snip]..
> Answer: don't build with manual steps, use scripts (and test them, of
> course).[0] 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[1], 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.[2] 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:picolisp@software-lab.de?subject=Unsubscribe
