| 🍕 | https://brynet.ca/wallofpizza.html |
| Main account: | https://bsd.network/@brynet |
| 🍕 | https://brynet.ca/wallofpizza.html |
| Main account: | https://bsd.network/@brynet |
I could use some help, friends. I'd really appreciate sharing.
If you can help out with the occasional pizza, that would really mean a lot to me. Monthly gifts would take care of a lot of my financial stress/anxiety as well.
https://brynet.ca/wallofpizza.html
https://www.paypal.com/donate/?hosted_button_id=ZQJC48GUPB3UU&source=url
Progress: $360 / $2500 CAD (monthly goal)
If you aren't able help with PayPal, I have an Amazon .ca wishlist with some odds & ends, computer hardware: https://www.amazon.ca/hz/wishlist/ls/2E7N6O3GTI6JF?sort=custom
(Native SegWit): bc1qzkchnc25yeqt9p24edsu5ln0mvh8hqdzdznlk2
Not great timing, I know, but I'm thinking a Intel mini PC (e.g: N150, 11th Gen i5/i7) would work for my #OpenBSD testing & hacking, Any help towards this would be greatly appreciated.
https://www.paypal.com/donate/?hosted_button_id=ZQJC48GUPB3UU&source=url
https://www.amazon.ca/hz/wishlist/ls/2E7N6O3GTI6JF?sort=custom
If any of my past work on #OpenBSD, or my highlight posts here (or elsewhere) has been helpful, a small recurring monthly donation would be extremely appreciated.
In addition to funding open source projects you use, if you can, consider extending support to the individual contributors/developers personally who work on those projects, many are volunteers and even a small monthly contribution could mean the difference. 🫶
For those who may not know, #OpenBSD still runs on Motorola 88K machines, more specifically the LUNA family of 90's Unix workstations released by Japanese company OMRON. There's even SMP support (w/ weird configurations, like 3 CPUs).
https://www.openbsd.org/luna88k.html
Largely a passion project by Kenji Aoyama as these machines are not easy to come, especially outside of Japan. It's possible to install 7.8 (or a -current snapshot, to try out Miod's 88k gcc4 port!
) using nono, a full system emulator for LUNA machines.
https://www.pastel-flower.jp/~isaki/nono/ — (nono emulator, in OpenBSD ports/packages)
Hooray! Jonathan Gray (jsg@) has updated the drm(4) graphics drivers (inteldrm/radeondrm/amdgpu) in #OpenBSD -current to Linux 6.18.y/6.18.16
Thanks to the OpenBSD Foundation for sponsoring this work.
Previously #OpenBSD -current was tracking the 6.12.y/6.12.66 longterm support versions, with additional backports from mainline Linux. OpenBSD 7.8 shipped with drivers based on 6.12.50.
Heads up: The recent pledge(2) "tmppath" removal has been backported to #OpenBSD 7.7/7.8, and includes updated base system utilities as well as new -stable packages for software using pledge(2), such as web browsers.
https://www.openbsd.org/errata78.html#p015_tmppath
https://www.openbsd.org/errata78.html#p016_pledge_sysctl
https://www.openbsd.org/errata78.html#p017_tmppath
https://www.openbsd.org/errata78.html#p018_pledgepaths
Don't forget to run pkg_add -u before applying the kernel syspatch/errata to avoid errors with old binaries on the new kernel.
In addition to funding open source projects you use, if you can, consider extending support to the individual contributors/developers personally who work on those projects, many are volunteers and even a small monthly contribution could mean the difference. 🫶
Goodbye pledge "tmppath", hello unveil("/tmp", "rwc")!
Some observant #OpenBSD users may have noticed developers removing the pledge(2) "tmppath" promise from all base utilities that were using it along with a handful of ports, because this promise, well.. it kinda sucks, and it predates a much better solution: unveil(2).
More info & some backstory in Theo de Raadt's commit.
deraadt@ modified src/{sys,lib}/*: pledge "tmppath" goes away because it sucks. The history is kind of
sad: unveil(2) was invented by Bob Beck and myself because a couple of us struggled and couldn't expand the "tmppath" mechanism to general use.
unveil(2) ended up being kind of "upside down" different, and so we never deleted "tmppath" because the refactorings seemed complicated.
However over the last two weeks, we're removed all the "tmppath" in base pretty easily, and the 18 ports using it have also been fixed.
The majority of situations now use unveil "/tmp" "rwc", unveil "/" "r" or similar, and then pledge "rpath wpath cpath", and this is generally needed to satisfy the mkstemp(3) family of functions in libc.
Use of "tmppath" will now cause pledge(2) to return EINVAL. There is no backwards compatible way of mimic the behaviour correctly using kernel-internal unveil hackery.
Prompted by a report from David Leadbeater; and extensive conversations with beck and semarie.