6 ms·

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

by renaudg 10y ago

cyberpunk 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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..
    - hobarrera 10y ago
      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.
  - cyberpunk 10y ago
    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...

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

by renaudg 10y ago

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

superuser2 10y ago
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 10y ago
  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 10y ago
    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..
  - hobarrera 10y ago
    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.
- cyberpunk 10y ago
  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...