Re: access to ld128 system
On Thu, Oct 28, 2021 at 03:28:51PM -0700, Steve Kargl wrote: > kib@ recently committed my implementations of cospi[fl], > sinpi[fl], and tanpi[fl]. These functions have been > extensively tested for float, double, and long double > where long double is the Intel 80-bit long double (e.g., > msun/ld80/s_sinpil.c). The 128-bit versions of these > routines have not been tested (e.g., msun/ld128/s_sinpil.c) > > kib pointed me to a system in the FreeBSD, which I have > access to. Unfortunately, that system has double == > long double, and can only test the support for the > weak references. > > Is there a system with 128-bit long double that I can > have access for some testing? > FYI. An individual has provided access to an aarch64 system. A patch has been submitted to fix the ld128 sinpi, cospi, and tanpi. For the record, I did limited testing to not overwhelm the system. The observed max ULP for sinpi and cospi were less than 1.1 ULP, which is slight worse that the desired less than 1 ULP target. This has been traced to the kernel for computing cosl() in the interval [0,pi/4]. I suspect the minmax polynomial coefficients need refinement. -- Steve
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Sun, 31 Oct 2021 18:15:25 +0100
Marek Zarychta wrote:
> W dniu 29.10.2021 o〓08:29, Andrea Venturoli pisze:
> >
> > On 10/29/21 00:47, Tomoaki AOKI wrote:
> >
> >> But possibly we need to delete current smbfs code from base and switch
> >> to ports (sysutils/*?) if it require some code having incompatible
> >> license for base.
> >
> +1 for removing smbfs(5) from the base and eventually moving it to the
> ports tree. I know some people are still using it with a bit of duct
> tape and baling twine to workaround〓 SMBv{2,3) incompatibility.
Keeping this in base as long as possible should be preferred, as
changes throuout all filesystems would be easier to be missed that on
ports. But borrowing GPL'ed (or any other BSD-incompatible licensed)
codes would disallow it.
> With SMBv1 support, only our smbfs(5) became useless a few years ago.
No. It's much better than nothing.
For example, DSM on Synology NAS disabled support for SMB1 and NTLM1 by
default, but admin can easily enable them again through control panel.
So it's usable (for local networks) at least for now.
> Unfortunately, there is no replacement in the ports tree. To mount SMB
> shares for Nextcloud the port net/pecl-smbclient can be used, but
> definitely deploying Nextcloud to mount only SMB shares is overkill.
>
> > OTOH having a port is not in any way worse as having a broken piece of
> > base.
>
> It sounds reasonable. Moreover, the story of net/wireguard-kmod has
> proven that moving some modules into ports, where the software
> development is done in a more flexible way, can be beneficial for both:
> the developers and the community.
>
> My opinion is only the opinion of the FreeBSD user, but I believe that
> sometimes the feedback from the userbase is important, especially that a
> few months I was told by one of the younger *NIX admins that our
> (FreeBSD) community is the best and he is willing to make a transition
> of some services to FreeBSD as soon as he gets permission from the
> management.
>
> With kind regards,
>
> --
> Marek Zarychta
>
>
--
Tomoaki AOKI
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
W dniu 29.10.2021 o 08:29, Andrea Venturoli pisze:
On 10/29/21 00:47, Tomoaki AOKI wrote:
But possibly we need to delete current smbfs code from base and switch
to ports (sysutils/*?) if it require some code having incompatible
license for base.
+1 for removing smbfs(5) from the base and eventually moving it to the
ports tree. I know some people are still using it with a bit of duct
tape and baling twine to workaround SMBv{2,3) incompatibility.
With SMBv1 support, only our smbfs(5) became useless a few years ago.
Unfortunately, there is no replacement in the ports tree. To mount SMB
shares for Nextcloud the port net/pecl-smbclient can be used, but
definitely deploying Nextcloud to mount only SMB shares is overkill.
OTOH having a port is not in any way worse as having a broken piece of
base.
It sounds reasonable. Moreover, the story of net/wireguard-kmod has
proven that moving some modules into ports, where the software
development is done in a more flexible way, can be beneficial for both:
the developers and the community.
My opinion is only the opinion of the FreeBSD user, but I believe that
sometimes the feedback from the userbase is important, especially that a
few months I was told by one of the younger *NIX admins that our
(FreeBSD) community is the best and he is willing to make a transition
of some services to FreeBSD as soon as he gets permission from the
management.
With kind regards,
--
Marek Zarychta
