A couple days ago, Miguel blogged about the Interactive C# Shell, a piece of minor awesome–a read-eval-print shell for C#, using chunks of Mono’s gmcs compiler. Not a lot of use to me, but very cool nevertheless. Tonight, though, we get the woah-cool part (which follows quite logically from the interactive C# shell): C# Eval: An Embeddable Compiler. This is way cool, and for me it replaces what I’ve been stuck using IronPython for. And since it’s licensed under the X11 license, all those cheap-and/or-poor people like me can use it for our dastardly deeds.

I ask–nay, demand–that you all tell Miguel that it needs to be named Miguel’s CSharp Evaluator. The reason is, of course, obvious and painfully punful.

Tonight after I get home from work, I’m going to see if I can get gmcs to compile from SVN (it’s happily downloading away on my home server) and I’m going to see about adding to it a feature that is of serious use to me, and probably others. When you use IronPython, you can tell the PythonEngine to compile a string or code file into an object, rather than immediate execution. I plan to attempt to bring this CompiledCode functionality to the C# tool Miguel put together here.

Many thanks, Miguel!

As mentioned in my original post on the topic, my Google Summer of Code project was Cloverleaf–a package of semi-related tools to facilitate developing for Mono while using Visual Studio. The idea was to lower the barriers to targeting Mono. So…well, I did.

All of the individual functionality mentioned in that post works, for at least nontrivial values of “works.” Test In Mono, Test With Gendarme, Test Remotely, all of it’s working in the “external tools” form of the program, able to be used in either VS2008 or VC# Express. Jonathan Pobst has done some work with it as part of Novell’s Hack Week; you can find some details on what he’s done with the external tools app at his blog.

What did not get done was the add-in that bolts into Visual Studio directly, as opposed to the external tools. However, it’s not like I’m done with the project–those are still on my agenda to get done and release. It’s still my project, so to speak, though I’m flattered that Jonathan saw fit to do some work on it.

If you’d like to download it from Subversion, you can get it at the GSoC repository. Instructions to make it work can be found here, though I recommend using jpobst’s stuff.

Many thanks to Miguel de Icaza, Michael Hutchinson, Jonathan Pobst, and Andreia Gaita for all their help!

Not a lot to say here, aside from offering a link to C.J. Adams-Collier’s blog. These guys, they are nuts.

I don’t much like Linux Hater’s term “freetard,” but boy, is it a tempting one…

We got up at the unconscionably early hour of 8AM or so and went to breakfast, then headed to the Baseball Hall of Fame and Museum (possibly the only reason ever to go to Cooperstown, I think). I went with my dad when I was younger, in 1998 or 1999, and boy, has it changed. It used to be bright and wide-open, but now it’s become a lot more like most of the other “new” museums I’ve seen. Much darker, more of the bad-countertop-plastic walls all over the place, lots of short-attention-span blurbs of text all over the place and entirely too many video screens. I was disappointed: my brother would rather rush over to a video screen than actually read the text and understand a little more about the game. I guess I was probably that way at his age, too, but it’s just disheartening to see. My dad thinks that my little brother’s all into baseball, but I’m not seeing it–seems he’d rather play video games.

Another thing that bugged me is the prominence of relatively basic information throughout the hall. I understand that part of the Hall of Fame and Museum is to educate people in the game. At the same time, though, it’s wasting a lot of space and a lot of potential value for the people who already get the game. Seeing a life-size picture of Jason Varitek (he of the Incredible Noodle Bat) doesn’t do much for me. I already know more about Varitek than most of the people walking through there and, more importantly, I’m well-versed in the game to the point where I could find out anything I wanted to know, be it hitting up somebody from Sons of Sam Horn or just some judicious Googling. The Red Sox/Yankees swag and photos seemed pretty disproportionate, too (and that’s coming from a diehard Sox fan). There’re other teams out there, fellas.

What I’d love to see is a sample of the archives. Have a floor–even the basement, if you’ve got to–for fans, as opposed to consumers. Excise the bullshit. You don’t need to tell us that the Red Sox went eighty-six years without a World Series title. We already know that. You don’t need to tell us what a brilliant player Josh Gibson was in the Negro Leagues. We already know that. And you don’t need to remind us that Bob Gibson and his ridiculous ERA were in part the result of a higher mound. Why? Because we already know this stuff. Just give us stuff to look at; I for one would prefer to look at it without the tour-guide-on-a-wall crap. Have sections for major league teams, for the Negro Leagues, for great players in particular (maybe pick a decade of Hall of Famers?), and just put stuff out to see. And you don’t need to spoon-feed to us all the information. Fans don’t need to see “This is the cap Clay Buchholz wore on Insert Date Here, when he pitched a no-hitter against the Baltimore Orioles, retiring twenty-seven batters without allowing a hit during his rookie season.” If you don’t know what a no-hitter is, you don’t belong on this floor. Just give us a little card with the name, the date, and the event, and let us drink in the history.

Smok on the libtcod-net forum asked for a step-by-step on how to set up the library for use in a C# project. Since I’m expecting there to be more breaking API changes in the future, I’m going to describe the process using the libtcod-net Subversion repository on Google Code in order to stay up to date with any changes. (This does mean that your code will occasionally break in new and exciting ways until the API stabilizes. If that’s not your bag, go download the source packages available here and start following these instructions at step 6.) I’ll be assuming that you’re using Windows and Visual Studio as well, mostly because I figure that if you’re using Linux you probably already know how to deal with this stuff. The instructions are after the jump.

Before we begin, you’re going to need a few tools. You’re going to need a C# environment. I recommend Visual Studio; college students can get VS2008 Professional for free via Microsoft’s Dreamspark program and anybody can get Visual C# Express. You will also need a Subversion client; I recommend TortoiseSVN because it’s a nifty shell extension and remarkably easy to use.

Alright, ready to move on? Rock.

• Create a directory somewhere, wherever you keep your projects or libraries, and name it libtcod-net.
• Go into that directory. Then right-click and select SVN Checkout.
• TortoiseSVN will present you with a dialog box.
  

  You'll see something more or less like this.

• In the dialog box, verify that the checkout directory is the one you’ve just created and enter http://libtcod-net.googlecode.com/svn/trunk as the repository URL. The checkout depth and revision should be already set for you. Click OK.
• TortoiseSVN will do its magic for you and download the source for the library for you. This might take a minute or two.
• In the root of the libtcod-net directory, you’ll see a Visual Studio solution file, libtcodWrapper.sln. Open it in VS2008/VC# Express.
• If you’re using Visual C# Express, you’re going to need to enable advanced build configurations. Go to Tools->Options, check Show All Settings, and check Projects->General->Show Advanced Build Configurations.
• In the Solution Explorer, right-click TCODTestLib and click Unload Project; you probably don’t have NUnit installed, so that project will throw approximately eight bajillion errors if you try to build it. (If you want to help develop libtcod-net, I’ll assume you already know how to deal with NUnit.)
• Make sure that Release is selected in the Solution Configurations dropdown (it may be on Debug by default) and then press F6 (or, via the menu, Build->Build Solution). VS will build the library and the sample project. If you’d like, you can dig around the demo project’s sample.cs and see how things work, but we’ll cover most of that here.
• Now, create a new solution in Visual C# Express, of type Empty Project. Make sure that you create a directory for the solution as well.
• Copy all the files in libtcod-net/bin/Release (there should be three files, an .xml file, a .pdb, and a .dll) to the root directory of your solution. Also copy Demo\libSDL.so, Demo\SDL.dll, Demo\libtcod.dll, Demo\libtcod.so, and Demo\terminal.bmp to the root directory of your solution. (While you don’t have to copy the files to your own solution right away, it’s easier to do so, so you have them all in one place when you need to access them.)
• Go back to Visual Studio and your project. Right-click on the “References” item in the Solution Explorer, then click Add Reference. Select “System” and “System.Drawing” from the NET tab and click OK. Go to Add Reference again, click “Browse”, and navigate to the root of your solution, then select libtcodWrapper.dll.
• You’re ready to write some code. Create a new code file, Program.cs, and input the following (my indentations have been mashed by WordPress, but Visual Studio will correctly handle them):
  

  using System;
using libtcodWrapper;
using Console = libtcodWrapper.Console;

  public class Program
{
public static void Main(String[] args)
{
CustomFontRequest fontReq = new
CustomFontRequest(”terminal.bmp”,
8, 8, 16, 16, false, ColorPresets.Black);

  RootConsole.Width = 80;
RootConsole.Height = 50;
RootConsole.WindowTitle = "Hello World!";
RootConsole.Fullscreen = false;
RootConsole.Font = fontReq;

  RootConsole rootConsole = RootConsole.GetInstance();

  rootConsole.PrintLine("Hello world!", 30, 30,
LineAlignment.Left);
rootConsole.Flush();

  Keyboard.WaitForKeyPress(true);
}
}

• Select Debug in the Solution Configurations dropdown, if it’s not already selected, and press F6 to build it. It should build correctly without error.
• Remember those files I had you copy into the root of your solution? Copy libSDL.so, libtcod.so, SDL.dll, libtcod.dll, and terminal.bmp into $PROJECT\bin\Debug (substituting your project’s directory for $PROJECT).
• Go back into Visual Studio and run your program with F5.
• Now get hacking! If you have any issues, feel free to post in the libtcod-net forum and people will try to help.

After a few magic words to Elgoog, this popped up in my search results: libtcod-net. I went “ooh!” and started poking around, and yea, verily, it is awesome sauce. It’s a wrapper around the BSD licensed libtcod, and to rip off a McDonalds’ trademark, I’m lovin’ it. My only issue is that it doesn’t feel very C#-ish: while the functionality is great (check out the sample demos to see what kinds of stuff this library can handle, it’s like the emacs of Roguelikes), it seems to have inherited some C-isms. Makes sense, though, as it seems to be a project mostly for his own use in his own Roguelike, Magecrawl. I shot him an email asking if he’d be interested in collaborating, because if I end up using libtcod-net for anything I’m going to have to make changes to make the bits and pieces more C#-ish. (I’m nitpicky enough to find something like “TCOD_key” as a class name absolutely painful. Yes, it’s a horrible habit. No, I can’t suppress it.) What’s especially cool is that he’s been filing bugs against Mono as he goes along. Anything to help Mono’s gravy by me.

Anyway, many kudos to Chris Hamons, the dev, and I encourage everyone to take a look at this library. It’s good stuff.

• The space between user paradigms. There’s a divide between the developers who use the command line and those who use the GUI, and invariably the users who use the paradigm the developers don’t favor get the short end of the stick.
• The space between languages. Interoperability with various languages is pretty weak, and it results in a lot of work being lost because of it.
• The space between programs. The tool-and-filter philosophy of the “Unix way” is nice for smaller, easily grasped problems (example: grepping through a file for instances of a phrase, then piping that into tail for the last 20 instances of it). It rapidly grows hairy and ugly when you start getting into more complex problems.

In this post, I’d like to put forth an idea that, while a fairly huge prospect, I think would be a great leap forward for Linux.

As a couple of commenters mentioned in the previous post, it sounds like what I’m describing is a managed code solution. It will then surprise absolutely no one that that is in fact what I’m talking about.

I’m not talking about something absolutely foolish, like a managed code kernel or something equally cretinous. Nor am I talking about piling up C coders like cordwood and setting them alight (I mean, come on…all that burning hair? Enough to make you start retching…). What I’m talking about is an expansion of the capabilities of the standard Unix programs (and other Linux-specific ones) to support newer methods of interaction with the standard Unix tools, methods that empower users and developers alike. I’m talking about replacing the current Unix tools packaged with most (all?) Linux distributions with managed code* equivalents.

.

Let’s start, first, with the three points I made above, and discuss how a managed code framework would benefit developers and end users in all of those areas.

• The space between user paradigms. When using Mono, at least, there’s a bit of a push toward writing more modular applications; it “falls out” of the framework and quickly starts to feel natural. Somebody writing a tool in Mono isn’t (usually, hopefully) going to just parse the command arguments and work their magic in Main(). Instead, they’ll break the functionality out into an object (or a bunch of them). The natural mapping that comes to mind is that of the command line options to properties on their “control” object, and it becomes a lot easier for a developer–whether it’s the same person who made the CLI application and library or not–to put together a GUI application to provide the same functionality.
• The space between programs. (Yeah, I swapped up this one and the languages issue, because in this case user paradigms and programs are pretty close.) Like I said before, pipes are a great method for people who want to use them–more power to you if that’s your thing. It’s not mine and it’s not a lot of other people’s. And with managed tools, we both win. You still get your command line applications. You can cat and tee to your heart’s content. Meanwhile, I get the code objects that you on the command line are using wrapped with a command line interface and I can deal with them directly, as I prefer to do. Everybody wins.And I realize that this sounds a little pathetic at first blush, but when you aren’t stuck piping text around and can work with actual objects, debugging becomes easier. You don’t have to wonder why your output file is blank just because you didn’t order the command line arguments correctly or the tool didn’t like the way you phrased one of the settings–instead an exception can be raised with actual valuable information that can help you solve the problem. Just try and tell me that doesn’t sound awesome.
• The space between programming languages. This one’s a meatball, whether you’re talking about the Java Virtual Machine (JVM) or the Common Language Runtime (CLR). Offhand, I can’t think of many even remotely popular languages that don’t have CLR implementations either in the works or complete. I’m still convinced that C# is the greatest thing since sliced bread, but just off the top of my head I can think of C++, Python, Ruby, Scheme, and PHP. Heck, there’s Prolog, Ada, Delphi, Object Pascal, and  at least two or three COBOL implementations that Wikipedia knows about (in fact, click here for their list of languages running on the Common Language Infrastructure, though I don’t know which ones are supported by ). The killer feature is that objects written in any** of those languages can be used in any of the others. If the maintainer of the managed version of ifconfig wants to write it in Python, more power to him! I don’t have to care what language he’s using; so long as the objects necessary to manipulate network interfaces are made public, I just have to reference his libraries and I can issue the in-application equivalent of ifconfig eth0 up all day long. Even Java developers can get in on the fun. I don’t know of a Java-on-Mono compiler (though one may exist that I don’t know of; it’s definitely possible, as Microsoft does it with J#), but there’s IKVM to run JVM code on Mono. Though I don’t know whether there’s bridging to .NET objects; Java’s not my thing.

This shouldn’t be construed as an attack upon the current stuff that’s there, because those tools are time-tested and good for what they are. Nor should the people who like the way it currently works be immediately hostile to the idea, because I can’t think of a reason they’d see any real difference. There’s no reason the command line flavor of the tools couldn’t mimic the GNU tools or the BSD tools or whatever else; people who choose to use them just like they always have*** can do so.

Now, I know that most of the functionality afforded by the various low-level Unix programs is available in Mono itself. That’s not the point. The applications themselves are important because they encapsulate known, well-used functionality in a package that everybody’s already familiar with. The ability to get all the data you’d normally get out of, say, ifconfig, in a format that you can actually work with programmatically without a bunch of ugly hackish text processing, is, to me, a big win.

.

Believe me, I recognize the huge amount of work this sort of thing would entail, though I think it’d be less than I’m estimating due to having something to look at. It’s not a glamorous project, either; ripping the plumbing out of a house never is. And it’s definitely only a start; even if this were accomplished, there’s a lot more out there. But I think it’s definitely a project that would benefit Linux as a whole. I don’t mean to be flip, but managed code is the future wherever performance can be “good enough” instead of “absolutely critical.” Linux needs to move it along.

I’m not trying to say I’m going to start this project. I don’t know if I have the chops to do it. But if you’ve got ideas or suggestions on the topic, or might be interested in working on it, drop me a line. At the least, it’s an interesting discussion topic.

.

.

* - When I say “managed code,” you can take that as “Mono” if you really want to. Writing these replacement programs in languages targeted to the JVM would be totally doable, and I’m not knocking the JVM, its developers, or those who use languages on it–I just can’t stand Java after using C#. I also develop on Windows, so C# and the CLR are a natural fit for me.

** - There are occasional exceptions where the object model doesn’t yet translate perfectly between CLR languages, but work’s regularly underway to round off those sharp corners.

*** - About the only difference might be in startup time. If the libraries need to load, starting up a Mono application can be a bit slower than a native code application. I can think of a number of ways to solve this issue off the top of my head.

“So what would you do to fix it?”

That’s not exactly a new question, but I hadn’t been asked it before. So I put a little thought into it. My first instinct was to look toward the kernel, but that was pretty stupid of me–the kernel no doubt has problems, but I’m not a kernel hacker and I’m not qualified to talk about them. The area where I routinely run into problems and annoyances is userspace, so why not look at that?

I ended up on what I’m starting to think might be the biggest problem with Linux today: what I’m calling “the space between.” This has three different meanings related to different issues I’ve seen and had with Linux. (I could come up with more tortured uses of “the space between,” but then I’d run the risk of sounding like a certain balding South African musician.) Also–I’m not claiming to be coming up with anything new, so don’t ascribe some kind of weird arrogance to me for it. I’m just putting things how I see it. It’s my blog, dammit, I can do that.

.

.

The first issue is nothing really new to anyone: the space between usage paradigms–the space between the GUI and CLI. The prevalent mindset among open-source developers seems to be “I’m only going to cater to my own style of usage.” Some developers only use the command line, and so their tools are all command-line; if there’s a GUI at all, it’s a thin wrapper over the command line application. Other developers (me, sad to say, though I try not to do this) prefer GUI tools, and so there’s not a lot in the way of command line access for those programs. Most programers will agree, if you ask them, that applications should be divided into a library with different interfaces as necessary–GUI, CLI, web, toaster, whatever. Whether these programmers actually do it…well, that’s a little more sketchy. Mind you, I’m not saying that programmers have an obligation to write a full-featured GUI for people who don’t like using the command line. They just need to make it reasonably possible by extracting the code into libraries that can be easily consumed.

.

.

The next issue is something that might be a little touchy: the space between languages. And sometimes, there’s a lot of space between languages. Say you’re writing an application in…let’s pick any ol’ pet language. Ruby. You’re writing your app in Ruby, and you need to accomplish X. No doubt there’s a libDoesX somewhere–no? No libDoesX? Crap. Welp, surely somebody else is going to use this code–you’d better make a library out of it. And a name–how’s libRubyDoesX sound? Cool, so now you’re peddling your library to accomplish X. In Ruby.

So you’ve written the application, and the handy library, in Ruby. Now I come along, waving my pet language, Python (anybody who knows me will now indulge in some uncontrollable laughter), and I need function X. Surely somebody’s written a libDoesX, so I’m gonna go find it! And there it is.

Your libRubyDoesX.

In Ruby.

Uggggggh.

I guess I’d better get to making libPyDoesX. Or figuring out some way to host Ruby within my Python application just to use your libRubyDoesX.

See the issue? Countless man-hours are wasted, doing the same thing over and over again. Some duplication is good–new features might crawl out of the woodwork. Lots of duplication? Not so good. That time could be spent doing what you originally wanted to do, rather than screwing around with writing yet another libDoesX. You didn’t want to write libRubyDoesX! You just wanted to accomplish X, but there was nothing out there for it. I didn’t want to write libPyDoesX, either, I just wanted to accomplish X, too. But since libRubyDoesX is the only game in town, I had to duplicate your work in order to do so.

There’s also the other common path for libraries to go, equally wastefully. Somebody writes the library in a relatively consumable language, like C. Then, as people need to use it, bindings pop up for it–Ruby bindings, Python bindings, Perl bindings, whatever. As “language purity” starts to take hold (and most of the time, at some point or another, it does), for some reason it becomes important not to depend on that C library anymore, and it’s time to reimplement that C library in Ruby, in Python, in Perl. C’mon, let me hear you now: “uggggggggh.”

.

.

The third “space between” is the space between programs. This relates somewhat to the first point, the space between usage paradigms, but is a bit different.

What has always been “the UNIX way” is to have a lot of little programs that can be piped together in all sorts of interesting and different ways in order to accomplish a task. That’s fine. That’s great. I’m not saying that that should go away for people who want to operate in that fashion. It’s not my bag to go whipping around sed and awk while hoping I don’t put my eye out or change Planck’s constant, but if that’s your M.O., more power to you. The problem I see with the UNIX way is that the lingua franca is absolutely horrible. Text, especially text that should be readable to humans as well, is, in my opinion, a bad way for two programs to talk to each other***. It’s hackish and while you can do some cool things with it, you can also shoot off your foot. We could have an easier way, something that doesn’t require you to jabber at sed and hope you didn’t miss a slash or something equally inane.

.

.

The question then becomes “what do you do about these issues?”, and it’s a loaded question. I mean, it’s not like you’re going to get people to all start hacking away in your One True Language of Choice, and I’m not sure you’d want people to anyway. You’re also not going to really get a developer hacking away at command-line apps to break their important functionality out into a library if it doesn’t benefit them (and somebody could go crazy doing it for them!). And you certainly don’t want to offend the people who like playing the aforementioned shell scripting games; I’m convinced they know magic and I don’t want to be turned into a toad. Not me, no way.

In my next Fixing Linux post, I plan to explore what I think is a good way**** to address these issues moving forward. Hope to see you back here for it.

I’d love to know what you think about this article; please feel free to comment.

.ff

.

.

Check out the second part of my jabbering about this topic over here.

* - I don’t intend to exclude BSD with these comments herein. I just get annoyed by saying “Linux and BSD” every time and I don’t like typing *nix all the time.

** - You there in the back, shut up–I know about Masaki Fukushima’s old Ruby/Python extension library. To the best of my knowledge, it’s old and unmaintained. His website, which is the first hit for the topic, says it was updated in September of 2000.

*** - I’ve made similar comments about SOAP in the past, but I can’t think of a better method for communicating between services on different hosts.

**** - False modesty alert. Yeah, I said “a good way”. I’d be a grandstanding asshole if I said “the best way,” wouldn’t I?

FSF: Go, minions, and hit the Apple Stores with a meatspace DDoS!

Go give that a read. When you once again have the presence of mind to pick your jaw up off the floor, c’mon back and click that “read more” link. Go on, I’ll wait patiently.

Back already? Wonderful. Look, the FSF has done the occasional good deed in the past. (I say that with tongue in cheek; they’ve done more than most.) But it is becoming more and more apparent that they are absolutely out of their heads! They just don’t understand that their tactics are more likely to alienate their “base,” the people who think open source software is a good idea, and seriously torque those who don’t have an opinion one way or the other on the topic. I don’t know who this blogger, Matt Lee, is, aside from a quick Google search–he’s the Chief Webmaster for the GNU Project and Campaigns Manager for the FSF. Which means he’s already bought into the RMS kool-aid, presumably enough to fill a swimming pool. But anybody in an advertising type of position for a major organization has to understand that the first rule is to not piss off people who aren’t causing you harm, right? Right? Right?

Apparently not. In the blog post, he writes:

Print out our handy questionnaire and information about how iPhone 3G restricts your freedom.

Excuse me, sir? My freedoms are being restricted by a gadget I don’t own? That’s very interesting, really. I didn’t know my freedoms could be restricted by something I don’t own, have no interest in owning, and will in all likelihood never buy. That goes for pretty much any of the FSF hangers-on who are stupid enough to think that this is a good idea–they almost certainly don’t own iPhones, so why the hell does it restrict their freedoms? They’re perfectly free to exercise their rights in a (somewhat) free market and not give money to the company that makes the stupid gizmo, aren’t they?

Or am I wrong? Are my freedoms being restricted because I simply allow a device like the iPhone to exist? Are my freedoms being restricted because Richard Stallman doesn’t like something and I don’t rally to his bearded, Emacs-loving cause?

Of course not. This insistence that everyone’s rights  (if they’re rights at all, which is pretty damned debatable, but I’ll let it slide and continue use their terminology against my better judgement) are being restricted because somebody sells a device that incorporates restrictions is one of the FSF’s favorite tactics, and it’s a really tiresome talking point from a group formed mostly to whine about being excluded because nobody wants to deal with their crap. If somebody buys an iPhone, they are agreeing to let their rights be curtailed. It’s like me going into a movie theater. I agree that I can’t run around screaming during the film, even though it’s my legal right to run around screaming under other circumstances. If I don’t like that the theater doesn’t want me running around screaming during the film? Tough! I can go elsewhere.

The people working at these Genius Bars are customer service representatives of the company. They don’t set policy. They’re told exactly what they can and can’t discuss with customers. They can say “we don’t support that, sorry” and very little else. Asking them to start commenting on politics is unreasonable and entirely rude. It’s not their job to talk politics when on the clock. It’s their job to help customers–which these FSF zealots are not; they are just pains in the ass. I’d love to see these exchanges between the douchebags the FSF is fielding and the people working the Genius Bars to go something like this:

Genius Bar Dude(ette): “Hi, can I help you?”
Troublemaking FSF Monkey: “I’m from the DRM elimination crew at DefectiveByDesign.org — I’d like to ask you a few questions about the defects Apple has designed into the iPhone 3G.”
Genius Bar Dude(ette): “Security will escort you out; please don’t return. Next!”

It shouldn’t surprise me that the FSF thinks this sort of thing is a good idea. It really shouldn’t. But it does. I guess I just expect that people actually take into account the effects of their actions upon other people. I guess I just expect that the FSF would go “hey, this isn’t a good idea, because while we might get attention, it will be entirely negative,” but I think it’s obvious I’m naive.

The organization that wants to “lead” free software forward should not be endorsing immature garbage like this campaign. This isn’t about “working their way up the ladder to the decision-makers.” The decision-makers can be reached directly. This isn’t about “opening a dialogue”; they wouldn’t be advocating clogging the operation of a commercial establishment if that was the case. This is about grandstanding. This is about some moronic idea somebody put together with their socially-incompetent friends, the circle of hurf-durfing propelling them to think that this was actually a good idea.

On my worst day I could come up with better ways to raise awareness about DRM. Hell, passing out pamphlets to people standing outside would have more concrete value (and they suggest doing that, once you’ve done your best to make a grunt-level employee’s life just a little worse). This campaign is designed above all else to simply harrass people who are just trying to make a living. It’s sickening. I would think that people interested in “freedom” would understand that people have the freedom to disagree and purchase what they want to, but the FSF (rather like the ACLU, in a different field) only believes in the freedoms they like.

Remember how I said that people are welcome to choose whether they want to buy an iPhone or not? Well, given the FSF’s actions, I’m free to not support them. So I won’t. I’ve already taken down all of my previously GPL-licensed code; I won’t write another line of it. No contributions, ever, to any projects that use the GPL. No donations, ever, to any projects that use the GPL. (I’d include the LGPL, but the FSF hates that, so I’ll give it a pass.) I’ll use GPL-licensed code when it’s the best tool for the job, but I’ll donate to projects I don’t even use if I think they have a good chance of supplanting the GPL garbage.

I realize that it’s more than a little silly, but just the same–I’ll confess to being honestly tempted to write a license for my own code, now, that affords all the freedoms of the BSD license except the freedom to relicense the code under the GPL or link with code released under the GPL. Extreme? Sure, probably more extreme than would be warranted if this was a single isolated incident. But it’s not a single isolated incident, it’s a continuing, regular sort of thing out of the FSF. They want to say “share all your code with us or we won’t share any with you,” huh? What if I want to say “you want everyone else to share all their code with you, so I’ll share mine with everybody but you”? I have to think that’d be a hoot.

Sit down and shut up, Mr. Lee. You do more damage than you could ever do good.

Aren’t zealots just so awesome?

Update, 8/4/08: They turned off comments for that article not long after I posted this. Funny, huh?

A few quick updates regarding Cloverleaf, as some folks have expressed some interest in the project. I’d like to throw a shout-out to Franz, whose questions got me off my ass and drove me to write a little documentation for installing the pre-pre-pre-pre-alpha CloverleafET code. If anyone else is interested, you can access that documentation on the Mono GSoC 2008 Google Groups page.

Last (first) blog post, I mentioned that my next goal was going to be getting ASP.NET to work remotely. It’s done…mostly. XSP2 support works, for a moderate value of “works”–there’s a possibility of leaving zombie processes and it currently is hardcoded to port 8080–and will be touched up in the next week or so. Apache2 support might take a little longer; that’s going to be much messier than I’d hoped for. Zeroconf also works, although I haven’t written any configuration for that yet so all you’ll see in the service browser is “Cloverleaf [$machinename, Unix]“.

I haven’t tested it on Linux using Avahi yet, because Ubuntu’s habit of making eight hundred million packages for any application you want to install is making it seriously painful to get working; I’m about ready to say to hell with Ubuntu and install OpenSuSE. If they hadn’t defaulted to KDE 4 (utter, utter crap, and no I don’t care that they say it’ll “get better later,” I’ll jut stop using Linux on the desktop when they drop support for KDE 3), I’m sure I already would have. But CloverleafService should run just fine if you can puzzle out how to put together the various bits and pieces.

Making progress, though. The next week will mostly be fixing the bits and pieces mentioned above, making remote instantiations of XSP2 listen on random ports so multiple users can use it and doing a little configuration work for CloverleafService. Then, it’s off to actually writing the add-in portion of the code so it actually plugs into Visual Studio and doesn’t just lout around in External Tools.

If you’re interested in Cloverleaf or any of the Mono Project’s other GSoC projects, the development trunk can be checked out from our Mono Project GSoC 2008 page on Google Code. You can also see our development discussions and weekly reports on our Google Groups page. Eventually, Cloverleaf will probably find a place to live here on my website, but that’s a ways off at least.