CYANOTYPE
BLUEPRINT DESKTOP
FAQThese are project positions stated by Swift Griggs, the Cyanotype Project leader. Where a sentence is in the first person, it is I, not we.
Come for the SGI nostalgia, stay because it rocks without nostalgia and outperforms many of its peers, and hangs tough with the rest. The whole effort is a "What if SGI didn't die?" project. It is currently about a 5-person undertaking with decades of man-years of programming experience, as well as experienced artists and musicians contributing live acoustic recordings or hand-drawn or hand-curated artwork. It absolutely, unapologetically, uses AI to fill in for the massive team of coders SGI had (see the FAQ about AI and Cyanotype), but is steered, reviewed, patched, and augmented by folks with extremely deep programming experience on UNIX platforms, real VFX artists, and real musicians with decades of street cred: people just like the original folks at Silicon Graphics in the good old days, before Belluzzo. It's intentionally written nearly exclusively in C99 (RIP Dennis Ritchie, long live C!) with shell scripts where that makes sense.
Cyanotype is for SGI fans or other lovers of simple environments enhanced with real art and music (which is created by real humans). For example, our viola performer used an extremely fine acoustic instrument for all the sound cues and demos. The drums are acoustic. The wallpapers are digital matte paintings. It is also for people with low vision, and for people with little or no hearing. The primary author has vision and hearing loss, and the whole team has family members with disabilities, many of whom are test users. Large type, high contrast, and an on-screen keyboard are there so that small print is not a reason to leave, and so a person who cannot hear the beep is not stuck waiting on a speaker. Accessibility is a huge goal of the Cyanotype Blueprint Desktop Environment, and we aren't done by a damn sight. We'll add many more accessibility features. It is also for anyone who just wants a cool environment, something different that works well and doesn't give way to new trends, only to quality and our specific blend of nostalgia with this modern twist.
We do not want bulk. We do not want features marching away with the performance and the usability. We keep CPU and memory for applications, not the environment. Tight code and efficiency are still a top priority. Optimization as a feature is the idea. The machines we test on are old MIPS, in the 200 to 800 MHz range. If it is quick there, it is going to fly on new hardware.
Cyanotype Blueprint Desktop (CBD a la IMD) consists of a window manager, a toolbar, a desktop file manager, and many digital versions of tools one might find on a busy wooden desk in 1885 (clock, notepad, calendar, etc.), but with many analogs to IRIX applications (and more to come). Adjacent to it are capital apps like Sunbeam, a SGI-a-like calendar for CalDAV users that complements the desktop, or CyThrough, a remote-single-application sharing rig that allows you to publish shared applications and run them from remote using a low-latency and highly responsive desktop sharing protocol.
It is tested on more than one platform, and it is written for more than one instruction set. It is optimized for old hardware and for low memory. That includes, especially, the SGI MIPS line running IRIX using the SGI MIPSpro compiler.
Day to day it is built and run on NetBSD, FreeBSD, OpenBSD, and a spread of Linux, with gcc and clang, including older compilers. IRIX is the design center: the C dialect, the library choices, and the refusal to require a new PC are all held to that machine. Solaris, AIX, Tru64, and HP-UX are in scope for the same reason. They are not weekend ports to be dropped the first time they are inconvenient.
I am critical of C's march of progress, and I do not like the efforts to turn it into C++ or otherwise ruin it. I do not want to push the language in Cyanotype past what compilers like MIPSpro or Sun Studio can optimize. There is very little payoff in that, and there are plenty of reasons to standardize on C99 besides the fact that C99 is what I want to see, read, and write. Modern compilers can still optimize it just fine, and modern compiler flags can be, and are, still used to make it faster and more secure, for example (on the platforms where it's possible). The build script (configure) handles that.
In practical terms, that means no C11, no C17, no C23. No _Generic, no _Static_assert, no anonymous struct members as a habit, no stdatomic.h, no threads.h. Variable-length arrays stay out. The code has to compile on MIPSpro's partial C99, on Sun Studio, on gcc 4.x and up, and on clang. When a POSIX function is missing on IRIX or Solaris, we carry a small replacement or we avoid the function. We do not raise the language standard to paper over it.
Blueprint wants to be what SGI might have done in IRIX 7. I am speculating. I am building a desktop that might have existed if SGI had survived and kept going. It is a speculation about their design sense, not a claim on their roadmap, and not their code. IRIX is dead, long live IRIX.
The project tries to meet the operating system where it is, without building new scaffolding and without inventing a new way to do the same job. We are not going to write NetworkManager. We are going to use the facilities the OS already provides to configure the network: its supplicant, its DHCP client, its ifconfig, its rc scripts.
Audio is the same rule. Find the hardware as it is, with the native tools and the native libraries. Do not refactor what the OS already does. CyMix moves levels. CySoundD plays events. Neither one is a replacement sound server. CBD doesn't need anything like GStreamer (nobody does, really) or DBUS. Intra-app communication is handled via --notify flags/messages on the applications themselves. Re-writing some C++ or Python wrapper around existing services that work just fine (ie. like PulseAudio did with ALSA) seems extremely wrongheaded, anti-Unixy, bulky, Windows-ish, and just plain a waste of time and energy that insults the work done on the OS.
Version progressions will include more features, and new software, but most of all, and foremost, optimizations. We will keep making it smaller, faster, and more respectful of your hardware. We will not bulk it up to the moon and then expect you to buy a new machine to run it. Core programs like CyWM will get faster, not slower, and we benchmark to ensure that. More apps will be added to the suite, for sure. However, shared libs they all use, like libcyui, will get faster also. They already have, by orders of magnitude, since the first few versions landed.
Cyanotype is an X11 project. It supports Wayland insomuch as Wayland supports X11. There is some controversy about that, and I don't test on Wayland directly. What I'm told is "don't worry, it supports everything in X11 but XDMCP." What I've seen is that this is about 98% true, but I'm still not truly interested yet. This project backports to IRIX, Solaris, AIX, Tru64, and HP-UX. I am not going to abandon those platforms, and I am not going to provide any native or direct support for Wayland after the fiasco with Xorg, until Wayland has fully dominated and killed X11, which may or may not actually happen the way things are going.
I support X11-based projects such as X11Libre. I do note that IBM and Red Hat effectively promoted a coup of Xorg and ruined the project through unfair personal and political actions by attacking productive developers outside of their shadow-organizations (IBM, Red Hat, Fedora). They effectively stole the site and the project, and killed it to try to help their own project, Wayland. That was not okay. That did not go unnoticed. It simply got little coverage from the media. I'm not going to jump in and help people like that. I worked for IBM for years and I have no love for them or their business tactics. This project is partially a reaction to that whole ugly episode.
I will not comply with any Red Hat, IBM, Microsoft, or Poettering-like degradation of X11 and friends. I disagree with them at every level. X11 is not that hard, and it is damn sure not hard with AI available to do some of the heavy lifting. I was writing X code long before that. I consider the Red Hat position a pack of lies and distortions aimed at control, and at redirection of the whole desktop and display stack. I despise Red Hat despite being a certified engineer with them and having worked with the OS for years, before they turned as evil as I opine them to be these days.
The high-DPI scaling problem has X11-specific fixes. Those were always possible without a complete rewrite of the display server and without dumping XDMCP. The libraries can be streamlined and optimized without starting a new display regime, especially one built on deception, bad-faith lies, and nasty political chicanery by IBM/Red Hat/Fedora-crowd folks. They killed Xorg on purpose. They quit accepting patches. Over 1000 patches from dozens of good-faith Xorg developers were ignored over the course of four years. They blocked work the users cared about. That is nasty, undesirable, wrong, and 100% factual. Remember Tron? He fought for the users! We consider him our unofficial mascot.
No. Cyanotype and the projects around it will never have a code of conduct. The project will never make political or religious statements, and it will never take sides on anything other than technology decisions. We will not represent any cause but our own.
On technology, the stands are strong and strident, and nobody in the project will hold your hands, stroke your hair, and make you feel better about the anti-patterns we identify.
We are not with Poettering, with Red Hat, with the captured Xorg project, or with IBM. They have made literally hundreds of bad calls, and what they ship is, as I've said, an anti-pattern. Essentially, whatever the Fedora or Canonical crowd would like, or be excited by, we are probably going to not-like and not-do it. Cyanotype's goals sit closer to OpenBSD, NetBSD, Devuan, and the old-school Unix variants, of which IRIX is the one this desktop answers to.
We operate on merit and on good design. It is not a democracy. It is a benevolent dictatorship. Well-written patches, bug reports, and requests are accepted happily.
Never. I am not ashamed of using AI, and I am not going to pretend otherwise. I'm excited to use it and consider it a boon that makes this project possible.
I have been programming in C since 1993. I have written sooooo many applications in C, including device drivers, system tools, and libraries. I have written C on over 30 platforms, and with at least 20 compilers. I also code in multiple assembly dialects, on about 8 CPU instruction sets. I write C. I critique C. I eat, sleep, and breathe C and ASM. Anyone calling me a vibe coder is completely delusional. I can very likely code blurry circles of light around anyone who lashes out with "but but, you used AI!"
I am one guy. Where were the people holding these opinions during the last 25 years, while SGI was busted and IRIX and its friends wandered the wasteland? They did not help. They did not jump in. The closest thing to this project was the MAXX Desktop. That work is hella cool, and it has my deep respect (if anyone knows what hard work that was, it's me). Its author did not give the code away, and the scope is not the scope of Cyanotype. That's okay!
Anyone with something negative to say about AI doing some of the heavy lifting, and the CI, on this project is someone who probably never wrote any code at all. That is being an unwelcome critic without being willing to help. Weak. Unacceptable. Stuff it.
I will do this myself if I have to. I do not plan on letting AI haters slow me down, or on letting them act as if using AI means I am not a programmer. I was likely writing assembly before they were born. If you want to code Indigo Magic, or IRIX, from scratch, knock yourself out. I am doing what I am doing because it is possible, and the time is now.
First, EPM can produce native packages like RPM or DPKG with less effort than hand-rolling every format. EPM also has a very functional self-installing package mode, which I find very helpful, simple, and effective. As far as big networked package repos like Flatpak or AppImage, I think those are cool, but often they have drawbacks such as installing in a Docker container, or some other restriction that isn't appropriate for a project with the large scope of Cyanotype Blueprint Desktop. We try to ship native packages or EPM self-installers.
As for GitHub, well, I'm old enough to remember why dealing with Microsoft is a foolish choice and a losing game. I absolutely hate Microsoft, and I'll do so to the grave. No surrender, no retreat. I didn't forget all the damage they did in the 1990s and after. There are other open-source distribution sites like SourceForge and Savannah, but I'm old-school and I run my own damn servers. I don't trust those guys because they seem neglected, and while the GNU project has my respect, I'm a bigger fan of BSD and I'll continue to do this on my own. I may partner with someone like-minded in the future, but today you can check GPG signatures and download directly from my web site.
Use the feedback form, or write to cyanotype@irix.expert. The form appends the note to a file on this machine. It does not mail it on, and it does not run it. A full file stops new notes. See that page for how the anti-spam check works and what it does not pretend to do. The feedback gets mailed to project leads once a week after being scraped for noise.
Cyanotype Project. Blueprint Desktop. BSD 2-clause.
Not affiliated with Silicon Graphics. SGI, IRIX, and Indigo Magic
belong to their owners. 1.0 is aimed at 31 October 2026.