I am also @[email protected]
I could have said it better.
I mean compressor as half of a compression/decompression algorithm. The better way I should have worded it is: when you apply machine learning to a compression problem, you can do it lossless…your uncompressed output will be identical to the input, every time.
“NNCP” is a good search term to learn more, specifically about how this works.
This is not new knowledge and predates the current LLM fad.
See the Hutter prize which has had “machine learning” based compressors leading the ranking for some time: http://prize.hutter1.net/
It’s important to note when applied to compressors, the model does produce a code (aka encoding) that exactly reproduces the input. But on a different input the same model is unlikely to produce an impressive compression.
Just switch to the F-Droid version.
Better: make sure all the apps you use come from F-Droid
“Starch based” plastic is just a way to greenwash PLA.
Just because the C, H, and O originally came from starch, does not automatically make the chemically synthesized product safe.
They do this to juice the gross margin number and make the auto business appear more profitable.
Haha…yes fair enough. I changed the truck’s oil.
TSLQ
But, I don’t think it’s smart. Holding this for more than a day or two is irresponsible. You capture more risk on the up days then you will gain on the down days of the underlying ticker.
Instead, invest in a business you expect to grow. Just ignore the failing ones.
Everything’s computer
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?)
Thanks for replying, instead of just downvoting!
I think the bloat is not (primarily) in the end users experience, but in the extra code that the nginx maintainers must now continue to support, test, etc on an ongoing basis, which is not core to its function as a http server and proxy.
To me, this change goes against the Unix philosophy of simplicity, modularity, and the idea that programs should do one thing well.
Nginx should not contain logic that is not expressly related to serving or proxying web requests. The content it serves is up to the end user.
If we accept this change, should they also provide localized versions of all the error pages, too? I’m happy if their responsibility ends at just serving the content I provide.
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.
Visual Studio has these issues daily.
Ten years ago VS was awesome. In the last 2 years, all they added is AI crap and every other feature got more buggy.