quicklisp-projects VS quicklisp-client

Where is it getting that system name from though? I thought quicklisp used project dir names: https://github.com/quicklisp/quicklisp-projects/blob/8aa3500e9c3c3c7e03e76675410008b7e4c4c42f/projects/jzon/source.txt

The tracking issue for adding cl-djula-svg to quicklisp is here. You may want to check it for any updates.

Why do you need to build them in when you can just load your favorite libraries that do these functions with https://www.quicklisp.org/ , especially for http the great libraries by Fukamachi: https://github.com/fukamachi parallel processing: https://lparallel.org/ etc.

I'm very grateful that common lisp does not version up (like python), but you can always load a new or newer version of libraries with no impact on your core production code. (Such as a rewrite when the language gets a new version - this never happens with Common Lisp)

QUICKLISP comes with a regularly updated software distribution, see quicklisp-projects. This software distribution is pulled once when QUICKLISP is installed and can be later updated with (ql:update-all-dists). Once a project is added to the QUICKLISP dist, its updates are also added regularly and are available to users who care of issuing (ql:update-all-dists).

Testing on quicklisp-projects

The Common Lisp bindings to GTK can be installed with Quicklisp. If you don't already have Quicklisp installed, it's painless. See the Quicklisp website for more details, but here's an example of installing Quicklisp on Debian and configuring SBCL. The steps should be the same for any Linux distro and macOS.

I've noticed that beta.quicklisp.org no longer resolves. Neither does https://www.quicklisp.org/. What's going on?

As for the packages themselves, you can look at the repository information for each package at https://github.com/quicklisp/quicklisp-projects and use that to get the packages yourself manually. Most of them just use the latest commit in the package's respective git repos. A few use specific tags. Some, have to be gotten by other means. It is always possible, by looking at the quicklisp update data listing all the packages, to get the url for the package tarballs on the quicklisp server and download them manually.

Yes, that's clear.

I'm not very familiar with how quicklisp works. I thought that “updates once a month” implies a separate update channel (distribution, ...).

Looking at the relevant issue, https://github.com/quicklisp/quicklisp-client/issues/167 , it's not clear that even hashes are in place.

I recently found out that most Nix fetchers use https, but do not actually do verification (`curl --insecure` or equivalent libcurl settings). Channel updates do verify and include hashes, so the overall chain is authenticated.

The latest comment I see about this here from Oct. 2022 says they're working on it. There's also comment by the developer in 2016 saying want to improve the security soon, so it doesn't really seem this will actually happen soon. I realise making signature verification work cross platform in pure lisp without external dependencies isn't easy but from latest comment it seems they have that working, in a branch written 4 years ago? The simplest no-code solution is just since quicklisp is published every month or so, on each new update publish a file with sha256 hash of every package contained in quicklisp signed with same developer's pgp key they are already using to sign download of the initial quicklisp.lisp, yes then users if they care about security would have to manually download the file and verify signature every month or so but it's at least some solution that can be done now.

> That's what regular devs do, they don't even bother writing articles or commenting on HN :-)

I'll take the bait, and roll up several of my comments into one.

First, the support contract costs from the commercial vendors can make sense. It's one of the most expensive parts of software. We joke about fixing relatives' printers, but its not false. Support costs introduce a counter-balance.

Second, a message to everyone looking into or using QuickLisp, it uses http instead of https: https://github.com/quicklisp/quicklisp-client/issues/167

You can patch your version to fix this. I'd also recommend adding firewall rules to deny in case your patches roll back. And any other mitigation. Or stricter policies, such as not using it, if it makes sense for your organization.

And the AI bots? I hope there aren't people herding them who don't want to, that's how you get unloving brats and a crappy world.

I found this github issue about it, open since 2018: https://github.com/quicklisp/quicklisp-client/issues/167

I agree 100% about needing to test and audit for security. But based on the information I've seen and public activity in repos, I assumed Xach was going for home-grown CL implementation. https://github.com/quicklisp/quicklisp-client/blob/pgp/quicklisp/openpgp.lisp