John Carmack

@CliffCrosland PvE instead of PvP

from William James’s essay “The Moral Equivalent of War” from 1910, encouraging hard civic labor for the youth: > “instead of military conscription,” there should be “a conscription of the whole youthful population” for several years as “part of the army enlisted against Nature.” awkward framing, but correct in the following sense: our civilizational project is to survive in a universe that is pretty inhospitable to us. i think this is why The Martian and Project Hail Mary are so compelling. i like watching people fighting the universe rather than people fighting people

I loved the Project Hail Mary movie (and the book). Science, technology, competence, and openness – this is my culture.

@WatsonLadd It causes stall bubbles.

@ID_AA_Carmack Head of line blocking does not affect transfer throughput

It is a shame that the simple act of transferring a large block of data as fast as possible over the internet is not handled effectively by the primitive operating system calls. You either multiplex over parallel persistent TCP connections to combat head-of-line blocking and slow starts, or reinvent reliable delivery and flow control over UDP. QUIC has a lot going for it, but it is a large library (six figure LoC!) and conflates security and performance in a way I don’t love. There is also fundamental information about competition with other processes and link layer congestion that should be useful, but is unavailable to user libraries. You should be able to just write(really_big_buffer) and it is all taken care of for you.

@jwatte That does nothing for head of line blocking, but I didn't know that setsockopt adjusted the TCP starting parameters -- got a reference for that?

@ID_AA_Carmack If you run on modern Linux and set the socket buffer size to something very large before connecting (this is the important bit!) it *is* taken care of for you. It's annoying that you have to call that setsockopt() of course, but it's not a deal killer.

Doom Just Received One Of The Highest Cultural Honors In The US dlvr.it/TSbrMH

@MohamedLamhaden @themoondesigner My 12 year old son said that, not me. Still has some truth to it!

@themoondesigner @ID_AA_Carmack Really! I guess this guy who wrote this quote is exgerating a bit

In the world of llms...still true @ID_AA_Carmack

@ankkala Axially aligned KD trees are generally a better choice for spatial partitioning today than arbitrary plane BSP trees. Quake was about the end of the times when rendering geometry usefully coincided with partitioning geometry.

why is binary space partitioning considered lost technology now

Guess who's coming to QuakeCon? 👀👀👀👀 Check out Hugo & Josh's announcement: youtube.com/live/DcmrBC2us…

I'm a little disappointed with myself that the high school algebra identity didn't occur to me right away.

I did a Doom port on BeOS, and I found it very pleasant. The NeXT workstations we were using had all the 90s Unix cruft (terminfo, as you mentioned, was a good example even then), while BeOS seemed to have implemented just the core goodness. In some ways, it might well have been a better transition OS for Apple at the time, but in the long run with the rise of Linux on the server, being “actually unix” with OSX genuinely has been the better path.

This is a really spectacularly good retrospective on the BeBox and BeOS, with oodles of technical and historical detail that answer questions I've been carrying around for decades. There's one omission I find very curious, though. The author never examines or even considers the impact of Linux on BeOS's competitive environment. And I think there was a major one. A major thrust of the BeBox was its attempt to capture the imagination of tinkerers and hackers. Thus the GeekPort with its pin spacing designed to be friendly to people who weren't already electronics technicians. That goal persisted when the company went software-only in 1997 - they counted on those forward thinkers to be early adopters and evangelize BeOS into mainstream acceptance. Alas, by 1997 the forward thinkers willing to take a flyer on something that wasn't Windows or MacOS had a more appealing alternative. Linux didn't have pervasive multithreading, or an uber-cool file system that was also a database, but it did have one advantage that trumped those: open source. Paradise for tinkerers, who could expect to achieve a degree of comprehension and control impossible while the OS remained an opaque proprietary blob. I don't think this alone doomed BeOS, but it was a blocker for the takeoff trajectory that Gassee and his crew had planned. Then they fumbled their negotiation with Apple, apparently thinking they held stronger cards than they did. It's a sad story. Some of BeOS's innovations, most notably the file system, were striking and worthy. I wish we'd gotten to keep those. jdhodges.com/blog/bebox-bea…

I've been coding for 40 years. Here are the top 5 things I wish I knew when I started. 1. 90% of the job is debugging and fixing, not creating new code. Which is still fun if you're good at it. I used to think programming was mostly writing fresh, clever stuff. In reality, most of your time is spent in other people's (or your own past self's) messy code, chasing down why something that "should" work doesn't. Get really good at debugging early. Learn assembly reading, call stacks, and kernel debuggers. It pays off hugely. The best engineers I saw were absolute magicians at this. 2. Manage complexity from day one (ie: don't write slop and "fix it later" if it goes somewhere). Very early on, I'd hammer out code and refactor afterward. Big mistake. Now I start with clean, skeletal structure (minimalism first) and flesh it out carefully, with AI or not. Messy code compounds and becomes unfixable. Upfront discipline on architecture, naming, and simplicity saves enormous pain later, especially in large systems like Windows. 3. Tools and processes matter more than you think We suffered with basic diff/manual deltas instead of modern source control like Git. Branching, testing, and good tooling would have made porting and collaboration way smoother. Invest in your environment, automation, and reproducible builds early. Good tools amplify your output; bad ones (or none) drag everything down. 4. Understand the problem and existing code deeply before writing Don't jump straight to coding. Map out the problem, study what's already there (you'll inherit a lot), and plan. Low-level knowledge (hardware quirks, alignment issues on different architectures like MIPS/Alpha) was crucial. Also: assert early and often. It forces clarity. 5. People, politics, and "the right tool for the job" beat pure tech arguments. Brilliant engineers still argue endlessly. Sometimes it's about ego, not merit. Learn to spot the difference and "steer" the conversation rather than "winning" it. Bonus from experience: Side projects like Task Manager (started at home because I wanted the tool) can become your biggest hits. Ship small, useful things often. If you're just starting, focus on fundamentals, patterns over syntax, and building resilience for the long haul. It's going to be a wild ride, but the fundamentals still matter.

@ijoshuajohnson The market was very different back then, but I was ruthless about simplifying the games, always in tension with the designers, and they still always took longer than we planned.

"Identify your customers clearly before you start. Not just a broad community, but specific people, and imagine them as you make decisions. Initially, build the smallest, most concise game you can imagine anyone paying for. It will still take much longer than you expect." Did you and John consciously do this?

My reply to someone considering starting a video game company: The distribution of possible rewards for starting a video game company are generally not very good today. The market is well served, and gaining a foothold requires strong execution on both business and product issues, along with a substantial amount of luck. Plan to burn through seven figures with a not-great chance of making it back. If you do go for it, some bits of advice: Identify your customers clearly before you start. Not just a broad community, but specific people, and imagine them as you make decisions. Initially, build the smallest, most concise game you can imagine anyone paying for. It will still take much longer than you expect. Once something exists, hill-climb the value. Hopefully you will have some elements that clearly bring joy to people, which you can magnify. There will inevitably be tons of things that people find confusing, frustrating, or just boring that you will need to fix.

Space launch was a clear case where there was a large difference in efficiency between what was possible and what was done in practice before SpaceX. A large part of that was due to everything being locked in to what (just barely) already worked, with huge risk aversion. WIth national prestige or a half billion dollar geosync satellite on the line, speculative engineering ideas that might result in a public debacle were not welcome. When failure is not an option, success can stay very expensive. You need to experiment to improve, and that fundamentally means being comfortable with failure. If you know it is going to work, it isn’t an experiment. I have long believed that nuclear power today is in precisely the same state as space launch two decades ago, but the even more pressing question now is if semiconductor fabrication might also be. On the one hand, Moore’s Law has been a sequence of heroic miracles of technology at the wafer fabrication level, grinding out hundreds of compounding small improvements. On the other hand, fabs are “too big to fail”, and there are elements of extreme conservatism at play. Intel’s “Copy exactly!” fab development exemplifies that mindset – instead of every new building being an opportunity to explore and optimize processes, it was deemed more valuable to just replicate. While each individual machine may be straining against physical limits of technology, it is possible that the systems orchestrating them all together could be far from optimal. The explore / exploit axis is fundamental to all decision making, but human risk avoidance probably biases away from optimal exploration.

@SandyofCthulhu @labs999999 That was the IPX networking issue I mentioned. Big bridged networks were being completely clogged up by broadcast packets from Doom multiplayer games.

@ID_AA_Carmack @labs999999 Also I definitely remember that Doom got banned all over in College networks because of some kind of packet issue. Is that the DWANGO thing you’re referring to?

Like anyone else, game companies can be cheated, and I witnessed this several times. In 1993, we at id Software played Doom together over our internal network. Now, you have to realize that at the time, we thought few people would want to play by modem or over the nascent internet. But we wanted that functionality, because it was super fun and we liked it. Now, John Carmack didn't want to program the internet code. We hired a guy who lived in (IIRC) California to do the code remotely. The deal, as it was explained to me, was that he was finishing a project for his current company, and doing our code in his spare time, with his boss's knowledge. When his project was finished, he'd join us in Texas. Well, when we were ready for our internet code, we called his company in California and got the guy's boss. He laughed hard at us. He told us, "This guy is a good programmer, but he is a compulsive liar. He knows he can never hold a job anywhere else, and I get he hasn't done a lick of work on your connectivity stuff. He just took your money." Well ... the boss was right. We'd been swindled. Worse, we didn't have that code. So John Carmack spent 2 weeks quickly hammering together something that mostly worked, and then we released Doom. There was some kind of issue with the way we did it, that if Doom was being played with a lot of people on the same net, even if they weren't playing each other, it multiplied the information packets hugely and crashed the system. Within a month Doom was banned on basically every college campus in the country. So we hired someone to give us new, robust, code and in a month or two Doom was all it could be. Of course John Carmack's not to blame - his strength was in 3-D, not connectivity. Plus he had only 2 weeks to throw it together. That dude in California was the villain and he can rot. 1/4

@SandyofCthulhu @labs999999 Pretty sure that was about the SNES Wolfenstein port. I had to stop working on Doom and do that myself after the contractor completely flaked on us.

@ID_AA_Carmack @labs999999 Then who was the guy you told me about that dropped the ball? I was told, I thought by you (maybe by Jay?) that he’d be joining us and that was cancelled.

@geysergod_ @SandyofCthulhu He might have been conflating the story about Bill Heineman and the SNES Wolfenstein port, which was around that time.

@ID_AA_Carmack @SandyofCthulhu Was the story of the fraudulent contractor a total hallucination?

@PalmerLuckey Yeah, just doing 60 fps 2D games with subpixel filtering, blending, scaling, rotation, and no hard tile boundaries would have allowed some very strong new designs.

One of the real bummers of the N64 software library is that despite being extraordinarily capable as a 2D system, almost all of the effort went into 3D games. Makes sense, that was the shiny new selling point, but the hardware is capable of so much as a sort of Super-SNES.