Bootstrap knowledge of LLMs ASAP. With a bias/focus to GPT.
Avoid being a link dump. Try to provide only valuable well tuned information.
Neural network links before starting with transformers.
# prefetch wstunnel's master for nix, and store the result in wstunnel.json | |
nix-prefetch-git https://github.com/erebe/wstunnel > wstunnel.json | |
# and build the wstunnel-tarball with nix, using the haskell.nix infra structure as above (see default.nix) | |
nix build \ | |
-f default.nix \ | |
rpi64-musl.wstunnel-tarball \ | |
-o rpi64-musl-wstunnel-tarball | |
--arg wstunnel-json ./ws-tunnel.json |
You'll probably be working with a single smartcard, so you'll want only one primary key ( |
#! /usr/bin/env python3 | |
"""Fixing bluetooth stereo headphone/headset problem in debian distros. | |
Workaround for bug: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1577197 | |
Run it with python3.5 or higher after pairing/connecting the bluetooth stereo headphone. | |
This will be only fixes the bluez5 problem mentioned above . | |
Licence: Freeware |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t