|Jabber and MacOS X|
As I told in an earlier post, MacOS X 10.4 aka Tiger feature Jabber compatibilty in iChat. I found the Jabber FAQ on MacOS X Tiger for those who want to make the switch. I'd really love to see the Mac users switcher over to Jabber.
Note that you don't need MacOS X 10.4 to connect to Jabber. There are a lot of Jabber client on Mac.
Alex Graveley links to subtext, I think this thing looks awesome. A perfect place to experiment with it would be something like GNOME panel applets, Apple Dashboard, or Second Life objects. All these are limited programming domains where making programming easy would be high-value. I guess any sort of plugin/extension system might be a good place to experiment, but graphical ones seem more exciting. Seth points out that it's similar or at least complementary to some Smalltalk ideas.
|Mac client printing to Cups server on Linux…|
So, I had quite a lot of head scratching today trying to get printing to work from my wife’s iBook to the spanking new installation of SUSE Linux 9.3 I put on my fileserver. It just wouldnt work, while my linux laptop printed totally happy in the meanwhile. The problem was OS X tried to use /ipp/printername as the URI, while CUPS was serving /printers/printername…
After a lot of googling I found out this mailing list archive where Andrew Schretter helps a fellow geek:
I think I can agree with the comment as well..
|Fri, 13 May 2005|
I just want to say that I'm looking forward to german beer and the company of good friends in a couple weeks, and I'm really grateful for the hard work that has been put in to GUADEC- I've peeked into the process a bit more this year than in past years and it is impressive.
The ever delicious but now sadly-bimonthly NTK today described neooffice as being "for those in interested in software that is 'free as in - oh shiny thing'". That cracked me up for some reason.
`Bhaskar' Ghose on IRC pointed me at Planet India, which is a pretty cool read. The energy Linux could (does?) have in a place like India is sort of mind-boggling, and it is cool to see things like Planet India that can let me peek into that. Apparently the event formerly known as Linux Bangalore is getting even more ambitious, which is cool too- I'd kill to make it this year; I had to pass it up the past two years because of budget, schedule, and vacation plans, but hopefully this year will be different.
|Apple and KHTML divorce ?|
Latest part of the story. News.com has an article about how Apple want KHTML developers to use Apple WebCore tree...
Here is the KHTML developers point of view. They seems to still be motivated, or at least to not have lost any hope about that.
The main problem I see is that using Apple CVS tree requires to have an ADC account and to to have an ADC account, you have to be over 18 as per Apple agreement:
That would have been fixed prior to any committment. Apple's definition of open source seems to require to be 18. Note that this is not to obtain the software as a tarball, but to obtain a CVS account... At least that is my understanding.
|13 May 2005: Stuttgart, Pilsen, Prague, Paris|
I have strategically placed a few cities on this Eurotrip to visit some friends and meet with some developers in the way. If you want to join me for lunch, dinner to discuss Mono, .NET, Gnome, free software or Linux write me an email to my gmail account firstname.lastname@example.org.
The dates are as follows:
Update: Sorry about the dates. A bug in my brain prevented me from incrementing the month to June. The dates above have been fixed.
A few new ideas for C# are being tried out on Spec#. It is taking steps into building tools to prove the correctness of the code. This is done by integrating into the language things like pre-conditions, post-conditions, object invariants, non-null types and checked exceptions. A separate tool is later used to do a lint-like process on the program.
File Systems in C#
You can now write your own user-level file system in C# bindings are here
Paco, r0ml, Stephen in Boston
It was one of the most fun dinners I had in a while everyone had tons of stories to share. We went to Casa Romero one of my favorite restaurants in Boston. Ben ordered "shrimp with something". Only later he learned that "something" was a sauce of corn parasites. He seemed to like it.
Only today I found that r0ml's not only had a blog, but he was raised in Brazil as a kid. His portuguese is vastly superior to mine, even after having being married to a brazilian for almost two years.
|13 May 2005|
Old GNOME hackers
Discovered what must be the the oldest gnome hackers in the world, I mean they where around when black and white was the only thing around :)
Noticed Zeenix assigning me a rather bastardized version of a theory. First of all I did tell him about it, but I was refering to a danish professor who was the originator. Secondly the represenation of the professor's theory was oversimplified a bit by Zeenix presentation of it. What the professor said (and considering this was two years ago even my memory of it is vague) was that since most people survive today due to medicines, social support etc., there was little natural selection going on anymore. If you combine that with the assumption that people who are successful are smart in some way (not necesarilly IQ) also tend to have few children, compared to people who are not very successful tending to have more children (Poor people having more children than rich) then the conclusion would be that we the human race where now devolving as a whole.
Wether I personally subscribe to the idea or not; I don't know. There are some plausability with the concept, but then again there are still a lot of stuff about the process of evolution we don't know yet. The professor did get shouted at a lot for being very politically incorrect with his idea, but I think that was going to far considering it did not target any specific race or group of people; of course the concept of successful people being smarter than less successful is a very broad generalization and a bit touchy.
|Design By Scribble|
Yesterday, I finally got around to hacking up a dialog in Sabayon where you can assign profiles to users. Code-wise, I knew it was pretty trivial, but for once I decided to spend some time thinking about the UI design rather than hoping a real designer would come along and rescue me later.
So, I scribbled down a rough design, humed and hawed for a while and got hacking. I'm not totally depressed with the end result, so that's something ...
|13 May 2005|
I got a few responses to the comparison between CVS, Subversion and Bazaar command line interfaces I posted earlier from Elijah, Mikael and David. As I stated in that post, I was looking at areas where the three systems could be compared. Of course, most people would choose Arch because of the things it can do with it that Subversion and CVS can't. Below I'll discuss two of those things: disconnected development and distributed development. I'll follow on from the examples in the previous post.
Disconnected development allows you to continue working on some code while not having access to the main repository. I hinted at how to do this in the previous post, but left out most of the details. The basic steps are:
To create the local archive, you follow the same procedure as for creating the original archive. Something like this:
mkdir ~/archives baz make-archive --signed email@example.com ~/firstname.lastname@example.org
This creates an archive named email@example.com (archive names are required to be an email address, optionally followed by some extra info) stored in the user's home directory.
Now we can create a branch in the local archive. From a working copy of the mainline branch, run the following command:
baz branch firstname.lastname@example.org/modulename--devel--0
It was necessary to specify an archive name in this call to baz branch, because the branch was being created in a different archive to the one the working copy was pointing at. This leaves the working copy pointing at the new branch, so you can start working on it immediately.
You can commit as many revisions as you want, and compare to other revisions on the branch.
When you have access to the main repository again, it is trivial to merge your changes back into the mainline:
baz switch email@example.com/modulename--devel--0 baz merge firstname.lastname@example.org/modulename--devel--0 fix conflicts, if any exist, and mark them resolved baz commit -s 'merge changes from email@example.com/modulename--devel--0'
You can then ignore the branch in the firstname.lastname@example.org archive, or continue to use it. If you want to continue working on the branch in that module, it is a simple matter to merge from the email@example.com archive first to pick up the changes made while you were disconnected.
In a distributed development environment, there is no main branch. Instead, each developer maintains their own branch, and pulls changes from other developers' archives. A few things fall out from this model:
So assuming you've branched off an existing developer's branch of a module, and want other developers to merge your changes. Assuming they can't access your local computer, it will be necessary to create a mirror of the archive. To make the archive most widely available, you should mirror it to a directory that is published by a web server. The following command will create a mirror of the local archive:
baz make-archive --signed --listing --mirror firstname.lastname@example.org sftp://email@example.com
Once the archive is created, you can mirror all the changes in the local archive to the remote one using the following command:
baz archive-mirror firstname.lastname@example.org
If you always have access to the mirror host, it is possible to set up a hook script that mirrors after every commit. However, if you often make changes while offline you might decide to mirror manually.
Now that the archive has been mirrored, other developers can merge your changes into their working copy using the following command:
baz merge http://email@example.com/modulename--devel--0
(after they've used your archive once, they can use the short name for the archive, and it will use the same location as last time).
While Arch allows full distributed development, most projects don't use it in a fully distributed manner. Often there will be a central archive that is the "official" one, which tarball releases are made from. The exact policies can differ from project to project. Some possible policies are:
I'm not sure which model would work best for Gnome. At least initially, one of the first two models would probably be a good choice. If you have good test coverage, PQM can help ensure that the mainline stays buildable, and changes don't destabilise things.
As has been mentioned elsewhere, regularly updated mirrors of various CVS repositories are being set up at arch.ubuntu.com. You can find out whether a mirror has been created for a module by looking it up on Launchpad. If a branch exists, you can check it out or branch it by prepending "http://arch.ubuntu.com/" to the full branch name (e.g. http://firstname.lastname@example.org/gossip--MAIN--0).
|13 May 2005|
Since planet gnome is not updated yet to my new blog, here is my thoughs on the recent "is gnome fun" discussion, copied from my blog:
Are language discussions fun?
I'm not sure how the "is Gnome fun" discussion turned into a language discussion. I would personally perfer using either C# or Java over C to code a new app these days. However, using C is not what makes hacking Gnome less fun than it used to be for me.
What makes Gnome less fun for me is the fact that Gnome is a stable high-quality codebase that I'm spending all my time maintaining. Each little change has to be very careful about not breaking backwards compatibility or introducing bugs and each new features must be very well understood and known to be right (because its very hard to get rid of it later). Most time I spend on gnome is reading bugzilla, fixing bugs in old code, discussing each little change forever, reviewing patches and saying no to feature requests. In essence, I have become a maintainance programmer, not a software developer. Of course, at times I do new development, but it is far more seldom than it used to be, and I almost never have time to do experimental stuff.
One reason using C# or Java would make things fun for me is because it would basically force me to work on a new application from scratch, which means I wouldn't have to care about all these things and just go wild experimenting and hacking. Of course, there isn't much chance for me to do that because even if I did start working on a new app I'd still have all the old code I'd have to maintain.
|revision control, languages, oh my.|
I've said to numerous people on IRC that I wasn't going to comment on the whole Mono versus Java versus 'continuing to use a real language(tm)' debate --- mainly because I don't particularly mind which is chosen to extend GNOME's functionality on the desktop.
Either way -- it probably means at least some of the 'GNOME can work on just about anything' use-cases that i've come to pride myself on maintaining during my tenure as GARNOME co-ordinator will come to an end, purely because of the extra dependancies that introducing either path will entail.
At least no-one is suggesting we should stick either of these 'solutions' into anything other than Desktop, which means users, developers and distributions are free to ignore whatever parts they want/have need to, while still being able to use the majority of the infrastructure to their advantage.
From the GARNOME point-of-view, i'll just point out that both of these are relatively painful to ship as part of our current 'ship something that will work on just about anything' mentality -- mainly (in my experience):
I think Alex summed it up well, the crux of which was:
but in the end:
(presuming, of course the said end-user eventually figures out this kind of application actually exists.)
You see, from the end-user's point-of-view this whole debate is pointless -- like the multimedia codec issue i've covered previously:
A user coming to GNOME from [insert_other_OS_here] won't notice and very likely doesn't care what their media player is coded in, but if it can't play the file they've just paid 99 cents for from iTunes -- we, as the people who are deemed to be responsible for that lack of 'compatibility', get told we have created a substandard product.
Just remember that.
As for the Revision Control argument, i'm firmly with Mikael in so far as both proposals are probably an easier way forward than CVS ... and Bazaar does look pretty neat, especially after spending time learning TLA, only to get highly miffed with a concept as simple as branching.
In both cases, it looks like a debate of pro's-and-con's will continue for the foreseeable future.
... and if you're reading this, coming from a non-free-software circle (*waves at El Jay and other syndicators*) -- welcome to the way we do things around here, for better, or for worse.
|Network Manager VPN|
So sweet, today I connected to Red Hat's VPN via Network Manager. Check it out.
After selecting the RHVPN item I got the normal little popup message from Red Hat, that I never read and always appears on VPN login.
Then everything thing worked, I was able to connect to mail and the internal IRC. One less command line app that I need!
The code is all in CVS right now, and should be coming out in a snapshot release very soon. David Z is working on a UI for creating VPN connections.
Something important to remember in the recent GNOME language debates is that both Java and C# are just an iteration on the existing crappy tools, and that neither is the future of computing.
Besides, debating empirically about what should be chosen and persued is antithetical to the way (free) software works.
If we could dictate this stuff – the avenue developers or software houses aught take – software, and especially free software, would be a lot less interesting.
Anyway, it will probably all work out thusly…
Using a Joel analogy, we need to stop arguing the design of the shed, and get some brains arguing over the aircraft carrier. Everyone understands how a shed should work and has an opinion. No one understands aircraft carriers, so people accept whatever is proposed, and you end up with a big pile of junk.
|Version Control System for GNOME|
As it seems most people that say something here is those that advocate Bazaar. So, let's just go with that, both that and SVN are better than CVS and I'm sure whatever new syntax and techniques you have to learn everyone should be able to.
Personally I think Bazaar looks interesting, only tested tla which was pretty scary but seemed nice in theory.
The part I have a problem with here is that we tend to make every decision into a long debate, every time. It's great to see the Bazaar people creating a repository instead of wasting time discussing the issue, over and over and over again.
Go Go Doers!
|12 May 2005|
Subversion vs Bazaar
Seems like I have an opinion on everything these days.
James, it's not the difference in the command set which makes the difference between svn and bzr - it's the distribution. I get headaches when I try and think about having an official version if there are even 2 or 3 levels of redirection in there. There is nothing wrong with people developing longer-lived projects on branches (svn is made to work nicely that way) but if we were to use bzr the way we use cvs now, we would just have a central repository and a bunch of children. Distribution is also the #1 selling point of bzr, I know - but it somehow feels wrong allowing big developments to happen outside the central repository.
Elijah, svn has pretty good off-line support. Not as good as bzr, granted. svn gives very cheap branching. Both svn and cvs (starting 1.10.something) have support for read-only access. I remember asking someone for stats on cvs.gnome.org and anoncvs.gnome.org access a while back to find out if there were a good reason to split them off - svn.gnome.org could easily give r/o access to anonyous.
|Decorate on a Dime|
I was out last night with friends at the usual Wednesday night haunt, the Overdraugt. Brian Clark asked me a question that got me thinking. “What are those funny looking statements in your DBus python code, you know the ones with the @ symbol?”, he asked. I had assumed that programmers could figure that out, it seemed so natural to me. But, I remembered that Brian was a designer not a developer.
It is easy to forget because Brian does do development but unlike developers he could care less about minutiae of a perticular language. He just uses them to get things done which can often times be more effective than reveling over an elegent language construct. As developers we often forget or target audience should be people like Brian. It is one of the reasons languages like Visual Basic or formats like HTML became popular. It targeted the masses.
Targetting the masses doesn’t have to mean everyone and their mother is going to use it but one should always have the mentality that they are developing for people outside of their core audience. That is how one expand usage and by shear luck of the laws of logic, expand the usefulness of what one is developing.
Good API is one way to get there in the programming sense, but VB will never be accused of having good API. Another way to get there is good documentation. I have noted in past blogs that Python has excellent documentation contributing to its success (it also has an excellent API IMHO). Formal documentation is all well and good but one can often get lost if they don’t know what they are looking for. So to further make the DBus Python bindings slightly more useful and teach others about a fairly new Python feature I present my understanding of decorators:
J5’s Understanding of Decorators from a DBus Point of View
Decorators are Python constructs used to “decorate” functions and methods. At the highest layers they can be thought of as markers that provide extra information about the function being decorated. Decorators begin with the @ symbol followed by the decorators name. In DBus we have two such decorators. These are:
These particular decorators can only be placed infront of python methods and not function because that is the constraints I placed on them.
Placing one of these decorators infront of a python method marks that python method as being exported as a dbus method or signal. Take this code fragment for example:
What is a Decorator Really (those who just want to use them can stop here)?
At the lowest levels a decorator is simply a function that takes a function or method as input and returns another function as output. Some other little bits go on in the background such as replacing the decorated function with the outputted function. What goes on inside the black box of the decorator is up to the developer. Decorators can simply return the function that was passed to it without modifying it. They can add metadata to the original function object or they could return a completely different function object.
The key to decorators is that they are executed when the function or method is parsed in the Python interpreter. This allows the decorator to modify the function before it is used. Take the dbus.Method decorator code as an example:
When the foo class is parsed the method decorator gets called and the interface is sent into the function. We validate the interface and then return the inner function which we have conviniently named “decorator”. Once the method class for “hello” has been created it is passed into the returned decorator function. The decorator function then sets a couple of attributes on the function object itself and returns the original function. Should another function be returned it would take the place of the original. Normaly if you did that you would call the original function somewhere in the returned function but it really is just a normal python function so you can do whatever you wish. The attributes we set is later used by a Metaclass to create a list of methods that need to be registered and exported over the bus and to construct the introspection data. That is all there is to it.
Other uses for decorators is validating argument types, adding generic debugging to a problem function, adding logging or forcing security checks. Since at its core decorators are just functions that replace functions one can dream up many applications for their use.
|Brain dump on recent topics|
Version Control System
It was nice to see James writeup a comparison of cvs, subversion, and bazaar. He concentrated on showing the similarities, but I'd like to point out a couple strong advantages bazaar would bring as a set of usage scenarios.
Usage case 1: If I'm working on a project hosted in cvs, I often just won't bother to hack on stuff if I'm forced to be offline. The reason is that the lack of access to the repository is just so limiting that sometimes I don't feel like it's worth it (I like to be able to look for more details about a specific commit in the past, being able to compare behavior to an old version, easily getting diffs without having to remember to make a full copy of a pristine version of the directory every time a cvs update is performed and/or hoping I remembered to do it when I need it, etc.) This can partially be solved in cvs by doing using rsync to make a copy of the repository itself and to attempt to update it when I get back online (which I have done), but it involves a bunch of hackery and is problematic at best--it'd be too easy to totally mess up the repository. baz makes it easy to replicate a repository and then merge between them. It's a very useful feature, even for a single-person project.
Usage case 2: When trying to fix a bug, usually in a product that I'm not too familiar with, I often have several cycles of 'cvs diff -pu | less' (to remember all the changes, extra debugging information I've added, initial failed attempts to fix stuff that caused lots of changes, etc.) followed by a number of changes to the code. With cvs and products like gtk+, this is really slow and aggravating as cvs diff takes forever. A local repository copy/fork/branch/whatever, which baz enables, fixes this problem quite nicely. (Yeah, yeah, I could check out another pristine working copy and just use normal diff recursively on the two on-disk directories; yes, I do that with cvs at times, but I usually think that "I'll only need to do this one more time..." and a full cvs checkout takes longer than a cvs diff)
Usage case 3: Lots of users with cvs are, of necessity, third-class citizens--they only get access to the anoncvs servers which are always out-of-date (even if only by a day) because there's no way to give them read-only access to the real cvs servers. baz can easily fix that (my developing with gnome guide tutorial is in a repository where only I have write access to, but the whole world has read access).
P.S. I don't mention tla here even though it shares these advantages, because its usability is so horrendously awful (IMO) that it could easily be seen as negating all its advantages (at least the last version I used). baz does suffer some still, but is far better in the most recent versions. I'm really looking forward to baz-ng to see if it can continue to improve the usability.
I realized that although we had a few patch reports, I didn't really use them. I found that after I went to them to find unreviewed bugs, I'd have to click on a link that would forward me to patch-status.cgi, which would auto-redirect to buglist.cgi after some time, from which I'd have to pick a bug (instead of a patch) and then scroll down to find the patch and finally click on the appropriate links for it. It was just too much of a pain. So, I wrote a new patch-report (which other patch reports now make use of in their links). You can also limit your search to a specific product or limit it to patches created in a certain day range such as the last week.
Also, I was seeing multiple people suggest or talk about having a special maintainer section that listed a bunch of common queries (e.g. all bugs with patches that have been marked as accepted-commit_after_freeze, or all bugs that haven't been commented on, or all bugs with a certain set of words in it, etc.). So I made something like that at the reports for maintainers section.
|12 May 2005|
The language debate - Don't forget Python has gotten the nod
One thing that people seem to be missing, and I had to some degree put into the forgotten drawer myself until Murray reminded me, is that there was a decision reached that Python is valid language to use for all GNOME development. This means that if you want to write something to go into the official GNOME you can write it in Python as long as the owner of the module you want to check it into is ok with it. This means that if you write something which is supposed to go into gnome-media or gnome-games or Nautilus for intance you CAN write that it Python as long as the gnome-media, gnome-games or Nautilus maintainer(s) are ok with it.
So while the fate of Java and C# is still not finalized in regards to GNOME you can start hacking with Python today if using C is not your cup of tea.
That said there where some good reasons for GNOME choosing to go with C when the project started up, and those reasons are still valid. C is highly portable, You can compile C code with almost any compiler and expect to to work with a library compiled with another C compiler or another version of the compiler (unlike C++ for instance). It is very easy to use C libraries in applications using other languages as most languages and compilers have taken into account that your probably want to interface with some C stuff at some level. The basic building blocs of GNOME will be done in C for the forseeable future, just like many of the other major components of free software; like glibc, the GNU/Linux kernel, gcc, X Windows and many many more. Python, Java, C#, Perl, Ruby, C++ and others are great tools for many kinds of applications and tools, but there is still no better choice than C for something like libraries.
|GTetrinet and GNOME-Mud releases|
In the last few days, two of the GNOME apps I'm somewhat involved in, GTetrinet, and GNOME-Mud, have released new versions. GTetrinet probably needs little introducing to many readers of the Debian and GNOME Planets as you've probably wasted one or two weekends trying to kick seb128's ass unsuccessfully.
For those who are new to Tetrinet, well, there's an old Chinese proverb which says You have not been on the Internet if you haven't played Tetrinet. Chinese proverbs are rarely wrong, so I would go play tetrinet if I were you.
GNOME-Mud is a MUD client for the GNOME platform, which according to some users that every now and then join the mailing list or the IRC channel, has the potential to become a very good MUD client for GNU/Linux. It supports most of the features you would expect to see in a MUD client: triggers, aliases, a mapper, a profile editor, etc. Oh, by the way, if you don't know what a MUD is, I think the elder Japanese think you haven't been to Uni.
What is not so cool about both of these apps is that for the last year or year and a half, the development has more or less come to a halt. The last few releases of both gnome-mud and gtetrinet are the fruit of random patches to fix bugs that keep floating around, contributed by different people (thanks guys!).
Dani, the lead developer for GTetrinet, had been working on a branch on separating some of the gtetrinet code that handles the tetrinet protocol to prepare a new libtetrinet package, which would then be used by some KDE folks that have expressed interest in writing a KTetrinet client. Some OS X people were also interested in writing a tetrinet client for MacOS X using the library, but the delays ended in them ripping most of this code into their own client Tetrinet Aqua. Dani had made lots of progress with libtetrinet before Real Life hit him hard and stopped having time to develop it. Future plans also included supporting different tetrinet protocols, most notably Tetrinet 2.
GNOME-Mud is an old project too, it's first releases date back to 1998. At that time, it was a GTK+-only application with little features. Right now, it's in the middle of a UI rewrite to make it HIG compliant and a bit more "Just Works"-like, but again, Robin has not had time in some time, and development goes on and off for one or two weeks every many months when someone in the mailing list reminds the rest that there's this or that patch available. The result is that it's taken 15 months to release 0.10.6, which has not that many changes anyway.
So, if you want to get initiated in GNOME development, this might be the tiny project that is desperately waiting for you to help. GTetrinet might involve some fun in figuring out how Tetrinet2's protocol works, and then writing a compatible client, and learning how to write shared libraries, etc. GNOME-Mud, on the other hand, might be interesting if you like app design. It really needs some usability love to re-think and redesign how it works. The current stuff is nearly 1999 stardards. :)
|This language thing|
Not that I particularly expect this GNOME language issue to be resolved anytime soon, but still: assuming that the choices are Java and C#, do people actually want to standardise/bless/whatever the language, the runtime standard (that is, "JVM" or "CLR"), one particular runtime ("Kaffe" or "Mono"), or some combination thereof?
On a totally unrelated note, I always wonder why on earth Microsoft chose a totally ungoogleable name for their language.
|12 May 2005|
Here's my take on GNOME and bindings (for what it's worth).
We have a choice for GNOME - either we aim at shipping a complete desktop environment, or a core people can build on. That works out with us choosing one of the 3 following things:
1. Add Python to official bindings, but fudge the java/mono question
Platform (in C)
In this model, we avoid the question again, and ship an incomplete desktop, without quality tools like Beagle and Fspot (big gaps in our offering right now).
2. Add everything
Platform (in C)
This way, RedHat won't ship GNOME as we ship it (C# apps), and likely others will choose to not ship other pieces.
This looks like a good way to fork the project across different vendors (open question: is that a bad thing, necessarily?)
3. The Permissive GNOME
Platform (in C)
We would continue to ship the platform, official bindings and official apps, and would add blessed apps (after release team debate, as happens currently) as an add-on. We would not ship blessed bindings, or the tools needed for them (just like we don't shop a python interpreter).
To ship a conformant GNOME desktop, distribs should ship all official pieces, and may choose to ship some or all blessed components.
This approach allows us to ship the best desktop apps around, and leave the politics of what to ship to distros.
I'm sure there are all sorts of reasons why 3 is a bad idea, but I can't for the life of me think of one.
|12 May 2005|
Here's hoping that myself and Murray don't get read by all the same people...
Because of demand for cheap accommodation, we came up with the very cheap (8 per night) Camp Feuerbach, a kind of summer camp type place where we can rent dorms for the weekend.
There's a minimum requirement before we can have it though. That minimum is pretty small, but hasn't been met (so far only 6 people have signed up for camp in the wiki. I get the impression (because of the demand we had beforehand) that there are many more people who want to avail of this, but perhaps they don't know wikis very well, or are holding off until the last minute on committing.
Murray Cumming has offered to put up the cash in advance to reserve the camp, but he needs numbers to do that. So if you want to sleep cheap in Stuttgart, mail Murray (murrayc at NOSPAMmurrayc dot com). Soon. Please.
The alternative is that people who have booked for this will have hostel places kept for them, at the less cheap (but still cheap) price of 80 for the weekend (3 nights).
|GUADEC cheap accommodation - last chance|
I think lots of people want to use this, but so far only 6 of you have told us. Have all our penniless students become rich 4-star hotel types? If not, you need to tell us today. Email me, or guadec-list at gnome.org, or put your name on that Wiki page.
This is the last chance. We can't afford to waste GNOME Foundation money (or my money) by booking places that won't be used.
|12 May 2005|
With the current discussion on gnome-hackers about whether to switch Gnome over to Subversion, it has been brought up a number of times that people can switch from CVS to Subversion without thinking about it (the implication being that this is not true for Arch). Given the improvements in Bazaar, it isn't clear that Subversion is the only system that can claim this benefit.
For the sake of comparison, I'm considering the case of a shared repository accessed by multiple developers over SSH. While this doesn't exploit all the benefits of Arch, it gives a better comparison of the usability of the different tools.
Before using any of CVS, Subversion or Arch, you'll need a repository. This can be done with the following commands (run on the repository server):
cvs init /cvsroot svnadmin create --fs-type=fsfs /svnroot baz make-archive --signed email@example.com /firstname.lastname@example.org
(the --signed flag can be omitted if you don't want to cryptographically sign change sets)
Once the archive is created, you'd need to make sure that everyone has write access to the files, and new files will be created with the appropriate group ownership. This procedure is the same for each system.
Now before users of the arch archive can start using the archive, they will need to tell baz what user ID to associate. Each user only needs to do this once. The email address used should match that on your PGP key, if you're using a signed archive.
baz my-id "Joe User <email@example.com>"
Next you'll want to import some code into the repository. This will be done from one of the client machines, from the source directory:
cvs -d :ext:user@hostname:/cvsroot import modulename vendor-tag release-tag svn import . svn+ssh://user@hostname/svnroot/modulename/trunk baz import -a sftp://user@firstname.lastname@example.org/modulename--devel--0
In the subversion case, we're using the standard convention of putting the main branch in a trunk/ subdirectory. In the arch case, you need a three-level module name, so I picked a fairly generic one.
Working with the repository
The first thing a user will want to do is to create a working copy of the module:
cvs -d :ext:user@hostname:/cvsroot get modulename svn checkout svn+ssh://user@hostname/svnroot/modulename/trunk modulename baz get sftp://user@email@example.com/modulename--devel--0 modulename
The user can then make changes to the working copy, adding new files with the add sub-command, and removing files with rm sub-command. For Subversion there are also mv and cp sub-commands. For Arch, the mv sub-command is supported.
To bring the working copy up to date with the repository, all three systems use the update sub-command. The main difference is that CVS and Subversion will only update the current directory and below, while Arch will update the entire working copy.
If there are any conflicts during the update, you'll get standard three-way merge conflict markers in all three systems. Unlike CVS, both Subversion and Arch require you to mark each conflict resolved using the resolved sub-command.
To see what changes you have in your working copy, all three systems support a diff command. Again, this works on the full tree in Arch, while only working against a subtree in CVS and Subversion. In all three systems, you can request diffs for individual files by passing the filenames as additional arguments. Unfortunately baz requires you to pass "--" as an argument before the filenames, but hopefully that'll get fixed in the future.
When it is time to commit the change, all three systems use the commit sub-command. This command also works on a full tree with Arch.
Branching and Merging
Creating a branch is relatively easy in all three systems:
cvs tag foo-anchor . ; cvs tag -b foo . svn cp . svn+ssh://user@host/svnroot/modulename/branches/foo baz branch modulename--foo--0
Unlike CVS and Subversion, the baz command will also switch the working copy over to the new branch. By default it will create a branch in the same repository, but can just as easily create a branch in another location.
To switch a working copy between branches, the following commands are used:
cvs update -r foo svn switch svn+ssh://user@host/svnroot/modulename/branches/foo baz switch modulename--foo--0
If we switch the working copy back to the trunk, we can merge the changes from the branch you'd do the following:
cvs tag -r foo foo-DATE .; cvs update -j foo-anchor -j foo-DATE . svn merge -r branch-rev:HEAD svn+ssh://user@host/svnroot/modulename/branches/foo baz merge modulename--foo--0
This is where Arch's history sensitive merging starts to shine. Since the working copy retains a record of what changes it is composed of, the merge operation simply pulls over the changes that exist in the branch but not in the working copy -- there is no need to tell it what range of changes you want to apply.
To merge more changes from the branch, the CVS and Subversion commands change, while the Arch one remains constant:
cvs tag -r foo foo-DATE .; cvs update -j foo-LAST-DATE -j foo-DATE . svn merge -r last-merge-rev:HEAD svn+ssh://user@host/svnroot/modulename/branches/foo baz merge modulename--foo--0
The current Bazaar command line interface isn't that different from CVS and Subversion (it's definitely worth a second look if tla scared you off). The main difference is that some of the operations work on the whole working copy rather than a subset by default. In practice, this doesn't seem to be much of a problem.
The history sensitive merge capabilities would probably be quite useful for Gnome. For example, it would make it trivial to merge bug fixes made on the stable branch to the head branch.
Disconnected development is a natural extension to the branching and merging support mentioned earlier. The main difference is that you'd have to make a local archive, and then create your branch of the code in that archive instead of the main one. The rest is handled the same.
Seth: I hope no one is in either a Mono or Java camp. Hopefully everyone is in the "lets get gnome moving / language discussions are stupid" camp. But, if I had to pick a camp, it would certainly be the "who the hell gives a shit which language is used, lets write badass applications that are easy to use in whatever tool it takes to do it" camp.
|TODO: Make GNOME on Solaris Rock aka Where Are You Kernel Developers?|
Since I know there's heaps of people out there reading blogs using GNOME, and the fact that Sun's a fricken huge company to communicate across, I figure I might as well send a blog request instead.
As I blogged previously I've started writing a list of things that we need to make GNOME as featureful on Solaris as it is on Linux. I think it's important to have a desktop roadmap for Solaris, specifically with kernel enhancements, and more just as importantly to have that available when the OpenSolaris goes live, sometime in the near future. People are going to need ideas for their pet project, right? [grin]
However, I'm a kernel weenie, and I need help since I'll see things from one angle only. If you have any suggestions or comments, direct them to glynn [dot] foster [at] sun [dot] com. Thanks!
|No more wisdom|
Today was the last chapter of a story that started quite ok, then got a bit worse, and ended with the last of my Wisdom teeth extracted.
Again, the operation went quite ok, although this time, the doctor couldn't just cut the tooth in two and extract both pieces separately... he had to open with a scalpel, take it out and sew the crater. Oww.
Now I sit in front of the monitor, feeling how the pain killers are wearing off, and imagine how long tonight will be... :/ Officially I can't spit, wash my mouth or eat anything hot. Unofficially I basically can't eat much for now. It's great timing, as I have a dinner today, another one with my cousins tomorrow, and in a few days, hopefully a birthday party.
Next steps in my dentist adventure is probably to get some very nice looking bracers. Oh yes!
|Stack Guard Page|
The most interesting little tidbit I learnt from the memory usage debugging yesterday was about the "stack guard page". Look at this bit in the strace:
mmap2(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7219000 mprotect(0xb7219000, 4096, PROT_NONE) = 0 clone(child_stack=0xb7c194c4, flags=CLONE_VM|...) = 2282What's going on here is that libc is mapping an area for the thread's stack, just before spawning thread. The interesting bit is that, using mprotect(), it also changes the permissions on the first page (the page at the top of the stack) such that any instruction which attempts to write to the page will cause a segmentation fault.
That's your stack guard page; it means that your infinitely recursing function won't go off an scribble over its neighbouring thread's stack, it'll just segfault like a good little thread.
(In true pthreads tradition, you can even configure the size of this guard area - see the pthread_attr_setguardsize() manpage)
So, it looks like Cowon/JetAudio/iAudio is coming out with a sweet looking Ogg/Flac/Mp3/etc. player with a color LCD display called the iAudio X5. It's nice to see that someone can make a nice looking player that supports open formats (unlike some other companies). You can also order it from a German website :).
|iPod syncing for Muine|
A while ago I started working on a plugin for Muine that syncs your library with an iPod. I worked on it a bit more lately and it seems to be coming along, so I’m trying to get people to test it. You need this and this, to start.
Right now there is no HAL integration, as I’m having an incredibly difficult time figuring out the correct way to integrate with that stuff. What it will do, however, is mount/umount your iPod assuming it is setup correctly in fstab (correct device, ‘user’ option, etc). It defaults to /media/ipod for the mount point, but that is configurable through a gconf key (/apps/muine/ipod/mount_path).
I’ve been using it for the last few days with no serious problems. I do suggest you backup your iTunesDB file before giving it a shot, though, as corrupting that is the worst thing that can happen. You can find it at /media/ipod/iPod_Control/iTunes/iTunesDB. If you encounter problems, feel free to email me.
Update: You will need muine 0.8.3 or greater to use this plugin, as previous versions lack the necessary interface.
Another Update: I’ve checked ipod-sharp and muine-ipod into arch at http://www.snorp.net/bazaar.
|11 May 2005: Open Source Java, part 2|
After my post on Apache's Harmony project I have been watching the fireworks on the blogs and the mailing lists. One thing is clear: nobody quite knows what Harmony is supposed to be.
Unlike Mono, open source Java faces a big problem: there are a number of free commercial Java runtimes available for every operating system that matters. The group of people who would have contributed to a free java to scratch an itch are gone. From those who remain another large chunk will switch in a heartbeat to a commercial implementation the moment they run into missing features, scalability issues, the lack of a moving GC or a hard to debug problem.
So you must rely purely on free software advocates or people employed to clone Sun's Java for a strategic purpose.
To illustrate my point: Mark reports that for the two months leading to May 7th GNU Classpath had 299 commits and today is made up of roughly 900,000 lines of source code. Mono in the same time frame had 985 commits to its core class libraries and has roughly of 1,600,000 lines of code. The previous count is only for the core class libraries and does not include Mono-specific or Gnome-specific class libraries. The Mono effort is also three years younger than Classpath and five years younger than Kaffe.
For an open source Java effort to succeed, it not only needs to match the functionality of Sun's Java first, but it must offer functionality that is not available anywhere if it wants to attract developers to its core. Today there are probably two openings in this area. IKVM which makes Java and .NET run side-by-side and GCJ which turns Java code into native code.
Java and C#, CLI and JVM
Havoc last post bounces across every possible point.
I was not going to enter the language discussion on PlanetGnome, because it touches on too many topics. For one, I think that:
I think my comments echo Mikael's post, which both Jeffrey and Havoc seem to have missed.
I wanted to follow up on a few things that Havoc mentioned:
|everyone with me: lemmy is coming to town|
I promise everyone who keeps reminding me I "should blog more" that i'll do a mega-update thing soon, but ... but... but:
*can't even bring myself to say it --- WAY too excited*
Motorhead are coming to my town.
December 6th ...
Tickets go on sale on the 25th, that gives me a fortnight to find the money to purchase a chance to see the one true god, live in person.
*must ... find ... cash*
|11 May 2005|
GUADEC (German visa): Just returned from the German embassy. It's 16:40 now, and we were at the embassy from about 9:15 until 15:00 (they had given us an appointment for 9:30, so we had happily arranged a translation party at 12:30, which got cancelled because of the delay).
We sat from 9:30 until about 14:15 in the embassy, a delay which we were completely unprepared for. We should have brought enough reading material, and I didn't even have my laptop because they had seized it at the entrance.
The visa officer who finally met us on 14:15 was very uneasy about us. Our case apparently wasn't straight-forward at all. It was also hard for her to understand what is it that we do exactly in FarsiWeb, and when she finally got it, she asked "So it's something like Persian-enabled Windows that you do?". I believe she very probably worded it that way on her terminal, very possibly using Farsisch instead of Persisch. At the end, she finally told me the consular section can't decide about the case, and they will pass it to the cultural section, since the cultural section is more experienced with things like research groups and universities. I am very hopeful about this, because it was the involvement of the cultural section that gave us a visa in nine days in 2001, without even an invitation letter (we were planning to apply for a US visa in Frankfurt, and all we had was a printout of an email from the American visa officer in Frankfurt).
I am supposed to get a hotel reservation confirmation to them until Monday, which MUST be "a fax with the letterhead of the hotel" (I just emailed Tim and asked for guidance). And they are supposed to tell us about the rejection or the approval of visa request on May 25 (and possibly give us the visa), about 16 hours before our flight (which will be 05:30 in the morning). The travel agency will have something like two or three hours at most, to reconfirm or cancel our reservation. I really enjoy this!
Behnam wasn't able to come to the emabssy because his exit visa (and hence his passport) is not ready yet. He will need to apply on May 17 unfortunately, which may be very late.
|11 May 2005|
Somethings wrong with the Immigration Department
Shortly after the scandal over Cornelia Rau (a mentally ill Australian who was in detention for 10 months), another case gets some media attention: Vivian Young/Alvarez/Solon.
She is an Australian citizen born in the Phillipines, who also suffers from a mental illness. From the news reports, the sequence of events seems to be:
Among the Australian family, she left behind a son who is still in foster care.
Rather than being an isolated case, it is quite likely that there have been other questionable deportations -- this one getting more attention because the person in question is an Australian. This case has racial overtones too, since it is unlikely that a white Australian would have been deported under the same circumstances. Despite all this, the Minister for Immigration does not feel that a Royal Commission would be appropriate.