2 ms·

On the contrary - we use kubernetes heavily and our development environment matches production about as closely as possible for the architecture we have. But we

by xmodem 6y ago

On the contrary - we use kubernetes heavily and our development environment matches production about as closely as possible for the architecture we have. But we’ve got to bootstrap minukube and seed configuration and data to uninteresting dependencies somehow. Using different scripts for that in development and production would be moving in the wrong direction, but I do often wish they were written in Python.

Alupis 6y ago
Has your team considered using a standardized VM to develop in? Your team could then freely use whatever computer/OS they wanted, but also keep everyone's development systems consistent with each other, as well as avoid any strange Apple-induced issues that come with running Apple hardware as a developer in 2020. You're really fighting an uphill battle with macOS these days... as sad as that might be for some. You've spelled it out in a few different posts - macOS breaks everything for your team. So why fight it? Get a different OS to develop in... or dumb down everything because macOS uses crusty, old utilities.
- xmodem 6y ago
  > Has your team considered using a standardized VM to develop in? How is that not what we're already doing? Minikube runs in a VM. But we have to set it up somehow. Running a minikube VM inside a maually configured linux VM makes no sense - if we did that, now we'd need a scipt to boottrap the linux VM. > You're really fighting an uphill battle with macOS these days... as sad as that might be for some. I can definitely see this becoming more and more true in many fields, but this hans't been an issue for us.
  - Alupis 6y ago
    > How is that not what we're already doing? Minikube runs in a VM. But we have to set it up somehow. I was implying a development environment inside a VM, not just a VM for testing. You posted several times about how macOS isn't compatible with your production environments scripts and what-not. The solution is to either not use macOS, or use a standardized VM every developer on the team uses to develop inside of, so that your scripts work "out of the box". > I can definitely see this becoming more and more true in many fields, but this hans't been an issue for us. Your posts seem to contradict this. Perhaps you were exaggerating the pain it causes the team when production scripts don't work on developer systems. Either way - it seems the writing is already on the wall. Apple isn't going to make it easier any time soon - so ditch the mac's.
    - xmodem 6y ago
      > You posted several times about how macOS isn't compatible with your production environments scripts and what-not. The solution is to either not use macOS, or use a standardized VM every developer on the team uses to develop inside of, so that your scripts work "out of the box". Another solution would be to write those scripts against a language and standard library that doesn't have wildly varying behaviour between its underlying platforms. One of my side projects has a bunch of supporting scripts in Python doing similar things and they run exactly the same on Linux and macOS. They even run fine on Windows with only minimal modifications. > Your posts seem to contradict this. Perhaps you were exaggerating the pain it causes the team when production scripts don't work on developer systems. Either way - it seems the writing is already on the wall. Apple isn't going to make it easier any time soon - so ditch the mac's. With this statement I was referencing specifically the complaints that have surfaced in the past few years about new OS changes and security features breaking tooling. I don't count our infra team using new bash features in this because the issue with outdated bash/unix tooling is a long-standing one. I can't speak for others, but for me personally, the usability of macOS for almost all of the things I do on a day-to-day basis is just day-and-night better than anything else, even if I have to hack up a bash script to work correctly from time to time. I will say the difference is less than it used to be - I use it occasionally and Linux has come a long way in the past 10 years.
- cle 6y ago
  This is basically what writing a Python script is. Python code is compiled into Python bytecode and interpreted by the Python VM, after all. (I know what you mean by VM, but I don't think the distinction is very important here, you get the same benefits either way, and using Python is arguably a lot simpler than using a full VM.)

by xmodem 6y ago

Alupis 6y ago

Has your team considered using a standardized VM to develop in? Your team could then freely use whatever computer/OS they wanted, but also keep everyone's development systems consistent with each other, as well as avoid any strange Apple-induced issues that come with running Apple hardware as a developer in 2020. You're really fighting an uphill battle with macOS these days... as sad as that might be for some. You've spelled it out in a few different posts - macOS breaks everything for your team. So why fight it? Get a different OS to develop in... or dumb down everything because macOS uses crusty, old utilities.

xmodem 6y ago
> Has your team considered using a standardized VM to develop in? How is that not what we're already doing? Minikube runs in a VM. But we have to set it up somehow. Running a minikube VM inside a maually configured linux VM makes no sense - if we did that, now we'd need a scipt to boottrap the linux VM. > You're really fighting an uphill battle with macOS these days... as sad as that might be for some. I can definitely see this becoming more and more true in many fields, but this hans't been an issue for us.
- Alupis 6y ago
  > How is that not what we're already doing? Minikube runs in a VM. But we have to set it up somehow. I was implying a development environment inside a VM, not just a VM for testing. You posted several times about how macOS isn't compatible with your production environments scripts and what-not. The solution is to either not use macOS, or use a standardized VM every developer on the team uses to develop inside of, so that your scripts work "out of the box". > I can definitely see this becoming more and more true in many fields, but this hans't been an issue for us. Your posts seem to contradict this. Perhaps you were exaggerating the pain it causes the team when production scripts don't work on developer systems. Either way - it seems the writing is already on the wall. Apple isn't going to make it easier any time soon - so ditch the mac's.
  - xmodem 6y ago
    > You posted several times about how macOS isn't compatible with your production environments scripts and what-not. The solution is to either not use macOS, or use a standardized VM every developer on the team uses to develop inside of, so that your scripts work "out of the box". Another solution would be to write those scripts against a language and standard library that doesn't have wildly varying behaviour between its underlying platforms. One of my side projects has a bunch of supporting scripts in Python doing similar things and they run exactly the same on Linux and macOS. They even run fine on Windows with only minimal modifications. > Your posts seem to contradict this. Perhaps you were exaggerating the pain it causes the team when production scripts don't work on developer systems. Either way - it seems the writing is already on the wall. Apple isn't going to make it easier any time soon - so ditch the mac's. With this statement I was referencing specifically the complaints that have surfaced in the past few years about new OS changes and security features breaking tooling. I don't count our infra team using new bash features in this because the issue with outdated bash/unix tooling is a long-standing one. I can't speak for others, but for me personally, the usability of macOS for almost all of the things I do on a day-to-day basis is just day-and-night better than anything else, even if I have to hack up a bash script to work correctly from time to time. I will say the difference is less than it used to be - I use it occasionally and Linux has come a long way in the past 10 years.
cle 6y ago
This is basically what writing a Python script is. Python code is compiled into Python bytecode and interpreted by the Python VM, after all. (I know what you mean by VM, but I don't think the distinction is very important here, you get the same benefits either way, and using Python is arguably a lot simpler than using a full VM.)