The End Of IT?

It's rare that I see a blog post with comments that are consistently smarter and more well-informed than the post itself. But, folks, we have a winner. This article by 37Signals' "David" is just such a mythical beast. It's so infuriatingly bad, so completely misinformed, and so utterly borne of ignorance and frustration, that I think I'll just go through bit by bit and explain why people should just stop posting this utter nonsense. (And, Gruber, shame on you for thinking there was anything even resembling a well-reasoned argument here.)

David begins his rousing critique of the IT industry thusly:

"When people talk about their IT departments, they always talk about the things they’re not allowed to do, the applications they can’t run, and the long time it takes to get anything done. Rigid and inflexible policies that fill the air with animosity. Not to mention the frustrations of speaking different languages. None of this is a good foundation for a sustainable relationship."

True enough. This is often what people talk about when they talk about IT. They rarely talk about how awesome it is that they have a usable network or rooms full of computers without viruses. But let's continue.

"If businesses had as many gripes with an external vendor, that vendor would’ve been dropped long ago. But IT departments have endured as a necessary evil. I think those days are coming to an end."

Typically, businesses don't have gripes with IT, end-users do. But, okay, I'm curious to hear your reasoning.

"The problem with IT departments seems to be that they’re set up as a forced internal vendor. From the start, they have a monopoly on the 'computer problem' – such monopolies have a tendency to produce the customer service you’d expect from the US Postal Service. The IT department has all the power, they’re not going anywhere (at least not in the short term), and their customers are seen as mindless peons. There’s no feedback loop for improvement."

I don't think that that's really the problem with IT departments at all. The problem is that many IT departments make crappy policy decisions that are user-hostile. But that's not because they have "all the power." In fact those decisions are often, I'd suspect, borne out of a need to satisfy certain technical goals using limited resources. The characterization that IT departments see their customers "as mindless peons" is offensive to anyone who works in this business, and generalizations such as these do as much to "fill the air with animosity" as any IT policy does. Clearly, the flip-side of "the problem" is an almost willful ignorance on the part of certain members of the tech biz — David, I'm looking at you — to make even the slightest effort to understand what IT departments do before making grand proclamations on the internet about the "end of IT." While I do agree that there should be better avenues for feedback, that doesn't mean I can always get what I want. And crying about it is a five-year-old's tactic.

"Obviously, I can see the other side of the fence as well. IT departments are usually treated as a cost center, just above mail delivery and food service in the corporate pecking order, and never win anything when shit just works, but face the wrath of everyone when THE EXCHANGE SERVER IS DOWN!!!!!"

You're goddamned right about that. I suspect that a well-respected, well-treated IT department would have warmer, fuzzier feelings for its "customers." But the fact is that, because people like David continue to see IT departments simply as "cost centers" and not as members of a single team with a shared goal, IT departments continue to be reviled, often by members of the very corporate structures upon which they depend. Unfortunately, this relationship has been sustainable for over twenty years. Probably because, in many institutions, it is a relationship that, though pathalogical in many ways, is necessary.

"At the same time, IT job security is often dependent on making things hard, slow, and complex. If the Exchange Server didn’t require two people to babysit it at all times, that would mean two friends out of work. Of course using hosted Gmail is a bad idea! It’s the same forces and mechanics that slowly turned unions from a force of progress (proper working conditions for all!) to a force of stagnation (only Jack can move the conference chairs, Joe is the only guy who can fix the microphone)."

No, IT job security is not "dependent on making things hard, slow, and complex." I'm so tired of hearing that. It's simply not true, and I'd love to hear a concrete, real-world example of some place where that was the case. The fact of the matter is, IT job security is dependent on making things work. Period. If you really think that the IT department uses Exchange Server so that their buddies can get a job, you simply don't have a clue what IT does.

"But change is coming. Dealing with technology has gone from something only for the techy geeks to something more mainstream. Younger generations get it. Computer savvyness is no longer just for the geek squad."

Change may be coming. Indeed, I hope it is, because I would love to see the relationship between IT and the end-user improved upon, and, where possible, lessened or even ended. And certainly "dealing with technology" is something everyone has to do these days, but after working in tech education for eleven years, I see no evidence that people have gotten any tech-saavier at all. In fact, from one year to the next, people seem to be pretty much the same: they're either tech-saavy or they're not. It has less to do with exposure, more to do with personality. Some people can sing, some people can't. Making the bad singers listen to music all day doesn't make them good singers.

"You no longer need a tech person at the office to man 'the server room.' Responsibility for keeping the servers running has shifted away from the centralized IT department. Today you can get just about all the services that previously required local expertise from a web site somewhere."

Apparently, David, you seem to think that all IT does is run servers, which you seem to think requires them to stand next to them inside a server closet somewhere. Hate to break it to you, buddy, but IT does way more than run your shitty-ass fucking servers. IT configures your switches; they deploy your workstations to your labs; they build and maintain your render clusters, your RAIDs your SANs; they provide all your network infrastructure and keep your workstations virus- and botnet-free. And they usually do it from some sunless underground cavern because idiots like you fail to see their importance. You cannot get any of those things from a website.

"The transition won’t happen over night, but it’s long since begun. The companies who feel they can do without an official IT department are growing in number and size. It’s entirely possible to run a 20-man office without ever even considering the need for a computer called “server” somewhere."

Again, your obsession with servers. And again, I'd love to see some numbers on this. But okay, let's assume for a minute that you're right. What you're basically saying is that there are a lot more smaller companies forming on a regular basis out there. And, sure, smaller companies don't need an IT department. But smaller companies never needed an IT department. Smaller companies could always outsource their technology needs. That's not new. That's not change. That's just more proof that you don't know the first thing about what IT departments are or what they do.

"The good news for IT department operators is that they’re not exactly saddled with skills that can’t be used elsewhere. Most auto workers and textile makers would surely envy their impending doom and ask for a swap."

And that's proof that you're a condescending asshole.

Finally, for the straight shit on what IT actually does, John C. Welch says far more than I ever could (as he actually works in IT) and with far fouler language.

UPDATE:

Here's the inimitable Mr. Welch's response to the very same article. See? I told ya so. (Thanks, John Mahlman, for the tip.)

Create a Dual-Format Drive for Mac and Windows

It's just come to my attention that it's now fairly trivial to split a drive into two differently formatted partitions, one of which could be used for the Mac while the other could be used for Windows. This is not necessarily new, but there are a number of things that make it of particular interest to me. Before I detail the process of creating this dual-platform drive, I want to talk a bit about some of the reasons you might want to do this and some of the challenges I've faced over the years with regards to the issue of cross-platform drives.

Some History

In the very cross-platform lab where I used to work we were continually on the hunt for the best filesystem solution for users of multiple platforms when they were using external firewire or USB drives. That is, some folks wanted their drives to be accessible from both the Mac OS and Windows. On the surface this can seem like an easy problem to solve — Fat32 (or "MS-DOS" as it's called in Disk Utility) is readable and writable on both platforms. But it's not so cut and dry.

The biggest problem for me was video. See, I taught — and continue to teach — a video class in that very same department. We use Final Cut Pro as our editing software, for a variety of reasons, not the least of which is the fact that I prefer to work on the Mac. I require my students to have a firewire drive appropriate to showing in-progress video work in class. But Fat32 has a 4GB file size limit, and video captures can often exceed that limit. What happens when this limit is exceeded is interesting from a systems standpoint, but devastating from a user standpoint.

Video and Fat32

When capturing video in Final Cut Pro to a Fat32 volume, what happens is that the video file gets segmented. That is, the capture file gets written in 4GB chunks. Initially, Final Cut will see these chunks and understand what they are. But after saving the project and quitting the app Final Cut will no longer be able to locate the captured media because it's in multiple files with different names. The path to the media that FCP relies on is now, essentially, broken. This actually happened to a student of mine some time ago, and we were able to use the cat command to reconstruct the single movie file onto an HFS+ volume and then point FCP at the reconstructed file. Boy was that fun.

NTFS

We've often looked to the ever-popular NTFS file system as a possible future solution. It does not have such small file size limits, and it's readable on Mac and Windows. But the Mac has never been able to write to NTFS. So, in the past, our solution in the lab — our recommendation for users who really needed a dual-format drive with read/write capabilities on Mac and Windows — was to use the HFS+ filesystem on the drive and use MacDrive on Windows to read and write to that drive. Inelegant? Yes. But it mostly worked.

Mac and Windows Partitions

Another potentially attractive alternative to a single, dual-platform volume was the idea of splitting the drive into two partitions and dedicating each partition to a platform/filesystem. This way, even if all your Mac and Windows data wasn't all mushed together in one volume, you could at least keep it all on one device. This solution would likely work for the vast majority of users. Unfortunately, there was never a particularly straightforward way of doing this. Sure, it was doable. But it wasn't easy, and it wasn't something you could tell new students to do. In fact, it was likely to require admin access and command-line heroics, and so just wasn't a viable solution to anyone but the most die-hard user. Until now.

Without too much mucking around, it's now possible to create a dual-format external drive that contains a mac-formatted partition and a Windows-formatted one.

MacFUSE and NTFS for Mac OS X

The first step is the only really tricky part, and it's not even that tricky. If you have need for a dual-format drive, this should be pretty easy for you. You're going to need to install the MacFUSE and NTFS packages. In a nutshell, MacFUSE is an experimental set of tools for doing unsupported things with filesystems like SSH, FTP and, of course, NTFS on your Mac. And, experimental though it may be, I've been using it for quite a while and have not had any problems to speak of. Installing MacFUSE and the NTFS drivers will allow you to mount NTFS volumes with read-write access.

MacFUSE

So, if NTFS can be mounted read-write on the Mac with MacFUSE, and it's obviously read-write on Windows, and it doesn't suffer from the file size limitations of Fat32, why not just use NTFS as your über-filesystem and format the whole drive with it? That's a great question, and I'm glad I asked it!

The thing about getting NTFS read-write access on a Mac with MaFUSE is that it's very much a hack. Yes, it works, but it has its problems. First and foremost among them is the fact that Final Cut Pro is really not a fan. In fact, FCP might just be the best barometer of a good cross-platform solution as it seems to be so picky about filesystems. So far, the only filesystem I've seen work consistently well with Final Cut is HFS+. No surprise there. And on NTFS it gets downright crazy. Files sometimes won't open. Sometimes they won't save. It's a scary mess, and I wouldn't trust my FCP data on NTFS for any amount of money.

But, what the MacFUSE NTFS package does get you is a relatively easy way to format your drive with separate Mac and Windows partitions, and this, at least in my tests seems to work just fine.

NTFS-3G for Mac OS X

The easiest way to get everything you need is to go to the NTFS-3G for Mac OS X website and download the latest package. This package will install the most recent non-beta version of MacFUSE as well as the latest NTFS libraries, and contains everything you need. Once you've installed this bundle, you'll need to reboot your system.

Creating the Dual-Partition Drive

After the reboot you'll see a new filesystem option when you go to format drives in Disk Utility.

A New Option

Moreover, that option will be available to individual partitions of drives that are otherwise formatted. And that's what's new (to me) and what allows the magic to happen. Here's how you do it.

  1. First, if you have any data on the drive that you need to preserve, back it up. This process WILL ERASE YOUR HARD DRIVE.
  2. Next, select the drive you want to dual-format and choose the Partition tab.
  3. Select a Volume Scheme. I'm just doing the simplest, two-partition scheme, with one Mac and one Windows partition, but you can certainly get more Byzantine with it if you'd like.

    Volume Scheme

  4. Set the Format for the partition you want to use on the Mac to "Mac OS Extended (Journaled)," give it a name and a size.

    Mac Partition

  5. Set the Format for the partition you want to use on Windows to "Windows NT Filesystem (NTFS-3G)," give it a name and size.

    Windows Partition

  6. Under the Options... set the partition scheme to "Master Boot Record." This is needed for Windows to see your drive.

    Partition Scheme

  7. Finally, hit the Apply button. You'll be warned that everything is about to be deleted. Click through, and after a few seconds you will have completed the formatting process and your dual-format drive will be ready for use on Mac and Windows.

Caveats

As I said, so far this has been working really well for my class. You may still want to file it under "experimental" for the time being, at least until you're sure it's working safely. But I'm confident enough in this method to recommend it to my video students who also need some external Windows drive love.

It's also important to keep in mind here that I am not endorsing using the NTFS partition for Mac data of any kind. Doing so is surely unsupported by Apple, and by all reports is fraught with problems.

The other thing to keep in mind is that, unlike with a GUID partition table, you will not be able to resize or split partitions without completely erasing the drive.

Erases Everything

Conclusion

Lastly, I realize that this process is hardly new, nor am I the first to discover it. It was pointed out to me by one of my video students, and I have a feeling the new admins at my old job have been using it for some time. But it's new to me. This is the first I've heard of this and it's exciting to me from an academic standpoint, in the context of my old job, in the context of my class, as a new option I can offer to whomever might need it, and as a symbol of progress — however small or kludgy — towards cross-platform filesystem solutions. This is just another of the very cool advances made possible by the existence of the MacFUSE (and the original Linux FUSE) effort. It's very cool to see this sort of thing coming to fruition at last!

Another intriguing extension of the MacFUSE project — and one that I've used a bit myself — is MacFusion, which allows for mounting of data over network protocols such as FTP and SSH. I'm sure there are tons of others. I highly recommend folks — particularly SysAdmins — check out and familiarize themselves with MacFUSE in general, as well. As much as has been done since the last time I looked at it, there is still a ton of future potential in the project, and I see it increasingly becoming a part of the admin's toolbox.

Experimenting with DokuWiki

Wikis are just one more thing I've always wanted to play around with. And my job has, once again, afforded me the opportunity to do just that. We're currently using an engine called DokuWiki, so I decided to kick its tires and see what it — and wikis in general — are all about.

DokuWiki's front page describes it thusly:

"DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It is targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required."

No Database

That last little bit — the lack of a database — is actually one of the things that makes DokuWiki unique. It is both its strength and its potential weakness, and one of its defining characteristics.

DokuWiki

If you are looking to install a documentation engine for a small to medium-sized workgroup, it's true: DokuWiki is great. It's very easy to install and only requires Apache and PHP be running on your server. This means it can be installed on any Mac OS X machine without having to install or configure much beyond Personal Web Sharing. I say, "much" because you will have to activate (not install) PHP, which isn't too hard for savvy users, but isn't exactly mom-friendly either. Still, it beats having to also install and enable a database application like MySQL, which most other wikis require. So DokuWiki is relatively easy to setup.

That lack of a database is nice, in that it makes installation quick and easy. But it's also a potential drawback, albeit a minor one. DokuWiki writes all its entries to flat files and that could affect scalability, and to some extent performance, if your wiki ever became extremely large. The merits of databases vs. flat files for storing data are debated all over the Internets, but databases usually only offer a significant advantage when dealing with complex, relational data, and that advantage is usually only seen by the developer. For small to mid-sized or even large-ish sites, DokuWiki is great. If you’re worried your wiki might need to grow very large some day (like, to the point where load balancing across multiple servers is required, for instance — we're talking big!), DokuWiki may not be for you. Otherwise, the flat file system offers additional advantages, like easy-to-parse and repair backups, to name just one.

Wherefore Wiki?

That said, once installed, DokuWiki is very easy to use. It does use its own markup for page layout, but that markup is exceedingly sensible and easy to learn. My biggest stumbling block was getting started: How do you create a page? Well, once you know, it's pretty simple, but figuring it out took me a minute. The easiest way to create a page, is to navigate to that page. If the page doesn't exist, DokuWiki allows you to create it. See? Easy! Maybe too easy!

So what's it for? Well, I'll tell you, TASB was almost a wiki rather than a blog. While both are types of Content Management Systems (CMSes), and essentially do the same thing — allow a person to easily and rapidly build and read a structured store of text and media data — the difference is intent.

Blogs — and therefore blog engines — are geared toward personal, diaristic, periodic writing. They're usually organized chronologically, like a diary, and require no special markup when creating entries. Entries, once made, are rarely revised. One of the things I enjoy about writing this blog is that it's a bit more personal. It's a record of personal experience as much as, if not more than, documentation. So I stuck with using the blog format. I like to be chatty.

Wikis, on the other hand, are made to be accessed like a reference, like an encyclopedia, for instance. They're not chronological, but are usually ordered and read alphabetically; and wiki articles are made to be maintained and updated as information changes. Wikipedia is a great example of this. There is also a blog called the Tao of Mac that uses a wiki engine for content management, showing that, in the end, the two types of engines do essentially the same thing. They simply present different capabilities to their users based largely on the purpose of the site.

Conclusion

If you're looking for a quick, easy-to-use and easy-to-maintain storehouse of information (either for yourself, or for use with others), a wiki is a great thing to have. Need to document a procedure for your workgroup? Put it on the wiki. Need to let everyone know where that essential file is? Put it on the wiki. Just want to jot down some notes for the general use? Put 'em on the wiki.

After using one for a few days I can already see just how damn handy a wiki is to have. And DokuWiki is super-easy both to install and learn. If you just need something small to document procedures or productions — or if you're just looking to dip your toe into the world of wikis — DokuWiki is very nice indeed.

UPDATE:

I've edited the article for clarity and accuracy regarding the use of flat file systems vs. relational databases. Thanks to DokuWiki's author for pointing out the error.

Portable Home Directories Part 3: Keychain Oddities

Hey, here's a weird one: I finally got my home account back to working order after my experiment with PHDs only to find that iCal couldn't open any of my online calendars. It kept saying the password was missing from Keychain, then refusing to let me add one, saying that the "Keychain could not be found."

Keychain Not Found

The Keychain application also refused to read my keychains. The keychains were there, as they always had been, in ~/Library/Keychains. Keychain.app just refused to see them. Refused to add them — or anything else for that matter — as well. Keychain First Aid reported everything as fine, but the damn things just wouldn't show up.

Suspecting some sort of weird, post-PHD permissions snafu, I copied the Keychain application to my Desktop and then launched it. This seemed to remedy the problem; the keychains became visible in Keychain.app. But upon re-launching iCal, my keychains became inaccessible again.

Mucking around in Keychain.app, everything looked fine. But I wanted to make sure that my "login" keychain was set to be the default. So I selected another keychain I have, right-clicked it and chose "Make keychain 'systemsboy' Default," then did the same to the login keychain, thus resetting it as the default keychain.

Remaking the Default

After doing this I launched iCal and the password complaints were gone; the calendars all loaded properly. Launching Keychain again, however, seemed to break everything. Again! WTF? No matter what I did, Keychain would eventually lose track of my keychains, and this would cause any application that relied on them to screw up. But I did eventually figure it out.

The solution? Well, it's so simple and so idiotic it's hardly worth a post. But here you go: I rebooted.

That's right. A simple reboot and all my troubles were gone.

Remember, kids: reboot, reboot, reboot!

Portable Home Directories Part 2: Oh God, Make it Stop

Last week I began testing the Apple Portable Home Directories feature. I'd heard a lot of good buzz, but my experience was pretty terrible. Of course I was doing things my own way, and not the Apple way, which is always a bit dicey.

Almost Proper

Wanting to get PHDs working, I decided to try doing things a bit more by the book. I set up our NFS Home Account Server as an NFS Reshare and shared it out over AFP. I also set my home accounts up properly in WGM, using the AFP share as my network home, and a local folder as my local one.

But PHD kept incorrectly syncing things, to the point where I've actually now lost some data. Seems PHD, when it syncs, is for some reason using the data on the network drive as the master data set. Files I've modified before leaving for work have been reverted back to their old versions — the ones on the network — over night. (Which is weird considering the fact that I was logged out.)

I'm sure this works in a perfectly standard environment, with no existing users and no NFS Reshares, when set up from scratch. But I have to say, I could not be more frustrated with PHDs. So I'm giving up for now and setting my home account back to the local drive. Of course, even reverting back to a non-managed, non-PHD, local account is difficult in this case.

Cache Insanity

The reason for this — and one of the things that's made testing PHDs so difficult in general — is the insane level of caching the server does with regards to PHDs. Caching is so aggressive that, even after disabling PHDs on the server and restarting the client machine, the SyncAgent on the client continues to attempt to sync my homes. If I try to stop it I get an error that says I can't stop it because I don't have a PHD. I'm a big fan of irony, but not in my server software, thank you very much.

No Mobile Account

So now the PHD service is incorrectly syncing my local home account with a network home it shouldn't even see. Thousands of conflicts are occurring. I'm losing data. Though I've disabled the service, the settings persist. This is terrible. Horrible. Godawful.

PHD Conflict Resolution

And there is no sanctioned, GUI way to stop this from happening.

Freedom!

Eventually I was able to stop the errant syncing by running the ever-trusty:

sudo dscacheutil -flushcache

Jesus! What a kludge!

You can imagine how difficult this has made my testing. I can't be sure that any change I've made on the server is actually happening on the client, so it's impossible to know where this is failing or what I might be doing wrong without starting from scratch every time I make a configuration change. And starting from scratch is pretty damned difficult as well, as the PHD settings are persistent to a fault.

Is That All There Is?

I'm not sure what to do with PHDs at this point. I don't think they're useful for our environment, or for any existing users. Testing them is downright painful. And data loss is a real possibility, and not a risk I'm willing to take with other users' data.

So, after a couple weeks of some very frustrating testing, I'm afraid I'll have to pass on PHDs. It's a nice idea, but not ready for prime time from where I sit.

There's a slight chance I'll try PHDs from scratch with a fresh home account, just to see if it works at all. But we'll see. I'm pretty annoyed at this point.

More annoyed than I ever was with Windows Roaming Profiles. And that's a feat.