I am also @[email protected]
Cut a circle of plywood roughly the inner diameter of the pipe, glue it into the end of the pipe (or just snug it in if its a tight fit), then screw down through this into the bottom board.
Can just unscrew it and screw it somewhere else if needed. Can also unscrew it and leave it on a bench if you need to swap tools out.
Ph-trees can do range and closest queries across N dimensions very quickly. I have not used it for 1 dimension, but I’d imagine it would work fine.
Can you share sample code I can try or documentation I can follow of using an AMD GPU in that way (shared, virtualized, using only open source drivers)?
You really piqued my interest. I use docker/podman.
W/ an AMD graphics card, eglinfo on the host shows the card is AMD Radeon and driver is matching that.
In the container, without --gpus=all, it shows the card is unknown and the driver is “swrast” (so just CPU fallback).
To make --gpus=all work, it gives the error
docker: Error response from daemon: could not select device driver “” with capabilities: [[gpu]
I was doing a bad job searching before. I found that AMD can share the GPU, it just works a little differently in terms of how to launch the container. https://rocm.docs.amd.com/projects/install-on-linux/en/latest/install/amdgpu-install.html#amdgpu-install-dkms
But sadly my AMD GPU is too old/junk to have current driver support.
Anyways, appreciate the reply! Now I can mod my code to run on cheaper cloud instances.
(Note I’m an OpenGL/3D app developer, but probably OpenCL works about the same architecturally)
AFIK it’s only NVIDIA that allows containers shared access to a GPU on the host.
With the majority of code being deployed in containers, you end up locked into the NVIDIA ecosystem even if you use OpenCL. So I guess people just use CUDA since they are limited by the container requirement anyways.
That’s from my experience using OpenGL headless. If I’m wrong please correct me; I’d prefer being GPU agnostic.
I think the pine hobby panels will be fine structurally. I think you mean the ones that are a bunch of smaller pieces glued together. In using these I have found not all the glue joints are great, though.
But, I suspect its the glue in the plywood that might damage the saw. Glued up hobby panels will likely act the same.
Might want to pick up a cheap crosscut saw / general carpentry saw for utility cutting and save the nice pull saw four detail work.
I bet the people you work with are very happy to have you as a lead.
I’ve been in this scenario and I didn’t wait for layoffs. I left and applied my skills where shit code is not tolerated, and quality is rewarded.
But in this hypothetical, we got this shit code not by management encouraging the right behavior, and giving time to make it right. They’re going to keep the yes men and fire the “unproductive” ones (and I know fully, adding to the pile is not, in the long run, productive, but what does the management overseeing this mess think?)
They were just trying to make us smarter.
https://studyfinds.org/chewing-on-wood-brain-function-memory/
[kidding]
To be fair, if you give me a shit code base and expect me to add features with no time to fix the existing ones, I will also just add more shit on the pile. Because obviously that’s how you want your codebase to look.
I’m not sure why no one is direct linking it.
(the data looks incredibly incomplete)
Check out ibuildit.ca
He has made a vise from a screw jack, and has some videos of it in action.
While I’ve not built his vise, I have roughly followed his instructions for other projects, and I think he really suggests things that actually work (not just “content”)
Name and shame the brand!
The original post has 58k views, the correct information has 2k. That is the level of efficiency that site has in disseminating correct information.
Everything’s computer