Re: [9front] [Patch] APE changes (2019 Lufia patches)

[Lucas Francesco <lucas.francesco93@gmail.com>]

Hi Aaron, thanks for the effort!!!

I am personally against #include_next and pthreads, the pthread
implementation is funky and has LOTS of TODOs, and since it involves
locking I'd like to see them in a separate patchset and with more
testing. (I'm also not sure we should have pthreads on the front,
since it may be ok to just to singlethread or port those programs to
our libraries)

But just so you know, I really appreciate the effort of porting those
patches!!!! I think we should nitpick what we need for things that
make our systems more approachable and easier to use, personally I
already have some use for some of it and have tested pthreads with a
new Equis port. (due to the Erlang port I was working, and some X11
tooling), and think endian, errno, intttypes and getpgid changes might
be fine.

Em sex., 26 de fev. de 2021 às 07:33, <cinap_lenrek@felloff.net> escreveu:
>
> Bringing back in libressl/openssl is a bad idea imho.
> (note, we used to have it in the base system for mercurial)
>
> These are unmaintainable monsters that take forever to compile
> and have so much code churn that we cannot keep up with
> constantly updating it.
>
> We can use libsec from ape programs and it supports the
> kernels tls device. it imlements all the modern ciphers
> and tls support you need with a fraction of the codesize.
> And libsec *is* maintained and in active use so receives
> testing and porting/arch specific support (compiler work,
> optimized assembly versions).
>
> This was done for example for the python hash module to
> use libsec instead of the openssl monster.
>
> Theres also not really a reason for git to implement its
> own dns, tls and https and ssh cients. All this is solved
> i plan9 using webfs and ssh. If git calls curl, you can
> probaly just write a wrapper script around it to use the
> native plan9 infrastructure.
>
> Dont try to emulate the broken way unix does networking
> onto plan9. It is a waste of time. If you must, attempt
> a proper port and *question* the dependencies that it
> clams to be needing.
>
> --
> cinap