6 ms·

> Watching someone manage their Redhat/centos servers from OSX (or even Windows) is just painful to watch, especially if something is wrong or down (which is us

> Watching someone manage their Redhat/centos servers from OSX (or even Windows) is just painful to watch, especially if something is wrong or down (which is usually when you need an admin the most). Why ? (Genuine question, I've been doing that for years (from Windows), never had a particular issue with it, even during crises. Not that I had the choice, if I did I would probably have installed Linux.)

lmm 8y ago
The subtle differences will bite you at the worst possible time. Things like a rarely-used command flag doing something different. I'm more of a developer than a sysadmin, but whenever I've had to use a different distro/OS on my development machine from what the servers were running, eventually I've hit a bug that only occurred on the servers and couldn't be reproduced on my development machine. And sure it's never impossible to diagnose and fix those bugs, but it's a bunch of extra effort that you just don't have to make if you're running the same distro everywhere.
- bionsystem 8y ago
  Oh I see, thanks for your answer. It's mostly a developper issue for you then, and it's your sysadmin job to provide you with the right tools ; but he probably won't take "just install debian everywhere" as a valid suggestion. A sysadmin just needs putty and then he'll build his infrastructure to make his life easier. He will never write or run code on his own machine, but on a machine similar to the production target. And he will rarely write code himself to begin with. You can ask your sysadmin for a FAAS (such as jupyterhub, or anything that you like) to be deployed on machines that are iso-prod. You can also ask him to provide a proper ci-cd toolchain (start small with the minimum, git to build to test deployment to unit tests). And of course matching your dev machine with the production will be beneficial if you can't get a FAAS, but your native OS may still be windows or macos, simply you will use virtualization or docker to make it compatible. As a sysadmin I face this problem a lot here. I work with python or R dev and we are providing them with server-side IDE (RStudio and JupyterHub), otherwise they will have something running on their windows laptop (provided by external teams, we have no control over that nor the right to change it), and expect it to run the same in production. But as a sysadmin I don't face the problem myself, because I don't develop much, that's why I didn't get the initial comment. Edit : just to clarify a point. Just a few months ago when I arrived, it was indeed really painful to see people write python or R code on their windows machines, and not be able to run their code on the server. Some of them even asked to have windows servers to get rid of that issue. That's the type of miscommunication that I'm talking about, because on the other side of the email, someone gave them the windows servers, not understanding/caring about their actual need. It was obviously the wrong solution but, in desperation and with the incoming deadlines, it became the right solution. So the problem isn't CentOS vs Debian vs your laptop, it's really about consistency in the toolchain and pipelines. The exact tool doesn't even matter (as long as it works).
  - lmm 8y ago
    VMs, remote IDEs, or FAAS are ways to develop on a server-like environment, but they all come with their own overheads; IME none has as good a debugging experience as being able to run the thing directly on your normal dev machine. (even for sysadminly scripting tasks, working via a putty window carries overhead and there are times when you'd rather be on the machine itself, though I'd agree that it's less common for it to be an issue there than for development work). You're right that the issue is consistency rather than the particular OS. But there is a real point here that Ubuntu in particular is functional as a first-class OS both on developer laptops and on production servers, in a way that none of the other options can quite match. (Windows' administration support/automation is lacking on the server, OSX servers barely exist, CentOS is outdated on the laptop, Debian is too principled to support laptop hardware, Fedora is undersupported on the server...). So it does make for a unique selling point for Ubuntu in practice.
craigsmansion 8y ago
Apart from having to hunt down things like "putty" off the Internet (Why am I installing a binary directly from the web that I'm going to use to directly type passwords in to?), and not even touching on exotic stuff like suddenly being in dire need of a serial terminal ("Wait, GNU Screen does that? I already have that installed!"), it can range from simple stuff like having "man mdadm" available right there on your laptop because the wifi is spotty, to searching for stray/mysterious files by installing the same software on you laptop and doing a locate (because locate might not be installed or running "updatedb" might be inappropriate to run at that time on the server). It's a thousand little things like that that make me feel like a fast typist/programmer who is watching someone hen peck entry forms when I watch someone administer Unix systems on Windows (and OSX, but to a lesser degree).
- bionsystem 8y ago
  I'm going to play devil's advocate here, but when you download debian it's mostly a binary from the web that you're going to type passwords into. But I totally get your other points. See my other answer above to get a partial solution. I think the main issue overall is the lack of dialogue between sysadmins and devs. I'm a sysadmin in a dev team and we don't have that issue together, because we are deploying the right tools and making it easier for everyone. But whenever we talk to the "others" sysadmin, I see a lot of frustration on both sides because they simply don't talk the same language. Those "others" sysadmins provide the whole underlying infrastructure, and it's "latest CentOS" and nothing else. They don't have time to explore, maintain and secure other options. They don't have time to be more specific about the tooling they can provide. They just give cpu/ram/storage in the form of a VM that you order from a ticketing system or a self-service portal. And then they spend their day rebooting unresponsive VMs and opening network incidents. So they couldn't care less about your python module that's not the exact same version as your laptop. (Heck, they don't even provide R or python, we have to build it and package it ourselves and include dependancies). So they get frustrated, and the devs get frustrated, and nobody can ever work together properly. Because the right strategy is not in place. But this has nothing to do with your laptop being this or that OS or the servers running CentOS instead of Debian. It's about your pipeline from your POC to your production code, and how people before you have tackled the issue (hint : most of the time they didn't).

lmm 8y ago

The subtle differences will bite you at the worst possible time. Things like a rarely-used command flag doing something different. I'm more of a developer than a sysadmin, but whenever I've had to use a different distro/OS on my development machine from what the servers were running, eventually I've hit a bug that only occurred on the servers and couldn't be reproduced on my development machine. And sure it's never impossible to diagnose and fix those bugs, but it's a bunch of extra effort that you just don't have to make if you're running the same distro everywhere.

bionsystem 8y ago
Oh I see, thanks for your answer. It's mostly a developper issue for you then, and it's your sysadmin job to provide you with the right tools ; but he probably won't take "just install debian everywhere" as a valid suggestion. A sysadmin just needs putty and then he'll build his infrastructure to make his life easier. He will never write or run code on his own machine, but on a machine similar to the production target. And he will rarely write code himself to begin with. You can ask your sysadmin for a FAAS (such as jupyterhub, or anything that you like) to be deployed on machines that are iso-prod. You can also ask him to provide a proper ci-cd toolchain (start small with the minimum, git to build to test deployment to unit tests). And of course matching your dev machine with the production will be beneficial if you can't get a FAAS, but your native OS may still be windows or macos, simply you will use virtualization or docker to make it compatible. As a sysadmin I face this problem a lot here. I work with python or R dev and we are providing them with server-side IDE (RStudio and JupyterHub), otherwise they will have something running on their windows laptop (provided by external teams, we have no control over that nor the right to change it), and expect it to run the same in production. But as a sysadmin I don't face the problem myself, because I don't develop much, that's why I didn't get the initial comment. Edit : just to clarify a point. Just a few months ago when I arrived, it was indeed really painful to see people write python or R code on their windows machines, and not be able to run their code on the server. Some of them even asked to have windows servers to get rid of that issue. That's the type of miscommunication that I'm talking about, because on the other side of the email, someone gave them the windows servers, not understanding/caring about their actual need. It was obviously the wrong solution but, in desperation and with the incoming deadlines, it became the right solution. So the problem isn't CentOS vs Debian vs your laptop, it's really about consistency in the toolchain and pipelines. The exact tool doesn't even matter (as long as it works).
- lmm 8y ago
  VMs, remote IDEs, or FAAS are ways to develop on a server-like environment, but they all come with their own overheads; IME none has as good a debugging experience as being able to run the thing directly on your normal dev machine. (even for sysadminly scripting tasks, working via a putty window carries overhead and there are times when you'd rather be on the machine itself, though I'd agree that it's less common for it to be an issue there than for development work). You're right that the issue is consistency rather than the particular OS. But there is a real point here that Ubuntu in particular is functional as a first-class OS both on developer laptops and on production servers, in a way that none of the other options can quite match. (Windows' administration support/automation is lacking on the server, OSX servers barely exist, CentOS is outdated on the laptop, Debian is too principled to support laptop hardware, Fedora is undersupported on the server...). So it does make for a unique selling point for Ubuntu in practice.

craigsmansion 8y ago

Apart from having to hunt down things like "putty" off the Internet (Why am I installing a binary directly from the web that I'm going to use to directly type passwords in to?), and not even touching on exotic stuff like suddenly being in dire need of a serial terminal ("Wait, GNU Screen does that? I already have that installed!"), it can range from simple stuff like having "man mdadm" available right there on your laptop because the wifi is spotty, to searching for stray/mysterious files by installing the same software on you laptop and doing a locate (because locate might not be installed or running "updatedb" might be inappropriate to run at that time on the server). It's a thousand little things like that that make me feel like a fast typist/programmer who is watching someone hen peck entry forms when I watch someone administer Unix systems on Windows (and OSX, but to a lesser degree).

bionsystem 8y ago
I'm going to play devil's advocate here, but when you download debian it's mostly a binary from the web that you're going to type passwords into. But I totally get your other points. See my other answer above to get a partial solution. I think the main issue overall is the lack of dialogue between sysadmins and devs. I'm a sysadmin in a dev team and we don't have that issue together, because we are deploying the right tools and making it easier for everyone. But whenever we talk to the "others" sysadmin, I see a lot of frustration on both sides because they simply don't talk the same language. Those "others" sysadmins provide the whole underlying infrastructure, and it's "latest CentOS" and nothing else. They don't have time to explore, maintain and secure other options. They don't have time to be more specific about the tooling they can provide. They just give cpu/ram/storage in the form of a VM that you order from a ticketing system or a self-service portal. And then they spend their day rebooting unresponsive VMs and opening network incidents. So they couldn't care less about your python module that's not the exact same version as your laptop. (Heck, they don't even provide R or python, we have to build it and package it ourselves and include dependancies). So they get frustrated, and the devs get frustrated, and nobody can ever work together properly. Because the right strategy is not in place. But this has nothing to do with your laptop being this or that OS or the servers running CentOS instead of Debian. It's about your pipeline from your POC to your production code, and how people before you have tackled the issue (hint : most of the time they didn't).