The NX server requires a font named fixed from the X core font subsystem when starting up. Fedora 9 no longer has the X core font subsystem by default — they solved it by compiling fixed and cursor right into the X server. Therefore, the X fonts package is no longer installed by default.

Without said fonts, the NX server fails. Once you’ve installed them, NX works again.

You’re welcome.

Why 64 instead of 32 bits? Integer arithmetic. atomic_add_64, the function in the ZFS sources that accounts for the most CPU time, is over twenty instructions of 32 bits assembler guarded by mutexes. The same function in 64 bits is one instruction. One.

Be free. Today.

I just sent this e-mail to the WHATWG discussion mailing list where HTML5 is being discussed:

From: Manuel Amador
To: whatwg@whatwg
Subject: Removal off Ogg technology: preposterous

Allow me to be the voice of the small Web developer -- which I consider to be the foundation of the World Wide Web.

In reference to: http://html5.org/tools/web-apps-tracker?from=1142&to=1143

The recent removal of the mention of Ogg in HTML5 and the subsequent replacement of its paragraph with the weasel-worded paragraph that would make Minitrue bust their collective shirt buttons in pride:

<p class="big-issue">It would be helpful for interoperability if all+ browsers could support the same codecs. However, there are no known+ codecs that satisfy all the current players: we need a codec that is+ known to not require per-unit or per-distributor licensing, that is+ compatible with the open source development model, that is of+ sufficient quality as to be usable, and that is not an additional+ submarine patent risk for large companies. This is an ongoing issue+ and this section will be updated once more information is+ available.</p>

is a preposterous and gross mischaracterization of fact (dare I say lie). At the very least, it's FUD.

It pains me to state what is and has always been public knowledge, and is being intentionally ignored just to "get the spec published":

• The Xiph developers were extremely zealous and almost fiduciarily diligent in researching all possible patent threats to Vorbis technology, and for more than a year they found none -- they even did the research before beginning to code, explicitly to avoid submarine patents. I know, because I was subscribed to their mailing list and read status updates of this research, practically at the start of the project. I also know that big-name software houses and media players manufacture products with Vorbis technology, and none of them have been sued. It's been what, seven years now?
• The Theora codec has had its patents practically relinquished by On3 with a perpetual royalty-free license.
• Ogg and its audio/video codec technologies are the ONLY free software media technologies with implementations widely available on all consumer computing platforms -- from WM codecs to Linux DLLs, passing through the entire range of hardware (floating-point and fixed-point) and OSes.
• Without guaranteed Ogg support (whose integration in user agents I think I already established to be sort of a weekend-level junior programmer project at NO COST, due to the ready availability of the technology in all platforms), authors will be forced to use patent-encumbered technology. Remember MP3? Well, with HTML5 it's 1997 all over again.

Ian, revert. This compromise on basic values is unacceptable, whatever the practical reasons you have deemed to compromise for. If you don't revert, you will be giving us independent authors the shaft. And we will remember it forever.

Here’s the position paper of the Xiph foundation, the makers of Ogg Vorbis and stewards of all Ogg technology. Let me quote a paragraph from them:

So, how do you make Theora and Vorbis popular? Why, by the very same process that made MP3 so ubiquitous: by using it and by sharing it. Only by advocating the formats will you see interest from the corporations. There is no other way around it. Let me write that one more time: there is no other way around it. Backup your films in Theora. Backup your music in Vorbis. Share podcasts and videocats in these formats. And do not wait for tomorrow; do it now. And by now, I mean yesterday.

There’s a lot of companies out there who do not wish to see Theora and Vorbis succeed, and they don’t even have to make much of an effort to affect them. The masses out there with their expensive iPod toys don’t care about Vorbis or Theora. Most of them don’t even know what they are.

Note that HTML5 in no way required Ogg (as denoted by the word “should” instead of “must” in the earlier draft). Adding this to the fact that there are widely available patent-free implementations of Ogg technology, there is really no excuse for Apple and Nokia to say that they couldn’t in good faith implement HTML5 as previously formulated. Throw your own theory here: DRM, proprietary control, et cetera.

The WHATWG had an opportunity here to eliminate the plugin morass (so 90’s) in favor of a baseline format that each browser could implement. Just as HTML specifiedhinted at baseline formats for images (GIF and PNG), this should have been an opportunity to suggest or even specify baseline free audio and video. And there’s still a chance.

Please, please help this issue get more public scrutiny. But if you’re going to exert pressure on the WHATWG, be reasonable — read the archives first!. And don’t let special interests kill computing for all — now it’s time to take a stand!

Update: the discussion at the WHATWG list is centering around the fact that Microsoft, Nokia and Apple disagree on having Ogg technology mentioned on the spec, due (I loosely quote them) to the potential threat that submarine patents may pose. My personal opinion is that you don’t get any freer than Ogg, and there is no such patent threat because major hardware and software players (gaming companies and America Online / Winamp, for example) have already shipped at least Ogg Vorbis technology in the past. Until this conundrum is resolved, they’re taking Ogg technology off the table because they don’t want to implement it in their browsers.

Since moving forward with HTML5 is a consensus decision, the thing’s just not moving forward until a viable alternative to Ogg is found (or, maybe they can be convinced?). Both Opera and Mozilla have preliminary implementations of in-browser VIDEO tags that play Ogg media. Read the mailing list archives to see the arguments espoused in favor of / against the idea, and read the comments below.

It really bothered me that Nokia referred earlier this week to Ogg as a proprietary technology, blatantly stating something so untrue. It also bothers me that Apple has expressed concern against Ogg. Both companies make great products — my entire life I’ve only owned Nokia phones, I was thinking about the N800, and it’s in no small part thanks to Apple that I have hassle-free Zeroconf networking at home — but this clearly puts the small content producer at a disadvantage.

I just discovered the position paper that Mozilla, through Chris Double (the author of the VIDEO embedding tag in Mozilla software), will be presenting in a few hours on the W3C video workshop. Interesting read.

You’re free to use this diagram on your own site or documentation, as per the license that covers it (see the footer). However, I do ask you for credit and attribution if you use it. The image is also licensed under the GFDL, just in case you need it for free documentation.

The diagram is also available as a Dia diagram.

Awesome awesomeness: start your downloads minutes after TorrentFlux finishes them

I’ve created a very, very complicated and interwoven (translation: awesome and straightforward) script that you may use and modify on your home computer. It works like this:

• Using SSH, it queries your TorrentFlux server’s transfer list, asking which torrents are completely downloaded.
• For each of the completed torrents, it grabs the file name of the downloaded file.
• Then, it uses rsync to incrementally transfer the downloaded file to your PC.
• Again using rsync, it removes the file from your TorrentFlux server, freeing disk space.

What you need to do before using the script

For you to use it, you will need to do the following:

• Enable SSH access to your (soon-to-be) TorrentFlux server.
• Set up public key (passwordless) authentication so that your home computer’s user account can freely log in to your server without asking for a password.
• Install TorrentFlux-b4rt and set it up so that your SSH user has read/write access to the torrents and downloads folders/files. Umask/permissions, you know the drill.
• Enable fluxcli usage on your TorrentFlux setup.
• Install rsync on both your server and your home computer.
• Install the BitTorrent package that contains the program named torrentinfo-console on your server.
• Create a destination directory on your home computer.
• Install a mail program such as mailx on your home computer.
• Install cron on your home computer.
• Configure the script altering the variables at the top.

Yeah, it’s a lot of work. Go bitch somewhere else, we’re here for the fun.

Installing the script

Put the script somewhere in your PATH. Make it executable. Set up a cron job for the purpose:

# m h  dom mon dow   command
0,10,20,30,40,50 * * * * /home/rudd-o/bin/torrentleecher -q

The script itself

It’s a stunning, hackish example of subprocessing, SSH remoting, pipeline integration, text processing, POSIX daemonizing and file locking, and samizdat logging. It gets almost all of them wrong, and yet it manages to stay standing. If you’re interested in reading a complete account of how this script grew out of nothing, well, click here.

It’s a miracle:

#!/usr/bin/env python

from subprocess import Popen,PIPE,STDOUT,call import fcntl import re import os import sys import signal

FIXME: this script doesn't deal with multifile torrents

vars!

wherever they are used, it's MOST LIKELY they need quoting

FIXME whatever calls SSH remoting needs to protect/quote the commands for spaces or else this might turn out to be a bitch

torrentflux_base_dir = "/var/www/html/torrents/torrents" torrentflux_download_dir = "/var/www/html/torrents/torrents/incoming" torrentflux_server = "yourserver.com" torrentleecher_destdir = "/home/rudd-o/download/" fluxcli = "fluxcli" torrentinfo = "torrentinfo-console" email_address = "rudd-o@awesome.com"

def getstdout(cmdline): p = Popen(cmdline,stdout=PIPE) output = p.communicate()[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output def getstdoutstderr(cmdline,inp=None): # return stoud and stderr in a single string object p = Popen(cmdline,stdin=PIPE,stdout=PIPE,stderr=STDOUT) output = p.communicate(inp)[0] if p.returncode != 0: raise Exception, "Command %s return code %s"%(cmdline,p.returncode) return output def passthru(cmdline): return call(cmdline) # return status code, pass the outputs thru def getssh(cmd): return getstdout(["ssh","-o","BatchMode yes","-o","ForwardX11 no",torrentflux_server] + [cmd]) # return stdout of ssh. doesn't return stderr def sshpassthru(cmd): return call(["ssh","-o","BatchMode yes","-o","ForwardX11 no",torrentflux_server] + [cmd]) # return status code from a command executed using ssh def mail(subject,text): return getstdoutstderr(["mail","-s",subject,email_address],text)

def get_finished_torrents(): stdout = getssh("%s transfers"%fluxcli) stdout = stdout.splitlines()[2:-5] stdout = [ re.match("^- (.+) - [0123456789.]+ MB - (Seeding|Done)",line) for line in stdout ] return [ match.group(1) for match in stdout if match ]

def get_file_name(torrentname): cmd = "LANG=C %s %s/.transfers/%s"%(torrentinfo,torrentflux_base_dir,torrentname) stdout = getssh(cmd).splitlines() filenames = [ l[22:] for l in stdout if l.startswith("file name...........: ") ] assert len(filenames) is 1 return filenames[0]

def dorsync(filename): cmdline = ["rsync","-avzP","--remove-source-files", "%s:%s/%s"%(torrentflux_server,torrentflux_download_dir,filename),"."] return passthru(cmdline)

def exists_on_server(filename): cmd = "test -f %s/%s"%(torrentflux_download_dir,filename) returncode = sshpassthru(cmd) if returncode == 1: return False elif returncode == 0: return True else: assert False # Not reached

def get_files_to_download(): torrents = get_finished_torrents() for t in torrents: yield (t,get_file_name(t))

def lock(): global f try: fcntl.lockf(f.fileno(),fcntl.LOCK_UN) f.close() except: pass try: f=open(os.path.join(torrentleecher_destdir,".torrentleecher.lock"), 'w') fcntl.lockf(f.fileno(),fcntl.LOCK_EX | fcntl.LOCK_NB) except IOError,e: if e.errno == 11: return False else: raise return True

def daemonize(): """Detach a process from the controlling terminal and run it in the background as a daemon. """ try: pid = os.fork() except OSError, e: raise Exception, "%s [%d]" % (e.strerror, e.errno)

    if (pid == 0):           # The first child.
            os.setsid()
            try: pid = os.fork()              # Fork a second child.
            except OSError, e: raise Exception, "%s [%d]" % (e.strerror, e.errno)

            if (pid == 0):   # The second child.
                    os.chdir("/")
            else:
                    # exit() or _exit()?  See below.
                    os._exit(0)      # Exit parent (the first child) of the second child.
    else: os._exit(0)                # Exit parent of the first child.

    import resource                           # Resource usage information.
    maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1]
    if (maxfd == resource.RLIM_INFINITY):
            maxfd = 1024

    # Iterate through and close all file descriptors.
    for f in [ sys.stderr, sys.stdout, sys.stdin ]:
            try: f.flush()
            except: pass

    for fd in range(0, 2):
            try: os.close(fd)
            except OSError: pass

    for f in [ sys.stderr, sys.stdout, sys.stdin ]:
            try: f.close()
            except: pass

    sys.stdin = file("/dev/null", "r")
    sys.stdout = file(os.path.join(torrentleecher_destdir,".torrentleecher.log"), "a",0)
    sys.stderr = file(os.path.join(torrentleecher_destdir,".torrentleecher.log"), "a",0)
    os.dup2(1, 2)

    return(0)

sighandled = False def sighandler(signum,frame): global sighandled if not sighandled: print “Received signal %s”%signum # temporarily immunize from signals oldhandler = signal.signal(signum,signal.SIG_IGN) os.killpg(0,signum) signal.signal(signum,oldhandler) sighandled = True

def report_file_failed(filename): try: os.symlink(os.path.join(torrentleecher_destdir,”.torrentleecher.log”),”%s.log”%filename) except OSError,e: if e.errno != 17: raise #file exists should be ignored of course sys.stdout.flush() sys.stderr.flush() errortext = “”"Please take a look at the log files in %s”"”%torrentleecher_destdir mail(”Leecher: error — %s”%filename,errortext)

def report_file_done(filename): try: file(”%s is done”%filename,”w”).write(”Done”) except OSError,e: if e.errno != 17: raise #file exists should be ignored of course mail(”Leecher: done — %s”%filename,”The file is at %s”%torrentleecher_destdir)

def main(): if not ( len(sys.argv) > 1 and “-D” in sys.argv[1:] ): daemonize() os.chdir(torrentleecher_destdir) if not lock(): # we need to lock the file after the daemonization if not ( len(sys.argv) > 1 and “-q” in sys.argv[1:] ): print “Other process is downloading the file — add -q argument to command line to squelch this message” sys.exit(0) signal.signal(signal.SIGTERM,sighandler) signal.signal(signal.SIGINT,sighandler)

    print "Starting download of finished torrents"

    try:

            for torrent,filename in get_files_to_download():
                    # no point in doing anything if the file was removed, right?
                    # so we continue if the file doesn't exist
                    if not exists_on_server(filename): continue
                    print "Downloading %s from torrent %s"%(filename,torrent)
                    retvalue = dorsync(filename)
                    if retvalue == 0:
                            report_file_done(filename)
                            print "Download of %s complete"%filename
                            # TODO: make use of fluxcli to kill the torrent out of TF
                    else:
                            if retvalue == 20:
                                    print "Download of %s stopped -- rsync process interrupted"%(filename)
                                    print "Finishing by user request"
                                    sys.exit(2)
                            elif retvalue < 0:
                                    report_file_failed(filename)
                                    print "Download of %s failed -- rsync process killed with signal %s"%(filename,-retvalue)
                                    print "Aborting"
                                    sys.exit(1)
                            else:
                                    report_file_failed(filename)
                                    print "Download of %s failed -- rsync process exited with return status %s"%(filename,retvalue)
                                    print "Aborting"
                                    sys.exit(1)

            print "Download of finished torrents complete"

    except Exception,e:
            report_file_failed("00 - General error")
            raise

if name == “main“: main()

If you want to learn the process of how this script grew out of nothing, here’s the story.

Very well, I must confess. File management is an everyday task — and most file managers get it right. What they usually don’t get right is the ability to do advanced things in an intuitive and discoverable way. Dolphin does — it successfully merges a basic file management interface with the most-requested advanced features, and in a non-obtrusive way.

Now, it’s been three weeks since I’ve been using Dolphin (the KDE 3 version) exclusively. As it turns out, Dolphin is quite versatile (if a bit more flickery than Konqueror 3) and faster as well. My only caveat was that I had to manually associate the inode/directory MIME type to get it to take over directory browsing.

But today, for the purposes of this review, it’s Dolphin 4 all the way.

How Dolphin starts up

There’s nothing magical about Dolphin. Picture a Windows Explorer folder view (with the side panel, not the side tree). Picture a Nautilus browse folder. That’s how Dolphin looks like:

Of course, Dolphin has the ability to show previews like any other file manager. If you want it to show previews, you just hit the big Previews button, and presto:

Network transparency

Of course, Dolphin wouldn’t be part of KDE if it didn’t put to use the fantastic KIO technology. KIO is a way for applicatios to request and send data to local and remote file systems. Any application that uses KIO gets two big advantages:

1. It becomes asynchronous. File operations never hang, because things happen upon notifications instead of waiting for them to happen.
2. It gains the ability to access data anywhere in the world, through any popular protocol (HTTP, WebDAV, FTP, SFTP, SSH and much more).

And Dolphin is no exception. However, I didn’t test KIO remoting via SFTP on Dolphin 4, so you’re just gonna have to take my word for it. It’s okay — I use it every day in Dolphin 3.

It hangs. Hard. But, well, it’s a beta

Of course, it wouldn’t be a beta if it didn’t hang

Let’s continue to explore what’s new in the (admittedly rather boring) file management world.

I’ve been following KDE since KDE 1.1 was released — in fact, back in the day, I used to compile KDE from source. Being the grownup that I am today, I no longer have the time to indulge in days-long compilation — instant gratification is the name of the game for me nowadays. Nevertheless, installing KDE betas has always been an interesting experience for me.

Evidently, I rejoiced when I discovered that Kubuntu is carrying the latest betas of KDE 4. After following the instructions on the aforementioned page, and installing the kde4base-dev package, I started to screencap and document the newest release.

There’s a new article called A cursory look into KDE 4 file management: Dolphin beta to go along this article. Make sure you check it out afterwards!

First impressions

I took home two distinct impressions:

1. KDE 4 started up faster than KDE 3 on my system.
2. There’s no flicker. KDE 3 applications used to flicker all the time. KDE 4 apps don’t anymore.

Long live Trolltech and Qt4 — I understand it’s in no small part responsible for these dramatic improvements.

For now, here are some key points to notice:

• It’s broken. If you know your way around a computer, you might be able to take advantage of it (so-to-speak).
• It’s gorgeous and interesting.
• It’s not gonna eat your configuration, since it uses a separate configuration directory. So it’s generally safe.
• It’s a big download. Dialup need not apply.

It’s all horribly broken right now

That’s right. KDE 4 starts up half-drunk and half-broken. In my opinion, this beta is (judging from the developmental stage) not really a beta but rather closer to alpha quality.

I don’t mind. KDE has always rocked, and even in its utter brokenness, it’s still awesome:

These first screenshots show you how KDE starts up. The picture of the devs in the splash screen is a nice touch! And the desktop appears unusually clean. That would be a good thing, except for the glaring absence of a menu with which to launch applications. All my attempts to add one were futile.

Plasma

KDE abandons the “desktop-as-scratch-folder” metaphor. It also abandons the notion of a panel separate from the desktop (Kicker’s dead. Long live Kicker damnit!.). Don’t be fooled — there is a panel as you can see in the screenshots. It’s just that now any object you want to place on the desktop can also be placed on the panel, and viceversa. This concept is called Plasma, and while it’s still rough on the edges, it’s a true revolution.

Let’s take a look at the desktop toolbox — where Plasma applets dwell before being added:

After toying around with the toolbox, these are a few examples of what I got:

Interesting, huh? The picture frame looks awesome both in concept and in real life.

This is a work in progress. I expect and will take your contribution into consideration — use the comment form below to voice your doubts, tips or flames.

With so many companies finally realizing the potential of free software and open source, it’s not surprising at all that some are failing miserably to engage free software communities effectively. Instead of focusing on what they’re doing wrong, let’s focus instead on what they must get right.

With that intent in mind, let’s explore seven principles that will make your life easier when engaging free software types. In summary:

1. Know your audience
2. Your argument must rely on facts and reason
3. Respect community members’ time, rules and terms
4. Develop a thick skin
5. Contribute
6. Be humble
7. Make it interesting, make it fun

Here’s each principle explained.

Know your audience

We’re not all the same. Before even attempting to address us, do your research and figure out the “rules” of the particular community you’re trying to touch base with.

Despite the title of this article, there is most definitely no single “free software community” to address in the first place. It’s all a multitude of communities centered around their own projects, and collaborating between each other in a loosely coupled fashion.

You see, the closest thing we get to have in common is the common core value of sharing = good — and even so, many in our own collective of communities do not necessarily place that value up high in their own scale of values (witness Linus Torvalds, for example). You could possibly argue we all share a passion for technology — which might be true — but we all most definitely do not share even technical proficiency; modern free software communities are chock-full of people doing translation, usability and multimedia artwork.

Some communities are led by consensus. Others, by meritocracy. Some have benevolent dictators. Many projects out there have no defined leadership and are in a stage of transition.

Corollary: do not assume. Do your homework.

Fortunately, this homework is easy:

• You can easily poke around a project’s Web site, skim over technical documents, and invest a couple of minutes reading mailing list archives, to get a general idea of how that particular community beats its drum.
• You can also look stuff up (Google is very free software-friendly).
• Try to familiarize yourself with the issues (esp. technical details). That goes double if you’re a reporter — there are reams of inaccurate stories out there, just because the reporter was lazy enough not to “go to the source”.
• Some communities (the most mature ones, usually) even list guidelines for contributors and explicit rules of engagement.

Therefore, be informed. An ounce of prevention beats a hundred pounds of hammering.

Your argument must rely on facts and reason

In general, free software communities place extremely high value on the ability to argue and persuade using facts and reason.

The reason this is so pervasive in free software is quite clear: every single last drop of development and communication happens absolutely in the open — usually with easily accessible public records. Think about it: past discussions, decisions and the reasons behind each and every one of them are archived somewhere and usually accessible by poking around search engines with the right keywords.

Another reason (I love to call it the “doers factor”) is that, since new ideas can be tested quickly and pitted against each other. Do you think Project X will fare better with wings rather than legs? Prove it! In fact, cloudy proposals usually meet head-on with that sentence in our public discussion forums.

As you can see, “conventional politics” stand little chance against the gospel of “try it and support it” (though they infrequently win some points).

So don’t attempt to convince a community of developers by using slick persuasion. You will be called on it and asked to provide facts backing your points of view. You might also get reprimanded by project leaders because you weren’t diligent enough to “check the archives”. In the worst case, you will be shunned for long.

Respect community members’ time, rules and terms

You need to understand that many people involved with the free software movement are volunteers. Though a large subset of those people will be happy to help you fix any issue you may have, efficiency is key.

That’s why we:

• use mailing lists with public archives,
• use bug tracking systems,
• idle a lot on Internet relay chat channels,
• respond sparsely and oftentimes with the dreaded RTFM acronym.

If you find a bug, please don’t just mumble to yourself — report it through the appropriate channel. Doing so, while requiring a bit of an extra effort on your part, multiplies the effect your report has, because it benefits everyone — not just you.

If you have an idea that you think it may be worthwhile to pursue within the scope of a community, bring it to the table. Try to address everyone in the conversation, not just particular project authors. That way everyone gets an opportunity to shape the idea or to strike it down (in case it’s a bad one).

Same goes if you need help. Especially in this case, you should try to consult with the Lazyweb — mailing lists and search engines should be your first stop. Chances are, someone else already asked and got a publicly available reply.

Develop a thick skin

If you make a mistake, most free software types will call you on it.

Some of us are callous individuals. Sometimes, everyone is distressed or tired. We all are guilty of calling people names at some point. Don’t get discouraged by these events. We might call you an idiot today — that doesn’t mean you’re really an idiot, and sometimes we don’t even mean it!

Some communities appreciate sparseness in discourse. This might be construied by some people to be the equivalent of “go away, outsider; we don’t need you here”. Nothing could be further from the truth — most free software aficionados are efficiency buffs, and talk is expensive. Imagine yourself dealing with hundreds or thousands of e-mails daily in addition to coding or management tasks, and you’ll have a clear idea of what managing a free software project is like. Efficiency is key.

Source code and conversations may contain tons of expletives. I read years ago a report on profanity in the Linux kernel. It’s not pretty if you’re into political correctness but, come to think about it, doesn’t it work just fine that way? Then who cares about the cuss thrown around sparsely?

So try to develop thick skin. Become immune to callous comments, and keep pressing important issues calmly.

And comfort yourself with the fact that, in the medum-to-long run, projects with truly contentious members drown anyway.

Contribute

The whole notion of free software is based on quid pro quo.

We give you something for you to take advantage in any way you please. We expect you to share in equal terms with you. And your contribution has value. We need you. Here are some clever ways you can contribute in effectively:

• We hate bugs, so please report them. Try to provide as much info as you humanly can within time constraints. Try to keep yourself “in the loop” during the process.
• Maintain Web sites and blogs.
• Help with project marketing.
• Write manuals, guides or tips on public sites.
• Deploy a project across the board — then report your issues so everyone benefits.
• Publish improvements to free software projects.
• Develop new code.
• Allocate manpower on collaboration with non-engineering tasks: artwork, translations.
• Fund or donate to projects. A million dollars is fine, but $10 may do it as well.

If you do any of these things (OK, OK, I’ll recognize, some of them are more valuable to us than others), your message is way more likely to come across. Bonus points (yay!) for directly helping the project build its next “killer feature”.

Fact is, if you have something to show, you’ll generate an incredible amount of goodwill towards you.

Be humble

I’ve heard all manner of derogatory comments against us free software developers, from the classic “pinko” to the Cold war-era “hippie”, through the equally ignorant “amateur”.

We’re not amateurs, so get rid of those misconceptions. Each and every one of us is highly likely to be much more proficient and professional in our field of expertise than you. We’ve made a career out of seeding high-quality products and harvesting respect and reputation out of it. Technical prowess is the name of the game for us.

In each field of technical expertise, there probably are a handful of gurus in the closed software industry — and probably an even smaller group of free software developers which are in all likelihood as proficient or even more so than their counterparts doing closed source. This should be self-evident, since free software developers have had access to much more code and learned much more from collective experience resources while having fun at it, whereas the rest probably did it for the money only. You might be recognized by anywhere between ten and a hundred punks in your company, but we’re recognized, revered and relied as sources of opinion and technical expertise for considerably many more people — some of us count their fans and users in the tens of millions.

Each and every one of us has made a name for ourselves. Can you say the same of you? Even if you could, can you co-opt your reputation and technical expertise for the community you’re about to address?

So coming with an attitude of superiority (whatever your reason for that attitude) isn’t going to help your cause.

Be humble, punk.

But don’t get the idea that we’re arrogant just yet. 99% of us are eager to share a few beers with anyone else in equal terms. The other 1% usually die young from lack of human warmth (and alcohol?).

Make it interesting, make it fun

Free software types, believe it or not, are much more play than work. We are honestly entertained by what we do, and when we no longer have fun, we usually delegate our project to someone else with a more pressing need or a newfound passion for our project.

In a sense, we are probably the luckiest people in the world. People who actually enjoy what they do from the outset (as opposed to people who secretly want to hang their boss, or people who have had to learn to like what they do by sheer necessity) are far and few between. And some of us even get paid doing it. I know I do.

Moral: If you can wrap your message around fun and challenge, you’ll benefit.

Conclusion

Let’s recap, one more time:

1. Know your audience
2. Your argument must rely on facts and reason
3. Respect community members’ time, rules and terms
4. Develop a thick skin
5. Contribute
6. Be humble
7. Make it interesting, make it fun

These principles might sound like common sense, mixed with a few unexpected nuggets of unique free software idiosyncrasies. Even so, every day people fail to heed this advice — hey, I’m guilty of it myself! But it’s never too late to bump the steering wheel and change course.

I hope this article enriches your future experiences with the free software community as much as writing it has enriched me. I wish you the best of luck, and welcome to the free software world!

The patch

The patch is against TagLib svn, the library in charge of reading the MP3 tags and feeding them to Amarok:

Index: toolkit/tfile.cpp

--- toolkit/tfile.cpp (revisión: 721576) +++ toolkit/tfile.cpp (copia de trabajo) @@ -30,7 +30,11 @@ # include <io.h> # define ftruncate _chsize #else + /* Rudd-O: for fadvise / + / I have NO idea how to make this conditional on compile time. Ideas? */ + #define _XOPEN_SOURCE 600 #include <unistd.h> + #include <fcntl.h> #endif #include <stdlib.h>

@@ -41,6 +45,7 @@ # define W_OK 2 #endif

+ using namespace TagLib;

class File::FilePrivate @@ -73,6 +78,7 @@

File::File(const char *file) { + int fadvise_retvalue = 0; d = new FilePrivate(::strdup(file));

// First try with read/write mode, if that fails, fall back to read only. @@ -87,12 +93,26 @@

if(!d->file) debug("Could not open file " + String(file)); + + /* Rudd-O: we don't want the kernel to cache this file descriptor or perform any readahead -- but only if no one else opens the file. see posix_fadvise(2) / + / FIXME I have NO idea how to make this conditional on compile time. Ideas? */ + if(d->file) { + fadvise_retvalue = posix_fadvise(fileno(d->file),0,0,POSIX_FADV_RANDOM); + if (fadvise_retvalue != 0) + debug("Could not tell the kernel to not cache the file " + String(file)); + } }

File::~File() { - if(d->file) + int fadvise_retvalue = 0; + if(d->file) { + /* Rudd-O: FIXME Also needs to be conditional to the availability of posix_fadvise */ + fadvise_retvalue = posix_fadvise(fileno(d->file),0,0,POSIX_FADV_DONTNEED); + if (fadvise_retvalue != 0) + debug("Could not tell the kernel to evict from cache the file " + String(file)); fclose(d->file); + } delete d; }

The theory

posix_fadvise(), in theory, on POSIX systems (Linux included) lets you tell the system how to behave with regard to a certain file. In particular, this patch tells Linux that the MP3 will be accessed randomly.

Linux 2.6 obeys it by simply not performing readahead. In effect, the patch says “you shouldn’t perform readahead whlie reading the tags on the MP3s”.

When the file is closed, the patch also uses the POSIX_FADV_DONTNEED hint, to make Linux evict any memory used by the recently read file from the page cache (but only if no other process/thread has the file open, so it should be safe).

Why this should work

TagLib figures out the tags by reading two key parts of the MP3 file: the very end for ID3v1 (a couple hundred bytes), and the very beginning for ID3v2 (up to 64 K, but usually considerably less).

What TagLib does is:

1. Open the file
2. Read the data (a total of anywhere between 16K and 64K)
3. Close the file

But the Linux kernel does a few magic performance tricks behind the scenes, which actually cause the following to happen:

1. Open the file
2. Read the data — with block device and filesystem readahead, so maybe up to 512K will be read
3. Put the data in the block memory cache
4. Close the file
5. Hold on to the data in the cache for as long as possible, maybe paging out some pages from the current working set

Now, under regular conditions, these performance tricks actually work. But in the context of a collection scan, it’s brain damaged — does your computer really need to extra data from thousands of files, and then keep that data in memory?

Since there is no need for readahead (at most eight or nine 8K blocks will be needed, and the read operation is explicit about that), we disable that. This should considerably reduce the I/O demands.

Since there is no need for caching the contents (what are the odds that you want to play a specific file in 15.000, seconds after it’s been scanned?) we save memory by telling Linux not to cache the contents of the files. This should relieve memory pressure considerably, and preserve other things in memory (think application icons or code).

This patch should make scans faster and make your computer more usable while your music is being scanned or when Amarok is starting up, but…

I need benchmarks!

Who volunteers? I’ll post them here!

Update: here’s the corresponding bug report in the KDE bug tracking system.

• a simple and curious idea published as a dear Lazyweb question,
• turns into a script,
• gets topped by the original poster, and
• spawns a new spin on the same idea in a totally separate site.

Thanks, Marnanel, for the mention in your script (and it will be extremely useful for me as well). And thanks, Behdad, for the great idea.

Do you remember how most no-voters voted, right? They voted “no, with comments”. This means that Microsoft gets a chance to address the comment, and a vote will take place in the future. Probably about a year from now.

So there will be another vote to see if OOXML (perhaps with a few modifications) is approved. Which is kind of dumb, since the world already has ODF.

And we’re running out of arguments to stop OOXML… because we have already discovered just about every single technical counterargument to OOXML. Now, you may say “but, so what? That should be enough” — and yet you couldn’t be further from the truth:

So it’s time to start supervising and attacking the process, and making noise every time Microsoft gains a seat on the OOXML vote table (metaphorically speaking, of course). I know that at least in Ecuador there is a powerful lobby of companies sworn to Microsoft that will try to tilt the balance in favor of the yes, despite all technical absurdities in OOXML.

So, the take-away message from this article is this: Microsoft will have no qualms rigging future votes. Thus, be vigilant.

Damn I’m infuriated by this. Technical decisions should be based on merit, not on depth of pocket. But now it’s not time to get mad — it’s time to get even.

The image was stolen from this place. Great cartoon!