Search Results: "will"

3 April 2008

Paul Wise: Surveying the Debian community!

As a Debian developer I have on occasion felt a bit out of touch with doing things with Debian and out of touch with other users. I mentioned to some folks at DebConf7 that I felt I focused too much on working on Debian and not actually connected to what the benefit of working on Debian is. Partially as a result of those feelings and partially because I thought it would be an interesting thing to do, I started to prepare a couple of simple surveys early this year. The first one went out earlier last month and I posted the second one a few days ago after far too much procrastination and running the wording by a few people - thanks to Micah for the drug boats question :) So, if you are a Debian user or are a new contributor (or DM/NM/AM or new DD), I would greatly appreciate hearing from you. Please respond to the survey addresses rather than my personal ones. So far I have 15 or so responses to the new contributor survey, but ideally I would have many more, so please send something in if you are getting involved in Debian development or helping others get involved. I've had about 24 responses to the user survey so far. Many of you will have heard about Debian success stories like Extremadura, Bhutan, HP, Skolelinux, Sanger and other high-profile Debian users. I'm hoping to hear about as many different uses of Debian as possible, so please keep the responses coming in. The primary audience for these surveys is the Debian development community. The results will go to the debian-devel-announce and debian-private, I also hope to have a discussion or two about them at DebConf8 in Argentina. There is no time-frame for closing the survey or releasing the results, like the Debian distribution, I release when ready :) PS: Please install the popularity-contest package on your machines if possible and subscribe to the packages.qa.debian.org pages for packages that you particularly care about. PPS: Please feel free to ask me questions in your responses and I will attempt to reply as time allows.

Miriam Ruiz: The European Commision and OOXML

After the approval of OOXML as a standard by ISO, it seems that there are two months for appealing the decision. The European Commission, Europe’s top antitrust authority, will investigate whether OOXML, as the format is known, is “sufficiently interoperable with competitors’ products”, as well as if there have there been any irregularities or attempts to influence the debate or vote. If national ISO bodies return evidence that Microsoft attempted to influence the votes to secure acceptance of OOXML, it would strengthen the Commission’s antitrust case. According to Thomas Vinje, legal counsel for the European Committee for Interoperable Systems (ECIS), “Even if the votes were legitimately won, which I doubt, OOXML is not an open standard because it isn’t fully implemented on competing platforms, and its future shape is subject purely to Microsoft’s control”. “Granting ISO status to OOXML doesn’t begin to resolve the competition law questions the Commission is looking into”. Lets hope the European Union investigates and clarifies all this. “An appeal would have to be resolved before publication of a document as an International Standard”, said Roger Frost, spokesperson for ISO. In other words, if an appeal is filed, it’s conceivable that final publication of OOXML as a standard could be delayed. Lets hope ISO appealing process, if followed, is less irregular than the approval one. Maybe I can still recover my trust in ISO. Lest see how it goes.

Martin F. Krafft: Swiss Hackontest 2008

From the official press release:
April 3, 2008 - The Swiss Open Systems User Group /ch/open organizes the first international Hackontest sponsored by Google as part of informatica08, the Swiss year of computer science 2008. Hackontest is a 24-hour programming competition of three teams of different open source projects. Its goals are to enhance popular Free Software projects according to user needs and to demonstrate to the public how enthusiastically open source software is being developed. Starting in April 2008 users and developers of open source software may submit feature requests for their favorite Free Software projects and rate and comment them. On Swiss national holiday August 1st, 2008 the Hackontest jury will pick the three most promising teams. They may travel to Switzerland on September 24/25, 2008 to participate in the competition located at the OpenExpo Z rich 2008. The jury is staffed of ten highly renowned open source hackers such as Jeremy Alison (founder of Samba), Bruce Perens (founder of the Open Source Initiative), Alexander Limi (founder of Plone), Harald Welte (founder of gpl-violations.org) and Jono Bacon (Ubuntu community leader). The Hackontest platform and further information about the event is located at www.hackontest.org.
I have been asked to serve on the jury. This sounds like it ll be a fun and interesting event, and if not only I finally get to meet Alexander Limi, with whom I ve worked on Plone, and Bram Moolenaar, author of the best editor around. Now, Debian! Let s get some proposals in! NP: The Good, the Bad & the Queen: The Good, the Bad & the Queen

2 April 2008

Peter Van Eynde: ipv6 with a Cisco ADSL router a short howto

For a long time I wanted to play with IPv6, but I never liked any of the tunnels I saw. This evening I started wondering if my Cisco 837 ADSL router cannot handle some form of tunnel.

A short time later and:
router#ping ipv6.google.com
Translating "ipv6.google.com"...domain server (195.238.2.21) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4860:0:1001::68, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 276/278/284 ms


How to do it: I configured a 6to4 tunnel on the router:

ipv6 unicast-routing
ipv6 cef
! enable ipv6
ipv6 inspect name MyIPv6Inspection tcp
ipv6 inspect name MyIPv6Inspection udp
ipv6 inspect name MyIPv6Inspection ftp
ipv6 inspect name MyIPv6Inspection icmp
! let's have a firewall
interface Tunnel1
no ip address
no ip redirects
ipv6 address 2002:51F0:CCA5::1/128
ipv6 enable
ipv6 traffic-filter ipv6ip in
ipv6 inspect MyIPv6Inspection out
tunnel source Dialer1
tunnel mode ipv6ip 6to4

interface Ethernet0
ipv6 address 2002:51F0:CCA5:DEAD::1/128
ipv6 enable

ipv6 route 2002::/16 Tunnel1
ipv6 route ::/0 2002:C058:6301::

ipv6 access-list ipv6ip
 deny ipv6 any any


Of course the 6to4 ip (the one on Tunnel0) is derived from my ipv4 ip. Which changes now and again. So I uploaded to the flash of my router the following file:

proc doconf   section setting   
if   [ catch   ios_config $section $setting   errmsg ]     error "configuration of $section $setting failed";  
 

set ipaddr [exec "show ip interface Dialer1   i Internet address"]
regexp  is ([0-9.]*)/  $ipaddr match ip
regexp  ([0-9]*).([0-9]*).([0-9]*).([0-9]*)  $ip match a b c d
set newipv6 [format "2002:%2x%2x:%2x%2x::1" $a $b $c $d]
set newintipv6 [format "2002:%2x%2x:%2x%2x:dead::1" $a $b $c $d]
doconf "interface Dialer1" "no ipv6 address"
doconf "interface Dialer1" "ipv6 address $newipv6/128"
doconf "interface Ethernet0" "no ipv6 address"
doconf "interface Ethernet0" "ipv6 address $newintipv6/64"


This is a TCL script that will get the current external ip (from Dialer1) and give the correct IPv6 ips to the right interfaces.

And with alias exec updateipv6 tclsh flash:update-ipv6.tcl I can quickly login and adapt the addresses myself.

The router handles IPv6 autoconfiguration on the inside, so my machine now says: 
# ip addr show dev wlan0 scope global
4: wlan0:  mtu 1500 qdisc pfifo_fast qlen 1000
 link/ether 00:19:d2:28:2c:a4 brd ff:ff:ff:ff:ff:ff
 inet 192.168.1.53/24 brd 192.168.1.255 scope global wlan0
 inet6 2002:51f0:cca5:dead:219:d2ff:fe28:2ca4/64 scope global dynamic
    valid_lft 2590061sec preferred_lft 602861sec

The one remaining problem is that when the external ip changes the autoconfig announcements change too, but the old ipv6 IPs remain on the interfaces.

PS: for those not in the know: I work for Cisco but this was done after hours and using public information (of course)

Russell Coker: Trust and My SE Linux Play Machine

Currently my SE Linux Play Machine [1] is running as a Xen DomU. So if someone cracks it they would also have to crack Xen to get access to directly change things on the hardware (EG modifying the boot process). As documented in my last post [2] a user of my Play Machine recently managed to change my password. Of course this was just two days after the vmsplice() kernel security flaw had been discovered [3]. Of course any machine that offers shell access to remote users (or the ability to run CGI-BIN scripts or other programs that users can upload) is immediately vulnerable to such exploits and while SE Linux has blocked local kernel exploits in the past [4] there will always be the possibility of kernel exploits that SE Linux can’t block or which can be re-written to work in a way that is not stopped by the SE Linux policy. So it’s best to assume that SE Linux systems are vulnerable to kernel exploits. At the time that the vmsplice() exploit was announced there was a claim that it could be used to de-stabilise a Xen Dom0 when run within a DomU. It’s best to assume that any attack which can make some software perform in an unexpected manner can also be used to successfully attack it. So at the time I was working on the assumption that the Dom0 could have been exploited. Therefore I reinstalled the entire machine, I firstly installed a new Dom0 (on which I decided to run Debian/Unstable) and then I made a fresh install of Etch for the Play Machine. There is a possibility that an attacker could compromise the hardware (changing the BIOS or other similar attacks), but this seems unlikely - I doubt that someone would go to such effort to attach hardware that I use for demonstrating SE Linux and for SE Linux development (it has no data which is secret). If someone attacks my Play Machine they would have to first get root on the DomU in question and then crack Xen to get access to the hardware. Then the machine is on a separate Ethernet segment which has less access to my internal network than the general Internet does (so they would not gain any real benefit). One thing an attacker can do is launch a DOS attack on my machine. One summer a Play Machine overheated and died, I suspect that the extra heat produced by a DOS attack contributed to that problem. But losing a low-end machine I bought second-hand is not a big deal. When discussing the machine there are two common comments I get. One is a suggestion that I am putting myself at risk, I think that the risk of visiting random web sites is significantly greater. Another is a challenge to put the machine on my internal network if I really trust SE Linux, as noted I have made mistakes in the past and there have been Linux kernel bugs - but apart from that it’s always best to have multiple layers of protection.

Share This

Lucas Nussbaum: Things you should know before buying an Asus EEE PC

I’ve been using an EEE PC since december, and people keep asking me if they should buy one. So here are some things you should know before making a decision. Screen The screen is small, but that’s OK. I couldn’t find many applications that didn’t work in 800×480. And for the remaining ones, you can usually use hacks such as running the app in a larger virtual desktop. Not ideal, but it works. Regarding usability, it’s not a too big problem. Jut expect to use many apps maximized, and use scrolling and virtual desktops a lot. (Important note: Xmoto doesn’t work!!) Keyboard The keyboard is probably a bigger problem than the screen (I hadn’t expected it to be a so big problem before buying the laptop). Every other keyboard seems to have HUGE keys after typing on the EEE PC keyboard. But with some training, you can type quite fast, even if probably not as fast as with a full size keyboard. The layout of the “special” keys is quite good (esp. the PgUp/Down, Home and End keys on the arrows. I should remap my other keyboard like that). Battery, power consumption One big problem with the EEE PC is that it consumes a lot of power while sleeping (using suspend to RAM). If you leave it sleeping for more than a few hours, expect the battery to be empty. That really sucks, especially since suspend to disk isn’t really a good option on such a device. Another problem related to power is that charging the battery is quite slow. SDHC card reader If you want to expand the storage capacity of your EEE PC with the SDHC port, choose your SDHC card carefully. There are only a few cards that work. The other ones will cause write error (they will work in read-only mode, so I’m using an external card reader to write, which sucks). A list of supported cards is available in the EEE PC manual. Random Q&A Q: I don’t have a laptop. Should I buy it? A: If you want to do a lot of real work on it, it’s probably not a very good idea. There are faster (but bigger) laptops at around 450-500 EUR. They are probably a much better option. The EEE PC is perfect as a the second laptop you only bring to places where you want to stay connected, read email and surf on the web (like conferences and meetings). Q: Does the VGA output works well? A: Yes. And it uses an Intel video card which works like a charm with xrandr. I already gave several presentations and classes using it. The laptop can output 1280×1024 (maybe 1600×1200, not sure). The only problem is that you will only have the top-left part of your slides on the laptop’s screen, because of the smaller resolution there. Annoying if you plan to read your slides.

Conclusion So, should you buy one? If you can’t wait, go ahead. If you can wait, it might be a good idea to wait until Asus fixes some of the problems (the SDHC card reader and the power consumption while sleeping are the most annoying ones).

Julian Andres Klode: Python Extension for libisofs


I am working on a Python extension for the libisofs library. The extension is written in Cython , a Python-like language designed to write Python extensions. At a later point, this extension will be used to create the ISO Images in debimg. It will be disabled by default, but you can enable it via a configuration option.

Miriam Ruiz: ISO/IEC DIS 29500 (OOXML) is now an International Standard

Today is a sad day. Corruption has won over rationality. ISO sucks. I guess I lost all the trust I had on the standards organizations. OOXML is a standard covered by many patents, ambiguous enough for Microsoft to keep the real specs closed, far worse than the previous ISO standard for the same task (ODF), and approved in a very suspicious way, in a process full of irregularities, which I hope the European Union will investigate.

MJ Ray: Tour of Flanders

Bernie S wrote in: “Bit concerned RTBF not showing Flanders on Sunday (4 hrs last year). Only Eurosport (19 east) and RAI Tre (13 east) I can find so far. I just checked ARD/ZDF no deal there. Also France 3 said on Sunday at CI that Flanders is not live there. So, coverage is a bit sparse, although NOS will probably show but are encrypted.” Thanks Bernie. Eurosport is schedules show it as 13:00-17:00 CET and RAI Tre has it 15:10-18:00 CET (which probably means Eurosport will overrun and not show the presentations, as sadly usual). Unusually, it’s also on SFinfo (13 east) at 13:00 CET. Highlights 15:15 CET Monday and 13:30 CET Wednesday on Eurosport.

1 April 2008

Russell Coker: SE Linux Play Machine and Passwords

My SE Linux Play Machine [1] has been online again since the 18th of March. On Monday the 11th of Feb I took it offline after a user managed to change the password for my own account (their comment was “ohls -lsa! i can change passwordls -lsals -lsa HACKED!“). Part of the problem was the way /bin/passwd determines whether it should change a password. The previous algorithm (and the one that is currently used in Debian/Etch) is that if the UID of the account that is having it’s password changed doesn’t match the UID of the process that ran /bin/passwd then an additional SE Linux check is performed (to see if it has permission to change other user’s passwords). The problem here is that my Play machine has root (UID==0) as the guest account, and that according to the /bin/passwd program there is no difference between the root account (for unprivileged users) and the bofh account (which I use and which also has UID==0). This means of course that users of the root account could change the password of my account. My solution to this was to run chcon on the /bin/passwd program to give it a context that denied it the ability to change a password. The problem was that I accidentally ran the SE Linux program restorecon (which restores file contexts to their default values) which allowed /bin/passwd to change passwords, and therefore allowed a user to change the password of my account. The semanage tool that allows changing the default value of a file context does not permit changing the default for a file specification that matches one from the system policy (so the sys-admin can’t override compiled in values). I have now fixed the problem (the fix is in my Etch SE Linux repository [2] and has been accepted for Debian/Unstable and something based on it will go into the upstream branch of Shadow. See the Debian bug report #472575 [3] for more information. The summary of the new code is that in any case where a password is not required to change the user’s password then SE Linux access checks will be performed. The long version is below: The new algorithm (mostly taken from the Red Hat code base which was written by Dan Walsh) is that you can only change a password if you are running as non-root (which means that the pam_unix.so code will have verified the current password) or if you are running as root and the previous SE Linux security context of the process is permitted access to perform the passwd operation in the passwd class (which means it is permitted to change other user’s passwords). The previous context (the context before one of the exec family of system calls was called) is used for such access checks because we want to determine if the user’s shell (or other program used to launch /bin/passwd) was permitted to change other user’s passwords - executing a privileged program such as /bin/passwd causes a domain transition and the context is different) than the program that was used to execute it. It’s much like a SETUID program calling getuid(2) to get the UID of the process which launched it. To get the desired functionality for my Play Machine I don’t want a user to change their own password as the account is shared. So I appended password requisite pam_deny.so to the file /etc/pam.d/passwd (as well as the chfn and chsh commands) so that hostile users can’t break things. The new code in /bin/passwd will prevent users from taking over the machine if my PAM configuration ever gets broken, having multiple layers of protection is always a good thing. The end result is that the Debian package and the upstream code base are improved, and my Debian Etch repository has the code in question.

Share This

Russell Coker: SE Linux Etch Repository for AMD64

My Etch back-port repository of SE Linux related packages (which I documented in a previous post [1]) now has a complete set of packages for AMD64. From now on I aim to make AMD64 and i386 be my main supported platforms for SE Linux development. There is a guy who may be able to give me a stack of well configured PowerMacs (2gigs of RAM), if he comes through with that then I may add PPC-32 to the list of architectures I support. If that happens then probably the machines will have their hard drives smashed for security reasons, so I’ll want to swap some G3 PowerMacs for hard drives.

Share This

Manoj Srivastava: Manoj: Migrating to Git

I have been using Arch to package my Debian packages since 2003; which means that Arch has had a good long run as my SCM of choice. I have been using CVS for a few years before I moved to arch, and the migration took me about six months, since it involved a while new philosophy of packaging; I am hoping that migrating to git would not involve such a major paradigm shift, and thus be less disruptive and time consuming. What follows is a narrative of my efforts to get educated about Git. This article is meant to be an annotated, selective, organized set of links to information about Git. How does it differ from the myriad of other link collections about Git proliferating on the web? Well, the value add is in the annotations and the organization: while not quite a narrative of my exploration, this is an idealized version of what I think my discovery process should have been, to be most effective. Staging the information is important; google finds one lots of information that is incomprehensible to someone just coming to Git. This selection of links is actually selective; I have included only pointers to resources that fed me information at the level that I could handle at that stage, and I have eliminated links to information that was not new at that point. I have tried to select the best (in terms of information and clarity) of breed for each kind of information source I have come across so far. There is a caveat: while still a beginner, though I am able to better judge now what is confusing to a beginner than I shall be when I have become more familiar with the system, I am still enough of a novice not to trust my judgement on what really is best practice. I can fix the latter as I gain experience, but then I ll need to be careful not to overload on complexity too early in the learning curve. On the down side, this selection is subjective, and probably shall be even in the long term: I include what appealed to me, and will probably miss loads of pointers to information that I have not yet come across. However, I hope this will make it easier for other people to reach the same goal: use git for their version control needs. Have fun.
Categorized under:

Erich Schubert: Ubuntu to rename top level directories

The usability experts of Ubuntu have finally started to handle the single most mentioned usability issue with Linux: the top level directory names.Quoting Finn C. Tional from the Ubuntu Usability Group:
It's one of the mysteries of Unix that the directory named "usr" is not for user data, and the directory named "etc" while looking like random stuff thrown together stores all the important config files. [...] This is probably the single most confusing hurdle for new Unix users. [...] We need to finally tackle this, before people are too used to these odd directory names.
Therefore, they propose the following renaming scheme:
/bin      /system/executables
/boot     /system/boot
/dev      /system/devices
/etc      /system/config
/lib      /system/libraries
/home     /users
/media    /storage
/mnt      /storage
/proc     /system/processes
/root     /users/Administrator
/sbin     /system/executables/admin
/tmp      /system/temporary
/usr      /system/applications
They'll include a patch for the GNU C library as well as for AppArmor to redirect the old path names to the new ones. Given the existing filename matching already done by AppArmor the overhead is expected to be neglible at least for AppArmor enabled systems. SELinux enabled systems will remain unchanged, since the user won't be allowed to see anything potentially irritating in the root directory anyway, but will be confined to his user directory.Since there are a dozen applications that will need changes to accomodate the new naming scheme, expect these changes only to be included with Ubuntu 10.4 (also lovingly named Ubuntu X) scheduled for April 2010.Other distributions are expected to follow up with these changes in 2011.P.S. Yeah, the Ubuntu folks really need to think this throuh some more. Russel pointed out that "My System" is even easier to understand; after all this is not about someone elses system or some systematic error or whatever. I figure he's right. How about "My Computer" than this lowercase (pessimistic?) "system" directory they're proposing there!

Neil Williams: Updating Emdebian docs

I've updated two of the Emdebian pages today, after some feedback on the list. I'm interested in feedback on the current Emdebian website because I'm aware that the site isn't that friendly to new users. (Note: feedback on the textual content of the site, not the structure or layout.) The updated wiki pages are the start of a longer process to review the website itself.

http://wiki.debian.org/EmdebianQuickStart

http://wiki.debian.org/EmdebianRootfs.

31 March 2008

Cyril Brulebois: Lufthansa machines landed!

As outlined some days ago, patience is a requirement. That said, I'm glad that all things come to (s)he who waits, Lufthansa hardware finally landed! Ganneff, already very busy with his well-known DAM and ftpmaster hats, managed to also handle shipping some hardware donated by the Lufthansa some months ago. pkg-games was promised a powerful box, look: Pentium 4 (2400 MHz, 1024 MB); we will finally be able to try and provide backports in a semi-automated fashion, so as to ease stable users' life, when it comes to installing bleeding-edge versions of their favourite games! Thank you for making this possible and keeping everyone posted about the status of that hardware donation. Hopefully, it'll be possible to also communicate through bits of the DAMs , as suggested some weeks ago on debian-newmaint@. Yay for communication! \o/

Steve Kemp: I don't shut up, I grow up

Recently I took stock of my Javascript programming efforts, with the intention of simplifying things. To date I've put together three sites which make use of Javascript:
debian-administration.org
There isn't very much javascript in use upon this site, and you might be forgiven for thinking there was none at all if you don't have an account, or don't login. There's a tagging system which is starting to creak under the sheer number of different tags, and several back-end parts of the site make use of AJAX calls. Most of the script lives in a single file common.js which I cobbled via a process of trial and error, augmented with a little copy & paste coding. It works. But I knew I could do better ..
ctrl-alt-date
This was my first attempt to make a site be truely dynamic and "pretty". It has succeeded in that respect, although the lack of members makes the site itself essentially a failure. This time round I decided that I'd utterly refuse to write my own Javascript. So instead I used script.aculo.us (damn I hate those ugly URLS). This library made it almost too easy to add flash. I liked it a lot. Having said that though the sheer scope of the library and the way it didn't fit in the way that I coded made it painful to use at times. It works, and it works well. Like it? Yes. Love it no?
mail-scanning.com
This site has a fair amount of javascript upon it, but that isn't obvious unless you're actually a user. The only piece that I can recall is the real-time count of spam caught upon the front-page. (Realtime stats are cool!) Most of the code here is the simple kind, reverting back to the way I worked on the Debian Administration site; we're talking about basic effects such as:
  • show/hide a div
  • make an AJAX request every now and again.
  • Do a bit of auto-completion.
To get more of a feel for whats out there I wrote this initially with my own code, then later migrated it to jQuery. Quite frankly jQuery rocks. The way it works is a little strange at first, but it is so natural after a while. As an example: 
// find the div called "foo" - hide it.
$("#foo").hide()
I'm liking this library a lot recently, but only time will tell if I use it more.
In conclusion I filed #473125: ITP jQuery failing to see the existing ITP already present. Once the package makes it through the NEW queue I will update it to follow the skeletal javascript-policy. I disagree about the naming scheme suggested by that policy primarily because we already have packages of several of the "big" javascript libraries, such as scriptalicious, and see no gain in renaming them. But otherwise the policy is sane enough; following it will cause no harm at the very least. ObQuote: Stand By Me

Eric Warmenhoven: Rewriting as a learning tool

So a year and a half ago, I mentioned I was trying to learn Haskell, and I still am. It’s been going much more slowly than I hoped, since I haven’t really spent any time on it. I never write anything new anymore! So I decided to rewrite something I had previously written myself, need be damned. So I chose the RSS aggregator I wrote, harsh. harsh hasn’t changed in eleven months (and that change was just about making the location of its configuration file configurable), but I still remembered how it worked pretty closely; at least enough that I didn’t have to really go searching through its code too much. That’s probably also a function of how small harsh is; in terms of lines of code (excluding blank lines): 
  config.c: 139
  cookie.c: 221
 display.c: 709
    feed.c: 577
    list.c: 96
    list.h: 16
    main.c: 96
    main.h: 84
     md5.c: 360
     md5.h: 76
     rss.c: 120
     xml.c: 276
     xml.h: 17
     total: 2787
It uses expat to parse the HTML, libnbio for socket management (which is available in Debian), and ncurses for the UI. It doesn’t have any sort of threading (libnbio does a good job of making sure that, other than DNS lookups, there’s never anything going on long enough to prevent responsiveness). About its only feature is that it will use my cookies.txt file, so that I can see my LiveJournal friends’ protected entries. I originally wrote harsh in about a day or two. It was really easy because of the 2800 lines, about 850 of them had been written in some of my other projects (list.c/h and xml.c/h) or are standard (md5.c/h). I was also really familiar with the three helper libraries from writing grim (my IM client) and stark (a tool for viewing GnuCash data files). As a learning exercise, rewriting harsh in Haskell was excellent. It’s incredibly small, does a lot of standard things (like networking and console UI), and doesn’t do a lot of non-standard things (like an AIM client does). I got to play with the Haskell light-weight threads and STM; I learned how to create a Debian Haskell package; I learned how to use ghci as a debugger with breakpoints; and I’m much more comfortable with monads and with the language in general. It did take me significantly longer to write than the C version, though that’s more due to me having to learn not just the language but some libraries along the way (like HTTP, Vty, and HaXml). I still think that it would take me just as long to write the Haskell version as the C version, but I’m still much more comfortable with C, and imperative programming in general. From a code size perspective, the Haskell version is about one-sixth the size (excluding comments): 
Config.lhs: 53
  Feed.lhs: 144
 Harsh.lhs: 272
  Util.lhs: 26
     total: 495
However, that’s not a very fair comparison. In the C version, md5.c/h are included in the total count, when really they should be considered a standard library (and on the Haskell side, I used Data.Hash.MD5 from MissingH). On the C side, I did all of the HTTP request and response processing myself (which is what more than half of feed.c is about), while on the Haskell side I left that to an HTTP client library. Excluding all those things though, the Haskell version is still about one-fourth the size. Anyway, I put the Haskell version of harsh up here. If any Haskell hackers out there could take a look at it and let me know what I’m doing wrong or oddly, I’d appreciate it.

Lior Kaplan: Where did the numbers go ? (major bug in OO.org 2.4.0)


About two months after the Israeli government stopped the support for openoffice.org localization, we hit a major bug (actaully - a regression) with version 2.4.0 effecting Hebrew users. In version 2.4.0 numbers written in Microsoft Word documents are shown as Hindu numbers instead of Arabic numbers. There’s a big confusion in the terms, as the number used in Arabic are the Hindu numbers and the number used in Latin languages are the Arabic numbers. Anyway, this means that, the facto, Openoffice.org 2.4.0 can’t show properly Microsoft Word documents which were written in Hebrew. I can’t start to describe how much interoperability problems that causes in Israel. Which such behavior I can’t recommend OO.org to people, and organizations already moved to previous versions of OO.org can’t upgrade to 2.4.0 and must stay with 2.3.1. This is also a problem as most Linux distributions (Debian, Ubuntu, Fedora) intend to include 2.4.0 for their stable release. With all the RTL related bugs, OO.org was still usable. But this bug absolutely changes things. I hope it will be fixed for 2.4.1 and won’t be delayed for version 3.0. I wish I could say this is an April’s fools post, but that bug is a reality… Please vote for this bug.

Mirco Bauer: Monsoon Hacking Weekend + Monday Evening Hack

This weekend I did a hack session with Alan McGovern on Monson. You don't know what Monsoon is? It's the sexy GTK# driven bittorrent client based on the MonoTorrent library developed by Alan McGovern. I created debian packages for Monsoon and wasn't happy with some features and/or bugs so I thought I can contribute some love to it. First thing I implemented was persistency of file priorities for torrents, so when you restart Monsoon it will restore all priorities. I also reported some bugs to Alan in MonoTorrent, like it was ignoring "do not download" flags, so it kept downloading all files of a torrent and the download progress of files were not correctly restored when it was resuming the torrent. He found and fixed the issues right away, great service smile.png
Then I implemented auto-start of torrents that were running when Monsoon is closed.
Monsoon will also now not flood your console with lots of debug stuff, as I added a -d / --debug parameter for that, which made my terminal unresponsible without it when downloading big torrents (~1000 files). And this evening, I replaced the usage of Gnome.IconEntry and Gnome.IconSelection with Gtk.FileChooserDialog + a preview widget. Alan asked for this, as he wanted to drop the GNOME# dependency for memory usage reasons. Allright, enough love for today! Now am hungry.... PS: We have now an IRC channel for Monsoon: #monsoon on GIMPnet, if you are interested, please join!

Lars Wirzenius: Progress bars everywhere!

As I get older, and more impatient, I find myself wanting every program to give more or less accurate estimates of the remaining time until it has completed whatever it is doing. This applies to command line utilities as well. In fact, since most of my time is spent on the command line, it applies particularly to command line utilities. The thing I, as a user, want to know is how long I will still have to wait. I don't particularly care whether the program has completed 97.12765% of its job, I want to know whether it will still take seconds, minutes, hours, or longer to complete. Not remaining file counts. Not remaining byte counts. Time. I'm interested in the entire task. If each file takes 0.1 seconds to process, that's fine, but I don't want to estimate myself that with fourteen thousand remaining files it's going to to take around 25 minutes more. It doesn't have to be completely accurate; a reasonably good estimate is fine. It can fluctuate: when downloading over the Internet, transfer speeds sometimes vary. That's fine. Just give me the current estimate using the average recent speed. For various reasons, I often deal with large files, in the multi-gigabyte range. Copying them with cp seems to be pretty effective, but it's annoying to have to set up something like "watch du -sh source.file target.file" to be able to track progress. I could use "rsync --progress", but that only works well for a single file. Otherwise it reports remaining time for each file separately. I realize that rsync has a particularly difficult job for estimating the remaining time, since it is dependent on the contents of the files at either end. But it could try. Because of these, I tend to like Nautilus for copying files. It has a pretty good indicator for remaining time. Unfortunately, that isn't always practical to use, either, since I don't always copy file so that the local host is at least one end of the transfer, and I often really want rsync. One of the nice lesser-known utilities is pv (in Debian and Ubuntu in the package of the same name). It allows one to construct pipelines that estimate current remaining time. For example, I use this to fill a filesystem's empty space with zeroes: 
pv -petrb -s "$ guess k" /dev/zero > temp
(where guess is the free space in kilobytes). Sometimes the pipelines need to be somewhat contrived to fit pv in. This can also make them slower than straightforward ones would be. But it's often nicer to get some progress reporting than to optimize for speed, at least for stuff that you have to actually wait for in real time.

Next.

Previous.