I think a lot of the MCP arguments conflate MCP the protocol versus how we currently discover and use MCP tool servers. I think there’s a lot of overhead and friction right now with how MCP servers are called and discovered by agents, but there’s no reason why it has to be that way.
Honestly, an agent shouldn’t really care how it’s getting an answer, only that it’s getting an answer to the question it needs answered. If that’s a skill, API call, or MCP tool call, it shouldn’t really matter all that much to the agent. The rest is just how it’s configured for the users.
Well AD is just a really opinionated LDAP/Kerberos setup, so you’d think that there would be something that Linux could do.
But when you’re talking about enterprise management of thousands of devices, you need some kind of consistent security policy management. That requires running OS software that accepts remote policy management, which is a very specialized configuration and not just “vanilla Linux”.
You can get really far with LDAP, but I’ve only used it for remote accounts, file shares, and sudoer config. I’m sure there are more policy configurations that would be possible with a more advanced tool.
I suspect the RHEL world has something to offer here, but I’d love to see a more general and commonly supported solution developed. It would make Linux more of an option for enterprise managed endpoints.
But, I agree with you - for an enterprise customer, this really needs to be some kind of paid/supported product. I wouldn’t want the French government to rely on some scripts that worked on my small cluster.
Windows uses Group Policy (which isn't particularly secure for many reasons) while Linux uses configuration files (e.g. udev, AppArmor, stuff in /etc like fstab) in conjunction with file permissions. However, you can go way farther by compiling your own kernel that has certain functionality removed (e.g. USB mass storage).
Managing lots of configuration files/scripts across many thousands of servers, desktops, devices, etc is a long-solved problem. Most enterprises use Ansible or similar.
In almost every way, managing many thousands of Linux desktops is much simpler and more straightforward than Windows. If you're using Ansible playbooks, you can keep everything nice and tidy in a single place and everything you'd ever want to customize is managed via a plaintext file you can modify with your editor of choice.
You can organize them however you want or even use a GUI to change stuff (if you pay for Ansible Enterprise or whatever it's called... Or use one of the FOSS alternatives).
Managing Linux desktops at scale really isn't much different than managing Linux servers at scale.
> Ask me a decade ago what an enterprise should do, and my answer would be straightforward: AD, GPO, Exchange.
That was also the answer two decades ago. But if AD and GPO are now dead, what killed them and what are the options? Is the problem mobile and BYOD?
I’ve been primarily on Macs since that time where endpoint management isn’t much, so there are fewer knobs to fiddle with. In some ways it’s nice in that admins can’t screw around too much with my system. In other ways, I’m sure Macs feel limiting for those in charge of enterprise security. However, most endpoint management feels like it’s written for Windows with Macs as an afterthought for checklist security. Knowing that, I’m happy there are fewer places for dodgy software to be able to interface with the OS.
> "if AD and GPO are now dead, what killed them and what are the options?"
The changing world. AD and GPO come from the mid 1990s before pervasive internet, before WiFi, before Cloud computing, before people had multiple computers, before iPhones, before AWS cloud infrastructure, before Kubernetes, before cheap fast hardware for virtualization, before cheap bulk storage, before BYOD and WFH and everything-as-web-app. Before that was the world of isolated 8-bit machines, expensive Solaris workstations and Unix mainframes with expensive admins, and after say 1998 the world was cheap Compaq/HP/IBM hardware running Windows server and Windows 9x desktop, and after about 2003 it was Windows Small Business Server (AD, GPO, SQL, Exchange, SharePoint) and XP Pro desktops.
Cracks started showing when people wanted to logon to a laptop away from the office when it couldn't refresh policies, run logon scripts, talk to domain controllers; when people wanted 'offline files' from a company file share while away from the office, but wanted their corporate email to work when their laptop was online but not pull down company settings over a dialup modem. More cracks when they got a Blackberry or iPhone, more when AppStores appeared and people expect to be able to install whatever they like, more with the rise of Apple Macbooks, with the growth of website based services people can use from anywhere, more with Amazon AWS where company infrastructure is on someone else's premises, more with BYOD and WFH, more with people expecting software to be cost-free, being trivially able to spin up Linux web and database servers because there was plenty of CPU/RAM/Disk and no worries about licensing costs.
> "it’s nice in that admins can’t screw around too much with my system"
If it's a company device, it isn't your system. The company has legal oblications and practical concerns that conflict with your desires as an individual. That might be pushing full-disk encryption or updates, or auto-locking, or restricting use of USB or websites to block potential customer information leak points, or trying to stop you saving work locally that might be lost if the device fails, or trying to stop your device being an entry point for malware or ransomware, or trying to stop you screwing around with their system which costs them employee time to fix and your downtime while it's broken.
It was absolutely not the case two decades ago.
There were no other options for an enterprise fleet, 20 years ago, if the question was asked. If you weren't Google (who never asked the question anyway), the answer for managing 25,000 endpoints was to use Windows devices with Active Directory as the management plane. Anyone doing anything else was in for a world of hurt... and that's why every enterprise ended up on Windows, and why everyone targeting enterprise management targeted Windows -- because that's what the endpoints were already running.
What killed AD & GPO was Microsoft, in their bullheaded push toward Azure everything. Instead of listening to what it was that the enterprise customers actually wanted, they designed a system that made sense to them, but to no one else. The original UI was written in Silverlight. It was horrific.
No, I meant that Windows AD was still the answer two decades ago. I can see how that may not have been clear - I edited my post to include the quote I was replying to. (You said one decade and I was just extending that timeline back another 10 years.)
There was LDAP and Kerberos support for *nix management, but nothing you’d deploy over a thousand end devices.
And you’re right, it wasn’t a question that got asked, because there wasn’t ever a second choice - AD was the only option.
I remember it almost being a trope at the time that every Kerberos question thread eventually landed on some subtle / niche incompatibility or edge case.
No alternative, you can't realistically fully control everything everyone does on every device in their possession. It was job security for useless control freaks, the products never should have existed.
Or, if you knew the bitcoin addresses, you could figure out exactly how much oil is being moved. I would think oil data analysts would love to have access to that data (if they don't already).
It wasn’t always scummy… but there was a definite shift after they got bought. It’s kept getting worse since then.
Then again, this was something like 20 years ago. Back then, Sourceforge was something closer to GitHub today. It was the de facto public source repository. You could even get an on-premise version, IIRC.
Actually, this is sounding a lot like GitHub these days… not sure what that means.
For project discovery, definitely -- but not as a source code repository.
Wow, we're dating ourselves on this, but I remember when it was a big deal that SF.net added SVN support. They apparently didn't turn off CVS until 2017!
Yeah, I remember introducing a web dev company to SVN in about oh maybe 2006. Prior to that their "version control" was a webroot full of shit like "index.php", "index.php.old", "index.php.broken", "index.ryan.donottouch.php", "indexTUESDAY.php" and so on.
Yeah no, guys, that's not what I meant. Let me just show you this real quick...
I wonder if enough of freshmeat still exists on the Wayback machine to make a clone, maybe a skin for forgejo?
Sometimes the code must be received through the bank’s app. I went though this process recently to open a new account (at a bank where I already had other accounts). I didn’t think much of it at the time, but if you didn’t have or want a smartphone, this could be a major problem.
I’ve been doing something similar with a RAG system where in addition to storing the documents, we use an LLM to pull out “facts”. We’re using the LLM to look for relationships between different entities. This is then also returned when we query the database.
But I like the idea of an LLM generated/maintained wiki. That might be a useful addition to allow for more interactive exploration of a document database.
I think the easy answer is: because there are customers there. It’s a region full of major commercial and industrial companies. I can imagine that you’d want data centers close to where those customer are.
Technically, I can see challenges in power and cooling, but those can be overcome. The real question is-
Are there enough customers in the region to support local data centers? I think that’s clearly yes.
I thought PPC was supposed to be highly performant, but not very efficient. I didn’t think ARM (at least non-Apple ARM) was hitting that level of performance yet. I thought ARM was by far more efficient, but not quite there in terms of raw performance.
But I could be wrong… I’m going from a historical perspective. I haven’t checked PPC benchmarks in quite a while.
Are you guys sure you're not confusing product lines? PPC is a PowerISA architecture, but hasn't been pushing desktop/server level performance for, what, almost 20 years? It's an embedded chip now, and AFAIK IBM doesn't even make them any more. Power (currently "10th gen"(-ish)) is the performant aarchitecture, used in the computers formally known as i-Series, formerly known as RS/6000. It's pretty fast, not not price competitive. They aren't really the same thing.
"PowerPC" was a modification of the original IBM POWER ISA, which was made in cooperation by IBM, Motorola and Apple.
Motorola made CPUs with this ISA. Apple used CPUs with this ISA, some made by IBM and some made by Motorola.
While Motorola and Apple used the name "PowerPC", IBM continued to use the original name "POWER" for its server and workstation CPUs. Later IBM sold its division that made CPUs for embedded applications and for PCs, retaining only the server/workstation CPUs.
However, nowadays, even if the official IBM name is "POWER", calling it "PowerPC" is not a serious mistake, because all the "PowerPC" ISA changes have been incorporated many years ago into the POWER ISA.
So the current POWER ISA is an evolution of the PowerPC ISA, which was an evolution of the original 1990 POWER ISA.
It is better to call it POWER, as saying "PowerPC" may imply a reference to an older version of the ISA, instead of referring to the current version, but the 2 names are the same thing. PowerPC was an attempt of rebranding, but then they returned to the original name.
Thanks for the lecture. My point is that people often confuse PPC in the embedded space (still in production) with Power in the enterprise space (where noone I know refers to it as 'PPC' other than historical artifacts like 'ppc64le' (we run mostly AIX), and haven't since the G5 days). Same/similar ISA, very very different performance expectations. YMMV.
Honestly, an agent shouldn’t really care how it’s getting an answer, only that it’s getting an answer to the question it needs answered. If that’s a skill, API call, or MCP tool call, it shouldn’t really matter all that much to the agent. The rest is just how it’s configured for the users.
reply