5 ms·

> The difference is that on Linux/OSX you don't need to install extra tools like mysysgit/cgywin or a different terminal emulator (ie, Cmndr or other 'Terminal'

by Encosia 12y ago

> The difference is that on Linux/OSX you don't need to install extra tools like mysysgit/cgywin or a different terminal emulator (ie, Cmndr or other 'Terminal' replacement on OSX), because the toolset is already there (bash, awk, sed, etc). Of course you're right that things like bash aren't present on a fresh install of Windows. I just don't see much issue with needing to run one Cmder install though, because I know almost no one who uses the built-in terminal app on OS X either. Installing your preferred terminal is somewhere around step 2, after installing your preferred browser. At that point, it's a wash. > Additionally, I don't believe you would be very supportive of the experience on Windows if you were more familiar with what is possible on Linux, OSX or any other Unix, and if you had strong understanding/knowledge/command of the toolsets available on those ecosystems. That's a huge assumption. Over the years, I've spent a ton of time with everything from DOS 1.0, to the Amiga CLI + REXX, to Solaris and AIX, to Slackware/RedHat/Ubuntu, to OS X, and to Windows. I first learned assembly on SGI Indigos running Irix and first accessed the web via Mosaic running on SPARCstations. I feel fairly confident in my perspective when it comes to the nuances of various platforms, but I currently prefer Windows. I mean this in the least confrontational way possible, but that's precisely the kind of off puttingly patronizing "you'd understand if you didn't use Windows" shtick I often see from Mac/Linux users that motivates me to comment on these threads. Heck, just last weekend I was ripping a buggy apt-installed xcache out of the Ubuntu/Linode apache server that hosts my blog and replacing it with a compiled .so to fix a bizarre edge case where xcache was breaking one of my WordPress plugins (and sucked up two weeks, on and off, of debugging with the plugin's author). In my experience, these type of opaque problems are tremendously more common on *nix than on a modern Windows Server. BTW, I use ssh from the Cmder command line when I log in to that Linode VPS, just like you might from the command line on any other platform. > 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.

kenshaw 12y ago
>> 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.

by Encosia 12y ago

kenshaw 12y ago

>> 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.