Wandering Thoughts archives

More on Linux FHS and /var

Through my Referer logs, I stumbled over this reply to my earlier entry on the FHS, which points out /srv as the answer to my criticisms. However, as the author of it notes:

[...] Then again I haven't seen any package management that does something to /srv [...]

Well, yeah. That's the problem; no one uses it. The FHS in theory might include /srv to deal with my exact criticisms, but it doesn't in practice because no one uses it. This is more than a matter of semantics and a little bit of configuration annoyance; as a commentator on my SELinux entry noted sort of indirectly, people have built software that assumes you are following the in-real-life FHS and thus are putting your data in the duly designated places in /var.

This points out my ultimate problem with the FHS and people assuming that it is always right: these people build software that requires you to follow the FHS without pausing to find out if people actually follow the FHS in real life and if the decisions that the FHS mandates actually make sense. When I don't follow the FHS for various good reasons, this software blows up in my face and makes me grumpy until I turn it off.

(I'm sure that there's people following the FHS and putting real data in /var; it's the path of least resistance, machines these days have huge disks anyways, and if you don't have that much data and you don't have significant infrastructure, you don't really care about these issues. I'll admit that we have some machines set up that way for exactly that reason.)

Update: I've been both unclear and somewhat too extreme here. See the comments for details.

Why I don't use either a thin client or a fat client

Back a month or so ago, Slashdot ran a story about how a lot of the people who are very positive on thin clients don't actually use one themselves and instead use what they call 'fat clients' (ie, regular computers). That started me thinking about the general issue because it sort of applies here; we have a thin client infrastructure, yet neither I nor any of my fellow sysadmins here uses it. In fact I don't use either a thin client or what I consider a 'fat client'.

Oh, my office workstation is a full computer, so it's 'fat' in that respect. But it's not a 'client'; instead, I've deliberately set it up as a completely independent non-client, a plain standalone computer. That it is standalone means that I can stay functional and on the network even if our infrastructure is melting down. In a pinch I'm not dependent on our fileservers for storage, on our local caching DNS servers for network name resolution, on our mail gateway for outgoing mail, and so on.

This is a very sysadmin thing to do. It's not the most convenient thing in the universe, and in practice a lot of my work is done on our login servers where I have all of the regular pieces of our infrastructure (storage, mail, DNS, etc). But every so often it becomes really very important that I am not dead in the water if the fileservers are down, and sometimes it's nice to have my own separate infrastructure for testing and the like.

(Admittedly, this is only half of the reason we sysadmins don't use thin clients. Honesty compels me to admit that our current thin client setup is decidedly pokey and slow and uncompelling.)

Sidebar: why people still use thin clients here

I'm sure that there are some people who like the simplicity of our thin client setup and who don't mind the (lack of) speed, but my perception is that a lot of the remaining thin client usage is because of funding issues.

The department doesn't centrally fund computers for people; instead it mandates that all researchers provide their grad students with some sort of computing access out of the researcher's general grant funds. If you're a researcher with next to no grant funds, thin clients are much the cheapest way to provide this mandated computing (and to get it for yourself). They're especially cheap in staff time, in that your Point of Contact doesn't have to spend any time ordering machines, setting them up for people, installing operating systems, and fixing system configuration issues (including virus infestations).

(Your Point of Contact may still help your grad students figure out the thin client environment, but at least they're not installing Windows. The thin client software setup itself is managed as part of core infrastructure, so it isn't directly paid for by researchers from their limited grant funds.)

As it happens, I believe that the research groups with the highest amount of thin client usage are also the ones that get the least grant funding.