Re: Hardware recommendation for small form factor, noiseless, server
> What exactly is "good" with OpenBSD? I summarize the issues in my last email > So again, what is "slow"? The machine running OpenBSD. Compared to similar ThinkCenters I have (m73 Tiny and m92 Tiny). Also a Raspberry Pi 3 (running OpenBSD at lowest freq). It seems not to be the SSD disk because the "slowness" is present when writing to MFS mounts. > 14 Watts for compilation or just idling? Just at idle. Granted OpenBSD tends to run quite hot compared to alternatives it still seems to draw more than the m73 and m93p. > What issues? I mention them in the last email > Might be, but you didn't checked by tests. Yes, of course you have to > use the same "C program" as before. I tested against different operating systems and different hardware. As mentioned there is definitely something up with this combo but I haven't had time to explore further. Hence my general note to avoid this machine if people can for now (if they want something guaranteed working). The C program can be as simple as compiling "Hello World" to exhibit the issue. Takes about 15 seconds to compile "Hello World". It doesn't need to be a "test" to suspect things aren't quite right here. > I suspect something different, I guess it is from the black / red > combination of the case colors. This is a broken combination and a > dangerous one in art and design. The m73 and m92 have similar case colors. So it is definitely not that ;)
Re: Hardware recommendation for small form factor, noiseless, server
> Second-hand Lenovo M710q tiny with a wifi-card could also work: > https://dmesgd.nycbug.org/index.cgi?do=view=5296 A quick note that the slightly older M625q (with an AMD processor) isn't quite so good with OpenBSD. It runs overly slow and I have yet had time to figure out why. Interestingly, even on apm -H it takes longer to compile a C program than a Raspberry Pi 3. It also takes 14 Watts so the power management isn't quite there yet. These issues aren't present with Linux or FreeBSD. It was ~£30 and completely fanless, so will almost be the perfect hardware for a home server once these issues can be resolved. In short, the M710q with Intel processor might be the better choice. I suspect it is to do with the pstate stuff that the issues are arrising from. Karsten
pkg_bundle - Create "relocatable" package bundles on OpenBSD
Hello there, I personally disliked when a large software package needed to spam my /usr/local with dependencies. At the same time I quite liked how Solaris had separate prefixes for different software collections (i.e /usr/sfw, /opt/csw, /usr/csw, etc). So as a compromise, I developed* pkg_bundle[1] which basically works with the existing OpenBSD compiled package infrastructure to fetch and apply "tweaks" to ensure packages can run when encapsulated within a simple directory that can be moved anywhere around the system. For example /opt/gimp, /home/kpedersen/libreoffice, etc. The following is a list of software currently tested because I regularly use them myself. - blender - chromium - dia - firefox - gcc, g++, gdb, gmake - gimp - git - libreoffice - vlc - wpa_supplicant However do note that only OpenBSD 7.3 is tested. When I get to 7.4 once it is released, it will likely require an additional set of tweaks. From past experiences, this tends to be fairly minor and I just do them as I encounter them day to day. The whole setup is fairly flexible to add new software as needed and can even work out of the box with many packages. Very few require patching of the binary (unveil/pledge, icu, blender, etc). Usage should be pretty simple (create bundle, copy to (i.e) /opt, run): $ pkg_bundle libreoffice # cp -RP libreoffice /opt/office $ /opt/office/libreoffice (You can also run bin/pkg_bundle straight out of its tarball, no installation needed). I perhaps don't recommend using this for *all* software. However you might want to consider it for some of the bigger packages that you only plan to use periodically. I hope someone might find this useful and would be very interested in hearing feedback. Not many people seem to take this approach. Personally I find it alleviates my general dislike of large software packages. Best regards, Karsten *I really just cleaned up a bunch of ratty scripts I had cobbled together over the years (probably from before 5.x). [1] https://github.com/osen/pkg_bundle
Some framebuffer related questions
Hi there, I have been working on a small library to allow drawing directly to the framebuffer, similar to FreeBSD's old VGL library. Including keyboard handling and in the future I will tackle sound too. I have made a quick port of the GNUBoy gameboy emulator as well as some debug programs here: https://gitlab.com/osen/openbsd_drmfb_gnuboy I have implemented this currently using the DRM framebuffer via libdrm but I am also in the early stages of using wsconsctl/mmap and the framebuffer provided by efifb for some platforms which is working well so far (and the code is so much nicer than libdrm). Just a few questions: 1) From wsdisplay(4) manpage, what is the difference between WSDISPLAYIO_MODE_MAPPED and WSDISPLAYIO_MODE_DUMBFB? Both seem to work by mmap'ing the filedescriptor. 2) When I do mmap of the i.e /dev/ttyC0 file descriptor, I use an offset of 0, so I am not sure where width/height is stored?, I am obviously missing something). Where does the separate ioctl call of WSDISPLAYIO_GINFO get this information? 3) I understand that vgafb(4) exists on macppc and sparc64 but can the vga(4) only do text-mode? Currently I can get a framebuffer on: intel via inteldrm (libdrm) amd via amdgpu/radeondrm (libdrm) raspberry pi via efifb (libdrm) nvidia with EFI via efifb (wsdisplay, mmap) nvidia with BIOS... ? I suppose the way forward for this one will be to pick apart vesafb from Xorg but I was hoping there might be something already in place (admittedly it isn't a common use-case). Any info would be greatly appreciated. That is probably enough questions for now :) Many thanks, Karsten
Re: OpenCV on 6.9 can't open camera
> I'd appreciate anyone's thoughts on fixing this! Not sure if this is a solution for you (unless you want to faff with creating some minimal Python bindings) but I hacked at the OpenBSD /usr/X11R6/bin/video source code to create a quick standalone C API to be used as a library. Yes, it is probably not so portable as OpenCV but it is much lighter in terms of dependencies. openbsd_cam.h [https://pastebin.com/1rDpFMR4] openbsd_cam.c [https://pastebin.com/kuv3KhCX] (Original program: https://cvsweb.openbsd.org/xenocara/app/video/video.c) I also chucked in some decoding so it basically provides you now with an array of bytes referring to RGB pixels. Best regards, Karsten
Re: chroot x11 via Xephyr
> > I tried this " doas mv /tmp/.X11-unx/x1 /chroot/test/tmp/.X11-unix/ " > The stdout was " Operation not Permitted". > Can I just confirm that the path was correct? It looks like you have a typo ".X11-unx". Also, does the destination directory also exist? "/chroot/test/tmp/.X11-unix/". Depending on your chroot creation scripts, you might not have this yet. Now, what I can't quite recall (and unable to test on my current setup) is if it works moving across a different partition (such as /tmp, /usr, /, ...)
Re: chroot x11 via Xephyr
> > DISPLAY=:1 is short hand for connecting via the Unix socket > "/tmp/.X11-unix/X1". > > That will only works if both the X server and applications run in > the same base filesystem. > > If you chroot the application and not Xephyr, then the application > cannot found the unix socket. > It is worth noting that you can move (not copy) UNIX sockets (again, so long as they are on the same filesystem). So, once Xephyr has started up, you can move the socket from "/tmp/.X11-unix/X1" into "$CHROOT/tmp/.X11-unix/X1" and then your chroot application can access it.
Re: Remote wipe software
> Thanks for your response, a lot to think about sure. I suppose having > some sort of phone home daemon running to know whether or not to dd > itself is probably the best way to at least somewhat destroy itself in a > disaster scenario As a note, it seems that dd on an SSD is not so effective due to the wear balancing algorithm. Instead the "ATA Secure Erase" command should be used (of course you have to trust that the SSD vendor has implemented that correctly in the ROM / hardware).
