Planet LUGOR Mobile Edition

Linux User Group of Rochester RSS News Feed: The LUGOR Meeting for Thursday, May 15 from 7:00 - 9:00pm will be held at RIT in building 70 room 70-1400. The topic will be "FOSS and Patents" by guest speaker Barnaby Bienkowski.

Tue, 13 May 2008 12:49:01 +0000

Justin Kirby: Qunu RIP?

Thu, 13 Dec 2007 00:01:44 +0000

First, I would like to apologize to everyone who put so much effort into qunu.

Current Status:

The server has been taken offline. There are no backups which are current, the latest is one month old.

Why:

The server that was just taken offline was to be a temporary home lasting one, maybe two months. We were then going to find a more permanent setup. As with most things that have a deadline it received no attention until it was necessary.

Apparently there was some confusion as to the date which the account was to be canceled. It was scheduled to be taken offline on December 21, 2007. However, the server was taken offline nine days before the scheduled time (e.g. today)

A few weeks earlier, Mickaël at process-one had generously offered to take qunu off our hands. So we had finally found the home we had been looking for. I had even started the process of getting all the data off the server. Unfortunately, the transition is not going as smoothly as I had hoped.

Once again, qunu will suffer through a period of downtime before it is finally resurrected again. Maybe qunu should be renamed Phoenix or Lazarus

At some point when all the kinks are worked out, probably next month, qunu will be started at its new home. Don’t hold your breath, but don’t give up hope either.

Justin

Justin Kirby: Selecting whole buffer

Thu, 06 Dec 2007 20:04:34 +0000

Just ran into this emacs key binding. Someday I need to just read the manual and mark all the stuff I wish I knew already for later study. But since I will probably never do that here is yet another cool thing in emacs which I didn’t know about:

C-x h runs the command mark-whole-buffer
which is an interactive compiled Lisp function in `simple.el’.
It is bound to C-x h,
.
(mark-whole-buffer)

Put point at beginning and mark at end of buffer.
You probably should not use this function in Lisp programs;
it is usually a mistake for a Lisp function to use any subroutine
that uses or sets the mark.

If you didn’t know about this, enjoy.

Justin Kirby: Emacs, the lisp OS

Mon, 03 Dec 2007 16:36:59 +0000

Not only can you edit videos in emacs now, but you can also create music. My initial response was WTF!? However, after watching the demo videos, I can see the practical uses.

Justin Kirby: nyc erlang/ejabberd meetup

Mon, 26 Nov 2007 02:56:51 +0000

I am going to be meeting with Mickaël Rémond at an adhoc ejabberd meeting. afaik, the location is undetermined, however, I am flying out in the morning and have decided that Gramstand is as good of a place as any for now. (primarily thanks to stumbling onto a coworking blog). Will probably move onto a more pub-like venue later on.

I am hoping to meet a few erlang/ejabberd devs on this trip. If not, the chance to chat with Mickaël f2f will definitely be worth the 1.2hr plane ride.

I am taking Jetblue flight1 from Buffalo to JFK and landing around 10:00am. Then finding my way from Queens to Manhattan via the subway. It looks like I will have about 8hrs to play with in nyc.

If you have the time or inclination give me a ring at 585-705-1877 I will be hanging out at gramstand writing erlang.

Justin Kirby: Impressive Incompetence

Tue, 25 Sep 2007 15:51:21 +0000

Open letter to NYSIF:

https://www.nysif.com/include/BrowserDetect.asp?browserNM=Netscape

You should be congratulated. This is a level of incompetence of which I have not seen since ’90s.

My scathing insult aside, what is that? The world has moved on. There are ther platforms out there such as OS X and Linux which have fully capable web browsers. You really should look into hiring a new web team if thats the best they can do.

Justin Kirby: Lisp Tutorial

Thu, 20 Sep 2007 15:09:31 +0000

This is a good idea.

Lisp Tutorial

Justin Kirby: I am now a jaiku lemming

Fri, 31 Aug 2007 00:43:56 +0000

I have been avoiding these social hype sites for a while now. I have
simply failed to see the benefit. (besides sucking yet more of my time.)

Today, stpeter posted that jaiku had a jabber interface. Anything that
allows me to quickly utilize their service via emacs is very
enticing. Since I use emacs-jabber jaiku was
simple.

While I was able to setup a profile quickly and get it setup
in jabber via xmpp:jaiku@jaiku.com I
have yet to find anyone I know on there. I have 348 people in my roster
and not one of them is on jaiku. Oh well.

I suppose the price one pays when they ignore all the social crud
crusting up the edges of the web is that they don’t know anyone
there. (Also, not blogging for a while probably might have something to
do with it.)

Justin Kirby: presence pendanticity

Thu, 03 Aug 2006 17:17:05 +0000

I just had an interesting chat with hawke about presence and transports. It may seem pedantic, but I think it strikes at an important point. A lot of clients assume that a jid must have a node; miranda,iChat,gtalk come to mind. If that jid lacks a node then it must be a transport, e.g. behave fundamentally different than a typical IM client connection. In other words the jid is being used to determine the basic functionality of an entity on the xmpp network.

Below is the chatlog, but it can be summarized as:

hawke asserts that presence is a mutual agreement for communication
I assert that presence is a reflection of an entities availability

This post is a solicitation for opinions.

Below is the chat log

[12:11] hawke> since most clients will show the quser
service as a transport, instead of (or as well as) sending the
message, just send offline presence.
[12:11] hawke> then they can just log back in
[12:11] hawke> instead of the ’status on’ message
[12:12] zion> thats a bit client specific though
[12:12] hawke> How so?
[12:12] zion> quser is not intended to be a transport
[12:12] zion> just because it doesn’t have a node in the jid
[12:13] hawke> I’ve not seen a client that determines
transport vs. other contact any other way.
[12:14] zion> emacs-jabber ;)
[12:14] zion> yeah… that semantic is annoying
[12:14] zion> so I don’t want to encourage bad habits
[12:14] zion> the client should disco to find out what it is, not use
the jid to assume
[12:14] zion> to many clients to that, and it sucks
[12:15] hawke> True
[12:15] zion> the jid is an identifier, nothing more
[12:15] hawke> But even so, the same thing applies to
quser as actual transports
[12:15] hawke> you still log on and off by sending
presence
[12:15] zion> no… there is not log on/off
[12:15] zion> I added that ability because it was requested
[12:16] zion> its a presence aware node on the jabber network
[12:16] zion> it doesn’t proxy your messages to another network
[12:16] hawke> I think the distinction between
“list/delist” and “logon/logoff” is pretty unimportant for this
purpoose.
[12:16] hawke> too many “o”s.
[12:16] zion> it is important actually
[12:17] hawke> oh?
[12:17] zion> if you go ‘away’ on aim/msn/yahoo then you are still
reachable
[12:17] zion> you are still connected to that network
[12:17] hawke> How does that relate?
[12:17] zion> so there is a diff between list/delist and logon/logoff
[12:18] hawke> Going “away” is different from logging
off though
[12:18] zion> thats my point!
[12:18] hawke> If I send offline presence to a
transport, I am logged off not set away
[12:18] zion> exactly
[12:18] hawke> if I send offline presence to quser, I
am delisted/no longer reachable to the qunu web service
[12:19] zion> there is NO logoff from qunu
[12:19] zion> you will not be listed
[12:19] zion> but quser can still contact you
[12:19] zion> since you are still on the jabber network
[12:19] hawke> Obviously.
[12:19] zion> qunu is a jabber service, not a transport
[12:19] zion> there is a distinct difference and the semantics of a
transport do not apply
[12:20] hawke> I know that; the logic is the same
though — log off/on.
[12:20] zion> if you log off aim, can the aim network still contact
you?
[12:20] zion> no
[12:20] hawke> Only the terminology is different.
[12:20] zion> no its not
[12:20] hawke> but that’s “can’t” vs. “won’t” isn’t it?
[12:21] zion> presence is significantly different than network
connection
[12:21] hawke> if I log off of quser, it
won’t/shouldn’t be inviting me to rooms.
[12:21] zion> inviting is only one activity
[12:21] zion> and there is no ‘log off’ quser
[12:22] hawke> Sure there is
[12:22] zion> *sigh*
[12:22] hawke> if I send offline presence, I am logged
off
[12:22] hawke> am I not?
[12:22] zion> if you send me offline … does that mean I am a
transport?
[12:22] hawke> I am no longer listed in the web
service, and I won’t be invited to rooms any more.
[12:23] zion> just because your client forces those terms in the UI
does not define it
[12:23] hawke> No. I’m not saying it is a transport.
I am saying that the particular action of sending online/offline
presence that applies to transports also applies to quser
[12:24] zion> right. if you send directed offline pres to quser, then
it will think you are offline and treat you accordingly
[12:24] hawke> Yes.
[12:24] hawke> though it will still respond to
messages.
[12:25] zion> I lost track of where we are… we seem to be
disagreeing about something, but saying the same things
[12:26] zion> you want quser to behave like a transport by sending
presence offline instead of using status on/off
[12:26] hawke> Let me restate my suggestion: The status
of quser should reflect the user’s listed status on the quser web
service.
[12:26] hawke> yes
[12:26] zion> my argument is that is not appropriate, because quser is
not a transport
[12:26] hawke> quser is a presence proxy.
[12:27] hawke> (and metadata bot, but that’s not
relevant for this purpose)
[12:27] zion> so quser should send an offline presence to the user
[12:27] zion> which will hide it from the roster ui
[12:27] hawke> I think so, yes. Sending the message,
so that they notice is also valuable.
[12:28] zion> but quser is not offline
[12:28] zion> and the user is not offline
[12:28] hawke> True.
[12:29] hawke> Well
[12:29] zion> imo, pres should indicate the availability of an entity.
[12:29] hawke> the user is “offline” as far as the
website is concerned.
[12:29] zion> not exactly correct. the website is just a jabber
client.
[12:30] zion> so the user is delisted from results, but not offline
[12:30] hawke> and with transports, presence doesn’t
indicate whether the service is available either
[12:30] hawke> it indicates whether or not you’re
logged in to it.
[12:30] hawke> For the purposes of the website, what’s
the difference between being delisted and offline?
[12:30] zion> currently, nothing ;)
[12:31] hawke> QED.
[12:31] zion> qed?
[12:31] hawke> http://en.wikipedia.org/wiki/Q.E.D.
[12:32] zion> ex: we are going to be incorporating pubsub into the
service
[12:32] hawke> OK..
[12:33] hawke> Does the users presence have any effect
on pubsub?
[12:33] zion> it should
[12:33] zion> e.g. if they are really ‘offlien’ vs ‘away’
[12:34] zion> if pres != chat || online then they are delisted
[12:34] hawke> OK..
[12:34] zion> if pres != chat || online || dnd || away || xa then send
them pubsub events
[12:35] hawke> So, only send them pubsub events when
they’re offline, or am I missing a status there?
[12:36] zion> only send them pubsub events when they are connected to
jabber, if they are offline don’t
[12:36] zion> there is a diff between ‘I am connected’ and ‘I am
online/away/xa/etc..’
[12:37] hawke> but surely you can send pubsub events
regardless of quser’s status?
[12:38] zion> of course… we could set it to offline and still send
stuff
[12:39] hawke> As I see it, the user sending directed
offline presence [to quser] means “I don’t want you to talk to me any
more”; quser then sends its own offline presence confirming that.
[12:40] hawke> So when quser decides “I’m not going to
talk to you any more” it should do the same thing.
[12:41] zion> you assertion is that presence is a mutual agreement of
communication
[12:41] zion> my assertion is that presence is a reflection of an
entities availability
[12:41] zion> regardless of its role
[12:42] hawke> OK, so amend that to add “…unless you
talk to me first.”

Justin Kirby: unnecessary pain

Wed, 05 Jul 2006 07:58:35 +0000

No plan survives contact with the enemy. This was made abundantly clear when Qunu was released as alpha for the public to abuse. As with any alpha there were countless problems that I dealt with on a daily basis. Clients insisting that a jid must have a node, xdata limitations in iq:register, double subscriptions, broken muc support, etc…

For some of these problems I was able to hack up a work around, such as quser@qunu.com as a subscription proxy for quser.alpha.qunu.com. A few of them had no decent solution and I had to suggest other clients. The wiki page, http://qunu.com/wiki/index.php/Documentation, has a list of clients which have the bare minimum feature set.

The default gtalk client does not support muc or groupchat. Since a lot of people had a gmail account they naturally tried to use their gtalk clients. Making the brash assumption that gtalk behaved like every other xmpp server I directed them to the above list of working clients to try. After several confusing chats and some poking of my own I quickly discovered that gtalk is not xmpp.

That may sound rather harsh so let me qualify that. While google’s xmpp-like servers may follow the letter of the xmpp RFC’s they most certainly do not follow the spirit. The reason I say this is that the gtalk servers will block any stanza which their default client will not understand regardless of which client you are actually using. This means that even if you wanted to get cool new features by using another jabber client, gtalk will block the stanzas before they get to your client. Not only do you have to get a different client, but you have to use a different server. *sigh*

The biggest issue, at least for qunu, is muc invites. GTalk silently drops them regardless of which client is on the other end. disco requests are reported assuming the default client. iq:version is always reported as not implemented, again ignoring the client.

Of course there is no bug/issue report system at google. Thus this blog post. Hopefully someone at gtalk will see this and file a bug. Of course, if you need further clarification, feel free test this yourself or ping me at zion@openaether.org

Justin Kirby: announcement: open qunu trial

Thu, 08 Jun 2006 05:15:37 +0000

After many long nights and lots of bug squashing we are finally ready to open up Qunu for general abuse. This is an invitation for everyone in the jabber community to try it out. Let us know what you think and how Qunu can be made better.

So what is Qunu?

<marketing-speak>
In a nutshell, Qunu is a Jabber-based ‘ask-an-expert’-style service that you can ‘tag’ yourself with. Qunu allows you to use your existing jabber client instead of forcing you to lurk on a web forum, irc channel or muc room. In essence, people looking for help come straight to you, the expert.
</marketing-speak>

How it works

Someone on our site searches for help in an area in which you have tagged yourself. They can request an anonymous chat with you. We then send a MUC invite to your jabber client which you can accept or reject. We only send thru invitations when you’re online and available, and you can change your presence with us at any time. You have total control.

<marketing-speak>
It’s a great way to give your expertise back to the community in a non-annoying,
non-intrusive way. You can give help when it’s convenient for you, and best of all, you get to see the ‘thank you’.
</marketing-speak>

How to get in

In order to accommodate the various ‘quirks‘ of all the jabber capable clients out there we have setup lots of ways to get in.

Use the site at http://alpha.qunu.com. This is simply a custom jabber client via html and javascript.
Register with quser.alpha.qunu.com
Add quser.alpha.qunu.com to your roster via a subscribe request
Add quser@qunu.com to your roster

The end result of all this is to get quser.alpha.qunu.com on your roster.

Let us know
This is an alpha release. We would love your feedback.

General discussion is in alpha@muc.alpha.qunu.com. The wiki at http://qunu.com/wiki and of course using qunu via http://alpha.qunu.com/search/qunu