The platforms that we offer the personal proxy for is intentionally very limited, relative to the platforms that are supported for the client itself. As such, we provide platform support for the proxy on only the platforms that we feel have a significant enough popularity. Although this may seem harsh and arbitrary, there are many reasons for this:

• Deployment of the proxy does not need to be as widespread as the client: With the client, it is advantageous to have a client for every capable platform possible, since each additional machine adds more computational power to the network. With the proxy, even a large corporation or computer lab typically only requires a single well-placed proxy server to accomodate hundreds or even thousands of clients. It is therefore very exceptional that among that many (presumably non-homogeneous) machines, that there is no other machine that is running one of the platforms already currently supported for the proxy.
• The proxy needs to be held to a higher level of testing quality: Because proxy servers have the potential of invalidating or corrupting the work of hundreds or thousands of clients that are sitting behind them, it is necessary to have a high degree of testing by many different people to attempt to detect problems quickly. With less popularly used platforms, there will necessarily be a far fewer number of installations using that ported binary, and therefore a higher probability that a binary containing a platform-specific bug may go undiscovered for a long time before it is noticed.
• The proxy needs to be regularly maintained and ported: Also using the reasoning from above that a proxy server has the potential of invalidating a large number of clients, it is necessary for continually updated binaries be made available for all platforms being supported when a new build is made available. All of the popular platforms that are currently supported by the proxy are widely accessible to the proxy developers and can be easily and rapidly performed by any of several possible developers if needed. With less popular platforms, we can usually only obtain one volunteer and there has been a higher rate of unavailability/unreachability and a lower retension rate of being able to continue to maintain a port for the indefinite future.
• Platforms must have perceived longevity for the upcoming future: It is difficult to phase out support for a platform after it was supported once, since users will generally tend to continue to run a binary for their platform rather than stop using it, even if it has been announced that a specific platform will no longer be supported and should no longer be used, even when running obsolete versions might compromise the results of client data going through that server.
• The proxy codebase is also the foundation for the fullservers and keymaster: Since the same codebase is used as the basis for the primary servers within the distributed.net network, there is a higher requirement of maintaining high-performance code that can handle the millions of transactions per hour required of the primary servers. Because of this, there is less flexibility in allowing significant architecture redesigns to accomodate the esoteric requirements or differences exhibited by platforms that do not offer function interfaces that conform to the existing platforms supported.

If we become aware of new platforms that we do not currently support but offer the significant amount of popularity and widespread usage, we will be happy to provide official support for them at that time.