I agree the arguments tend to be over complicated but I think Penroses argument is basically
>it is argued that the human mind cannot be computed on a Turing Machine... because the latter can't see the truth value of its Gödel sentence, while human minds can
And the debunk is that both Penrose and an LLM can say they see the truth value and we have no strong reason to think one is correct and the other is wrong. Either of both could be confused. Hence the argument doesn't prove anything.
I'm so glad that my hit-and-run post has been so useful. After seeing Fabien's blog post I did a quick search and it turns out that the solution has spread fairly broadly to other forums. My choice of 0x33 was arbitrary so makes a nice canary for seeing it spread out. I'm thrilled. Sharing experiences and solutions is so essential to learning. I've benefited enormously from the generosity of open source developers and communities and from individuals documenting pieces of their projects, glad to have raised the ocean a little in return.
My use case was (and remains) having a Xilinx Artix 7 FPGA in an external Thunderbolt 3 enclosure for testing the development of DSP accelerators using open source tooling. I didn't want to have the FPGA board inside the PC to be able to swap it to my laptop easily, because it produces a lot of heat, and so when I misused the PCIe soft core (litePCIe: https://github.com/enjoy-digital/litepcie/) it doesn't take down the OS. Being able to reload the FPGA and effectively hotplug the device has been very helpful.
Since I knew my issue was around hotplugging I searched for information around PCIe hotplugging and I think (it was two years ago...) that I found the answer from one of these two threads. Both mention the option of reserving PCIe addresses for hotplug busses as a workaround, and a workaround was all I needed.
dmesg and the various kernel logs are my first stop for any odd behavior on Linux. Especially with any state change to a device (plugging in, turning on, removing, reconfiguring etc) the kernel logs tend to give invaluable info.
I had already been looking at eGPU forums to choose the Thunderbolt 3 enclosure (ended up with the ORI-SCM2T3-G40-GY) and there were various discussions of hotplugging issues there, but I don't think I found the specific kernel options to fix it there.
For the string "pci=realloc,assign-busses,hpbussize=0x33"
`realloc`
Enable/disable reallocating PCI bridge resources if allocations done by BIOS are too small to accommodate resources required by all child devices.
assign-busses
[X86] Always assign all PCI bus numbers ourselves, overriding whatever the firmware may have done.
`hpbussize=nn`
The minimum amount of additional bus numbers reserved for buses below a hotplug bridge. Default is 1.
0x33 (decimal 51) is arbitrary, but large enough that I was unlikely to ever exhaust that address range even with a large number of devices chained together on the Thunderbolt bus. I think (though would have to check) that the address space does get exhausted with multiple hotplug cycles. I haven't hit that issue since I shutdown the computer close to daily to save power.
Sadly, there's no Segway, those things are expensive and I have a long wish list before reaching that point. Currently I'm saving up to get a microscope, I have a large box of RF integrated circuits that I'd like to do some show and tell with on Twitch. :) Also no unmarked 40% keyboard, RSI means I'm a total fanboy of the Microsoft Ergonomic keyboard and the Anker vertical mouse. Cheap and so comfortable. I have done some kernel compiling, mostly to learn more about kernel modules as I've been trying to make the learning curve and user experience of experimenting with FPGAs over PCIe easier. If anyone has some experience with DKMS and creating Debs I'd welcome a chance to chat. Ditto if there's any Debian maintainer with experience packaging kernel modules, I made some headway a while back to repackage linux-gpib but got stalled out on a few of the details of maintaining patches against the upstream.
No extra tooling, no symlinks, files are tracked on a version control system, you can use different branches for different computers, you can replicate you configuration easily on new installation.
I agree about the nuisance of creating DOM elements. innerHTML is OK if you’re doing static content, but for anything that needs to be dynamic (untrusted input, event handlers, etc.) I have a little tiny helper library that I carry around in my head and write into projects that need it:
const $T = text => document.createTextNode(text)
function $E(tag, props, kids) {
const elem = document.createElement(tag)
for (const k in props) {
elem[k] = props[k]
}
for (const kid of kids) {
elem.appendChild(kid)
}
return elem
}
(Add flourishes as necessary for things like optional arguments and allowing falsey kids.)
This isn’t as nice as JSX, but it makes a reasonably ergonomic API for quick little projects. Here’s what the example in the article would look like (admittedly it’s a bit easier to follow with syntax highlighting):
You can argue that the electronics themselves are not that interesting, or that they are overpriced. That may be true. But Lego's manufacturing quality and QA is legendary. The fact that these robotics kits are seamlessly compatible with the entire system opens up some really fun possibilities.
I would recommend visiting a fan exhibition when things get back to normal. The things people come up with are astounding. (https://www.youtube.com/watch?v=kFD2e3IxO_c is the readiest example I could find).
>it is argued that the human mind cannot be computed on a Turing Machine... because the latter can't see the truth value of its Gödel sentence, while human minds can
And the debunk is that both Penrose and an LLM can say they see the truth value and we have no strong reason to think one is correct and the other is wrong. Either of both could be confused. Hence the argument doesn't prove anything.