>> For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Converse

>> For instance, installing PostgreSQL/MySQL/Apache/Nginx/or whatever on Windows is extremely painful, cumbersome, and not standardized across systems. Conversely, compare this: (yum|apt-get|port) install (postgresql|mysql|apache|nginx). > Come on. No one who has ever installed any of those things in production would pretend it's so simple. You're going to spend so much time on configuration that the difference between apt-get and running an .msi is negligible. Actually, no. This discussion is about development and configuration of a workstation for development and the necessity to have the developers run the same unit tests that also need to run the same on the integration servers (not Windows). For the vast majority of cases, actually yes, all one needs is a apt-get/yum/port install of the package dependencies and that's it -- most if not all "out of the box" configuration for most developers will work just fine for the development environment (ie, the developer's workstation). Additionally, those system package managers provide a much simpler and easier way for a developer to manage system updates (have you ever used Windows update? it's unbelievably slow). And, to your above reference, re: Ubuntu, while I've personally never had any issues with using Ubuntu as a production server, I wouldn't recommend doing that (and do not use it where I have direct authority/control or choice), because for production one would want 'debian stable' (and is what I have recommended for years). One would not want a headless server environment to use Ubuntu, as the differences that make 'Ubuntu' vs 'debian testing' are primarily downstream additions that are only good/applicable to the desktop and do nothing to help the underlying stability of the system. To emphasize here, I am not discussing simple one-off Wordpress deployments for your hobbyist blog that likely no one reads, and that you most likely don't even need xcache for. I highly doubt you have the traffic volumes wherein xcache would actually show significant improvement/performance over nothing at all (do you even understand what xcache does?). And if you did, you should likely move on to HHVM (which, btw, is production ready, and works out of the box for the most popular distributions). Quite frankly, the fact that you are discussing compiling a .so for xcache on Ubuntu shows just how far behind the time you are on the state of Ubuntu and PHP as there are working xcache apt repositories that you can use quite simply, please see: https://www.dotdeb.org/ https://www.dotdeb.org/ . Your anecdotal failure of having a problem building a single .so (which you shouldn't have been wasting time compiling yourself anyways), is only representative of your particular issues and is not at all representative of how software is actually used, developed, tested, and deployed in large, significant (monetarily, culturally, politically, etc) systems. Additionally, the most basic "best practices" for system administration would call for the use of packages wherever possible. Manually compiling extensions (or other dependencies) that you did not write (xcache), directly, on your production linode instance, really shows that you are likely treating your server instances as pets and not as cattle, which doesn't really work in the cloud / server 'farm' paradigm. It also shows that you're likely not working in a large, audited secure environment wherein all commands/actions/configuration changes need to be signed off / logged. I'm also going to guess you do not understand the intricacies of continuous integration/deployment, security, and many other basic aspects/tenets of system administration, and, thus, do not fully grasp why what you did -- manually compiling a .so on a server -- is such a no-no. Please understand, I am coming from a background of building large, mission-critical software projects with large, geographically diverse teams who have varied skillset levels (from newbie to guru), and that the necessity to conform to corporate and governmental regulations (audit or otherwise) is non-negotiable, and thus certain things must be done (automated testing, etc) which in turn limits the scope of what can be done with minimal resources/time. Bringing this back to relevancy and 'Spartan', this is why without working ports that fit into existing toolchains (unit testing on Unix-likes), it will never be a relevant (nor in my book, "modern") browser unless it magically gains significant market share overnight. I find that highly unlikely since Windows is a dying platform, and the majority of users have shifted to mobile. I also find it highly unlikely that Windows will start to outpace Android or iOS anytime soon as a mobile platform. While I welcome the new browser, Microsoft is unlikely to gain the needed marketshare unless they give developers the features/tools they need to integrate into existing, well-developed workflows/infrastructure. That isn't going to happen without a Unix port.