That’s probably a fair point. I can’t say too much as I haven’t touched Windows desktop or server too much.

Could be apples vs oranges here though as we’re talking about getting started versus well established setup, but my current employer is looking at adopting Ansible + Packer for imaging and partially Ansible-managing Windows servers where it makes sense because of limitations in SCCM and GPO. As far as I can see across the divide Windows Server isn’t all smooth sailing.

I can’t say I’ve managed Linux desktops at scale (so technically I should leave it there) but I do manage several hundred Linux VMs with Ansible, and I manage all of my PCs with Ansible. Desktops are a different ballgame to servers, dealing with end users and all, but I still don’t think it would be that hard once it’s been set up.

That sucks :( I’m pretty much in the same boat. I get to use a Linux desktop at work on the proviso that I don’t raise support requests. We use Microsoft for nearly everything so naturally it’s an uphill battle. The web UI is quite buggy and “not recommended” by my org. Teams doesn’t support Firefox so I have to run a separate browser especially for it.

But aside from interfacing with Microsoft everything just works, and really nicely.

That’s awesome - great to hear about Linux desktops bring used by non-techies especially in a company.

How was it received out of interest?

Securing proprietary hardware against peeps installing alt OSes

Yeah me too, safety in numbers. Maybe if Linux desktop gets bigger than Windows they’ll swap it around 👨‍💻

Something that often gets missed is the difference between packaging conventions between distros.

For example, Debian has Apache httpd packaged as “apache2” and has wrapper scripts for enabling sites. Fedora/RHEL has “httpd” and includes conf.d from the main conf. Arch also has “httpd” but doesn’t have a conf.d out of the box. Of course you can pretty much configue Apache to your heart’s content and have an identical setup between all three distros.

From what I’ve read, Debian tends to patch and change software to fit more into their overall system whereas Fedora and Arch tend to be more upstream.

RPM and Arch both have group packages and metapackages. Debian just has metapackages AFAIK. Debian also has “recommended” and “suggested” levels of soft dependencies, the former which is enabled by default. RPM has the capability for weak dependencies but AFAIK most RPM distros don’t use it. Arch doesn’t have soft/weak dependencies AFAIK.

When you install a new system daemon on Debian, it’s generally enabled and started by default, whereas RPM-based and Arch don’t do that.

When I think of the base of the system I tend to think of some of those more subtle idiosyncrasies that tend to spread around the ecosystems, like Ubuntu and Debian behave quite similarly for instance.

Last edited 2014-01-12 12:30:18 UTC