3 ms·

Yes. I should have framed the issue more carefully: Are they as efficient as Windows' Active Directory and Group Policy? It's a bit of a hard-to-define question

Yes. I should have framed the issue more carefully: Are they as efficient as Windows' Active Directory and Group Policy? It's a bit of a hard-to-define question, and not many people have the experience to answer it. I've seen plenty of deployment and configuration management tools that definitely fit the definition - those are easy to make - but were inefficient for one reason or another; that's the hard part. One major advantage of AD/GP is the market power of being the tools for the dominant corporate OS: Every application vendor who hopes to put a toe in the corporate market makes their product work with AD/GP, including GPOs (Group Policy Objects) that provide the settings to manage their product, makes sure they work sufficiently well (at least they have incentive to try!), and supports them. If they don't, then corporate IT usually won't give them the time of day - it's a job requirement; their 'resume' goes in the circular file. Given Linux server share, I could imagine some good tools there. A secret of IT management - the difference between what even highly skilled hackers do at home, and IT administration - is that the time resource is highly constrained; it's the most valuable asset and you spend it very carefully. You don't have nearly the time to do everything you need to do; you certainly aren't spending it trying to make some application work with your Linux config management for purposes of - what? your FOSS hard/wide-on? what is the big ROI here for this major project that you're going to bring to the VP? - and do it over and over again for each application. It's not even a consideration.

jolmg 3y ago
> but were inefficient for one reason or another; that's the hard part. The efficiency of such tools is mostly just a matter of familiarity. It's like asking what programming language is most efficient to do e.g. web development. There may be arguments for X or Y language depending on the specifics of what you're going to do and what you value, but ultimately the most important factor that determines whether it feels efficient to work with or not is how familiar you are with it. > you certainly aren't spending it trying to make some application work with your Linux config management I struggle to think of them needing to be aware of one another. Configuration management is pretty much completely a matter of moving configuration files and running commands. It's pretty universal. There's no "make some application work with your Linux config management". Configuration management systems may provide application-specific helpers that make things neater, but if you can copy files, maybe template them, and run commands, you're pretty much set.
- wolverine876 3y ago
  > The efficiency of such tools is mostly just a matter of familiarity. That is just not true. Think of making that statement about any software - is the efficiency of all software roughly equal? > I struggle to think of them needing to be aware of one another. IT administrators have an order of magnitude less time than you seem to imagine, and an order of magnitude more systems and subsystems and components to manage than you imagine: It's not that they can't copy files and run commands, it's that they don't have time to learn to do that, manage it (including documenting procedures, changes, etc.), and implementing it for every action for every application on every system. It's not like your personal computers - the magnitude makes it a different thing entirely. The application needs to provide a management component that integrates with the admin's system management tool, just like your new railcar needs to integrate with the train tracks. Now if your railcar is really valuable, the train company might adapt it themselves, and IT admins do that, but it's a real cost. (OK, the railcar analogy is a bit of an exaggeration, but not as much as you think.)

jolmg 3y ago

> but were inefficient for one reason or another; that's the hard part. The efficiency of such tools is mostly just a matter of familiarity. It's like asking what programming language is most efficient to do e.g. web development. There may be arguments for X or Y language depending on the specifics of what you're going to do and what you value, but ultimately the most important factor that determines whether it feels efficient to work with or not is how familiar you are with it. > you certainly aren't spending it trying to make some application work with your Linux config management I struggle to think of them needing to be aware of one another. Configuration management is pretty much completely a matter of moving configuration files and running commands. It's pretty universal. There's no "make some application work with your Linux config management". Configuration management systems may provide application-specific helpers that make things neater, but if you can copy files, maybe template them, and run commands, you're pretty much set.

wolverine876 3y ago
> The efficiency of such tools is mostly just a matter of familiarity. That is just not true. Think of making that statement about any software - is the efficiency of all software roughly equal? > I struggle to think of them needing to be aware of one another. IT administrators have an order of magnitude less time than you seem to imagine, and an order of magnitude more systems and subsystems and components to manage than you imagine: It's not that they can't copy files and run commands, it's that they don't have time to learn to do that, manage it (including documenting procedures, changes, etc.), and implementing it for every action for every application on every system. It's not like your personal computers - the magnitude makes it a different thing entirely. The application needs to provide a management component that integrates with the admin's system management tool, just like your new railcar needs to integrate with the train tracks. Now if your railcar is really valuable, the train company might adapt it themselves, and IT admins do that, but it's a real cost. (OK, the railcar analogy is a bit of an exaggeration, but not as much as you think.)