The problem here is MacOS. The amount of work around and hacker I've had to do on Mac far exceeds anything on Linux and more surprisingly Windows. Let that sink in, it's easier to get things to work on Windows than Mac.
Aside from some expected path issues (builds too stupid to actually look rather than assuming a disk layout, etc) and some BSD <-> Linux issues (builds that assume all the world runs linux), I've had very little problem getting most things working on OS X.
It does help to learn what Apple has, uh, improved. This point is related to what an awful time I have getting anything to work on Windows - I hate it and don't want to learn about it.
At least in the article, there are hints that the author hasn't taken the time to learn about the platform they want to run code on. Which is fine - I feel that way about Windows[1]. But it is also a good idea to understand why you're having the problems you're having.
[1] Which is why I don't touch Win at work and the VM I run at home is a hacky mess that works for what it does, but only after a few aircraft carriers-worth of cursing and slash-and-burn hacking that I know can't be the 'right' windows-land way to do things. (The abomination is completely firewalled off from the outside world - I try not to be a disease vector.)
Having built applications for all three platforms I find they all require a certain amount of patience but once you understand the motions, it's relatively painless.
Totally agree. We had developers recently join our team, which primarily uses OS X and Linux. They were excited about using Windows since they had previously been developing in .Net. They now appreciate that development in Windows is not as easy as Microsoft wants you to believe.
The problem that won't go away anytime soon is that Microsoft spent years not making it easy on developers to develop in anything that isn't typical to develop in Visual Studio. They will not overcome that overnight. When a development team has focused on Windows, all is fine, but don't expect things to work without problems otherwise.
Maybe if Apple maintained their own ports tree, but they don't. There's no UNIX under there. There is a BSD kernel, a bastardized UNIX-ish base on top of an ancient file system (yes HFS+ has finally been replaced, but just this year) with a proprietary display system and yaks fucking turtles all the way down.
MacOS is a terrible developer OS. 10.6 and Expose and work spaces. 10.7 took this wonderful thing and replaces it with Mission Control; which only allowed one row of workspaces, no columns and windows were now grouped together so you couldn't see shit. No way to revert to the old behavior either.
Then Apple destroyed Final Cut. Goodbye video editing.
I switched back to Gentoo + i3 and never looked back.
I know there are now tiling window managers for MacOS. That's cool. I might try them one day. If I'm forced to.
Use vagrant or Docker or similar on the Mac -- this way you get reproducibility, snapshots, etc.
I'd do that even if I used Linux (in fact I used to use Linux and did just that).
Why would I want to setup my Desktop Linux box as my deployment/developer environment and have to change it and mess with it anytime I work on a new project / another deployment target?
>Then Apple destroyed Final Cut. Goodbye video editing.
As a professional video editor, I have to disagree with this too. They cut some features from FCP7 for the first FCPX release, but they brought them back, with more features and better implementations in subsequent releases. And all that with a codebase that's not some 2000's relic, but built for today's challenges.
Besides, I don't see what's much better to use for video editing on Linux.
A modern package manager, such as Nix or even most language-specific package managers, will allow you to set up some sort of sandbox for the project without having to take the performance hit of full-blown virtualization while developing. Of course, you'll probably want to spin up a VM while testing, just to be sure. And Nix can handle that for you too!
All while staying completely reproducible from your config files, all without having to bother with your virtualization program's snapshot system.
It is a little, but I've found that running headless (and no reason not to) drops this overhead considerably. And with 4 cores, 16GB memory and SSD, I hardly notice it.
Also modern containers like Dockers can drop the overhead to almost zero -- though I haven't really tried them to see how comfortable they are to work with.
Besides, if you natively run e.g. node, postgres, some work queue, etc, you're still gonna get the overhead on your host from those processes.
Nix sounds nice, but as you say you still want to spin some VM to know it all works in the final deployment setup. Not sure about your last suggestion "Nix can handle that for you too", will have to check Nix out more.
Docker makes this workflow a lot easier than multiple VMs. I'm running ubuntu with vagrant on macOS, and each project has a docker-compose file that spins up all the services. Stopping everything for one project and getting another one up is just one command, and takes a few seconds at most. With docker's layered fs, there is almost no space overhead.
Even if you don't use docker for deployment, you can just use a container as a psuedo-VM to use this workflow.
What do you use for video editing on Linux (that's in the same calibre of Final Cut Adobe Premiere)?
The video-editing software and support is vastly better under OS X than under Linux.
Nowadays, though, I run them on Vagrant (again on the mac) -- mainly to have snapshots and easy copying/reproduction of any target system. And even if I run Linux, I'd still run Vagrant on top of it for development too.
In my experience, it's far preferable to work with an isolated and repeatable process whenever possible. I really love Vagrant for this, since it scales from simple inline shell scripts to setup a VM, up to integration with your favorite flavor of provisioning software (Chef, Puppet, Ansible, etc.). I've setup environments that ran common provisioning toolchains that scaled from individual dev setups straight to production clusters. Similar motives drive a number of other approaches, esp. container-based systems like Docker.
Once you're fluent in these kinds of tools, you never really want to go back...
Ubuntu saves me so much time. (Also for some reason, Windows hates my graphics card and produces terrible sound in my BT headphones. Somehow a multi-billion company can't figure out BT while an open-source project can)
It's actually kind of revolutionary.
I have Windows 10 installed on a separate drive for when I want to play games but even then, I have to cater to Windows. Make sure to save constantly because sometimes Windows decides it is too much and causes my graphics card to flip. And I also have to plug my headphones in or else I get static-y mono sound.
Admittedly I could probably go buy "For Windows" headphones and figure out what is going wrong with the graphics card... but I shouldn't have to. We are talking about the latest operating system whose ancestors have been dominant across the world for decades, developed by one of the largest companies in the world. How are they getting it wrong?
You're also talking about them being able to perfectly support every modern piece of USB/PCI-e/etc connected hardware, which is no small feat even for the market leader. For comparison, I've never had these problems you describe since installing Windows 10. How can you be sure your success with Ubuntu isn't just good luck?
I've been doing sysadmin, programming, devops, etc professionally since 1995 and I've had to shave SunOS yaks, HP/UX yaks, Solaris yaks, Windows yaks, MacOS yaks, MacOS X yaks, Python yaks, Ruby yaks, Java yaks, Make yaks, C++ yaks, git yaks, cvs yaks, rcs yaks, ext2,3,4 yaks, Netapp yaks, Fibrechannel yaks, Cisco yaks, F5 yaks, nfs yaks, smb yaks, frame relay yaks (!), tcp yaks, rpm yaks, deb yaks, homebrew yaks, npm yaks, pip yaks, yum yaks, apache yaks, http yaks, xml yaks, tia568a no wait b yaks, serial crossover cable yaks, who the hell thought they could use 75 ohm as thicknet cable yaks, ... you get the idea.
We deal with a complex ecosystem with even more complex interactions that is often poorly documented at best. We're lucky when we can treat it as a black box and it all works. But often something breaks and suddenly we're hoisted by our own petard and there's yak hair friggen everywhere. I consider it a modern miracle that I don't have to pin ethernet duplex anymore! Glad we finally figured that one out.
Converse to your assertion, I switched to OS X back in 10.2 days because I got tired of shaving the hairball that was Linux desktop at the time. Oh, you want to print something? Here's an lpd yak for you... have fun! Oh you have a new monitor, here's some scanline settings to put in your xconfig that may work. Mac OS X is amazingly smooth as a desktop OS. [1]
But since you mention OS X, I'm reminded of of my favorite Apple technical note ever which began: ”As if it were a swarm of bees, you should stay away from the SyncServices folder in Mac OS X.” And that should apply to our whole industry, really... a swarm of bees.
Anywho, shaving yaks, story of my life, at least it pays well.
Pro-tip: when shaving yaks, take notes. I guarantee you you'll shave this yak again and it's handy to have your own reference to refer back to... even in these days of google, stack overflow, and quickly moving technologies. At worst, maybe it will be inspiration for a fun blog post some day. :-)
[1] So here's a fun story. Back in 2003 or so, I wrote a perl script which would forward emails to my phone via SMS. It did so by POSTing to a web form on a Verizon server. Worked fine when I was developing it on my OS X desktop, but failed to work on my Linux server. Yak shaving time. Eventually I'd broken out tcpdump after diagnosing that the Linux server, sitting on the network right next to the Mac, couldn't even connect to the Verizon server. Turned out the Linux server had ECN enabled, which being new at the time, Verizon's firewall was rejecting. Only had to peel about 5 layers of the onion on that one.
This is “yak shaving”: http://catb.org/jargon/html/Y/yak-shaving.html https://joi.ito.com/weblog/2005/03/05/yak-shaving.html http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_t...
I suggest you try linux again, find new yaks and update your arguments. You haven't had to mess with scanlines in over a decade. I've never done it. Heck, you don't even need to create an xorg.conf any more. And some time Real Soon™ even X11 will be gone.
I remember editing XF86Config, .fvwmrc, and PPP init scripts back in the long ago, but I'm damned if I could do so from memory today.
Use vagrant or Docker on the Mac -- you get reproducibility, snapshots, an environment fully compliant with any server you want to deploy to, etc, and you still get to code for it (editing source etc) from the Mac.
growing up at with a dad from DEC I actually learned how to use systems I've never used since :D but my dad ran Windows and hated macs (he worked at Xerox before DEC). so I grew up with dos and Windows for many years, then I switched to Linux when I was a teen.
I hated on macs and Windows (mostly macs) then, it was a shit show to my eyes and Linux was the ultimate (even though back then with my current pov Linux was the actual shit show, things broke and had to be fixed relentlessly)
I worked in more corporate type jobs for a while and used my Linux and Windows skills when needed, and then started in the OSS startup world and saw that everyone had a Mac, writing free software on a Mac, my head nearly exploded!
but I was given a shiny new MacBook Pro and so I had to give it a go. I was determined to hate it but once I found tools that let me use the command line I was fine with it. it was pretty slick, minus all the crap I had to do to get it working.
in the end I found they all have individual uses that the others aren't as good at and I use all 3 operating systems daily. the Windows boxes are good for some applications that just suck in wine, the Mac is good for applications that are written exclusively for macs but are very useful and I love that it turns on and is usable right when I open the lid (probably the only reason I bring it out with me when I leave my command center)
technology has gotten to an amazing point, especially if you're proficient enough to use and understand it (which admittedly isn't easy to do, but worth it if you can)
some of this stuff is just amazing, I run X11 on everything and I have a few very beefy servers that I use to just run my software on and display it on my main workstation.
using some newer tools I am able to use the video cards on my headless machines, I can run wine server on a dedicated wine box and run rdm or xencenter and when I decide to go mobile I just switch those sessions over to my Mac and use them there.
I have a IDE server that I run IntelliJ and all my other coding projects off of throug X11, it's got super redundancy and is more securely protected than my other boxes.
using automation tools like Jenkins, tasker, pythonista, auto input, auto remote, and Pagerduty I can get notified of any incident and automatically have the servers connected through dbus and yakuake send output to my phone with stalled processes etc..
its all good IMO