pf-badhost + unbound adblock v4 released
Hey folks, just thought I'd share with you that I've released the latest
versions of pf-badhost and unbound-adblock.
pf-badhost webpage: https://www.geoghegan.ca/pfbadhost.html
unbound-adblock webage: https://www.geoghegan.ca/unbound-adblock.html
Key pf-badhost changes:
* pf-badhost goes portable, we now support {Open,Free,Net,Dragonfly}BSD
as well as MacOS!
* Support for IPv6 subnet aggregation added thanks to the excellent
aggregate6 utility written by job@
* Greatly improved IPv6 handling in general
* User configuration section added for configuring whitelists and custom
blocklists
* Bogon filtering added
* Greatly improved error handling
Key unbound-adblock changes:
* unbound-adblock goes portable, we now support
{Open,Free,Net,Dragonfly}BSD as well as Linux!
* Greatly improved error handling and input sanitation
* User configuration section added for configuring whitelists and custom
blocklists
pf-badhost changelog:
https://www.geoghegan.ca/pub/pf-badhost/0.4/changelog.txt
unbound-adblock changelog:
https://www.geoghegan.ca/pub/unbound-adblock/0.4/changelog.txt
Re: OpenBSD master volume GUI TCL, how to contribute?
On Thu, Jul 2, 2020 at 4:50 AM wdaver wrote: > > There are posts asking for a GUI to control volume for OpenBSD. > I wanted the same and wrote an 85 line TCL (8.5) script. It calls > sndioctl, has a volume slider and mute button, sized for touch > screen convenience. I use it every day. > > I am ok with just posting here, for users to copy and paste. > > It could be a port (maybe the smallest port ever). I know there is an > introduction in the FAQ for ports and I have zero experience creating > ports. Seems like it would need a brief man page. > > The script may stop people from asking about it... > > Suggestions for the best way to contribute this tiny script to OpenBSD? > Putting it here is a good start. Maybe put it in a publicly accessible repository (maybe Gitlab? I'd suggest GitHub, but Microsoft) so you can also push any changes needed, and anyone who wants to can suggest improvements and report bugs. >From there, if you (or anyone) wants to submit a port, they've got a central place to pick up the latest version. If you wanted to do this yourself, your best bet is to look for any ports that have TCL as a prerequisite, and go from there. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
OpenBSD master volume GUI TCL, how to contribute?
There are posts asking for a GUI to control volume for OpenBSD. I wanted the same and wrote an 85 line TCL (8.5) script. It calls sndioctl, has a volume slider and mute button, sized for touch screen convenience. I use it every day. I am ok with just posting here, for users to copy and paste. It could be a port (maybe the smallest port ever). I know there is an introduction in the FAQ for ports and I have zero experience creating ports. Seems like it would need a brief man page. The script may stop people from asking about it... Suggestions for the best way to contribute this tiny script to OpenBSD?
Re: strlcpy version speed tests?
On 7/1/20 8:05 AM, Luke Small wrote: I spoke to my favorite university computer science professor who said ++n is faster than n++ because the function needs to store the initial value, increment, then return the stored value in the former case, while the later merely increments, and returns the value. Apparently, he is still correct on modern hardware. For decades the ++ and *p could be out of order, in different execution units, writes speculatively queued, assigned to aliased registers, etc, etc, etc. Geoff Steckel
Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?
Hi Again, Sorry about the delay in responding. I disabled the uftdi using config as described. (also added it to /etc/shutdown.rc as mentioned by Chris Bennett. Seemed like a good idea.) It does now seem to be disabled, the boottime message has changed to show "ugen" rather than "uftdi" i.e. > ugen1 at uhub0 port 2 "13-37.org Infinite Noise TRNG" rev 2.00/10.00 addr 3 Unfortunately the behaviour seems unchanged: > mjoelnir:software 1.07 17:39:16 # ./infnoise > Error: USB read failed FYI, "usbdevs -v" reports these two device using/being driven by ugen: > ... > Controller /dev/usb0: > addr 01: 8086: Intel, xHCI root hub > super speed, self powered, config 1, rev 1.00 > driver: uhub0 > addr 02: 1050:0407 Yubico, Yubikey 4 OTP+U2F+CCID > full speed, power 30 mA, config 1, rev 4.37 > driver: uhidev0 > driver: uhidev1 > driver: ugen0 > addr 03: 0403:6015 13-37.org, Infinite Noise TRNG > full speed, power 10 mA, config 1, rev 10.00, iSerial 1337-ECA4E8A6 > driver: ugen1 > ... If it is of interest, I also uploaded the output of kdump here: https://paste.c-net.org/HallwaysFeliz It's the complete trace, about 2700 lines. I wasn't sure about adding a 1000 lines to my message here. Cheers, Robb.
Re: strlcpy version speed tests?
On Wed, Jul 01, 2020 at 07:05:02AM -0500, Luke Small wrote: > Are you clinging to traditions for some purpose? I gave two different > versions. strlcpy3 is clearly more easily understood and even slightly > faster and strlcpy4 which sets up the following workhorse lines which > through timing the functions is hands down faster on my Xeon chips: > > > strlcpy4: > while (--nleft != 0) > if ((*++dst = *++src) == '\0') > ... > > the others: > > while (--nleft != 0) > if ((*dst++ = *src++) == '\0') > > ... > > > I spoke to my favorite university computer science professor who said > ++n is faster than n++ because the function needs to store the initial > value, increment, then return the > > stored value in the former case, > > while the later merely increments, and returns the value. Apparently, > he is still correct on modern hardware. If you really care about speed, you should probably look into an arch/ asm version instead
Re: strlcpy version speed tests?
Are you clinging to traditions for some purpose? I gave two different versions. strlcpy3 is clearly more easily understood and even slightly faster and strlcpy4 which sets up the following workhorse lines which through timing the functions is hands down faster on my Xeon chips: strlcpy4: while (--nleft != 0) if ((*++dst = *++src) == '\0') ... the others: while (--nleft != 0) if ((*dst++ = *src++) == '\0') ... I spoke to my favorite university computer science professor who said ++n is faster than n++ because the function needs to store the initial value, increment, then return the stored value in the former case, while the later merely increments, and returns the value. Apparently, he is still correct on modern hardware. -- -Luke
spamd vs IPv6
Hi folks, spamd(8) still mentions 127.0.0.1, but no indication of IPv6 support. Looking on Google for "openbsd spamd ipv6" gives me some entries of 2015 and 2016, but no up-to-date information. Please excuse if I am too blind to see. I am a big fan of spamd, but I wonder is spamd in a dead-end wrt IP address families? Would you recommend "IPv4 only" for EMail? Regards Harri
Re: AMDGPU
On Mon, Jun 29, 2020 at 11:59:28PM -0500, Charlie Burnett wrote: > For sure, whatever helps! > Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* sdma_v4_0: Failed to load firmware > "amdgpu/vega20_sdma.bin" > Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* Failed to load sdma firmware! > Jun 27 18:58:21 tabr /bsd: drm:pid0:psp_v11_0_init_microcode *ERROR* psp > v11.0: Failed to load firmware "amdgpu/vega20_sos.bin" > Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* Failed to load psp firmware! > Jun 27 18:58:21 tabr /bsd: [drm] *ERROR* sw_init of IP block failed -2 > Jun 27 18:58:21 tabr /bsd: drm:pid0:amdgpu_device_init *ERROR* > amdgpu_device_ip_init failed > Jun 27 18:58:21 tabr /bsd: drm:pid0:amdgpu_attachhook *ERROR* Fatal error > during GPU init > That's with the old firmware, and yeah that's with the newest firmware. I > had to use newer firmware on your newdrm branch as well. Let me know how I > can help! :) Thanks, I've updated the port to 20200619 after checking vega10 and picasso. It will later be available via fw_update(1).
