Assuming that this is indeed the end of Solaris (and it certainly looks that way), it offers a time for reflection. Certainly, the demise of Solaris is at one level not surprising, but on the other hand, its very suddenness highlights the degree to which proprietary software can suffer by the vicissitudes of corporate capriciousness. Vulnerable to executive whims, shareholder demands, and a fickle public, organizations can simply change direction by fiat. And because — in the words of the late, great Roger Faulkner — “it is easier to destroy than to create,” these changes in direction can have lasting effect when they mean stopping (or even suspending!) work on a project. Indeed, any engineer in any domain with sufficient longevity will have one (or many!) stories of exciting projects being cancelled by foolhardy and myopic management. For software, though, these cancellations can be particularly gutting because (in the proprietary world, anyway) so many of the details of software are carefully hidden from the users of the product — and much of the innovation of a cancelled software project will likely die with the project, living only in the oral tradition of the engineers who knew it. Worse, in the long run — to paraphrase Keynes — proprietary software projects are all dead. However ubiquitous at their height, this lonely fate awaits all proprietary software.
There is, of course, another way — and befitting its idiosyncratic life and death, Solaris shows us this path too: software can be open source. In stark contrast to proprietary software, open source does not — cannot, even — die. Yes, it can be disused or rusty or fusty, but as long as anyone is interested in it at all, it lives and breathes. Even should the interest wane to nothing, open source software survives still: its life as machine may be suspended, but it becomes as literature, waiting to be discovered by a future generation. That is, while proprietary software can die in an instant, open source software perpetually endures by its nature — and thrives by the strength of its communities. Just as the existence of proprietary software can be surprisingly brittle, open source communities can be crazily robust: they can survive neglect, derision, dissent — even sabotage.
Dropbox Tech Blog has this in-depth article on “Optimizing web servers for high throughput and low latency“. It goes over everything from hardware and low level operating system stuff all the way up to the application level.
Great job, guys!
“Linux Inside” is a book-in-progress about the Linux kernel and its internals. You can read it online or download as a PDF. It’s also available in several languages. Some of the things that you’ll find inside are:
- The boot process
- System calls
- Timers and time management
- Synchronization primitives
- Memory management
- Data structures in the Linux kernel
- … and more.
Julia Evans, who blogs about her programming endeavors, now also draws simple, note-like sketches on a variety of the computer and programming related subjects. Those are great as kick memory refreshers or reminders for “I wanted to learn more about that” kind of things. Here’s her take on pipes, for example:
Worth an RSS subscription!
Here is a quick overview of the Linux Boot Process, if you are a little rusty. After all, it’s not every day that you need to look into, troubleshoot or adjust the boot process of a Linux box. This might come handy before your next SysAdmin job interview too.
Computer Science from the Bottom Up — A free, online book designed to teach computer science from the bottom end up. Topics covered include binary and binary logic, operating systems internals, toolchain fundamentals and system library fundamentals.
The #! magic, details about the shebang/hash-bang mechanism on various Unix flavours
Linux Insides – a little bit about a Linux kernel
unix-history-repo – a git repository representing the Unix source code history