Terry Davis' TempleOS Brutal Take Down of Linus Torvalds
Terry Davis Old Archive
AI-assisted summary of Terry Davis' TempleOS Brutal Take Down of Linus Torvalds — original source. Check the original for full context.
Source published:
Key ideas
- Terry Davis contrasts Linux and TempleOS using a vehicle metaphor: Linux is an over-engineered 20-gear semi-truck trapped in 1970s mainframe paradigms, while TempleOS is a lightweight motorcycle built for the raw, unprotected simplicity of a modern Commodore 64. (0:00)
- TempleOS establishes a strict hard cap of 100,000 lines of code with zero third-party dependencies, allowing the entire operating system (~50,000 lines across kernel and compiler) to recompile from source in roughly one second without linkers or makefiles. (4:59)
- By executing entirely in Ring 0 with identity-mapped memory and capping executable code to the lowest 2 GB, TempleOS performs 4 to 4.5 million task context switches per second and uses compact 5-byte relative 32-bit call instructions. (12:17)
- Davis rejects modern time-sharing and complex multi-tasking schedulers, designing TempleOS around a deterministic master-slave multi-core model explicitly tailored to push maximum CPU graphics and execution throughput for a single application at a time. (15:25)
Detailed notes
## Background This video was published on YouTube by the Terry Davis Old Archive channel on July 19, 2017. According to the description, the channel archives old videos created by Terry A. Davis before he deleted his original channel, crediting Vincent Canfield for preserving the footage. The page also provides links to other automated archive mirrors, Terry's official website, and a Vice Motherboard article covering his life as a programmer.
## TL;DR In this technical monologue, Terry Davis critiques modern operating systems, contrasting the design philosophy of Linux with his own creation, TempleOS. Davis argues that modern operating systems are weighed down by decades-old mainframe concepts such as complex file permissions, memory swapping, and sprawling multi-million-line codebases. Drawing an analogy between Linux as an unwieldy semi-truck and TempleOS as an uninhibited motorcycle, he champions a radical return to single-user Commodore 64 simplicity through identity-mapped Ring-0 execution, deterministic multi-core processing, and a strict 100,000-line code cap. He defends idiosyncratic engineering choices like a 2 GB code memory limit to optimize x86-64 instructions and demonstrates that stripped-down architecture delivers millions of context switches per second without academic abstraction.
## Atmosphere & style The presentation carries the unmistakable intensity of a lone digital artisan delivering an unscripted, defensive manifesto from his desktop. Davis speaks with raw, combative conviction, fluidly alternating between granular architectural breakdowns and barbed attacks against mainstream software culture. The mood feels intimate, erratic, and deeply defiant, pulling the viewer straight into the mind of an isolated genius determined to prove that simplicity outshines the entire computing establishment.
## Bulletin - [00:00](https://www.youtube.com/watch?v=gBE6glZNJuU&t=0s) Terry Davis contrasts Linux and TempleOS using a vehicle metaphor: Linux is an over-engineered 20-gear semi-truck trapped in 1970s mainframe paradigms, while TempleOS is a lightweight motorcycle built for the raw, unprotected simplicity of a modern Commodore 64. - [04:59](https://www.youtube.com/watch?v=gBE6glZNJuU&t=299s) TempleOS establishes a strict hard cap of 100,000 lines of code with zero third-party dependencies, allowing the entire operating system (~50,000 lines across kernel and compiler) to recompile from source in roughly one second without linkers or makefiles. - [12:17](https://www.youtube.com/watch?v=gBE6glZNJuU&t=737s) By executing entirely in Ring 0 with identity-mapped memory and capping executable code to the lowest 2 GB, TempleOS performs 4 to 4.5 million task context switches per second and uses compact 5-byte relative 32-bit call instructions. - [15:25](https://www.youtube.com/watch?v=gBE6glZNJuU&t=925s) Davis rejects modern time-sharing and complex multi-tasking schedulers, designing TempleOS around a deterministic master-slave multi-core model explicitly tailored to push maximum CPU graphics and execution throughput for a single application at a time.
## Key takeaways - [00:00](https://www.youtube.com/watch?v=gBE6glZNJuU&t=0s) Linux remains conceptually constrained by 1970s mainframe requirements, such as managing 2 MB of RAM across 100 simultaneous users with strict multi-user permissions and crash prevention. - [00:00](https://www.youtube.com/watch?v=gBE6glZNJuU&t=0s) The design goal of TempleOS is to recapture the spirit of the Commodore 64, treating the user as an active programmer-developer with direct hardware and graphics access. - [02:44](https://www.youtube.com/watch?v=gBE6glZNJuU&t=164s) Modern computing has abundant gigabytes of RAM, rendering disk swapping and virtual memory thrashing an unacceptable failure rather than a useful conservation technique. - [02:44](https://www.youtube.com/watch?v=gBE6glZNJuU&t=164s) TempleOS loads entire files directly into memory instead of relying on legacy UNIX-style pipeline streaming and buffer chunks. - [04:59](https://www.youtube.com/watch?v=gBE6glZNJuU&t=299s) Scaling downward yields non-linear architectural benefits, eliminating the need for linkers, make utilities, and separate header declarations in favor of chained `#include` files. - [08:56](https://www.youtube.com/watch?v=gBE6glZNJuU&t=536s) Restricting code memory to the lowest 2 GB is an intentional x86-64 optimization that allows 5-byte `CALL REL32` instructions rather than bloated 13-byte indirect absolute calls. - [12:17](https://www.youtube.com/watch?v=gBE6glZNJuU&t=737s) Operating entirely in Ring 0 with an identity-mapped address space avoids memory map swaps and privilege transitions, enabling 4 to 4.5 million context switches per second. - [12:17](https://www.youtube.com/watch?v=gBE6glZNJuU&t=737s) Task switching in TempleOS is measurably faster than reading a single hardware I/O port, which takes roughly one microsecond via x86 `IN` and `OUT` instructions. - [15:25](https://www.youtube.com/watch?v=gBE6glZNJuU&t=925s) Davis rejects multi-user multitasking trade-offs, prioritizing running a single multi-threaded application at peak performance over juggling multiple competing consumer games. - [17:47](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1067s) TempleOS eliminates the distinction between processes and threads, treating all execution units as tasks within a shared memory map managed by a lightweight round-robin scheduler. - [17:47](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1067s) Academic computer science is criticized for admiring and producing artificial complexity in journals to project prestige rather than pursuing elegant simplicity. - [21:53](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1313s) TempleOS implements a deterministic master-slave SMP architecture, running primary logic on Core 0 and explicitly dispatching parallel workloads across secondary cores to avoid dynamic scheduler frame drops. - [21:53](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1313s) Unlike Linux and mainstream OSes that offload graphics to the GPU, TempleOS renders multi-threaded real-time graphics directly on the CPU across all eight cores. - [24:19](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1459s) A compact 100,000-line codebase functions cleanly with a single global symbol table, concise variable naming, and global variables, avoiding deep hierarchical namespace abstractions. - [24:19](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1459s) Modern programming curricula are faulted for insulating students from raw memory management, assembly code, and pointers instead of teaching low-level fundamentals like `malloc` and `free`.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=gBE6glZNJuU&t=0s) Mainframe vs. Commodore 64: Vehicles of Computing
Terry Davis opens with a spontaneous lecture contrasting the core design philosophies of Linux and TempleOS. In his view, Linux is structurally trapped in the paradigm of a 1970s mainframe, an architecture designed around extreme resource scarcity—such as two megabytes of RAM shared across a hundred simultaneous users—where system crashes were completely intolerable and had to be avoided at all costs. In stark contrast, Davis explains that his operating system aspires to recreate the spirit of the Commodore 64, an intimate personal machine whose user manual directly taught hobbyists how to construct sprite graphics out of raw binary data and write quick BASIC programs.
```mermaid flowchart TD accTitle: Operating System Vehicle Analogies accDescr: Metaphorical comparison of Linux as a semi truck, Windows as a car, and TempleOS as a motorcycle. subgraph Analogy["Vehicle Analogies"] L["Linux: The Semi-Truck<br/>(20 gears, file permissions, multi-user overhead)"] W["Windows: The Passenger Car<br/>(Standard consumer product)"] T["TempleOS: The Motorcycle<br/>(Raw speed, no side airbags, crashes if you lean over)"] end ```
To illustrate this gulf in thinking, Davis deploys his signature vehicular metaphor: Linux is an industrial semi-truck, Windows is an everyday passenger car, and TempleOS is a lightweight motorcycle. A semi-truck has twenty gears and will never serve well as a passenger vehicle, just as elaborate multi-user file permissions have no business being forced into a consumer product. While Linux users remain deluded by enterprise complexity, Davis embraces the directness and inherent danger of a motorcycle, pointing out that an operating system stripped of safeguards does not bother with protective padding. As Terry Davis puts it: “Linux is the semi, Windows is a car, TempleOS is a motorcycle.” He accepts that a user can easily crash TempleOS if they make a mistake, remarking that if you lean over too far on a motorcycle it wipes out, so the straightforward remedy is simply not to do that.
- **Mainframe roots**: 1970s mainframes managed roughly 2 MB of RAM across 100 users, requiring absolute crash prevention. - **Commodore 64 heritage**: Designed for single-user creativity, sprite manipulation using binary numbers, and simple BASIC scripting. - **The vehicle metaphor**: Linux represents a 20-gear semi-truck burdened by file permissions; Windows is a passenger car; TempleOS is a bare-bones motorcycle without safety nets.
---
[02:44](https://www.youtube.com/watch?v=gBE6glZNJuU&t=164s) Fighting the Last War: Memory, Swapping, and File Loading
Davis argues that mainstream software engineers constantly handicap themselves because they are endlessly “fighting the last war” by blindly copying mainframe concepts from forty years ago. When a computer only possessed two megabytes of RAM for a hundred users, virtual memory and disk paging were absolute necessities. On modern workstations equipped with gigabytes of memory, however, paging code out to disk is so prohibitively slow that any user whose system begins thrashing immediately considers it an unacceptable failure. Davis clarifies that while he is not attacking hardware memory paging itself, traditional virtual memory swapping simply has no place on modern personal computers.
This divergent philosophy fundamentally changes how TempleOS approaches I/O and resource consumption. In a mainframe or Linux environment, a compiler must walk on eggshells to avoid hogging memory, relying on UNIX pipelines that stream tiny chunks of data sequentially through buffers. Because modern machines have abundant RAM, Davis rejects chunk-based streaming in favor of reading entire files into memory all at once, maximizing simplicity and aesthetics. As Terry Davis notes: “If you ever do cause it to start swapping to disk, it's way too slow to be acceptable.” For him, clean, beautiful source code takes precedence over backward-looking conservation mechanisms.
---
[04:59](https://www.youtube.com/watch?v=gBE6glZNJuU&t=299s) Scaling Down: The User-Developer and 100,000 Lines of Code
Davis asserts that his highest ideal is minimizing lines of code (LOC), establishing a hard limit of 100,000 lines for the entire TempleOS codebase and completely outlawing third-party libraries. His operating system is tailored strictly for the “user-developer”—a term he considers trademarking—emulating the Commodore 64 era where the computer booted into a 20 KB ROM and the person sitting at the keyboard was simultaneously the operator and the programmer. Rather than catering to enterprise software vendors, Davis prefers to cut out third-party developers entirely to protect the purity of the user-developer experience.
Modern software developers, Davis argues, have been thoroughly “Jedi mind-tricked” by an obsession with scaling up to massive proportions. He points out that scaling is a two-way street, and scaling downward produces non-linear benefits that dramatically simplify an operating system. Because TempleOS scales down, it eliminates the need for linkers, make utilities, and header separation. An entire project is defined simply by chaining code files together with `#include` statements. Demonstrating live on his screen, Davis taps a single shortcut key to execute a full system recompile from scratch:
```mermaid flowchart LR accTitle: TempleOS Compilation Architecture accDescr: Shows the compilation pipeline from source files directly to binary execution without linkers. subgraph Build["TempleOS Streamlined Build"] direction LR Src["Code Files<br/>(#include source directly)"] --> K["Kernel<br/>(~20,000 LOC)"] Src --> C["Compiler<br/>(~20,000 LOC)"] K & C --> JIT["Total ~50,000 LOC<br/>Compiles in ~1 Second"] JIT --> Boot["Adam Directory<br/>Compiled at Boot / JIT"] end ```
As Terry Davis emphasizes regarding the industry's architectural blind spot: “Guess what, scaling works both ways: you can get bigger, what happens if you look the other direction and you scale down?” In roughly one second, TempleOS recompiles roughly 50,000 lines of code—consisting of a 20,000-line kernel and a 20,000-line compiler—with the remainder handled via just-in-time compilation, starting with the root "Adam" task named after Adam and Eve.
- **Code limit**: Strict cap of 100,000 lines of code for the entire operating system, with zero third-party dependencies. - **User-developer model**: Direct lineage from the Commodore 64's all-in-one ROM environment. - **Build system simplicity**: No linker, no `make` utility; code files directly `#include` other implementation files. - **Compilation speed**: Compiles ~50,000 lines of code (20,000 kernel + 20,000 compiler) in approximately one second flat.
---
[08:56](https://www.youtube.com/watch?v=gBE6glZNJuU&t=536s) The 2GB Limit, x86-64 CALL Instructions, and Arrogant Engineers
Davis addresses the frequent criticism he receives for imposing a 2 GB code memory limit on a 64-bit operating system. Programmers conditioned by corporate computing scoff at this ceiling, reflexively mocking Bill Gates' apocryphal claim that 640 KB of memory should be enough for anyone and insisting that memory caps are always foolish. Davis fires back that people who cannot define "what is enough" are mere sheep rather than shepherds, pointing out that Linux itself is an unoriginal rehash of UNIX. He compares modern arrogant engineers to a hypothetical Westinghouse electrical engineer in 1900 mocking Nikola Tesla, or two thousand anonymous physicists at CERN walking around with unearned superiority without ever pioneering an original breakthrough of their own.
Technically, the 2 GB code limit is an intentional optimization for binary size and execution speed. In x86-64 architecture, there is no direct 64-bit relative `CALL` instruction. Calling an arbitrary 64-bit absolute address requires loading the destination into a register and executing an indirect call, which bloats the instruction footprint:
| Call Strategy | Assembly Sequence | Total Size | |:--- |:--- |:--- | | **TempleOS (Lowest 2 GB)** | `CALL REL32` | **5 bytes** | | **Standard 64-bit Far Call** | `MOV RAX, imm64` (10 bytes) + `CALL RAX` (3 bytes) | **13 bytes** |
By restricting all executable code to the lowest two gigabytes of the address space, TempleOS can exclusively use the compact 5-byte relative 32-bit call instruction (`CALL REL32`), resulting in tighter cache utilization and faster performance. As Terry Davis remarks about conventional programmers' knee-jerk mockery: “So when I say 2 gig, they say, 'We're not that stupid, we know it's never enough.'”
---
[12:17](https://www.youtube.com/watch?v=gBE6glZNJuU&t=737s) Port I/O, Instant Context Switches, and Ring-0 Simplicity
To demonstrate the raw efficiency of his architecture, Davis walks through a low-level hardware driver loop waiting for a disk controller to become ready. The driver executes an `IN` instruction against an I/O status port and checks the busy flag:
``` // TempleOS hardware polling pattern if (status & BUSY) Yield(); ```
Davis explains the performance math: an x86 `IN` or `OUT` instruction takes approximately one microsecond (translating to a baseline ceiling of roughly one million operations per second). In Linux, relinquishing execution via a task yield incurs massive overhead because the kernel must switch privilege levels, reload register state, and swap page tables by reloading the `CR3` register. TempleOS, however, runs entirely in Ring 0 with an identity-mapped address space: tasks never alter memory mappings or transition privilege rings.
```mermaid flowchart TD accTitle: Context Switch Overhead Comparison accDescr: Contrasts heavy Linux context switches against the lightweight identity-mapped TempleOS yield. subgraph LinuxSwitch["Linux Context Switch (High Overhead)"] L1["Change Privilege Level"] --> L2["Reload CR3 (Change Memory Map)"] L2 --> L3["Save/Restore Extensive Task State"] end subgraph TempleOSSwitch["TempleOS Context Switch (Ring-0 Identity-Mapped)"] T1["No Memory Map Change (Identity Mapped)"] --> T2["No Privilege Transition (Always Ring 0)"] T2 --> T3["Fast Register Swap (~4-4.5M Switches/Sec)"] end ```
Davis claims that TempleOS can perform between 4 and 4.5 million task context switches per second, meaning switching tasks in software is actually faster than reading a single hardware I/O port. As Terry Davis states: “I can save tasks and switch tasks faster than I can read a port.” To prove his assertion, he runs a live benchmark on his screen containing an unconstrained `while (TRUE) Yield();` loop, observing task switch counters soar into the millions even while background video capture is active.
- **Port I/O baseline**: Hardware `IN`/`OUT` instructions take roughly 1 µs (~1,000,000 ops/sec). - **Linux context penalty**: Mandates privilege boundary crossings, `CR3` page table reloading, and full memory map switches. - **TempleOS speed**: Identity mapping and permanent Ring-0 execution allow between 4,000,000 and 4,500,000 task switches per second.
---
[15:25](https://www.youtube.com/watch?v=gBE6glZNJuU&t=925s) SMP Architecture, Trivial Solutions, and Single-App Mastery
Davis critiques the multi-user, multi-tasking priorities of modern operating systems, arguing that Linux developers “would move heaven and earth just so that you can play two video games at once.” He compares this engineering over-complication to the famous fable of NASA spending millions to invent a space pen while Soviet cosmonauts simply used a pencil. While acknowledging the pencil story is technically a myth, he points out that it embodies the design philosophy behind his company, which he intentionally named *Trivial Solutions*. By dropping CPU privilege rings and complex task isolations, TempleOS embraces straightforward solutions over over-engineered safety nets.
Davis then diagrams the symmetric multiprocessing (SMP) model in TempleOS across his eight CPU cores. The system hierarchy begins with the master "Adam" task, which spawns executive set-tasks for each core. On Core 0, the machine runs the Window Manager (responsible for painting screen frames), the frame grabber, the active user task, and Adam itself. The design does not attempt to juggle dozens of competing consumer applications; instead, it is explicitly built to dedicate the machine to a single primary application at a time—such as an intensive multi-threaded game—mirroring how enthusiasts pushed the Commodore 64 to its absolute limits. As Terry Davis summarizes his operating philosophy: “Basically, you're going to run one application at a time, and it might be multi-threaded on this.”
[17:47](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1067s) Simplicity in Task Scheduling and the Rejection of Overcomplicated Mainframes
Terry Davis explains that in TempleOS, everything operates within the exact same memory map, eliminating any distinction between processes and threads—they are simply tasks. When a task waits for disk access, it performs a simple yield. Terry expresses frustration with conventional computer science theory, dismissing critics who label this approach blocking as “little brainwashed book people” and comparing his situation to Nikola Tesla being ridiculed by uninspired academics. He asserts that modern operating systems are stuck fighting the last war by building 1970s-style mainframes, whereas he is adapting to a completely modern computing reality.
```mermaid flowchart TD accTitle: TempleOS Task Scheduling Loop accDescr: Round-robin scheduler evaluating tasks based on wait states.
subgraph Scheduler ["Round-Robin Task Ring"] T1["Task 1 (Running)"] T2["Task 2 (Waiting for Disk)"] T3["Task 3 (Waiting on Message/Time)"] end
T1 -->|"Yields CPU"| T2 T2 -->|"Swap in, check ready, swap out (~0.25 µs)"| T3 T3 -->|"Permanently skipped until event triggers"| T1 ```
Terry deliberately uses a basic round-robin scheduler without task priorities. He argues that complicating code just to impress others is an academic sickness, stating: “Is it because I can't do priorities? No, it's because an idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple anyway.” He adds that people in academic journals write deliberately convoluted material so that others treat them like gods because no one can understand it.
- Tasks waiting for a message or a timer tick (jiffy) are swapped out permanently until the event arrives. - When waiting for input or disk reads, the scheduler cycles through tasks; a context check costs roughly a quarter of a microsecond. - For five tasks, cycling takes about one microsecond, whereas on an operating system with a hundred tasks, this model would become problematic. - Terry clarifies that high-concurrency time-sharing is irrelevant to his architecture: “I'm making a Commodore 64; I don't do sharing.” - The operating system is explicitly architected around a single video game running across multiple threads, rather than trying to juggle multiple heavy desktop games simultaneously.
---
[21:53](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1313s) Multi-Core Architecture: Master-Slave vs. Linux
Addressing symmetric multiprocessing (SMP), Terry responds to Linus Torvalds’ remark that multi-core processors are overrated. TempleOS implements a strict master-slave paradigm: all primary application logic executes on Core 0, and whenever the application requires parallel computing power, it explicitly spawns slave tasks directly onto specific secondary cores.
Terry highlights his flight simulator demo running across all eight CPU cores to show why Linux’s scheduling model fails real-time graphics. Linus Torvalds offloads parallel graphics processing entirely to the GPU, leaving the CPU largely idle on a single core. In contrast, TempleOS computes graphics purely on the CPU. Under a conventional dynamic scheduler, assigning seven graphics tasks across cores risks clumping two tasks onto a single core, cutting frame rates in half from 30 frames per second down to 15 frames per second. Because TempleOS allows deterministic direct core targeting, Terry insists it utilizes multi-core far more effectively for dedicated single applications.
> “TempleOS can only run one application faster; Linux can run two applications faster—their geniuses, okay.”
---
[24:19](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1459s) Scaling Down: Single Namespaces, Short Variables, and Low-Level Mastery
Terry shifts to codebase size and software ergonomics, arguing that systems do not merely degrade when scaled up—they actually become significantly better when scaled down. While enterprise systems require deep hierarchies, packages, and namespaces to manage code bloat, a compact operating system needs only a single, flat global symbol table. Terry inspects his own symbol table in the editor to illustrate this elegance, contrasting TempleOS’s 100,000-line codebase against the tens of millions of lines comprising Linux, which he accuses Linus of bloating purely to intimidate others.
```mermaid flowchart LR accTitle: Architectural Scale Comparison accDescr: Contrasting TempleOS's compact model with conventional multi-million line kernels.
subgraph ScaledDown ["TempleOS Philosophy"] A["100,000 Lines of Code"] --> B["Single Namespace"] B --> C["Short Variable Names & Globals"] C --> D["Direct Hardware / CPU Control"] end
subgraph Bloated ["Modern OS Philosophy"] E["20–50 Million Lines of Code"] --> F["Complex Hierarchical Namespaces"] F --> G["Overly Verbose Variable Names"] G --> H["Abstracted Runtimes & Safety Nets"] end ```
He rejects modern dogmas that forbid global variables and short identifier names. In small programs—such as a 180-line game a kid might write—global variables and concise names are the correct, natural approach. Terry lambasts modern pedagogical trends and high-level language abstractions that insulate students from memory mechanics:
> “Nobody knows what a pointer is, nobody knows what assembly code is, they've all been so confused by the liberals trying to make it easy for them.”
- Terry demands that programmers “just man up and learn what `malloc` and `free` are” rather than relying on safety wrappers that conceal hardware reality. - While he shares Linus Torvalds’ preference for raw systems programming over heavy academic abstractions, Terry notes he prefers C++ extensions (as in his dialect, HolyC) while retaining raw C simplicity. - He notes an industry-versus-academia cultural rift: academia publishes discoveries to seek prestige, whereas private industry hoards breakthroughs as trade secrets. - Terry champions concise naming conventions across his APIs—such as compact 64-bit datetime types—concluding that short, direct names make an operating system easy to navigate and completely understandable in the spirit of the Commodore 64.
## Notable quotes > [00:00](https://www.youtube.com/watch?v=gBE6glZNJuU&t=0s) Linux is the semi, Windows is a car, TempleOS is a motorcycle. — Terry Davis
> [17:47](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1067s) I'm making a Commodore 64; I don't do sharing. — Terry Davis
> [12:17](https://www.youtube.com/watch?v=gBE6glZNJuU&t=737s) I can save tasks and switch tasks faster than I can read a port. — Terry Davis
> [24:19](https://www.youtube.com/watch?v=gBE6glZNJuU&t=1459s) Nobody knows what a pointer is, nobody knows what assembly code is, they've all been so confused by the liberals trying to make it easy for them. — Terry Davis
## Mentioned Terry Davis, Linus Torvalds, TempleOS, Linux, Windows, Commodore 64, UNIX, Bill Gates, Nikola Tesla, Westinghouse, CERN, NASA, Trivial Solutions, HolyC, Vincent Canfield
## Video description This is an archive channel dedicated to hosting all of Terry A. Davis' old videos before he deleted his channel.
Full credit for saving these goes to Vincent Canfield https://vc.gg/templeos/
I just upload them to YouTube.
Other archive channels that upload from his website:
https://www.youtube.com/channel/UC7XZSFX4YhqzXbt513F2sEA (this one is fully automated)
https://www.youtube.com/channel/UC2JvKvUmoWdtE55ta15a3tg
https://www.youtube.com/channel/UCEPEqMr199q3iRTwToIotVA
Vice article on Terry A Davis: https://motherboard.vice.com/en_us/article/wnj43x/gods-lonely-programmer
Terry's official website: http://www.templeos.org/
[Source](https://www.youtube.com/watch?v=gBE6glZNJuU)