So what is so much better on Linux than Mac? You can use nvm, etc
Yeah, right.
>not being bound to Apple hardware.
Not an issue for years already, unless we are talking about some very specific hardware.
PS: not trying to advocate for either of systems, worked on both linux (ubuntu, arch, centos) and macOS. Both have their share of pros and cons.
A Hackintosh is a breach of the EULA, and no company should allow one to be used for their development, as it can create a potentially massive liability for them.
Having said this, I also don't agree with using Hackintoshs.
Having to press `fn` key in addition to backspace key is not a big deal at all, and I like more `fn` in combination with cursor keys than separate PgUp/PgDn/Home/End keys.
>Yeah, right.
Minimal Arch Linux with a minimal desktop and rolling updates.
> >not being bound to Apple hardware.
>Not an issue for years already, unless we are talking about some very specific hardware.
It is an issue, if you have a budget and you want a fast computer for compiling and so on. Right now I'm having a modern 4GHz i7 with 32 gigabytes of ram, a m.2 SSD and two monitors where the other is a 30" IPS. Having the fastest computer in the office is pretty nice, with a price of a macbook and monitor.
>Minimal Arch Linux with a minimal desktop and rolling updates.
I switched to Arch after Ubuntu 10.04 (or 10.10, I don't really remember when they brought Unity up). And yes - it's much better in this regard, but you still see an update on their main page from time to time that will tell you this and that about some big changes and instructions to handle this. OSX\macOS didn't have anything like that in years now.
[0] http://apple.stackexchange.com/questions/69223/how-to-replac...
Better say that environment will be the same, I guess.
That being said - as an ex-Linux user (for about 10 years) I see now real reason for this kind of switch. You can have the same (or almost the same) env on you macOS.
Kernel - obviously, as I said earlier. As for packages and libs - Brew + something like pip\rvm\whatever will most likely solve this for you. You won't have the same lib, because it was build for a different env, but the way it works should stay the same. If not - I'd rather consider using different lib.
This + docker(or something similar) as someone already mentioned.
Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway.
Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for.
[0] We usually develop on Windows and deploy on UNIX.
Running the same libraries, on the same base OS is invaluable to me - but that can depend on what you are developing.
> Also, unless IT agrees to put beefy machines under each one's desk, the server is quite different from what developers can use anyway.
With "the cloud", these days that is not necessarily true. a t2.large / m2.large are 2 cores, 8GB RAM. - well within the reach of a basic laptop.
> Finally if there is any issue that really needs testing on the server, that is what remote connections (including remote debugging) are for.
Never debug in production. No developer should have access to production.
Which is why we just connect to "cloud" and clone our own instance from a production server, if we really need to.
> Never debug in production. No developer should have access to production.
Maybe in a perfect world.
On real life I have been in projects where developers were exchanging dlls and jar files on them.
All of these issues tie together.
Developers can't access production, so they start using production like environments, which allows for proper Ops work (Infrastructure as code - e.g. config management), which allows for easier setup of production like environments for developers ... and continue cycle.
Its hard to move to that, and takes time, but it really helps. I know it can seem overkill, especially for small teams, but the tech debt paydown that happens when you end up doing it in the future can be huge, and massively disruptive.
Our main hardware guy would have liked to make sure all the DASD (Disks) where from the same production run as well.
* There are substantial subtle differences between Mac and Linux that will eventually trip you up when leaping the divide between development and deployment.
* The Mac often has ridiculously old versions of tools because of its GPL allergy.
But hey, Macs are shiny and popular.
I will say their screens are a step above 90% of other laptops, not that it makes a huge difference when you are reading text.
> Package management isn't a train-wreck (I always have
> troubles with brew
> The Mac often has ridiculously old versions of tools
> because of its GPL allergy.
I would actually love to ditch macOS - I used Arch on my MBA for some time, but in the end it was better drivers and brew that brought me back. I seriously miss i3wm though.
Brew is the best package manager I've ever used - so simple to add your own or edit existing formulae if what you want isn't available.
* Conflicts with other software installed causing all sorts of weirdness.
* Numerous packages not in the main repo that weirdly have to be installed by some other mechanism (pip, cask, etc.).
* Dependency on XCode. There's like a 5 step installation process to get it up and running!
* brew install rsync -> rsync [xyz] -> why isn't this working? -> oh wait, the version of rsync on the PATH is still the ancient system one for some reason.
* whatever brew doctor does. the fact that command even exists is a big red flag to me.
^^ This is just the stuff I've run into recently when I've had to debug stuff that was working just fine on linux but somehow broke on a somebody's mac.
> Conflicts with other software installed causing all
> sorts of weirdness.
> Numerous packages not in the main repo that weirdly have
> to be installed by some other mechanism (pip, cask,
> etc.)
> Dependency on XCode. There's like a 5 step installation
> process to get it up and running!
I think the only way around this would be for brew to ship a compiled binary, and then mandate that you install either XCode Command-Line Tools, or gcc. (Some formulae will need to compile.)
> brew install rsync -> rsync [xyz] -> why isn't this
> working? -> oh wait, the version of rsync on the PATH is
> still the ancient system one for some reason.
> whatever brew doctor does. the fact that command even
> exists is a big red flag to me.
> Please note that these warnings are just used to help
> the Homebrew maintainers with debugging if you file an
> issue. If everything you use Homebrew for is working
> fine: please don't worry and just ignore them. Thanks!* This is basically just a cross section of problems I came across helping other people who used a Mac over the period of a few days. I can only imagine how bad it is using it day to day.
* Everybody just accepted that these types of problems happened with a shrug. Except me because I've gotten used to them not existing (I almost never get PATH related issues on ubuntu).
* They may all have a solution but they shouldn't exist in the first place.
* They may not even be brew's fault per se, but it's still all part of the pain you have to deal with when using a mac which makes me want to toss it out the window.