Search Results: "reg"

18 April 2006

Jose Carlos Garcia Sogo: Boot Time Enhancements

Does somwbody know what happened to those efforts to increase boot speed? Not long ago, some people started making funny graphics with boot times and some solutions regarding paralellism were given. But I haven't seen them applied, and the discussion about this issue disappeared. If I remember right, the main problem was with hotplug, and I know that this problem has been solved in latest udev packages by preloading some modules, bu tanyway I think that start up time can and should be cut off as most as we can. This is not ony important for desktop users (which have also another point that can be improved in GNOME or KDE, as well as X itself), but also for servers. If some problem occurs that leads to a reboot, the shortest this reboot time is the better, as you will get your services back sooner.

17 April 2006

Andreas Barth: dpkg-source 2.0

These days, I started to play with the dpkg 2.0 source format. I converted one of my packages to dpkg-source 2.0 format, and then forced the dak-installation on my laptop to accept that package. Already now, I found some over-strictness bugs in dpkg-source. Now that this step is done, I need to search a victim box to set up a regular dak, so that people can play a bit more with it (and of course, that dak installation will accepted any signatures from the regular keyring). Furthermore, I plan to add autobuilding for some archs to it (i386? powerpc? amd64?), so that one can really see how it behaves in a real world scenario. Something else one should also do there one day: create an extra directory where the packages will be repacked in dpkg-source 1.0 format.

16 April 2006

Clint Adams: Old man sitting on the white sand

Up in the Catskills, the sun sometimes shines on a cairn. Sometimes it shines on people near that cairn. Sometimes people roll cigarettes while eying that cairn suspiciously, and sometimes one of those people has two eyes whose colors differ. This person may like David Bowie, and he may be from eastern Massachusetts, and he may like to regale his ex-girlfriend with stories of the Japanese girls he conquers in Canada. All that happens in the shadow plane, with the pale shapes, and time will not be what it seemed. Yet closer to the center of the Earth runs a stream, the centerpiece for a suffusion of lush, vegetative growth. That place in the forest, devoid of signs of vertebrate life, transcends time in a much different way. There are other places like it, but they lack one important factor. For if I am to ask the question to bring it full-circle, who is left to answer me but the dead?

Brett Parker: bpgallery.sh v1.0.2 released

Just tagged up the latest version of bpgallery which is my rather light bash script for generating static gallerys, this version fixes a couple of (minor) bugs, removes some duplication of code (to make it easier for me to maintain, and because I'm going to need to extend that part of the code for the next release), and fixes an outstanding part of the todo list (i.e. regenerate thumbnails if the required width changes). It's also added a per gallery config file option, so now putting in a file called .bpgallery.rc with the right variables in it (WIDTH, TITLE, BPGALLERY_THEME), will use that file as the last one to get settings from, overriding previous settings (well, unless they're set readonly, in which case it won't ;). Next release should have some extra themes in the release as a demonstration, medium sized images (and the pages to go with them, and an extension to the themeing for this), next and previous 'buttons' on the autogenerated pages, and should generally just be a nice release! Sometime I'll get round to finishing off writing the documentation for it, but until then, if you're using it and get a problem, mail me (or find me on IRC!).

14 April 2006

Jordi Mallach: 75 years of the Spanish dream

Recently Spain remembered the 65th anniversary of our tragic Civil War, an episode which broke the state in two halves which still today haven't been glued together at all. The origin of that nightmare is the dream of many Spanish people of the early 20th Century. In the morning of the 14th of April, 1931, the Second Spanish Republic was proclaimed in Madrid, after two days before, a majority of republican and leftist parties won the local elections; many people celebrated throughout the Spanish territory, and the tricolour flag was shown in many town hall buildings. With the king in exile after these quick happenings, Spain was again a Republic, as decided by the election results. The Republic brought many social measures to Spain: women suffrage, eight-hour day and many other labour related improvements. The nobility titles were abolished, and those properties were confiscated by the government. And this was just the provisional government. All of this is regarded like a big social and cultural revolution, which was just starting. Not everyone was happy about this, of course. The newly approved Constitution of December 9 gave the government power to confiscate many of the Church's properties, and limit their great power in political matters. Soon, the episcopacy came with a strategy to defeat the Republic in any possible way. The Royalists were also not happy. There were a series of revolts in the South, and an attempt of coup d'etat by General Sanjurjo. These attacks were repealed; the Republic was still strong. In 1933, the Anarchists started to be seriously unhappy about the moderate path the government was leading and started striking, which led to violent repression by the Government. The General elections of November brought a victory of the right and extreme-right, and many social and anti-church measures were repealed. Riots and strikes spread throughout the territory. The Martial Law proclaimed by the right wing government resulted in thousands beings imprisoned. Things went even worse when three ministers of the fascist CEDA entered the Republican Government. A big worker uprise started the 1st of October in Asturies, and Catalunya proclaimed the Catalan Republic. The revolts were supressed by General Franco, who would be well known in the world just a few years later. Thousands were killed and injuried during the few weeks of revolt, and the Socialist Party was dissolved, leaving the Spanish Courts with barely no left representation. The next years saw a very unstable government from the right due to internal disputes within the parties that formed it. New elections were called in 1936, and the left united under the Popular Front, which won by a slight margin; Manuel Aza a was the new president. The right, the church and the army continued to undermine the Republic in any possible way. In an attempt to make the military heads more loyal to the established government, the fascist Falange Espa ola was dissolved. The 2nd Spanish Republic received a massive blow on the 17th of July, 1936 when Franco and other generals attempted a new coup d'etat in the Northern African territories. The Republic started to die as people started fighting the coup back, and the Spanish Civil War started throughout the territory. With the aid of Fascist Germany and Italy, Franco managed to seize control of more and more areas of Spain during the nearly three years of war, and the Government of the Republic had to move a number of times, to Val ncia and Barcelona. In January 1939, most of Spain was in Franco's hands, and Catalunya soon fell. Two months later, the fascist troops entered Madrid, and hours later, Val ncia surrended. Still today, people talk about dos Espa as , the victorious and the defeated. Still today, the is much difficulty in having official recognition for the thousands who died while defending what a majority of people had voted for in a democratic way. Still today, one of the major political parties in Spain refuses to acknowledge what the forty years of Franco meant for the disidents, for the exiled, and for the dead. They are the legacy of Franco. Today Spain celebrates the 75th anniversary of our Second Republic, with many events in many cities, which will be ongoing for a few weeks. Izquierda Republicana has a good list of events.

13 April 2006

Jeff Bailey: Tagging entries

First - I've switched the feed for http://planet.debian.org/ to RSS instead of atom. Atom doesn't work, and apparently never has despite there being a fair number of registered atom feeds.

Second - I'm likely to start blogging comments about religion. I think most people who know me know that I'm a UU and have been now for about half of my life. So this isn't new - I'd avoided posting religious things in my blog before because the software that I was running at home had no method for trivially separating things based on tags. I moved to LJ a while ago, and I think it has this. The question is what's the best way to keep things posted to planets without those entries? Is there some sort of a thing I can setup that says "make a feed for everything that *isn't* tagged religion?" If you have an idea, let me know. Or perhaps people don't care, in which case don't worry about it. =)

(Why doesn't the LJ spellchecker include obvious things like "RSS", "Blogging", and "href"?)

12 April 2006

David Welton: Ruby vs Tcl, round 2

Ding ding. (Round 1 - for those who missed it) Kidding aside, remember that I like and respect both of them. Libraries In the first article, I mentioned that Ruby has a lot of momentum, which is a pleasant change from Tcl's relative 'uncoolness' amongst the Web 2.0/O'Reilly/"next big thing" crowd. That said, there are still places where that momentum hasn't taken it. I set about writing some code that I'd wanted to play with that involves sending some email. Something that's very easy in Tcl: http://tcllib.sourceforge.net/doc/smtp.html (towards the end of thepage). Python seems to have a pretty complete email system too, for that matter: http://docs.python.org/lib/module-email.html. So it appears that, based on a sample of one attempted task (how's that for statistics?), that Ruby is still lacking a few things in its standard distribution. Note that this functionality is available elsewhere (TMail, to cite one), but email is ubiquitous enough that it ought to be in the standard library. Command line swiss-army knife While Ruby's OO system gives it a head start when you need to create a larger system with distinct parts, it can still be used as a quick'n'dirty scripting language for quick one-off jobs. From the man page:
% cat /tmp/junk
matz
% ruby -p -i.bak -e  $_.upcase!  /tmp/junk
% cat /tmp/junk
MATZ
Very handy. Tcl's command-based syntax just isn't quite as quick for those sorts of operations, so Ruby wins hands down here. I've suggested that the Tcl folks distribute a second program that takes a lot of the Perl-style command line arguments for this sort of work, but the idea doesn't seem to be of much interest. C API's On another tack completely, one of the things that originally drew me to Tcl was its very, very nice C API. It's documentation is clear, and thorough, and the API itself lets you get involved in pretty much any aspect of the language that you want. This makes sense, because when Tcl was originally created by Dr. Ousterhout in the late '80ies, the idea was to create a scripting language as a C library that would be loaded into other programs. The language has always been faithful to its heritage, and to this day I find it lots of fun to merge Tcl with C code. I have to admit that I don't know the Ruby API all that well, but what I have looked up looks pretty nice. To a certain degree, it's comparing apples and oranges, because Ruby requires you to deal with the very object oriented nature of the language, whereas Tcl is a lot more direct. The Programming Ruby book's coverage of the subject also leads me to believe that Tcl really gives you access to more stuff (interpreters, channels, events, and many other parts of the system). Ruby seems to take an approach that might best be described as letting you write Ruby in C - meaning that you create Ruby objects, use their methods, get their values, and so on, but you're still really dealing with Ruby. This has a certain elegance, but sometimes it's necessary to muck about with things at a lower level. I don't know how it works out in practice, but Ruby has a bit more infrastructure in place for actually building extensions once you've created them. Tcl has "tea", which is a set of m4 macros, but anyone can tell you that the auto tools are not much fun to work with (going to the dentist is more fun) - anything that keeps me away from them is welcome. Garbage collection One of the more interesting aspects of the different approaches to C interoperability is the fact that Tcl uses a simple, robust, straightforward reference counting system to keep track of, and throw away resources that are no longer used. Ruby has a mark and sweep garbage collector, which is probably more sophisticated, but also more complicated, and requires a bit more support from the programmer initially. The benefit is that once things are set up, they require less keeping track of, because you hand off memory management to the computer. From the end user's point of view, Ruby wins here, but if you happen to be writing a C extension, I could see it being more difficult to write and debug to this API, although Tcl has its own warts, one of the worst of which is the fact that Tcl values must be convertible back and forth to strings, so that for things like a file handle that can't really survive the round trip, because it's just a pointer, you use a hash table and some sort of string to hold onto the object:
 "file1" -> int fd1
 "file2" -> int fd2
which makes it impossible to GC these values. I suspect that both approaches have their merits - Ruby's is more elegant, but Tcl's is simple and rugged. Licensing Bouncing back to something completely non-technical, Ruby's licensing is either the GPL, or their own license. If I understand things correctly, you can get around the GPL's "viral nature" by simply renaming things, if you have a need to include Ruby in a proprietary product:
  1. You may distribute the software in object code or executable form, provided that you do at least ONE of the following: a) distribute the executables and library files of the software, together with instructions (in the manual page or equivalent) on where to get the original distribution. b) accompany the distribution with the machine-readable source of the software. c) give non-standard executables non-standard names, with instructions on where to get the original software distribution. d) make other distribution arrangements with the author.
So it seems that you're ok if you just call it something else. However, the license goes on to talk about several other files in the core distribution:
  1. You may modify and include the part of the software into any other software (possibly commercial). But some files in the distribution are not written by the author, so that they are not under this terms. They are gc.c(partly), utils.c(partly), regex.[ch], fnmatch.[ch], glob.c, st.[ch] and some files under the ./missing directory. See each file for the copying condition.
Looking through the LEGAL file in the distribution shows that there are files distributed under other terms. Of course, they're all free software, but some are LGPL, some BSD, and a few others for good measure. Tcl's licensing, on the contrary, requires very little understanding. The language was developed at the University of California, Berkeley, and the license remains BSD. This goes for many of the libraries and extensions as well. If you need to embed a language in your proprietary system, Tcl and its libraries present no problems whatsoever. Of course, I prefer to work with open source code and communities, but that's not possible 100% of the time, so it's always nice to know things are free and clear, should that need arise. Internationalization This is something the Ruby folks know they need to fix, and are working on, so it's not worth dwelling on it much, but it is a proud point for the Tcl community. Tcl has had very nice i18n setup for many years, at this point - since the 8.0 release. It's built into the language, so that everything works with it. You have commands to set encodings of IO channels, and even munge strings. Tcl wins here - no contest. As I continue exploring Ruby, I think I'll find more stuff to compare with Tcl, so we won't ring the final bell just yet.

John Goerzen: Tuttle: Neither Gone Nor Forgotten

So just when I thought the whole Tuttle story had wound down, more starts appearing.

The Register has a new article: Only "freaks" waste their time with Linux in Oklahoma. In it, they posted a video clip from an Oklahoma TV station that called Tuttle "an international laughing stock." Quite a funny little piece. The Register also mentioned that the Tuttle city manager left work when he heard a TV crew would be there to interview him. Favorite quote:

Instead of a website, Taylor discovered an Apache server configuration page that mentioned CentOS. He's an Oklahoma man, and the Apache feather must have proved frightening.


Today's next little piece of fun is this page at the Tuttle Times. Look on the right, under Links. See the link that reads "Example of CentOS test page"? Notice where it points to. Yes, that's right, www.tuttlechamber.org. Click on it, and sure enough, up comes the infamous test page. So the Tuttle Chamber of Commerce apparently is getting ready for round two...

And while we're speaking of the Tuttle Times: they have published a letter to the editor from Johnny Hughes, the CentOS lead developer that was on the other end of those exchanges with Tuttle. I think Johnny wrote an excellent little piece there.

And finally, another funny headline from the Tuttle Times homepage: "Prosecution attorney presents complete case." I am glad to hear that at long last this terrible scourge of incomplete cases has been brought to an end. But beware, this shocking story is not over yet! The next article is "defense raises compelling questions." Another first for Tuttle?

Lars Wirzenius: Random hacks: doc-get

I often want to save interesting web pages on my own disk, so that I have a copy even off-line, or in case the page goes away. Occasionally a bit of a pack-rat I am, yes. Web browsers can do this, but not in a perfect manner. For example, Epiphany does not save all embedded objects (images), so viewing the saved page can result in images being loaded from the net. Another problem is that I'd like to record the URL of the page that was saved, in case I want to go back some day. And finally, I would like to be able to get an entire multi-page document (say, a manual) in one go. The other day I played around with wget options, and came up with this set:
wget -N -nd -k -p -H -P "$dir" "$url"
This seems to work fairly well so far. I've wrapped it in a little shell script I call doc-get. It doesn't do the multi-page document thing yet, but I'll look at that later. More things that doc-get might do, but that I'm probably too lazy to implement in the near future: updating an already saved document; better heuristics for the name of the directory (currently it's date + MD5 of URL); having a central registry of saved documents, so that you can do "doc-get --update-all" and refresh everything; inventing something to make it easy for publishers of free documents (say, much of the Creative Commons stuff) easily downloadable by doc-get, even if their directory structure is complicated.

11 April 2006

Anthony Towns: Developers and Maintainers

My first blog post after winning the Debian Project Leader election. Scary. Links so far: debian-project, Slashdot, ZDNet Australia. I’m trying to make sure I’ve got something vaguely new to say before replying to press requests, and to also make sure I say anything new on some Debian forum first, and given there’s one I’m replying to tonight, well, you do the maths… So my tentative theory is to put together a list of ten-twelve “interesting projects” to push forward over the course of the year, in theory one a month. The idea is that’ll stop me from letting my time be taken up reacting to things – whether that be problems, questions, the press or what have you – and thus losing control of what I’m doing, and that it’ll also force me to keep moving onto new things regularly, and also to actually “finish” them too so they don’t cause an ongoing distraction. My current list of topics is: maintainers; partners; extended suite support; constitutional stuff; non-free; distributed leadership; localisation/specialisation; livecds; the etch release. Those are just heading to roughly remind me of various s3kr1t pl0ts I’ve thought about in the past, and you shouldn’t read too much into it – you’re welcome to think about them yourself, and get inspired though. And I’m sure I’ll change some of them around over the next few days; but one that won’t include the first one, which is something that I’ve been thinking about for most of the year now. I’ve talked about it privately with a few people over drinks and IRC, and it looks like it’s basically at the point where it seems sensible to everyone, and just needs to be coded up. But enough teasing. There are a few ways to explain the concept, this is the one I prefer. The idea is to do away with the whole concept of “sponsored uploads”, and replace it with a more formal and efficient way of doing the same thing. Sponsorship has a few significant problems: first, it makes it harder to work out who’s actually responsible for an upload when you can’t just rely on the name in the changes file; second, it puts a roadblock in the way of getting bugs fixed in the sponsored package – you don’t only have to have the fix ready, you have to find a sponsor with free time to check your work and upload; and third, it confuses who is responsible for broken packages: the sponsor for not doing sufficient checks, or the packagers for not getting it right in the first place. The obvious way to fix the first problem is to make dak check that the key used to sign the .changes files uploaded actually matches the person listed in the .changes file as doing the uploading. But of course, that alone would kill off sponsorship, and thus make a fairly large number of packages (does anyone know how many?) essentially unmaintained, and also make it harder to prove you know what you’re doing when going through the new-maintainer process. Interestingly, the obvious way to solve the second and third problems is also to do away with sponsorship, but in a different sense – namely by letting the packager upload directly. Of course, that’s unacceptable per se, since we rely on our uploaders to ensure the quality of their packages, so we need some way of differentiating people we can trust to know what they’re doing, from people we can’t trust or who don’t yet know what they’re doing. Of course, there’s not really anything stopping us from doing that; and it’s something that’s been suggested before – it just means that as well as separating some contributors to the project out as “Debian Developers” after passing the new-maintainer process, we need some other level of people who’re trusted to do what sponsored packagers currently do – maintain a single package, after getting vetted by a developer. And basically, that’s what I think we should do; and I’m calling the intermediate level “Debian Maintainers”. The idea is that while a Debian Developer (DD) can do everything we currently can – upload NEW packages, NMU each others packages, hijack packages in extreme cases, and so forth – a Debian Maintainer (DM) can only maintain a specific package, after being authenticated by a DD in three ways: first to ensure they’re a real person via the usual key signing mechanisms, second to ensure they can be trusted to understand what uploading to Debian involves, and third to ensure that they understand what’s involved in maintaining a particular package before being given rights to upload new versions of that package. Hrm. This is getting too long, so I’ll leave commenting on implementation details for later, and close with some of the possible implications on how Debian works. One thing is that it means is that it adds an extra way in which you can contribute to Debian; from just using it, you can move to helping other people in usergroups, to contributing bug reports, to helping fix bug reports, to sending the maintainer patches to upload, to becoming a DM, to becoming a DD. Another thing it means is that the DAM role becomes somewhat more decentralised; suddenly every DD can vet new contributors, though in a far more limited way than the DAM and FD does. Another thing is that the utility of being a DD both rises and drops: if you just want to maintain some package, being a DD instead of a DM is pointless; but on the other hand, this is a new ability DD’s don’t currently have. It’s possible that might have a flow-on effect to new-maintainer, meaning that fewer people bother with it – giving AMs more time – or that the people who do bother with it need to be more thoroughly tested, or tested on different areas – giving AMs less time. Another thing it means is that there’s the possibility of more central control over who can upload than sponsorship allows – rather than only looking at which DD is involved and which package is involved, we’ll have signatures by the person who did the actual packaging directly. And of course if we have their key anyway, we can – if we choose – allow that key to sign votes in elections, with whatever limitations we might choose, such as requiring they be a registered contributor for over six months before voting, or that their votes are advisory only rather than binding, or that they can only vote in some elections, or that their vote is weighted less than a DD’s vote. And, of course, we could try different arrangements out and see what effect they have. This is a big thing, so it needs to be done with a great deal of care. In particular, it seems like the best way to handle DMs will be to do so almost entirely automatically (rather than add extra tasks to keyring-maint or the new-maintainer team eg), which means both that the scripts need to be written with extreme care, and probably also that all the information they work with be completely public so that it’s easily auditable. The current theory is that becoming a DM should work roughly like:
  1. work with some developer, by helping resolve bugs, providing or testing patches, and otherwise demonstrate you’re interested and sensible
  2. ask that DD to send an advocate mail to a bot supporting your desire to be a DM
  3. reply to an automated mail from the bot, indicating you support the social contract, agree with the DMUP and constitution etc
  4. receive an acknoledgement from the bot that your replies are in order, that your key is signed by a DD other than your advocate, and that you’re a registered DM
  5. ask that DD (or another) to upload a new version of the package you want to (co-)maintan with your name and email address added to the Maintainer: or Uploaders: field
  6. maintain the package directly
So that’s the theory. More detailed thoughts on the implementation later, hopefully after I’ve caught up on some sleep. I debated a bit where to send this – since I expect trying to get this idea happening will be my main focus this month, maybe it would be better off on one of the Debian lists; but on the other hand, it’s a bit more half-baked than I’d feel comfortable posting to -devel-announce, and I suspect just posting to -devel would miss some people it shouldn’t. And hey, it’s not hard to forward a url, or just cut and paste the whole thing, right? Discussion (probably on debian-devel) encouraged.

8 April 2006

Wouter Verhelst: Crypto law in Belgium.

I've always thought that I live in a sane country regarding crypto law—or, at least, one not as insane as the US. Apparently I was a bit too optimistic. According to this page, or more specifically, the Belgium-specific bits, you need a special license to be allowed to export cryptography outside of the Benelux. This is in relation to the Wassenaar Arrangement, an international agreement on cryptography laws which allows "public-domain" software, but not necessarily other types of software. If I can assume that the term "public domain" here really refers to software of which the source is freely available, then there is no issue; otherwise, I may be doing something illegal. I guess I'll have to investigate that. Moreover, and this is really a surprise to me, law enforcement officials in Beligum can, after an order of an investigation judge, order me to "make accessible [...] data in the form ordered by the judge", which might involve decryption; or they can also order someone whom they reasonably suspect to have special knowledge of encryption services to give information on "how to get the data at stake in intelligible form"—how to break the algorithm, if that can be done. Failure to comply with this might get me between 6 months and a year of imprisonment and/or a fine between 26 and 20 000 BEF (1EUR = 40.3399 BEF) I had no clue.

Robert Collins: 8 Apr 2006

Yay for siproxd. Working multi-user sip is a beautiful thing. Key notes: You need to configure siproxd, allow siproxd to use some ports on the firewall, and configured your sip client. after installing the package, edit /etc/siproxd.conf and set if_inbound=INTERFACENAME if_outbound=INTERFACENAME hosts_allow_reg=your internal network/netmask do not set hosts_allow_sip - I found it interacted strangely and got 408 'timeouts' - which is how siproxd shows 'access denied' to the client. edit /etc/default/siproxd and set it to enabled. do a sudo invoke-rc.d siproxd start Now, in your iptables rules you need to allow the following ports for 'INBOUND' on your inside and outside interfaces: 5060 (sip) 7070-7079 (rtp - the voice and video data) Activate those rules, and you are done on the infrastructure, now its just each client that you need to configure. So fire up your sip client. It should have a sip proxy field - in there put 'sip:' + your gateway address/ip. if you have STUN configured - disable it. The sip proxy will forward registration and all traffic for you, STUN will at best confuse the issue. And bingo, you should have working sip.

7 April 2006

Matthew Palmer: Stunning. Simply Stunning.

Rails is the framework that just keeps on loving. A new feature in the recently-released Rails 1.1 is an integration testing framework. The general idea is that your unit tests make sure that your data model and validation work, functional tests make sure that business logic is specified correctly, and then integration tests tie a whole typical user session together, to ensure that your whole app holds together nicely in real-world usage situations. Basically, think of integration tests as an automated "click around" to make sure everything's working -- and, like everything that's automated, you can do it quite regularly without getting RSI, and it'll never make a mistake. Now, automated integration testing is pretty cool, there's no doubt. But there's more to this than meets the eye. You can also use the integration testing features in rails to test drive your entire Rails application from the Rails console. Big geek points to Mike Clark for the tip.

6 April 2006

Jeff Bailey: Has the hula hoop fallen?

Last weekend I found myself looking for something to hack on that wasn't something I see during my work day. I took a look at <a href="http://www.hula-project.org/Hula_Project">Hula</a>. I've wanted something like this for use at home. It would be nice if <span class='ljuser' style='white-space: nowrap;'><a href='http://auzure-skies.livejournal.com/profile'><img src='http://stat.livejournal.com/img/userinfo.gif' alt='[info]' width='17' height='17' style='vertical-align: bottom; border: 0;' /></a><a href='http://auzure-skies.livejournal.com/'><b>auzure_skies</b></a></span> and I could see one another's calendar, have our own Jabber server, and have easy access to our email through a local client or through webmail.<br /><br />There seem to be a steady stream of commits to Hula's SVN, but almost no discussion on the mailing list. I've sent in <a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-March/001012.html?id=1613&amp;prjname=hula&amp;mlname=dev">one patch</a> to the Makefile so that make dist would run (<a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-April/001014.html?id=1613&amp;prjname=hula&amp;mlname=dev">accepted</a>), and sent <a href="http://forge.novell.com/modules/xfmod/maillist/archbrowse.php/hula-dev/2006-April/001013.html?id=1613&amp;prjname=hula&amp;mlname=dev">another</a> asking for design information (No answer yet). In general, the codebase seems crufted with a bunch of legacy NetWare concepts. It's written in at least four languages (C, C , C#, and Python) and doesn't seem to have a testsuite. The code also currently doesn't run on powerpc without segfaulting.<br /><br />Ah well. Anyone know if there's another project that has similar aims and goals? Basically some sort of server software that will handle almost all of what evolution can hand to it, plus some sort of extensible interface so that it's reasonably easy to add things like Jabber servers, RSS/Atom Aggregators, etc.

5 April 2006

Adeodato Sim : grep-dctrl -s Source:Package

I just wanted to say thanks to Antti-Juhani Kaijanaho, the author of grep-dctrl, for implementing a fix for my wishlist bug #355960. Now it is possible to obtain the value for a field (eg. Source) from some other field (eg. Package), when the former is not present. For example, to obtain a list of source packages that need to be rebuilt in a MusicBrainz transition: grep-dctrl -FDepends musicbrainz -ns Source:Package. Formerly, one would have to list binary packages, and do some juggling to get the list of sources. I think regular grep-dctrl users will surely appreciate this capability. NP: Almod var & McNamara, Suck it to me

Clint Adams: Do I earn frequent blogger points by doing this?

Matthew,
1) I say "The Debian project believes that works under the GFDL, with invariant sections, are non-free". Someone is insulted, because they believe otherwise. Is my statement incorrect? Should that person feel insulted?
That statement would seem reasonable given the outcome of a project-wide General Resolution. If the individual believes that the process by which said outcome was reached was flawed beyond a reasonable point, that person might feel frustrated. If it is widely held that such was flawed beyond a reasonable degree, and the speaker advancing that position were widely regarded as being obviously deceptive, then that person should feel insulted.
2) I say "The Debian project believes that it is a shame that a member has died". Someone is insulted, because (for whatever reason) they disagree. Is my statement incorrect? Should that person feel insulted?
If you are basing your statement on a mailing list discussion in which no one was obliged to participate; which excluded anyone who didn't subscribe to that mailing list, anyone who refused to participate in said discussion for whatever reason, and anyone who quite correctly failed to recognize said discussion as a decision-making process; and which was generally shameful and embarrassing; then you are manufacturing consensus out of your ass. Yes, that statement is incorrect. Yes, we should all feel insulted. Trying to argue that we should just spout meaningless platitudes (no matter how strongly a tiny minority might mean them) at a whim is insane. The Debian project condemns the U.S. head of state for being a retard; everyone with whom I discussed this today agrees. I know that Debian's about technical excellence, but what harm can a simple political statement do? Maybe we should darken our website to show our support for those who died at the Gulf of Tonkin. If it's in poor taste to vote on whether or not the project believes something is a shame, then I think it's probably in poor taste to pretend that that was decided in some other manner.

Clint Adams: Batman was running Wesley Willis amok

Matthew, you continue to be disingenuous. If you, in your official capacity as Debian representative, expressed condolences to the GNOME advisory board with regard to the death of GNOME's UI, I bet that some of the people not laughing might be angry with you. Now how many of them need to speak up before you'd acknowledge them as people and not rabid stick figures?

Rapha&#235;l Hertzog: Leader election: last chance to vote

Given the low participation, it looks like the choice of a DPL is difficult this year. It probably means that the platform of the candidates do no suit everybody… however with DPL teams, there’s more than just the DPL and in theory each member should have their own platform. That’s not the case for me because writing a platform is a big job… which I can avoid since I’m not candidate. :-) However I now do feel the need to tell what I would like to propose (and do) if I’m part of a team so that you know better what to expect if you vote for a team where I’m involved. I’d just like to give a warning, those items are quick notes and are in no way full- and flesched out solutions, they will need to be discussed and refined in all cases, and somes ideas may be dropped of course. This list is neither complete nor definitive. Not all items will be achieved but each of them is a real progress IMO and I’d like to be able to work on them. For people who are concerned by those changes, I’m sorry if you discover my ideas by this post even before I had the opportunity to talk to you… I’m posting those ideas now because they may be considered by people who are currently voting, but it does not mean that I’m not interested to discuss them with you. It’s also true that some of those ideas can be implemented without being part of the DPL team and I’ll certainly try to implement some whatever the outcome of the election, but I really believe that being part of a DPL team helps greatly because you have access to some important informations, and you can effectively discuss with core teams which are otherwise difficult to approach for non-technical discussions when you’re a random DD. And last but not least, the trust of the developers is a big motivation (at least for me) to work effectively on those problems. See this post for my personal vote recommandation and see you in 3 days for the result of the election !

4 April 2006

MJ Ray: KohaCon 2006, 2-3 May, Paris

"We'd like to extend an invitation to libraries, developers, media and library supporters to attend our first conference. This event is the first formal gathering of the wider Koha community, including developers, users and supporters [...] Registration is free but essential." [link to conference web page]

Matthew Palmer: Rewriting in Rails -- A Practical Examination

[Note: this article was mostly written some weeks ago; I left it in my "to be edited" box and then promptly forgot about it. So any and all temporal references are way out of whack. Since originally writing this article, I have commenced an incremental rewrite of an in-house business management application from crazy-PHP (a common -- some may say overwhelmingly so -- dialect of the language noted for it's complete lack of any sort of good software development practices, such as the creation and use of functions (!)) into Rails. Articles on this effort will be appearing presently.] Almost immediately after I'd finished writing my previous discussion on why rewriting software is evil, I decided to make a little experiment. What I did was take a fairly well factored PHP application, and rewite (a portion of) it in Rails. My intent in this was not to produce a production-quality rewrite. I have no interest in proliferating yet more functionally equivalent clones on the world. Instead, I undertook the work simply to get a feel for (a) writing a whole, traditional, Rails app in a short space of time, (b) how quick Rails really was to produce an application, and (c) whether wholesale rewrites really are as boring and life-sucking as I imagined them to be. My methodology was this: with a small amount of knowledge of the target application (SysCP), the existing database schema and templates, and a weekend, rewrite as much of SysCP as I could in a close-as-possible reproduction of critical SysCP functionality. My summary results are: rewrites are as boring as I thought they would be, Rails is powerful but fairly complex and slightly buggy when you get down into it (especially if you're working from an existing -- possibly suboptimal -- database schema), but overall, Rails is Way Good Stuff. On the boredom aspect -- I had two days to write code. I had some domestic duties to attend to (walk the dog, visit the hardware store, help my wife with attaching a new bag rack to her bike, mow the lawn, etc) but on the whole, it was dedicated to programming. I've spent whole days (hell, 40 hour marathon stretches) cutting code before. I knew this wasn't a six-month deathmarch, but only a weekend experiment. Despite that, I feel that my motivation levels were lower than they normally are when coding. I can only imagine what it must feel like, two weeks into several months of hard core coding, knowing that you'll end up with what you had before, functionally speaking. If you are going to do the rewrite thing (and may the Flying Spaghetti Monster have mercy on your soul if you do), then pick the right project. SysCP is large masses of tangled PHP (is there any other kind?) but it has a fair amount of local and global structure once you get down to it -- for instance, it's quite well factored into business logic and display, and the code is broken down fairly logically by action handler, so you get entire source files that look like this:
  if ($action == 'edit')
   
    // 150 lines of twisty passage PHP
   
  else if ($action == 'new')
   
    // Another 150 lines
   
  // repeat for another few actions
and so on. The nice thing about this is that, if you have to look for how something works, you can almost certainly find it in one place in the source. Deciphering it might be another matter, but at least you've got something to start from. As I mentioned, the display in SysCP is pretty nicely split off from the logic -- a large number of templates, with common header/footer files, with some small parts in common templatettes. Some HTML is still generated within the actions, but due to the above action-based structure, it's usually fairly easy to identify all of the HTML that will be associated with a particular action and turn it into a coherent Rails template. I would dread doing a rewrite of the presentation layer of, say, IRM. It's idea of well-factored presentation is to separate print statements from logic by a blank line. To my great shame, I've had the reins of IRM for a year, and it's still this bad. I claim it's because I hate HTML coding with a vengeance, but I think I'm actually just scared to try and tame that particular monster. (Update: Martin Stevens has been doing some good work turning IRM's HTML into Savant templates. The only downside is that I can hear his manic laughter -- caused by IRM's insanity slowly infecting him -- all the way from England, and it's keeping me awake at night). I also had to re-learn that most hated but most important of lessons -- that, no matter how much reading you may have done, until you've cut chunks of code in a language or environment, you have no idea how it actually behaves in your brain. Specifically, I spent a fair amount of my alloted rewrite time learning a few little lessons in how Rails actually behaves, and all of it's cool little features. Of course, everyone is going to have this pain, and I've suffered it in every language that I've done any appreciable amount of programming in, but it's always a shock to the system that -- after all this time programming -- a new language still makes my brane tingle curiously for a while. Luckily, I'd read and digested all of both the Pickaxe (Programming Ruby) and AWDWR (Agile Web Development with Rails) so I knew what was possible, I just usually wasn't sure how exactly, so I spent a lot of time with my head in the books. Rails' little foibles also bit me in the bum more than once. For example, I spent over an hour (a no foolin' hour) trying to hunt down what I was doing stupid in my code to make Rails completely forget about the value of a couple of my fields. The answer turned out to be to restart Webrick (Rails' internal webserver for development testing), and the problem cleared right up. You could hear my screams of anguish from the moon (even through the vacuum of space -- it was a lot of anguish). Rails isn't the Final And Ultimate Solution To The Webapp Problem, but it's a good start. There is near-zero administrative bumf when you're writing a Rails app. Rails is fairly intelligent about working out what you want done from the world around it. Code generators (which produces sensible, minimalist templates -- not the ugly, unmaintainable behemoths produced by Visigoth Studio, which has given the whole code generation world a bad name) handle a lot of the low-level "oh bugger, I have to add a new file" feeling. It's very, very anal about project structure, but (in contrast to many other bondage-and-discipline frameworks I've looked at in the past) this structure seems almost comforting (maybe I'm just getting old and turning into a satisficer). What all this means is that you (a) don't write much code unless it moves you toward your goal, and (b) Common structure means that any Rails app will be fairly familiar to an incoming programmer. Unfortunately it also means that cunning wankers will, sooner or later, work out a whole pile of ugly tricks and contortions to get themselves out of Rails' comfortable-but-no-doubt-incompatible-with-many-people's-ways-of-thinking straitjacket, which I will (sooner or later) end up maintaining. Like many of Rails' (and Ruby's) features, though, I don't see them being any more abusable than most features of any programming language or environment -- and at least they're powerful and useful (unlike, say, register_globals, magic_quotes_gpc, magic single-character variables, mandatory indenting, or banning tabs as indent characters -- I thought I'd spread the slagging amongst lots of languages). Productivity-wise, although I was only just kicking off my Rails webapp knowledge, I felt I was doing fairly well. From experience, what I produced in my weekend was roughly on par with what I could produce in PHP in the same amount of time, had the situation been reversed. Considering that I have about 3 weeks of Ruby/Rails knowledge, and about 5 years of PHP experience, I think that's a big win. (Update: I've since produced a DNS management applet for work in about 6 hours billable time, and a virtual mail account application in about 12 hours, both using Rails. There isn't a hope in hell that I could have performed a similar feat in PHP, especially with the same amount of inherent flexibility that the Rails solutions contain). Overall, my impression of wholesale rewrites as being soul-sucking experiences stands. I suggest they be approached with the greatest of care, and only be permitted after an appropriate period of psychological counselling. There is plenty of code that needs rewriting (but why do I always have to find it?) but replacing it by doing an rm -rf on the source tree and starting again is not the answer.

Next.

Previous.