GNU/Linux

Recently, Gentoo documented what they view as the Composer Problem: Basically, PHP projects using Composer can't be packaged the way they want to package it, with system-level shared libraries. This is not a new complaint; Other distributions have complained about Composer's impact before. But fundamentally I think the issue stems from having the wrong mental model of how modern PHP works when viewed from a distribution or sysadmin perspective.

Pay It Forward was a 2000 romantic drama featuring Kevin Spacey, Haley Joel Osment, and Helen Hunt. Decently well-received, I found it a good, heart-warming, thought-provoking movie.

It is also an allegory for how open source works.

As Drupal gets bigger and bigger in the marketplace, it is moving into areas where system administrators still hold sway. Dedicated servers or server farms have a different set of needs than a shared host when it comes to monitoring and performance.

That's not even Drupal specific. For any high-end web app, it's useful to be able to interact with it for administrative purposes through standard system tools. On Windows, that's the Windows Administrative Tools or IIS. On LAMP, that could be a unified web app like webmin or a KDE control panel plugin or a Gnome applet. Getting a web app into certain organizations requires offering existing sysadmins a way to integrate it into their existing management workflow.

But what pieces of the app do sysadmins want in their existing admin tools? Calling all sysadmins, what do you want from us? :-)

It's the little things that really make or break a system. For instance, earlier tonight a song came up on my playlist in Amarok. I realized the name was misspelled. I corrected the ID3 tag. I then went to the directory where the file was and renamed it. The song was still playing. Amarok noticed and rescanned my collection, updating its records of the new file name, and kept on playing the song without any interruption.

That is how a computer is supposed to behave. :-)

Dries has been commenting recently, both on his blog and elsewhere, about one of the chief advantages of using open source: All developers/users are on equal footing. If you try to learn a proprietary app or framework, you know what the main developer feels like deigning to let you know. Anything else is either a mystery or, in some cases, illegal for you to find out (if there's any encryption or copy-prevention involved). You can never be as good an expert as the author, because the author has access to the Holy Book (code) and you don't. With an open source project, everyone gets the same access to the code. The only thing stopping you from being the best expert on the planet is your own skills and time.

He's very right about why you should choose to use an open source project. But what about why you should start one, or release your own code open source? As a developer, that's a far more interesting question for me.

Over on the Planet, someone posted a link to a budding Drupal user who was having the usual first-time-user troubles. "I want to do X, Y, Z, but I can't figure out how and no one will tell me, help!" Been there, done that, I suppose. But how can that be if there's so much Drupal documentation? Simple. The questions most people ask are the hardest to answer, because there isn't just one kind of documentation.

The great question of the day has been solved, and it is Emacs that wins.

Not that I use Emacs, mind you, but I've said for years that sooner or later, GNU/Linux would go away and be replaced by your choice of KDE/Linux (KDE having taken over so much functionality that all it needs is a kernel) and Emacs/Linux (Emacs already being almost an OS, except for missing a text editor). The only question was which would happen first.

So it seems Ubuntu, a distribution I have grown to like more and more of late (especially every time something breaks in Debian Sid), has decided that init has got to go. Their answer? Not any of the various attempts to replace it in the past, but once again start from scratch with something called Upstart. While I agree that init is one of the many parts of typical GNU/Linux system that desperately needs to grow out of the 1970s, I'm not sure that Upstart is the right way to do it.

Some people complain about how GNU/Linux isn't desktop-ready. It's too hard to use, the applications aren't there, it does things in silly and quirky ways... We've all heard the list. And some of us persevere anyway.

Recently, though, I've been working on-site with a client for a few weeks on a PHP project. The web app we are building is on a remote GNU/Linux server. Our desktops are all Windows XP SP2, of course. Because I need to edit the files locally but test them remotely, I need a fair bit of network transparency. Of course, Windows XP provides none unless everything is using SMB, which our production web server does not (naturally). So what setup did I have to cobble together?

As various associates and friends of mine know, my typical Linux distribution of choice is Debian. Once upon a time, the main thing that differentiated Debian from other distributions was a nifty suite of tools called APT, or Advanced Packaging Tool. While users of "those other distributions" wallowed in RPM hell, having to track down package dependencies manually, Debian users relied on a vast online archive of packages all parsed by the apt system. By using the apt-get tool Debian users could install one package, and all required dependencies would be installed and configured automagically. No scouring the 'Net for a specific version of an RPM. Coolness!