
Linux on the Mac – State of the Union - Redoubts
https://lwn.net/SubscriberLink/707616/cf37d7edcb88444f/
======
voycey
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 :)

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

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

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

~~~
matthewmacleod
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 :)

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

------
jxy

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

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

