Linux on the Mac – State of the Union | Hacker News Reader

Linux on the Mac – State of the Union

lwn.net

44 pointsRedoubts12 comments

I have taken jobs where they have automatically requisitioned a Mac for me as if it is what I am expected to want to use as a coder, the first thing I would try and do is install linux on it as I find OSX painful to get modern Ops environments set up on - this article shows now how much more effort it would be to even get a working environment setup.

Saying that I am currently using Windows with a very smooth Virtualbox environment running Ubuntu so that is always an option now processors are fast enough to run them :)

Which modern Ops environment do you find difficult to set up on macOS and easy on Linux ?

Maybe difficult isn't the best word, but it's sure a pita to be on !mac on most teams these days, at least at the beginning of a new gig when you're first getting everything setup and don't know enough about the app yet to get it running yourself..

If the various dev and ops (or multifunction) teams are using macs then a few things will probably not work on your !mac without a bit of messing around.. Some random examples: any kind of makefiles, shell scripts that have hardcoded paths to things, assumptions on how to start up VM's / Docker containers, how to check for deps, the 'local dev guide' on confluence that has you clone some repo and run a script that does a load of 'brew' commands to setup virtualenv or vagrant, or whatever and so on ad nauseum. You know how it is...

It's not a problem, really, for most of us -- since we can fix all that stuff and having people on the team which will be forced to change these things to work on different OS's makes everything better, but it's a bit of a PITA and doesn't really contribute to the client.

Even when you get it working on YOUR linux but the other dev on linux is using fedora while you're on arch and you're back to abstracting how to run pkg commands and so you contemplate rewriting the while thing in ansible or something, then your brain explodes and you just do it by hand and move onto more important things....

edit: I know the OP says that they find OSX difficult to get setup on and my point is the reverse of that.. shrug docker to the rescue, it seems..

Every minute of prerequisite to get someone new to the project to the point of "I edit code and see its influence on the program's behavior" is toxic waste. Minutes spent getting or recovering a working desktop shell are radioactive toxic waste.

Smart companies ruthlessly optimize and automate these things. IMO it's usually unconscionable not to. Maybe that means Puppet manifests for the laptop model and linux distro the company has chosen to issue developers. Maybe it means a handcrafted AMI for cloud dev VMs where everything already "just works" + a pointer to a decent code sync tool for local editing. Maybe it means shell scripts for OSX. Or some combination. It also usually means the ability to hand off your current "broken" computer and get a new one with minimal friction and in less than half an hour.

But it any case, throwing away the work that was done for you and lighting your own time on fire (or worse, expecting others to light their time on fire) to satisfy your personal taste in operating systems is almost certainly a bad idea, and something employers should not humor.

And if the automation work hasn't been done yet, the employer should insist that the next person to stumble through setup leave behind a script that will work for everyone else (i.e. in the environment that everyone else is using).

My company lets new hires choose to be issued Thinkpads with Ubuntu. Inevitably within the first few days of training or work something doesn't work as expected, and they are rightly told to go back to IT and exchange it for a Mac, because it isn't anyone else's job to help you make your nonstandard environment choices functional.

Nonsense. Don't force employees into any particular environment. While a good developer will always be able to adapt to using a new set of equipment, I'd wager that the productivity gain from allowing them to customise it will exceed any costs involved in helping them set it up.

Anyway, I reckon the time spent writing automation scripts would be better spent fixing your application so that it's dev setup process is less broken :)

I'm with you. Besides, if someone asked me to run some puppet or whatever on my laptop at a client; I'm not sure I'd be able to stop myself from getting physical...

Docker is really found a sweet spot here though. You can pull in, move around, clone, bla bla whole working environments, or just skels which are ready to run/compile your code with a simple bunch of commands and it works pretty agnostically across almost all clients.

Doing a 'docker run someapp:prod' should be within grasp of anyone without the load of 'stuff'/config mgt that we had to deal with back in the vagrant dayz..

Exactly! Sure, I can use eclipse. But I'll probably write 10x code if you let me use vim, exactly as I've configured it on my own laptop. I did configure it that way for a reason.

Not so sure I really follow this.. I think you might be taking that to a bit of an extreme here. The problem you describe is the reason why we ended up with things like vagrant, and why docker is a good tool to get various setups to a 'common state' for work these days.

Even with those tools though -- there are probably a few setup things that will need to run before I can start using these things and forcing everyone to use something they might not like/know just to make that setup bit quicker seems like shooting yourself in the foot.

I'm a better developer when I'm working in my personalised environment (which I've been tweaking to my own and really specific requirements for over a decade, and that applies to most of us) than I am when being forced to adopt someone else's.

We're a pretty picky bunch, some of us will want intellij and others emacs. Maybe someone wants to use BSD or Gentoo or OSX. You consider it radioactive toxic waste for devs to have their own work environment instead of adopting what the first person on the project uses?

I'll conceed there might be a time saving in the first day on the project, but that barely counts in the bigger scheme.

As an employer, I want my devs to work in whatever way they're most comfortable (and thus, productive) doing so. Forcing tooling across the board produces the reverse effect.

edit: and not to be too harsh, but if your developers can't even run their code on their machines then perhaps you hired the wrong developers...

> using Windows with a very smooth Virtualbox environment

What are you using? I just installed Vagrant and the experience is almost there, I have some problems with file permissions (can't delete on Linux side, can't remove executable flag, etc).

Virtualbox with a Ubuntu Desktop install on it, virtual dual monitor setup to match my physical dual monitors, 256 video memory and a decent set of my Alienware's CPU and Memory assigned to it. Feels native :)

    > The MacBook Pro introduction in October caused unusually
    > negative reactions among professional users
    > ...
    > Perhaps that's a good moment to look at the current state of
    > Mac hardware support in the kernel

Start by bashing the MacBook Pro, and still want to use the hardware. What?

He is making a observation. Many people saw the October as a disappointing 'bump' to the Macbook lineup.

Reply on news.ycombinator.com