Today we announced that Dapper will include full support for SPARC, and in particular for the UlstraSPARC T1 (the “Niagara” architecture) in all its multicore multithread glory.
I would credit the Linux/SPARC community (and David Miller in particular), and the OpenSPARC community, with the speed of this port moving from “first code” to production supportable. When I first saw David speaking about Niagara support at LCA in Dunedin in January, we all thought that Dapper could support traditional SPARC at release but then get Niagara support some months later in an update.
But the fervour with which the community at large under David’s leadership attacked the problem has meant that Linux on Niagara has progressed far faster than we expected – so much so that the first SPARC CD release of Dapper (which will be uploaded a little after the other architectures when we make the Dapper release) will support most UltraSPARC T1 machines out of the box. David – wow! Thanks for that leadership. I guess we have to add your SPARC work to the list of things for which the free software community have to thank Red Hat 😉
I should also thank Matthias Klose, Ben Collins, Jeff Bailey, and the unstoppable Fabio di Nitto for integrating that community work into Dapper and for making sure that the installer and userspace bits are all in good shape. I hope that the Linux-on-SPARC community will experience a bit of a resurgence now that these officially-supported options are out there and in production use.
The other aspect has been the OpenSPARC process, which essentially means that everything you need (all the documentation, the source code of hypervisors etc, and even the RTL defining the processor itself) is published under free software licences. So this is the first time that Linux has been ported to a TOTALLY open architecture. My hope is that this will allow Linux to keep up with the proprietary alternatives in supporting the very latest and greatest hardware features on SPARC on the day the machines first roll on out of the factory.
Now, if only more hardware manufacturers took that approach, we wouldn’t have to deal with the frustrations and shortcomings of binary (or worse – entirely unavailable) drivers on Linux.