Re: Hosting a FUDforum on lilypond.org

2021-08-05 Thread Han-Wen Nienhuys
On Mon, Aug 2, 2021 at 2:25 PM Jean Abou Samra  wrote:
> I was able to install it on a local Apache server. In my
> experiments, I encountered some issues when trying to post to
> the lists via it [13], but only with one SMTP server; another
> was fine. The rest of the functionality worked correctly. Thus,
> FUDforum appears to be a potential solution. And I do not see
> other solutions currently. I therefore propose to try it out
> for real.
>
> The big question is: where to host it? There is lilynet.net,
> administrated by Valentin, but he's been busy in the past
> year, so he might not want to take that blame. Before I buy
> a domain, how about lilypond.org? That would make it more
> of an official community space and more discoverable for
> newcomers.
>
> Han-Wen (administrator of lilypond.org if I understand
> correctly), and all, what do you think?

If someone wants to take on the task of administering a forum, I could
setup a DNS entry for forum.lilypond.org.

However, the fact that all these forums have fallen over also holds a
lesson: hosting content is work, because it needs moderation, and
dealing with all the things that can go wrong when you have users
(hijacked accounts, spam, GDPR/cookie wall etc.).

Also, the security record of fudforum doesn't have me impressed:
* https://www.exploit-db.com/exploits/40803
* https://www.cybersecurity-help.cz/vdb/SB2019111508

The facebooks and reddits of this world are experts at running
messaging platforms. Should we really spend precious developer time on
running a message board? I know I won't.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen



[RFC] Add set of scripts to build static binaries on Linux

2021-08-05 Thread Jonas Hahnfeld via Discussions on LilyPond development
I just posted the first version of completely rewritten scripts to
build static binaries for LilyPond:
https://gitlab.com/lilypond/lilypond/-/merge_requests/864

Some key design decisions are:
 * Build natively, avoid cross-compilation.
 * Use static builds of dependencies, no shared libraries.
 * Be specific to LilyPond, no generic package manager.
 * Use tarballs for sources, no download from git.
 * Keep it simple, stupid.

For more details and context, see the added README and
https://lists.gnu.org/archive/html/lilypond-devel/2020-03/msg00337.html
https://lists.gnu.org/archive/html/lilypond-devel/2021-05/msg00027.html

I think it would be best to have discussions about the higher-level
decisions on the mailing list (if needed), and code review in the form
of comments on the merge request itself.

Cheers
Jonas


signature.asc
Description: This is a digitally signed message part