3 ms·
> Anyone that used it or wrote code for it hated it. I didn't! Used Coherent 3.0.0 and all later versions and wrote quite a few programs for it and ported many
by nils-m-holm 3y ago
> Anyone that used it or wrote code for it hated it.
I didn't! Used Coherent 3.0.0 and all later versions and wrote quite a few programs for it and ported many more. UUCP packages, news readers, wrote my own CU clone, my own mail client, etc. It was a real Unix system for $99 and fit easily on a 20MB ST-225 hard disk with plenty of space for your own stuff. I loved Coherent.
Maybe in commercial software development things look different, but for me as a hobbyist it was a dream coming true.
- icedchai 3y agoI still remember the documentation that came with Coherent 4.x. It was amazing!
- nigel_bree 3y agoHey Nils, love your work - back around '90 when I joined Mark Williams I was a big Scheme fan, so your whole t3x.org site and "Scheme 9 from Empty Space" particularly puts a smile on my dial. I do think the fact that Coherent really hewed 100% to the original V6 approach based on the basic design constraints of bootstrapped minimalism was part of the charm. Doing the 4.0 release process I really pushed myself hard to get as much POSIX compatibility in as humanly possible, but the balancing act was the size-coding part - making /bin/sh still be 16-bit while having $(()) and shell functions and able to process those insane MB-sized GNU autoconf scripts that embedded >64kb here documents, etc. Another big part of why the size-coding style mattered was keeping the system comprehensible since with only a few developers everyone was spread so thin, but that's again part of the fascination. I've always wanted to give Coherent a bit of a conceptual reboot for modern x86 (particularly multicore, which means a complete new kernel) but staying to the 16/32-bit size and with a style similar to your books walking through the process of making it and how all the design choices need to interlock to make that possible is something I wish I had the free time for.
- nils-m-holm 3y agoThanks, and always good to hear stories from Mark Williams! The minimalism of Coherent 3.x indeed gave it a special place in my heart. I still have a virtual machine image of it, now even with the complete source code. A book about the internal workings of Coherent would really be cool! Why would you even need to create a new kernel? Just describe what is there. I think it would be a very interesting book (even though the audience might not be very big). Maybe you will have the time to write it some day.
- nigel_bree 3y agoThe big thing I think with any book is to aim to inspire people (especially younger ones) to create for themselves, and while there's probably a way to do that with an exegesis of the existing source I don't know what it would be. The approach you take in your books is one that I think is inspiring to people to get them trying these things on their own - which is after all where the real hard learning happens. That's particularly true because so many point design decisions made in commercial codebases like Coherent were conditional on a wider context - both technological and business - that just doesn't exist any more, and that I think gets in the way of helping younger people reaching a deeper understanding and appreciation of the design decisions made. Recontextualising that code, and re-examining those decisions in the light of the modern day is just more interesting to me, and as well provides the chance to lead people through the process of solving the design problems in a way that's narratively easier to follow. Bootstrapping forces an order on what you do that gives a particular structure to the presentation, while at the same time we have aspirations about what future elements we want to achieve that shape and give context to all kinds of decisions as we work out how to get there. After showing how to build something today, we can do a compare-and-contrast against the existing Coherent code that's more meaningful, especially because we can then measure the outcomes. Anyone can do (and lots of people do) ill-informed hand-wavy postulations about what-ifs, but the process of actually building things that do work forces your hand in ways that armchair enthusiasts miss.