| """ | |
| The most atomic way to train and run inference for a GPT in pure, dependency-free Python. | |
| This file is the complete algorithm. | |
| Everything else is just efficiency. | |
| @karpathy | |
| """ | |
| import os # os.path.exists | |
| import math # math.log, math.exp |
This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
| { | |
| "log": { | |
| "loglevel": "warning" | |
| }, | |
| "routing": { | |
| "domainStrategy": "IPIfNonMatch", | |
| "rules": [ | |
| { | |
| "type": "field", | |
| "ip": [ |
I have a Linux virtual machine inside a customer's private network. For security, this VM is reachable only via VPN + Citrix + Windows + a Windows SSH client (eg PuTTY). I am tasked to ensure this Citrix design is secure, and users can not access their Linux VM's or other resources on the internal private network in any way outside of using Citrix.
The VM can access the internet. This task should be easy. The VM's internet gateway allows it to connect anywhere on the internet to TCP ports 80, 443, and 8090 only. Connecting to an internet bastion box on one of these ports works and I can send and receive clear text data using netcat. I plan to use good old SSH, listening on tcp/8090 on the bastion, with a reverse port forward configured to expose sshd on the VM to the public, to show their Citrix gateway can be circumvented.
I hit an immediate snag. The moment I try to establish an SSH or SSL connection over o
| #!/bin/bash | |
| # ============================================= | |
| # Created by: Richard Barrett | |
| # Date Created: 02/27/2020 | |
| # Purpose: Kube Auto Collector for Support Dump | |
| # Company: Mirantis | |
| # ============================================= | |
| # Documentation: | |
| # ======================================================================================== |
Historically, all memory on x86 architectures were equally accessibly by all CPUs on the system. This is an effective implementation, but there's increased bandwidth on the bus, and the more CPUs you have, the further away from the memory it is. This layout is called Uniform Memory Access.
Modern x86 architectures introuduce the concept of memory nodes (also referred to elsewhere as zones or cells), where new writes are associated with a CPU's memory node. The nodes are connected by a bus, so all the memory is still accessible via any CPU, but of course, we have faster memory access time for CPUs accessing local nodes.
When you have a virtualization layer on top, and you are scheduling workloads, you can take advantage of this by pinning processes to specific CPUs.
Currently in no particular order. Most of these are kind of ancient.
Where's all the modern documentation? So much of what I've turned up searching is other folks complaining about having few options beyond reading source code.
The OREILLY books, while dated, seem to be some of the best available. Note that these can be read with a 7-day trial. Do this! At least get through the introduction section and first chapter of each to see if it's what you're after.
So I needed to upgrade my home "web hosting" server from a Raspberry Pi 3b to something more flexible where I could even simulate a Raspberry Pi 3b given power. The new server hardware is now an Intel NUC i7 16GB / 250Gb SSD NVME. 😁
I order to accomplish this task I had to find a way to bridge the wireless interface which is the faster one on my actual home network setup.
I've also tried to mix the functionnality from another Rapsberry Pi (3b+ this time) who's acting as WLAN to LAN bridge. More details on this setup. But this was finally a bad idea and I was not able to make it work along the virtual network bridge created by libvirt or manually created... (I will explain why later)
The main difficulty was to use the DMZ IP address given by the router and route the traffic to the guest VM's.
