How Pixar Stopped Worrying And Learned To Love Linux

If you weren’t already aware, it will probably come as no surprise to hear that the pioneering computer-animation studio Pixar built its early workflow on Silicon Graphics SGI workstations. These were beefy Unix machines that, as the name implied, were developed for graphical work. When the age of the RISC workstation came to a close, many Unix users were pushed onto Windows NT — but not at Pixar. At Pixar, they learned to love the penguin.

It comes down to hardware rather than software. You know the story: PCs got faster and cheaper with different vendors competing for a giant market, while the world of RISC workstations couldn’t keep its lead. Pixar would have been happy staying on Unix workstations, even SGIs if that had been a practical option — but with every project increasing the load on the render farms, it wasn’t. Yet Pixar’s entire workflow was predicated on a Unix environment. They had written a couple million lines of code for their internal use, and really didn’t want to port it over to Windows, even after a mistaken rm command nearly cost the world Toy Story 2.

The path of least resistance would be to port to something more similar to IRIX’s Unix environment, something POSIX compliant. That path led Linux, and by 2001, the port was done. By 2003, a new render farm using Xeon processors brought the whole studio to Linux and x86, which has since become an industry standard.

We’re left with only two questions: one, why didn’t more industries — like the CAD/CAM world — that were also reliant on Unix Workstations follow Pixar and Hollywood onto Linux, and two, why did Pixar go with Linux instead of some variety of BSD? [Crierlon] doesn’t address either question, but we’re betting some of you might have an idea. Let us know in the comments if you have the inside scoop; inquiring minds want to know!

64 thoughts on “How Pixar Stopped Worrying And Learned To Love Linux”

  1. Mostly because those deciding on top were and are themselves trapped in the Windows paradigm. I’ve seen it many times: engineers and coders firmly rooted on Unix (any form) until somebody decides on top it is better for the company to use only Windows, plainly ignoring the arguments of the people who actually do the work. Like some colleagues being forced on Windows, using it as a VM host to do their real job on a *nix VM…

  2. It wasn’t a failure of Windows but Pixar themselves who instead of a sustainable workflow and a clean pipeline relied on ever growing mess of custom UNIX spaghetti code.

    1. I’ll never understand you Windows apologists. Pixar already HAD a functioning production pipeline whose fundamental assumptions were UNIX/POSIX-adjacent. Moving that pipeline to Linux was an incremental port, not a complete rewrite. Moving it to Windows NT would have been a substantially different engineering project. “Sustainability” and Windows don’t belong in the same discussion, as anyone who has been involved in large codebases can attest. Even Windows itself… there are entire sections of the codebase that nobody will touch because the greybeards have moved on, and there’s nobody left who understands it. They’ve scrapped entire rewrites because of it.

      We’re talking two million lines of internal software, not a handful of crusty shell scripts. The Linux port went quick (contemporary reports suggested ~2,000 lines a day), because the tooling wasfundamentally in the same shape. Calling that “spaghetti code” is ridiculous.

      Why would anyone throw away a working production infrastructure and spend YEARS rewriting it merely because Windows became the “industry desktop standard”? Pixar’s workflow was ALREADY sustainable enough to make feature-length films, so much so that they were literal pioneers in the field. Pixar didn’t choose Linux because they were incapable of building a “clean” pipeline… they chose Linux because they already had one.

      1. “Sustainability” and Windows don’t belong in the same discussion, as anyone who has been involved in large codebases can attest.

        That’s why I can still run binaries of my games, RATs and other crapware I’ve written in WinAPI under WinXP SP1 when I was a teen and Visual Studio was the hot stuff.

        1. “WAS hot stuff?” That made me feel old. Even in more recent years IBM has been looking to attract talent to mainframes by moving from 3270 “green screen” terminals to Visual Studio, including the AI “Bob”(which they also had to make available as Bobshell, because many aren’t convinced of the “modernization”). Also refactoring COBOL to Java(why dear lord, why?) I’m just dipping my toes in this world, I can’t say much about z/OS, but certainly it’s steady development over time makes competing PC OSes look like a wacky side show.

      1. Yes, but that would have been Microsoft’s problem. Pixar wouldn’t be developing and maintaining Windows on the side since there’s a whole other corporation whose business it is to do that.

        1. there’s exactly ONE corporation whose business is to do that, and that’s the issue. The same single choice would exist for MacOS and Apple. With Linux, choosing either in-house, or outsourcing to a variety of different corporations, makes it a natural choice, or really a whole collection of several choice, imo. You’ve also answered “why not BSD?”, because again outsourcing OS issues would then be very limited. If Pixar were a small, new company, Daddy M$ would be an attractive choice, but then, can MS be trusted not to use dirty tricks to keep your company tied to it’s products?, and to demand levels of investment to MS for your growth? to this single monopolistic behemoth? I don’t see it as a good vs bad technical choice, it’s an economic one.

        2. The point is its pretty absurd to throw stones at a multimillion dollar company with “spaghet” code then tell them to run an OS that is itself spaghet.

          I am sure Pixar would have LOVED a forced reboot update when working on a film lel

          1. “forced reboot” – yes. On every single computer in the rendering farm. And not all at the same time, maximizing downtime! Plus BSODs galore!
            Dunno how their rendering processes work, but on Windows, I bet every time a machine reboots, all the machines will have to start over.

        3. “that would have been Microsoft’s problem”

          Yeah, just like fixing all the other kludge that crashes explorer on my chonky workstation at least once a day is their problem? Just because they theoretically should be making an acceptable product doesn’t mean that they are.

          I’d be on an Ubuntu machine like all my non-ME coworkers in a heartbeat if I didn’t need to run W11-only CAD packages.

    2. Pixar came from early compsci times, UNIX was well established and Windows (especially NT versions) was still relatively unproven at this scale (renderfarm scale). Would they have been early Windows adopters, they’d probably have at least as much entirely importable ‘spaghetti’. At least staying closer to POSIX allowed them to pivot more quickly, and allows them the same flexibility again if needed.

      1. Yep. Pixar stayed on *nix because they wrote/invented all their stuff. If you are just starting out now, the barrier of entry is much lower to go with an already-existing ecosystem.

      2. was still relatively unproven at this scale (renderfarm scale).

        There’s a point of “free is the enemy of good”, plus “the devil you know”. An important and demanding paying user like Pixar might have been a major influence on Microsoft and a reason to push development ahead faster and harder. Switching to Linux was up-front cheaper for migration and the operating system itself was “free” but it put them at the mercy of a community that had no particular interest in providing support or making changes, so they ended back where they started to support themselves.

        1. So IBM Red Hat doesn’t exist? AWS is at the mercy of the FOSS community? For goodness sake Android has a linux kernel! “a community that had no particular interest in providing support or making changes” ?!?!?!? “they ended back where they started to support themselves” -yes, rather than be subject to NotPetya or WannaCry, for example. You’re dragging up dead arguments from 2001. In hindsight, in 2026, the move to Linux looks brilliant. Apple brought out OS X in March 2001, and you could at least make interesting arguments if Pixar went with OS X instead. But arguing with hindsight for Windows?

        2. And you really think an important company sponsoring the development has no ability to shape Linux or whatever subsystem they need!?
          The community of developers has plenty of reason to make whatever Pixar needs should they be one of their sponsors, as they are literally the ones putting food on at least some of the developers tables. And if Pixar finds it needs anything that isn’t already on the road map they can thanks to the magic of open source simply pay a developer to create exactly that thing, then make the choice of sharing this new widget so the community will end up actively ensuring it stays working or not.

          Loads of companies fund FOSS development as its good for them that these things are developed and developed in a robust flexible way that suits more folks than just their own needs at this moment gives them a better baseline than if they wrote it themselves. And all without having to pay for ALL the development costs in house.

  3. Xenon processors? AFAIK in 2003, they used 1,024 Xeon processors. Xenon was the codename for the IBM PowerPC-adjacent CPU used in the Xbox 360.

  4. Bruce Perens worked at Pixar (as a sysadmin i think) early on, and was a vocal Linux / Open Source advocate. He showed the “Geri’s Game” short to the 1998 Linux Expo in Durham NC as part of his presentation there. As I recall, he was asked where Pixar used Linux; there wasn’t much tooling for their sort of graphics or massive clustering yet. “Beowulf clusters” was the hot topic still being developed.

    1. Bruce was my office mate at Pixar in the late 90s. He and I were in the Studio Tools Group, who developed Pixar’s proprietary animation system called Menv internally but formally named Marionette and later Presto. Before I left in 1998, we were preparing for a major rewrite of Menv. Menv needed good OpenGL support, which was still in the early days in Linux, so Jobs ordered that the new animation system should target Window NT primarily with IRIX and Linux as secondary targets. (It was also going to be in C++, not C as the old system was.) No one in the Tools group was happy about that, we were all Unix people, but those were the orders. Fortunately, Linux OpenGL support got good faster than expected and MacOS X also became an option, so the NT mandate was dropped. (This was after I left, so I’m not sure how far the NT port got.) In the following years, both Linux and MacOS desktops were used by the animators.

      I can’t speak to the Renderfarm other than to say it was primarily a Sun cluster running SunOS, not SGI systems running IRIX. It mostly was used to run the Renderman renderer and Renderman was more portable than Menv (no OpenGL needed!), so moving from SunOS to Linux was probably not that big a deal.

      1. Piggybacking, I was a RenderMan engineer starting in 1991, back when Toy Story was still years in our future and we’d just given up on manufacturing the Pixar Image Computer, and we were just Pixar, not Pixar Animation Studios. In those early days, being part of the RenderMan group meant porting RenderMan to whatever architectures would pay us. There was a Cray port. The first project I did was a port to some Motorola 68K based HP-Unix workstation. There were of course Windows and Mac ports (I recall working on the Windows 3.1 port, and was part of the team that implemented Typestry and “Glimpse”, our shader previewing technology). The original Toy Story was rendered on a melange of SGI machines. But by the time we were getting ready to do Bug’s Life, it was clear we needed hardware that was better than just a random collection of desktops. That meant Sparcs. https://www.hpcwire.com/1998/12/18/pixar-used-sun-systems-power-bugs-life-renderfarm/ There were still a great variety of SGI machines on desks to run menv, and there was a lot of back and forth about how to deliver software on the desktop. About that time the first accelerated graphic cards were coming to market, and it was clear (to me at least, and later to others. I was booed away from a mic at SIGGRAPH for expressing this idea) that the days of the high end graphic workstation from the likes of SUN and SGI were limited. All of our investment in SGI/Unix software would have been difficult to shift to Windows NT, but in a strange bit of synergy Linux had begun to get traction, with Red Hat first shipping around 1995. It became viable far faster than anyone probably had any right to think, and allowed us to leverage the experience with our prior code bases. By the early 2000s (Finding Nemo time frame?) that was pretty much a done deal: Linux had taken over almost entirely.

        Why not FreeBSD? To be honest, I don’t actually remember. I was using FreeBSD at home (starting with the 1.1.5.1 release, ~1994) but I don’t recall that it was ever strongly considered. I suspect that the rise of Red Hat offering commercial support was part of that decision: there was no similar business-friendly company prepared to provide support for FreeBSD.

        SGI and Sun wouldn’t survive the dot-com bubble burst, and that further cemented our shift to X86 based servers running Linux.

  5. Because I don’t have a big render farm, so I need GPU drivers unfortunately. They kinda work now, but that’s a more recent development, and there’s still bugs on the frontier, which is what you end up needing more often than when you’re just playing video games or whatever.

    Blender and better drivers make Linux a lot more tempting in the last few years. Now if only I could ever afford another graphics card…

    1. Recent development? Mesa supported 3dfx Voodoo on linux in 1997. I used a GPU on my linux desktop around 2000, and it worked well with 3D games at that time. For a while you couldn’t just buy any graphics card and expect it to work, but it has been possible to use many different GPUs since last millennium.

      GPU drivers have always been buggy, no matter the OS. Two years ago my coworker had to turn off a lot of features on his fancy new graphics card when he uses it on windows, everything still doesn’t work with the windows drivers.

  6. Interesting. No mention of Steve Jobs. He bought Pixar in 1986 and put maybe 5 times the purchase price into it. For some reason I thought NeXT computers and his Unix played a role. The Pixar hardware platforms did not sell well and Jobs moved the focus to producing animation. Also that after Jobs returned to Apple, Pixar used a lot of the new Mac’s / OSX and Apple servers for graphics design.

  7. Here we are 25years later with Linux market share of 5%.

    Don’t ever mistake application specific OS with generic worry free OS.
    Linux is only free if your time is free.

    1. I’ve spent a lot of unpaid time fixing Windows as well. And yeah that market share might be accurate strictly for consumer desktops (which are 90% only used to access a remote server running linux)

    2. I mean I have linux on more than 15 systems in my office. The only one that had issues was an oddball aliexpress special that used a portrait screen rotated to landscape and a super oddball split of audio from HDMI. It took about 20 min if fiddling and has been solid for years. Every other computer has been stable since install.

      Sounds like you haven’t really used linux at all.

      1. 15 October 2023

        unplugging Logitech USB receivers has for the past several months been causing the Linux kernel to crash.

        https://www.phoronix.com/news/Logitech-USB-Unplug-Linux-Crash

        Bullshit like this is why I went back to Windows and nowdays I only keep desktop Linux as a VirtualBox VM for some rare cases where I need to dd stuff or something. 99% of my shell needs are fulfilled by MSYS2.

        Monolithic kernel with no stable API, where some misbehaving mouse driver can crash the entire system just because lol n00b get rekt scrub is a grave mistake that ensures desktop Linux will forever remain a mere curiosity.

        1. Isn’t it great that one company doesn’t have a predatory monopoly on the PC operating system market so you do have that choice?

      2. Sounds like you haven’t really used linux at all.

        Ah, the typical “it’s the user’s fault” 😉
        Reminds me of Apple’s “you’re holding it wrong!” 🙂

    3. maybe it’s 5% on the desktop, but +90% of the internet and computing runs on linux. something like 2/3 of microsofts revenue is cloud almost all of it linux

      1. Yup. And that’s worrying. These “+90%” run all on the same cheap OS, share all the same security holes..
        That’s monoculture, that’s bad practice.
        Back in the 80s and 90s it all was about heterogenous networks.
        There had been multiple Unix OSes that server software did run on.
        Some early private servers even ran on Mac’s System, Amiga OS or Windows 3.1x.
        There was diversity in short. No single malware could exploit security flaws in all of them.
        Then came Windows NT and Linux..

        1. If Linux servers running pretty much the entire internet had so many security holes, Microsoft would be screaming from the rooftops about it. They don’t. You know why? They use Linux too, like every other major company in the world.

          OS dominance question has been settled 2 decades ago. Next battle is AI.

          1. A problem I see is that Linux is a good target if all Linux servers on the net are up-to-date, on same revision.
            Like it used to be supposed from a security point of view (an OS should be up-to-date because of latest security patches).
            In such a homogenous network landscape it’s in theory possible for a worm or other type of malware to attack all Linux systems simultanously.

            On top of that, an LLM/A.I. which has access to the current Linux source code
            could then figure out several weak points in no time and create a malware that exploits them all.

            With multiple OSes or at least multiple Linux revisions and different server software this wouldn’t be as easy, perhaps.
            Especially if some of the OSes are closed-source or obscure and/or do run on different hardware platforms each.
            An heterogenous network structure, in short.

            The issue with LLMs is the speed at which they operate and improve, I think.
            Human software developers can’t keep up with that and likely can’t fix the security holes in time.

            And using A.I. for defense from A.I. attcks for some sort of “balance of power” might be leading into a downwards spiral.
            Because both might recognize patterns of the other one and learn to improve over time.
            By contrast, human developers are more unpredictable here.

            Btw, that’s probably why the Linux author welcomes Rust and A.I. assistance, to quickly fix decades of leaky C++ code without built-in memory protection (a Rust feature?).
            Considering how large the Linux kernal has grown over time it’s understandable that a massive code rewrite has to be automatised somehow.
            Otherwise, it would take years to finish that undertaking and big tech which uses Linux and pays for Linux can’t wait for that.

  8. I suspect that Pixar’s case is pretty different from that of most CAD shops. Somewhat similar on the workstation side; you’ve got a relatively expensive person who needs a machine that can render what they are working on in real-ish time at an OK preview resolution; but Pixar has a massive HPC cluster in the back that they are shoving things onto for the full studio render(not necessarily the most demanding HPC in terms of node/node interconnect depending on how they were able to cut the problem up; but a lot of nodes); while a CAD shop is sending the finished models out to the machinists unless they are specifically doing CFD or finite element analysis or whatnot on them.

    Doesn’t mean that the CAD shop couldn’t go Linux; but the case for linux is way, way, stronger if you need to manage a ton of nodes(both in terms of maturity of tooling and not paying for a license for every identical Xeon numbercruncher) than if you are just buying a handful of workstations to run whatever Autodesk is selling you.

  9. It seems wherever someone needs workstations, you’ll find windows, because you have a stable gui infrastructure. You know (knew; GL in 2026) you can get replacement hardware and it’ll work.

    But when you’re building a server farm, with your own custom cpu based renderer, the gui gets in the way, Linux is much better. Today you’re going to Amazon of course.

    1. “Stable” unless windows pushes updates that break stuff…..that never happens right?

      Windows 11’s biggest September update is breaking WSL-based apps, Remote Desktop, and causing issues with File History backup…

      Or how about the Jun one?
      Windows 11 KB5094126 update is causing systems to fail to boot, getting stuck on the BitLocker recover screen, or hit the BSOD

      Yep super stable

      1. And of course those updates are super optional and won’t just install themselves at inconvenient times wasting several man days of effort to get all your systems back to the same level of function they had the day before, for now.

      2. When talking about M$ Windows one should not think about Spydows 10 and SyperSpadows 11 ;-)

        IMO/AFAIR updates didn’t break stuff nearly as often with “real” Windows (2000, XP, 7, 8.1, maybe even NT4?). That shit really started more with 10 and got into high gear with 11.

        1. 2000 and XP were much simpler and often very broken/crash happy etc thanks to some programs, the drivers etc messing up without worrying about the updates. To my recollection a BSOD wasn’t exactly uncommon. Much as I hate to say it later M$ does tend to break less often in the find the big red switch level of terminal unrecoverable and often hard to diagnose failure than my memories of XP (though part of that may be how young I was playing with the family computer in XP terms).

          Still massively massively better than modern stuff really as you can usually get real stability with some fiddle and fortune, perhaps not installing the drivers or actively removing the less needed bit of hardware that doesn’t play nice. But really IMO 3.1 was the best windows as it was so so simple and didn’t really try to hide how a computer works to let those that don’t want to learn anything of the workings use one. It simply made doing simple in concept tasks as easy to do correctly as they are in theory with less chance of that wonky rm type command being used and causing trouble from a minor miss arrangement of the eldritch commands, small error in the file paths etc. And of course having many windows so you didn’t have to have a scribble pad or really really good memory to keep track of your work.

          Win7 was the last Windoze I’d actually use even if that was primarily to game from a VM on a Linux host. I’d accept arguments it was the best, as it did really open using a computer to everyone and mostly just work even if you are a know nothing type of user.

      3. Good idea: Windows as a standalone product (3.11-98)

        Bad idea: Windows as a service (7-11)

        Note: we dont speak of the gap from 98-7

      4. Apples and oranges, I’d say. 🙂
        It’s as if we’re comparing a 1995 lite Linux distro with some of the latest consumer monstrosities.
        Back in the 90s, the ordinary desktop version of Windows NT still was a “workstation” release.
        It was even in the name: Windows NT Workstation
        Windows NT 3.5x, 4.0 and 5.0 (W2k) were solid workhorses.
        It wasn’t until Windows XP (NT 5.1) that both the NT line and the 9x line had fused.
        That’s when home and office users at large switched over from 9x.
        After that, merely the “server” series (server, advanced server etc) of NT line remained truely “professional” in that sense.

      5. It’s not about software. It’s the “Windows Compatible” or “Designed for Windows” sticker, that hardware developers where allowed to put on their products.

        That is what created stability in that eco system. You want to sell you graphics card, you need that sticker, you need to guarantee your hardware works with windows.

        Linux does not have such an agreement, still not, even with RedHat.

        As the IT manager, that has to keep the machines for The Talent going, no matter what, or it’s your job, you want plenty of alternate hardware sources.

        But, if Mr nVidia has his way, those will all be virtual computers, perhaps used by virtual employees (not sure what he is on, clearly left my world).

        1. One of the flaws of Linux also was that it didn’t respect the BIOS in anyway, it simply ignored it.

          By contrast, both OS/2 and the DOS-based line of Windows could fall back to BIOS service routines while Linux couldn’t.

          Windows 3.x and 9x could even fall back to DOS first, which then could fall back to BIOS if no DOS driver was loaded.

          In the days of 386/486 and 586 PCs the hardware was still compatible to industry standards (PC/AT, VGA+VBE, IDE/WD1003, SB Pro/SB16, NE2000 etc).

          For example, better SCSI controllers had an int13h handler in ROM chip
          and were supported at BIOS level even if no device driver was loaded yet.
          So they worked on Windows 9x even if no driver was loaded.

          On Windows NT, they might still work in safe-mode, too, not sure.

          But on Linux.. The HDD volumes were simply not accessible if an unsupported SCSI controller was installed.

          This mirrors a design choice of Linux, I think.
          It’s very dominating and wants it stuff to works its way.
          Compatibility, compromises or co-existance is not part of its nature.

          Here, OS/2 Warp was more tolerant. ;)
          It could either emulate access to devices or use the native interface.
          – I’m thinking of VGA and memory support in DOS windows here, mainly.

          1. Windows 95 allowed drivers to access hardware directly, cheaper, no bios. WinModems. Those never had support outside of windows 95 and where then incompatible with windows NT.

            Windows NT making things better for Linux as well.
            But getting a hardware accelerated driver for Linux took some time. Initially nvidia did release source code, I think. I recall a colleague looking at nvidia Linux source to optimize a windows game engine.

          2. @Christian What I wonder is why Linux didn’t have the priority to try to support all of Windows NT hardware. Or maybe it did?
            Because in the 90s, Windows and Windows NT came with an HCL, a Hardware Compatibility List.
            That list did contain all the hardware that was supported out-of-box.
            Windows 98/98SE had that list in the form of a HLP or CHM file, I think.
            It was somewhere located on the Windows CD-ROM, I vaguely remember.
            Older versions such as Windows NT 3.1 had it printed in the manual, if memory serves.

          3. @Joshua

            I do not know. I did not become a Linux user until ’06 and my WinNT computers where company owned and maintained. Most of my Linux exposure, in the 90’s, was from coworkers that very strongly opposed Microsoft, opposed to multi app gui workflows, opposed to configuration gui…. they’re right.

            But I did develop on WinNT for Win95. I think it was stability reasons, my dev code would not take down the WinNT machine with every test run.

  10. Strictly speaking, they used both Irix and SunOS/Solaris. Irix was used for their interactive work, and Sun’s ran their render farm. In 2000, at a Sun internal event, I had lunch with the Pixar salesguy and he showed me how they’d taken the headless Sun IPX and disks and made high density render blocks which they could package and cool well. It was kinda cool, and while I suspect they’d rather have used SGI systems through-out, for non-interactive rendering Sun had the performance and packaging advantage. SGI did have the Origin 200 (basically a cut-down Origin 2000, built for @Home), but nothing like the little Sun servers.

  11. CAD/CAM went to Windows because engineers did The Rest Of Their Job on Windows boxen. A lot of the typical engineer’s day is spent writing reports and preparing presentations. Add in the fact that quite a lot of engineering computations are done on spreadsheets, and it’s easy to see that engineers would spend a good part of their not-attending-meetings day in MS Office. An even stronger pull to remain on Windows came when CAD/CAM developers successfully merged CAE into their CAD/CAM software. BTW, this a lot of FEA analysts out of a job. I was at a CAE software developer throughout the 90s (as well as some years before and after). We entered the 90s with CAE as the domain of UNIX–from RISC workstations to Crays; we exited the 90s with X86 replacing them all. To put a finer point on that, a specific “body-in-white” analysis from a major US auto manufacture needed several CPU-hours of Cray C90 computation time around 1994; by around 2002, that analysis ran in about 60 minutes on a personal, not outrageously configured, P4 (running either Windows or Linux). As much as I personally hate having to use Windows, Linux just wasn’t ready for that typical engineering workload (Word/Powerpoint/Excel) at the start of the millennium.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.