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... :-)

Capitalismnymia: 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.

GnomeChat
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:

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).

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.

Software
Currently, my thoughts on that which matters least are:

LibGTcpSocket

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, addLINCError 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

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.

GObjectPrivate

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!

Life

Things which affect me indirectly...

Terrorism

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.

GnomeChat
Implemented the prefs dialog. I realized I'd been too long without considering UI when X-Chat 2.0's "let's reimplement multirow notebooks" UI started to make sense. :-P

LibGTcpSocket
Started work on the docs. I'm thinking of releasing a beta version after I finish them and write testgtcpserver.

School
Perhaps it's simply the Political Science dept. at my school that's insane, perhaps it's the western world, I'm not really sure. I'm sorry, but Thomas Aquinas was nuts, and his arguments are weak at best.

Paranoia
I'm really not the most patriotic person, in the right-wing, "wrap your racist xenophobia in the flag, flip the UN & ICC the bird, and start bombing wedding celebrations," sense of the word, nor am I exceptionally prone to bouts of paranoia, but when a person I've never seen before approaches me, immediately launches into a brief "stop screwing around in their country" tirade, and ends it with (direct quote) "so what do you think about all this?" I tend to get a little paranoid.
This happened the day before the news started running stories about terrorists in the U.S. Ugh.

libgtcpsocket
libgtcpsocket is a GObject-based networking wrapper intended for use in GTK+/GNOME applications which need an easy-to-code-against connection wrapper that ties into the mainloop/signal system nicely. It's currently in GNOME CVS, in the "libgtcpsocket" module, and is nearing feature-complete-beta status, proxy support is the only major feature left to finish.

libgircclient
libgircclient is a subclass of libgtcpsocket for IRC client connections. Currently unusable, waiting on libgtcpsocket to be stabilized. In GNOME CVS, in the "libgircclient" module.

gnomechat
GnomeChat is Yet Another IRC Client, using GNOME 2.0, libgtcpsocket, & libgircclient. The major design goal of GC is to provide an IRC client that anyone could use to easily handle common IRC tasks, such as channel oping, sending/recieving files, and communicating with other users. The UI is about half complete, the other half is waiting on libgircclient. In GNOME CVS, in the "gnomechat" module.

Random
If you mistype "strong" as "string" without thinking and
create a few screenshot mockups months back, does that mean
you are qualified as a Journeyer? Somehow I doubt it, but
that's what I'm certed at... Go figure.

UI Hit Squad
Sigh. Well, I haven't posted any updates because for all
practical purposes the Hit
Squad is dead. This is partially my fault for jumping in
when I had no clue about project management, so pity the
poor fool. I haven't decided what exactly to do about this
ex-limbo status given Eazel's expressed desire to work on UI
as well. I know they have the talent and drive to basically
take over from the GNOME UI Improvement Project after
Nautilus is out the door, so I think I'll concentrate on
learning programming so I can help implement what they come
up with.

Projects
Well, I'm currently hacking together a patch for X-Chat
1.5.x's GNOME version that contains major UI reworkings. So
far I've gotten through the server list, reworked the menus,
and am starting to change the main window's UI. Thank
goodness C and GNOME/GTK+ isn't that difficult (except
strings, which I have grown to seriously hate in the last
few weeks -- although I'm sure that's at least somewhat
related to the fact I had no idea what I was doing going
into it (On a semi-related note, I really wonder what the
heck people who programmed strings in DOS back in the bad
old days were on -- using an OS where a segfault == a reboot
is a pain when you are learning strings, believe me [I don't
know if Windows is as clueless on this, but somehow I have a
hard time believing it isn't]). Hopefully I will have enough
of a clue when I am
finished to start making real contributions for a
change.

Scandalous
I go back to college later this week, so my IRC usage may
drop in favor of forced torture (C++ course *and* a COBOL
course in the same semester <<shudder>>). On the
plus side though, I will get cheap 1mbps DSL, so I can
regain some of my stature as a LPB in various online games.
That's about all from the personal front.

Projects
I've started modifying my GTK+ XMMS Skin to match my
"XenoFace" (Interface) GTK+ theme (which is the hack of
Xenophilia-0.4 that showed up in Carbamide's
Nautilus screenshots from May or so).

Personal
Well, seeing as this is what the diary junkies *really* want
to see, I suppose I have to throw in some detail or event
that isn't computer-related just to let the hardcore IRCers
among us know that the world isn't actually a computer
generated simulation of the real world, composed of channel
bots and the like.

Got back from the oral surgeon a good report (the holes in
my jaw where I used to have two teeth are not infected and I
can go back to eating junk food regularly). Not much else to
report.

I've decided to take the Salon article as an
admonition for
me to start keeping this diary up to date, rather than
posting one diary entry every five months...
:-)

Projects

The "Gnome System Administrator" application
will not be
coded by me. Helix is
working on a scaled down version of it, and I
trust them more than I trust myself re: coding.

Musing

I agree 100% with what I've heard of Miguel's
comments on coding (although I think a transcript of his
keynote will have to be put up somewhere
There
is waaay to much code duplication.
Slashdot's ignorance not withstanding, it's just plain dumb
for every app to load into memory it's own dialogs, stock
buttons, printing support, etc.
From a coding point of view, you're
making you're own job tougher by doing this. From an
efficiency point of view, you're making the system's job
harder by making it load a different version of "Common
Feature X" for each app.
What's more, the aguments for not
depending on lots of libraries is foolish. Unless you're
doing something dumb, like linking to an unreleased library
under heavy development, the APIs are not likely to change
that much between revisions, and if they do, the earlier
revision will still work (you can have more than one version
of a library around, remember).
"Saving the user some download time"
is also lacking in veracity. If you put links up to the deps
that need to be downloaded on the same page as your app
download link is on, and toss some instructions on the page
as well, where's the huge loss. These people are on the
Internet all the time, and they still can surf while they're
downloading (Modems are both not 14.4 and not
single-tasking).
Then there is the argument that
libraries take too much disk space... Can anyone guess what
the majority of my disk space is taken up
by? MP3s. 30% of
my system is MP3 files. One five minute song in 160kbps MP3
format takes up more space than all the .so files in
gnome-libs and gdk-pixbuf. I would bet a
serious amount of cash that a great majority of the people
so concerned about their disk space can spare a few measily
megs for what most GNOME apps need on top of GTK+... (And if
you aren't using GTK+, you're using something nearly the
same size.)

However, the most serious reason for using libraries (at
least from my point of
view and taking into account the assumption that your app is
GUI-based :-)) is that they allow for a consistent user
interface
far more easily and with much more
structure than the implement-it-yourself method does. And
seriously now, what is the point of releasing a GUI app to
the world if you don't care about the interface looking good
and fitting in with the rest of the system.

Ok, this is the first entry for me, so I'll attempt to bring
everyone up to speed on whatever I can.

First off, I would like to appologize for not posting a UI
Summary yet. The reason I haven't done this is because we
haven't finished anything yet, and the entire thing would be
a bunch of links to Eazel, Inc. resources and articles. I
would like to get at least two news items before posting a
new summary, so that's that.

Somewhat related to the first item, I did send out Proposal
#2 (Improving The GNOME-Core Interface) to the other members
of the Hit Squad. All that's left is for them to vote on it,
me to HTML-ize it, mix it with the redesign screenshots I've
already done, and announce it to the world (at which time, I
will post the URL).

And as a little teaser to get you all flipping out (:-)),
I'm planning on learning GNOME/GTK+ programming so I can
code a GNOME System Administrator application. The basic
idea is that I steal the Control Center 2.0 code (the next
gen codebase), change a few labels, and write some sample
capplets. And what do these capplets do? Simple. Configure
system services! That's right, a gnomecc-style interface for
setting up Runlevels, httpd, nfs, exim, samba, etc. And
since it uses capplets, service authors can (read: should)
write their own capplets which handle the intricasies of
their service. A Roxen capplet could ship with Roxen, an
Apache capplet with Apache, etc. This way nobody has to keep
track of every config file format under creation, just the
few that the sample capplets I'll provide handle (I plan on
doing capplets for the current OSS Linux versions of all the
major services: NFS, Apache, Samba, Exim, and a Runlevel
editor). So after this is finished, pester your favorite
vendor to write a capplet for their setup.

If you are already working on such an app, please contact me
immediately so I don't waste my time, thanks ;-)

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.