Older blog entries for Jimbob (starting at number 15)

The Good Book

Of course, I'm talking about Jennifer Government, which came today. Somehow, this book managed to impress me despite my ludicrously high expectations of it. Imagine if The Matrix trilogy lived up to it's potential, rather than following the Star Wars model (the first movie is revolutionary due to the topic and implementation, the second movie is the best movie from an entertainment POV, and the third movie is a total letdown after the first two), and you've got Jennifer Government. I don't think it's outside the realm of possibilities to have this book end up alongside 1984 in Jr. High School reading lists.

And to finish the "fanboy" tone, I'll say that this book is good enough for me to double my typical reading speed out of sheer enthusiasm. Really, buy the damn book. :-)


So there's some recent efforts at creating a GObject-based IO stream, based loosely on some discussions from a year ago. Strangely, both me and a person halfway around the world started asking the participants for comments on the same idea within 24 hours of each other. Since I don't believe in coincidences, this is a big encouragement.

GNetwork ties in to provide the socket() stream object, servers, DNS and service query stuff. Best of all, the whole chain-o-objects thing can be done properly using this framework (somewhat like System.IO.Stream). It's different from other things in GNOME (GTK+ is similar), but System.IO.Stream is a nice starting point -- one that can be simplified and improved with GObject signals and properties.


I committed a bunch of stuff to CVS lately, mainly the big move away from using GInterface to using abstract base classes. For those who are implementing libs and such which provide GObjects, here's what I learned: GInterface is for particular APIs which can exist outside the normal object hierarchy. If you don't need the API to exist outside the normal hierarchy, or you do need the "chain-to-parent" functionality, don't use GInterface, do a GTK+-style with bunch-o-abstract-base-classes. It's actually much simpler that way.

I will say that it'd be really nice if all the various GNOME APIs for data streams were combined at some point. GLib, GStreamer, ORBit, Bonobo, and GnomeVFS all have some form of a "read from file" API, and it's silly to duplicate that in 5 places.


Yep, still not on Orkut, though I did take advantage of the fact that everyone else is to catch up on e-mail and get going on a sexy new GNetwork framework...


So libgnetwork isn't going into GNOME 2.6, which is good, since rodrigo was telling me that the current arch isn't flexible enough, which means that writing a flexible one won't break too many things (I know of only a couple users of libgnetwork that aren't me).

I also spent about four hours wracking my brain on how handle detaching a GSource from it's GMainContext (so you can attach a source to an object which has a "main-context" property, then change the property and have sources just work with the new context), until I went on Google and found out you can't... on purpose. Oh well, "notify::main-context" here we come. :-(

26 Jan 2004 (updated 27 Jan 2004 at 02:45 UTC) »

...or the abolition of the class hierarchy.

Of course, I'm talking about GStreamer and it's potential uses outside of the media world. What I'm thinking here is it's uses for things like XML, networking, etc.

So, for example, your encrypted jabber connection could be "GNetworkTcpSource -> GNetworkSslElement -> GNetworkProxyElement -> XmlElement -> JabberElement -> (JabberChatSink | JabberAppSink)". The "JabberAppSink" element would be an autoplugger that handles creating/destroying chats, as well as the buddy list and presence stuff. Tres cool, no?

But... (and there's always a but), I'm not sure how (or even if) GStreamer handles bi-directional pads. It'd kinda suck if you had to have "in_src" and "out_src" pads, but that's not that much worse than "received" and "sent" signals.

Welp, it appears that I've been officially on drugs (at least, according to Hallski and yakk) with the above plan. I've decided to concur after learning from thomasvs that doing bi-directional streams in GStreamer requires two separate, uni-directional streams. When dealing with networking, that's an unsurmountable difficulty, so blah.

Now, I still believe the chain-o-objects model of stream handling is the way to go (libsoup and libgnetwork both do SSL as a GIOChannel chain :-P), but I'm not about to re-implement GStreamer to find out for sure.

I have been working on (read as: rewriting large sections of) GnomeChat, though not committing my work to CVS, because it doesn't build yet. This brings me to GConf Hint #1:

When trying to keep your app's GConf code in a centralized place, the nicest way is to create a GObject, with properties which are mapped to GConf keys (I use a static GHashTable, with key/property names), and only have to deal with all that GConf housekeeping (like the notification functions) in one place. Then, from your app's code, simply get an instance of this proxy object and connect to the "notify::prop-name" signal. This is basically a GConf-wrapping version of GtkSettings.

This kind of thing is what I've been doing, cutting down on the sheer size of the functions which exist inside GnomeChat.

I've also been rewriting things to use the "objectification" branch of libgircclient, which handles channels, queries, and users as GObjects. This means rewriting the chatbox (viewer/entry/userlist/topic), viewer, userlist, and connection stuff. I'm also working on porting things over to GTK+ 2.4's APIs. Finally, I'm trying to figure out a nice way to handle only keeping the RDF stuff in memory when it's being used -- which may require *another* rewrite away from the current GtkTreeModel impl -- ugh.

GNetwork Library
However, keeping me from working full-time on GnomeChat is the GNetwork Library, the rewritten version of LibGTcpSocket. It's proposed for GNOME 2.6, and the plan is to have the gnome-network module/package/app suite use it.


GnomeChat is coming along again, I just committed changes to support local icons in the RDF file, fixed a couple bugs, etc.

Freenode is once again the bastard child which crashes my work. I realize that running an IRC network is not child's play, but would it be too much to ask to support the existing de-facto standards for IRC? Take the 005 line, for example. The 005 line is used to notify clients about how certain messages from the server are formatted, what channel & user modes are supported, what commands are supported, etc. For a long time, Freenode's servers didn't provide one. Since I was expecting one, things broke (in a "crash" way) when Freenode didn't. Ok, whatever, it's not an actual codified standard, so I hacked a sensible default into libgircclient. Freenode recently began providing the 005 line, but the broke the way the PREFIX variable is defined.

PREFIX=(ov)@+ is the way it should be listed. What it means is, when listing users, channel ops have "@" char before their nickname, and voiced users have a "+". This way, the client can map between the actual mode command char ("/mode +o nickname") and the character used in lists of users ("@nickname"). Freenode doesn't do that. Freenode uses PREFIX=@+, which broke my parser. Yes, yes, an IRC parser should be robust enough to handle blah blah blah. But it wouldn't need to be anywhere near as robust on the client side if the servers had their shit together. Sheesh.

The main problem is that the IRC "standard" is so bloody loose and hacked together that it's rediculous. And worse still, quite a few networks don't even bother to support the more machine-parsable pieces. Basically, it's a protocol for geeks on the console who want to feel geeky for chatting on IRC, not for people who want to have a nice, friendly, easy-to-use, just-works-right means of coordinating, say, a massive, million+-LOC Desktop Project.

New Zealand

I don't live in NZ, nor do I plan to move there anytime soon, but I would like to say (again) that socialism is not state ownership of anything. Socialism is defined as "worker control of the means of production" — democracy on the job. If the worker doesn't have final say over his or her own job, then it's not socialism. Period.

Both the western nations and the former "communist"-bloc countries spent a great deal of effor in propagating the oxymoronic myth that socialism is state-capitalism, because it served the powerful in both sides of the Cold War. The USSR had a vested interest in keeping those who agreed with the incredibly basic concept of "worker control of industry" (a majority in the USSR) believing that the State was just the way that control was exercised. The truth about what went on in the USSR — the horrible waste, corruption, brutality, etc. — was used in the west as an indictment of socialism, rather than an illustration of exactly how non-socialist the USSR (and the western forms of state-capitalist "socialism", like welfare, state ownership of services, etc.) really was. IOW, both sides lied about what socialism really was, because it was in their interests to do so.

But don't take my word for it, here's George Orwell, from Homage to Catalonia (online version):

"In every country in the world a huge tribe of party hacks and sleek little professors are busy 'proving' that Socialism means no more than a planned state-capitalism with the grab-motive left intact. But fortunately there also exists a vision of socialism quite different from this. The thing that attracts ordinary men to Socialism and make them willing to risk their skins for it, the 'mystique' of Socialism, is the idea of equality; to the vast majority of people Socialism means a classless society, or it means nothing at all.
Since it needs repeating, equality doesn't mean "everybody" and "the state/managers/bureaucrats". Equality means equality. There's no such thing as "partial equality" or "equality in name only". Either people have equality or they do not. There is no try... :-)

Israel & Palestine

I realize I'm opening another can of worms by commenting on this, but I feel as though I must. Hamas would not have the power or the popular support they have today among the Palestinians if the Israelis did not give Hamas the opportunity. What I mean by this is: if Israel did not attempt to starve, maim, and otherwise drive the population of Palestine out, then Hamas would not enjoy the support they have — support they gained because they provided the food, water, and community organization the Israeli military destroyed. IOW, they kept Palestinian society from completely collapsing, and the Palestinians support them for it.

Attacks on Hamas leaders enrage Hamas militants, yes. But those militants would not be there if the Israeli military did not do things like wage helicopter missle attacks on crowded city streets in the afternoon, or drop laser-guided bombs from F-16s in the same situation. Those militants would not be there if Israel didn't cut the power, cut the food, wall off the areas, bomb them from the air, fire on ambulances and medics, roust people from their homes, and all the other innumerable acts of tyranny that happen the Palestinian areas when the Israeli military comes to town. Of all political organizations, the State of Israel should be the first to avoid the Warsaw ghetto, not the first to repeat it.

Most importantly, the question must be asked: Why is Israeli military in the Palestinian areas to begin with? What possible good can come from that? Revenge is one possible motive, defense of colonization efforts (called "settlements" on TV) is another (more plausible) one. It's like the U.S. Cavalry being called in to defend the white settlers after they took Apache land — Yes, what happened to the settlers was tragic, but if they didn't take somebody else's homes, they'd be breathing today.

But whatever, I'll take the right-wing libertarian out and say that I just don't want to pay for it.

Welp, I've been suckered into rewriting the XML IRC network list to use (gasp) RDF. My current plan is to have a parser that will parse something like this:

<rdf:RDF (xmlns garbage)>
    <rdf:Description about="irc://GIMPNet/">
             irc:width="77" irc:height="57 />
        <dc:Description rdf:parseType="Literal">
            <p>A paragraph.</p>
            <p>Another paragraph</p>
<!-- servers go here --> </rdf:Description> </rdf:RDF>
What's the major advantages to ditching what I've got for RDF? First and foremost, RDF is already a standard. The "irc:<blah>" stuff is a custom namespace, yes, but custom namespaces are accounted for in the standard, and a real RDF parser would take them into account (even if the values are unread). Also, if I'm already using an RDF parser, it shouldn't be that difficult to handle things like FOAF & vCard, which would both be undeniably cool features (trade address-book cards in your IRC client? groovy!). Finally, RDF's use of URIs means that I can easily handle conversion between <irc://irc.gnome.org/> and <irc://GIMPNet/>, as mandated by the Mozilla IRC URIs spec. Of course, all this is dependent on the assumption that I have any clue about RDF... :-)

nymia: Sorry about the extras, being in college I got used to having to explain what I mean when I use the terms socialism/communism/capitalism in discussions (It helps keep the intellectual level above "You're a pinko!" "And...?"). :-) Also, since no exchange system is perfect or totally incorrect, and no organizational system is perfect or totally incorrect, they are only "good" or "bad" in relation to other systems, or possible systems.

johnnyb: Please attempt to parse what I'm saying, we're arguing similar positions w/ conflicting definitions. You're using a different definition of the term "socialism" from the one that I'm using (which is why I stated my definition of socialism up front). Further, I didn't say that a socialism was a "gift" economy, I said specifically that they were different. And yes, a gift economy is similar to a market economy, in that they are both means for multiple groups to exchange goods/services.

So, one more time: exchange systems != organizational systems. Capitalism and socialism are both organizational systems. The "market economy" and the "gift economy" are both exchange systems. You can have a socialist factory exchanging goods and services with a capitalist factory, using money. That's socialism & capitalism co-existing within a market economy.

We're saying something of the same thing, capitalism != markets, socialism != gift economy, because organization != exchange. A capitalist gift economy is possible, as is a socialist gift economy. A socialist market economy is possible, as is a capitalist market economy.

Socialism is the idea that "the workers control the means of production": IOW, the person on the line who actually writes the code, sews the shirt, mines the ore, or builds the car gets a vote on who that car/shirt/ore/code goes to, and gets a split from the proceeds. Socialism is just employee ownership to the point where the term "employee" is a misnomer. (As an sidebar, when you are forced, it is no longer a truly socialist organization -- force & democracy are mutually exclusive.)

As to the motivational power of monetary gain, it is a farce. Monetary survival (having enough money to live w/o fear of being evicted, starving, etc.) is a motivation, but that is the motivation of fear, not the motivation to excel. I have never worked harder at a job because I wanted a raise, nor do I ever see myself doing so. I may work harder to avoid getting fired or because I need a raise in order to eat, but I don't think working out of fear of being fired or starving is a very productive work environment, personally. As per Office Space: "you work just hard enough not to get fired."

And however you measure motivation, at the end of the day, a person's excellence is measured only through the respect of their peers, not on how much money they have.

So, I've decided to create an IRC Network Markup Language based on XML to describe the server list. However, this isn't intended to be just a local data storage format. Ideally, IRC networks could generate their own network lists, and the client would just download/cache them from the URIs given. Ideally, an IRCNML document would include everything a user-friendly client would need to know about an IRC network and it's servers. Sooo, here's an example, for GIMPNet:

    <network id="gimpnet"
     data="http://www.gnome.org/gimpnet.xml" />
And, in gimpnet.xml:
    <description>Some description on GIMPNet (content whitespace is significant)
Another paragraph of description...</description> <encoding>UTF-8</encoding> <website>http://www.xach.org/gimpnet.html&lt/website> <channel id="#gnome-help"> <name>Help With GNOME</name> <description>Get help on the the GNOME Desktop</description> </channel> <server id="dupe.xcf.berkeley.org"> <address>dupe.xcf.berkeley.org&lt/name> <ports> <port>6667</port> </ports> <location> <name>dupe.xcf.berkeley.org</name> <city>Berkeley</city> <province>California</province> <country>United States</province> <continent>North America</province> <iso>US</iso> </location> </server> </network>

Anyways, to get this working, I'm writing a GInterface for file transfer objects, and a wrapper for async/cached transfers using GnomeVFS (Which means I can either write a GnomeVFS module for DCC file transfers or a LibGTcpSocket-based one, if I want). Of course, doing things this way also means I can write global file-transfer list dialog (of some kind), which is cool (though probably unecessary for an IRC client--we'll see).

Capitalism, Socialism, & Communism

Warning: The following is my (oversimplified) interpretation of Karl Marx. If you don't like Karl Marx, or don't want to know what I think the difference between capitalism, socialism, and communism is, well, skip to the bit about software.

johnnyb: I'm sorry, but your terms are wrong. Capitalism is an organizational system whereby those who control (own) the capital (land, technology, machines, raw materials, etc.) are not those who use the capital to produce things. It's an extension of feudalism, whereby the nobles owned the land, but the peasants worked the land, and paid the nobles for the use of the land. Under capitalism, rather than pay the capital owner for the use of the land, everything you produce is automatically owned by the capital owner, and you get a portion of what you produce (or it's equivalant, in $) it as payment.

Socialism, in contrast, is the organizational system whereby the capital owner and the laborer are the same. So, for example, in a real socialist system, employees would vote on what their pooled capital should be used for. In extreme cases of disagreement, those who are not willing to abide by the vote can pack up and leave, taking with them their share of the capital. IOW, true socialism is employee ownership to the point where the term "employee" is no longer accurate (since every "employee" works for both themselves and every other employee at the same time).

I think when you're saying capitalism, you mean an exchange system which uses money as means to quantify exchange value (exchange value = labor used + capital used). An exchange system based on money does allow for optimization of the organizational system used to produce things, but is generally unrelated to whether the organizational system is capitalist, socialist, or some mix of the two.

Communism, (by which I mean the raw definition of communism, not what the USSR, PRC, USA, etc. say communism is: state capitalism, industrialized feudalism, or just plain old fascism) on the other hand, is a socialist organization of production combined with a non-value exchange system. Thus, the communist exchange system is the so-called "gift economy". I think everyone agrees that a gift economy would be really cool if it could work, but disagreement arises over whether or not it could work.

As for the question of morality, I think the answers are obvious (given accedance to the definitions above, of course). In a working, purely "gift economy", no one could starve unless there simply weren't enough resources to go around. In a working, purely "market economy", people can starve, even when there are enough resources to go around, simply because there is no guarantee that one will have enough of the available resources to survive.

As you mentioned, there is a connection between the morality of the people laboring in the system and the efficiency of a "gift economy". I'd counter by saying that it's a chicken/egg problem. Are people immoral because market economies reward such immorality, or are market economies simply rewarding people's natural tendancies to be immoral. That's a personal question, obviously, based on your own beliefs on human nature. I would like to add this, however: Gift economies worked fine for the most of the pre-columbian Native-Americans in North America. Were the Native Americans better people than their European conquerors, as they had accepted a more "moral" system of exchange? Or were both the Native Americans and their European conquerors simply responding to their respective environments: tribal communalism in North America vs. the feudal market system in Europe?

So, with the morality of exchange out of the way, on to organization! :-). In a working, purely socialist organization of production, each person has an equal say in what their resources (and more importantly, their time) are being used for. Conversly, in a working, purely capitalist organization of production, only those who own the capital have a say in the use of resources and labor time for not only their own resources and time, but also all those who labor for them (their employees). The morality of socialism vs. capitalism is the morality of freedom vs. slavery. Take your pick.

Currently, my thoughts on that which matters least are:

LibGTcpSocket is almost ready for a full-fledged 1.0 release, but the duplication of code between this & LINC is disturbing (at best). I've got something of a plan on how to handle this:

First, add a new enumerated type, LINCError. Then, add LINC_ERROR and LINC_LOOKUP items to the LINCStatus enum. Then, add a LINCError item to the object-private data. Then, add
LINCError linc_connection_get_error (LINCConnection *conn);
to the API. Finally, hook all these new things in, and LINC would be totally usable by LibGTcpSocket. AFAIK, the changes should be ABI compatible and (mostly) API compat (the additions to LINCStatus would need to be taken into account by users of LINC).

LibGTcpSocket would then become a wrapper around LINC which does automatic proxy traversal, and has a nicer API. This is easier for me, as I like the LibGTcpSocket API, and would cut down a lot on GNOME's code duplication if LibGTcpSocket became the officially sanctioned way of handling network connections.

Of course, LINC is now private to ORBit, making all this moot. Perhaps a stable, next-gen LINC API/ABI can be re-introduced back into GNOME at a later date... (hint, hint) -- This is what I get when I stop paying attention to mailing lists for a while.


GnomeChat is officially usable as an everyday IRC client. It doesn't support DCC yet, and there are a bunch of both design and implementation bugs which need to be worked out for it to be officially "ready" for a 1.0 release, but if you just want to chat on IRC, it'll work. I would recommend that you not leave it idling while you go off (away for more than a few seconds) and do other things, though, as no efforts have been made to ensure it's secure.

Currently, I'm working on a custom GtkTreeModel implementation for the XML-based network list.

Nautilus URIs

I personally think Nautilus URIs are a bad idea, and would never intentionally use one if I could avoid it. However, with that said, if people want to waste their time writing one, I say more power to them -- I wouldn't want them being used in the "Official" GNOME, but as add-ons, I think they're acceptable.


One of the nicer things in GObject 2.4 (the whole dynamic typesystem thing is really cool once you get used to it) will be the GObjectPrivate feature. Basically, it's replacing the *_priv members and keeping it all straight in GLib. Of course, if your object already has _priv, it's slower to call a function & get the *_priv data than just access *_priv, but that's not the point.

The point is to add new features to ABI-frozen library objects, which require new struct members to do well. So, for example, GtkWindow can have stock-id-based icons, or GtkPaned can do click-to-collapse on the separator, in a drop-in-replaceable way. Very cool!


Things which affect me indirectly...


I often wonder why people in the United States view the government as their friend, if not savior. Historically, blind faith in one's "leaders" (rulers is a better term, IMHO) is a recipe for disaster, repression, and genocide. Ask the Germans, French, and Russians. They are well aware of what happens when you put such faith in a ruler. The very word "terrorism" was originally invented to describe the form of government that the Jacobins instituted after the French Revolution (thus stealing the people's revolution and turning it into the original experiment with state communism). All three states each killed more people than all the terrorist incidents in the last 100 years combined.

And the right-wing in the U.S. wonders why they were the three loudest voices against Bush's War(s). Yes, the governments involved opposed the war for political/economic motives. Yes, Iraq owed each of the three states huge amounts of cash. That, however, doesn't explain the opposition of those countries to the war. If the states wanted their money, why not jump on the bandwagon and demand a fair shot at those lucrative rebuilding contracts? (BTW, all those contracts have thus-far gone to companies with direct ties to the Bush administration.)

The reason is simple: 90%+ of the populations of those states didn't want to go to war. They were (gasp) following the principles of democracy--when the majority of the population wants peace, you don't go to war, and you don't make up lies about weapons of mass destruction, and 9/11 to convince them to go to war.

Our Western European "allied states" in this war were massively un-democratic in their approach to the war. In Spain, 95% of the population opposed the war, and the largest unions called a 1-day general strike to show their distaste for the government rejecting what an undefeatable majority of the people wanted. In U.K., before the war, opposition was between 70% and 55% of the population (depending on the survey & exact date). The governments rejected popular demands to stay the hell out of it, and instead chose to accept foreign domination of their political process, the people be damned.

And then there is Turkey. Neighbor to Iraq, it was included in early plans of the invasion. Unfortunately for Bush, the parliment their realized that revolution was not far off if they chose to allows U.S. forces to use Turkish soil over the complaints of 90% of the Turkish population. So the Turkish parliment voted to reject the U.S. demand. And what happened? Bush demanded a re-vote! I'm sorry, but if Gore didn't get a re-vote to confirm his victory in the 2000 election, why should Bush get a re-vote in another country, to support an invasion that even a third of U.S. citizens didn't want?

Of course, there'll conveniently be another terrorist attack just in time to get Bush re-elected. Just watch TV and be afraid of who they tell you to be afraid of.

6 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!