Habits control our choice sometimes more than we would like to admit… New mobile phone Since about two weeks ago I’ve a new mobile phone. The Nokia E51 will replace my slowly dying Nokia 6130i. I knew I needed a new mobile phone when my 6310i started to turn off itself shortly after I turned it on. I needed up to about ten times switching it on to make it stay on. Sometimes it already switched itself off before I could enter the PIN. Looks like a loose contact, but I never figured out where it is. Although I know about Nokia’s behaviour in Germany, I still had to buy a Nokia, because after using a 6130 (the GSM 1800 only clone of 6110 and 6150), a 6210i and the already mentioned 6130i over the last decade, I got so used to how Nokia mobile phones are navigated and how you type with Nokia phones (blank on 0, point and comma on 1, case changing on #), everything else (especially those with blank on 0 and case changing on *) would be worse than the half-dead mobile phone, I’m currently using. Spoilt for choice So which Nokia? For a long time I refused to buy a mobile phone with a camera or radio in it. But since the E70 was no more available (and is said to have quite buggy software) and the E61 has been replaced with the E61i, there are no more smartphones without a camera, at least not from Nokia. But I also found some useful uses of camera phones. After a while I could track down the number of choices to four: Communicator E90, E61i, E65 or E51: The picture above shows that the main differences of those models is size: Although having a QWERTY keyboard on the phone would be nice (for ssh, Jabber, the web, etc.) and the E90 being only slightly bigger than the 6310i on the paper, the size difference to the 6130i is more than only noticeable since the 6310i tapers off at the top. Besides, for the price of an E90, I get an E51 and an EeePC together… (Thanks to maol in whose blog I read about Sizeasy.) The E61i also has a (very small) QWERTY keyboard and is primarily only much wider than any of the other phones. It even has no bigger screen resolution than the E51 or E65. (Only the no more available E60 – a normal monoblock smart phone like the E51 – had a better resolution: 352x416 pixel instead of 240x320 pixels.) And since I usually carry my mobile phone in my trouser pockets, width matters most. So I had the choice to either get a phone which is too big for my trouser pockets or one without a QWERTY keyboard. The I remembered those foldable external keyboards for PDAs. There are at least three different makers of foldable bluetooth keyboards said to be working with Nokia Symbian S60 3rd Edition phones, so a QWERTY keyboard on the phone itself was no more important. (Only passwords will need to be entered over the number keypad since I don’t want to broadcast them… ;-) The choice between E65 and E51 was made easier by their reviews (E65, E51) at Xonio: The E65 seems to have not that good standby and phoning times while the E51 seems to be quite good regarding endurance. I looked through the usual shops around Z¨rich HB: Swisscom Shop, MobileZone, Phonehouse: All had the same prices (about CHF 250 for a two years contract at CHF 25 per month), except that Phonehouse had no E51 available in the shop. Interestingly digitec had a much lower price (CHF 100 for the same contract) and the choice of color (the shops always only offered one color), so I ordered a black one there. Converting a prepaid card to a postpaid contract isn’t that easy I wanted to change from a prepaid card to a postpaid contract, both at Swisscom, so I already own a SIM card. But digitec only offers new contracts including a SIM card or contract renewals, but no switching to a contract with keeping the number. And a new SIM card costs CHF 40 extra in their online shop. So I called their hotline and asked. The answer was: I need a new SIM card since prepaid SIM cards can’t be converted to postpaid SIM cards (but can be used with different providers). When I came to the shop, the employee needed three tries to fill out the Swisscom form for the number migration and still did it wrong somehow. No postpaid contract acknowledgement from Swisscom after two workdays. So I called their hotline. They told me, the wrong SIM card number has been entered and I need to make digitec to enter the correct one. A few days later back at the shop they were overextended. After a while an internal e-mail was on the employee’s screen which clearly stated that in case of prepaid to postpaid conversions (and a few other cases) no new SIM card must be given out and if this happens too often for the same employee he will be charged the CHF 30 a new SIM card costs digitec… (So they have a 25% margin of every sold SIM card…) About one hour after they closed their doors (I was there about ten minutes before shop closing time) Swisscom had accepted the contract changes and I had a credit note of CHF 40 for the erroneously sold SIM card. And the mobile phone became even cheaper than in all the other shops. :-) New gadget, new features So after a week, I can say that in general I’m quite happy with the new phone. It has a nice web browser, an IMAP over SSL capable mail reader and a feed reader, it can connect to the internet via WLAN and the 240x320 resolution isn’t as bad as I expected. I already have a Symbian port of PuTTY on it and sshing into my workstation works fine, even if I currently only have the phone keyboard and T9 as input device and helper. I also have Opera and Opera Mini installed, but to my own surprise the included web browser from Nokia (said to be based on Apple’s HTML rendering engine WebKit which itself is based on KDE’s HTML rendering engine KHTML) is way better, especially in navigation, even although Opera Mini 4.1 caught up a little bit in comparison to Opera Mini 4.0. (Hey, and you hear that from a web browser fetishist and Opera fan!) The only thing which currently really bugs me on the builtin web browser is that even an enforced updating of my feeds sometimes just results in nothing. Maybe a firmware upgrade can help… As barcode reader, I have installed the i-nigma Reader. (The Quickmark QR Code Reader download just showed the content of something which seems to be a Windows DLL instead of downloading it. *plonk*) It’s amazing how fast the i-nigma Reader recognizes a 2D barcode from Semapedia on my laptop screen. Of course I also have ScummVM on my new Symbian phone. I will also play around with Amora which turns your Symbian S60 mobile phone into a remote control for your presentations on Linux (or any other unixoid operating system) running laptop as soon as I managed to get an amd64 Debian package of it. (Currently there seems only i386 packages and no source packages available, but this may be due to the “Show all downloads” link gives a server error…) Oh, and many thanks to foosel since I found Amora in her blog. BTW: Any recommendations for a free (preferably free as in DFSG) Jabber and/or IRC client for Symbian S60 3rd Edition? I already downloaded and installed Gizmo5, but somehow it refuses to work each time I try to create an Gizmo account. Accessories Since the E51 has no QWERTY keyboard, I ordered a Nokia SU-8W Foldable Bluetooth Keyboard at Brack. It was a little bit bigger and thicker than expected, but OTOH the metal case seems to be very stable and robust. Since this keyboard is designed to fit on Nokia mobile phones it also has the two Nokia typical soft keys and the middle select key. So nearly all phone functions can be used with the external keyboard, even turning off the phone’s key lock. Only locking the phone’s keys again doesn’t work via the external keyboard. Additionally I equipped my E51 with a 2GB microSD card. Probably a bluetooth headset for driving will come once, too. What the Nokia 6310i did better than the E51 There are a few things which are annoying regarding Nokia’s UI consistency over the years. That the backspace key is no more the right soft-key is ok. It took me only five tries to get my e-mail account setup without hitting the abort key (no “Do you really want to abort?” questions ;-) instead of backspace key. But what’s really annoying is that the menu navigation via number keys only works for the first level and no more for all levels. So no more “menu 4 4 4” to switch to manual network selection. It’s also annoying that you (or at least I ;-) can’t enter phone numbers as the recipient of SMS directly anymore, at least those SMS never reach their receipient neither do I get an error message. Same counts for the missing acoustic acknowledgment of locking the keypad. You only hear pressing the first key but not even the second key anymore. And if you press the volume keys on the side of the phone, you also have neither acoustic nor visual feedback if you pressed them hard enough so that the volume changed. The 6310i had visual and acoustic feedback. The alarm clock in the E51 seems to be artifically castrated: After having pressed the snooze button two or three times there is no more snooze button on the right the soft key anymore. With the 6310i you could press snooze as often as you want. Only disadvantage with the 6310i in regards of the alarm clock: the snooze time was much too long (10 minutes)… Oh, and what’s also annoying is that I can’t move over the whole addressbook of my 6310i in one piece but have to send each contact via bluetooth or infrared and then the E51 even get’s the contact names mixed up: ‘Beckert, Axel’ becomes ‘Firstname: “Beckert,” Lastname: “Axel”’… Great! I have to edit nearly all contacts manually… The cut and paste feature helps here, but it takes about one to two dozens of key clicks to copy the whole content of a filed into the clipboard… The E51 can run several applications at the same time and that you can switch between them any time. While that’s generally a nice feature I started using quite soon, it’s sometimes annoying that you have to wait up to a second or so after you’ve chosen some menu entry until you can do anything further. Also the screen often flickers while loading applications, showing them, then showing only the background, showing them again, etc. … but finally I already got used to the new mobile phone so much that I already have the feeling that my old 6310i became more thick since I have the E51. (Won’t think about how thick the about ten years old 6130 feels now compared to the slim E51… :-)

Steve Kemp writes about security issues with C programs [1]. It seems obvious that if you are going to do something that is overly tricky (such as anything related to setuid programs) then you should have a good knowledge of what you are doing. Steve goes a little further and suggests that anyone who doesn’t know C should not package a C program. Andrew Pollock is a Debian developer who doesn’t program in C and yet packages some C programs, he explains why he thinks that it’s correct to forward C coding bugs upstream [2]. In this debate I have more sympathy for Steve’s position. Security is one of the most important things in software that we develop, if you can’t develop secure software then IMHO you shouldn’t distribute any software. Although it should be noted that the two posts in question don’t directly conflict. Steve’s main point (your should know the code well to do something relevant to security) does not directly conflict with Andrew’s main point that a non-C coder can maintain the Debian packaging files and forward bug reports related to C code upstream. In the more general case it’s often impossible to know all languages used in a project. It’s not uncommon for a single project to have core code written in C, a configuration file format (which is a programming language), a Makefile (GNU Make is a fairly complex interpreter), Autoconf/Automake (even more complex tools for creating complex Makefiles, and then some Perl or Python to manipulate input or output data. The SE Linux project has code in all those languages plus the M4 macro language. It seems obvious that in a large project the number of people who are capable of understanding all languages which are used is going to be a small sub-set of all Debian Developers. It also seems likely that someone who knows some of the languages really well may be capable of doing a better job than someone who has a passable knowledge of all of them. For the vast majority of my work in Debian I have been a member of the upstream project in question (for Bonnie++, Postal, Portslave, Maildir-bulletin, and logtools I’m the sole upstream developer). Often I start maintaining a package with the intent of doing the minimum needed to keep it maintained in Debian but then end up doing upstream work, for example I briefly had write access to the CVS repository for pppd when I was maintaining it and I had write access to the KDE CVS repository when I was working on KDE packages (which incidentally was before I became an official DD). When I first started working on the SE Linux project I aimed to merely package the code in question for Debian. I was not planning on spending seven years doing upstream work! When I’m working on a project I spend my time working on the things that most need attention. That often means that I get diverted from Debian packaging bugs (which are often minor issues) to work on upstream bugs. In many ways my work practices make me a Debian user and upstream developer who also does Debian packaging rather than a dedicated DD. This of course does have a detrimental affect on the quality of my Debian packaging work - but overall I believe that it’s best for the users! As an upstream developer who is focussed on Debian there are significant advantages in being a DD. I can immediately upload a new package to Unstable without any delay, and there is the potential to take over a related package (either be given the package or NMU) if it’s the best way to get around a roadblock. Another benefit is that in certain limited situations I can speak on behalf of Debian (in terms of packages I “own”). When it comes to upstream development of SE Linux I can make decisions about how things will be done in Debian and work with other upstream developers to ensure that cross-distribution compatibility works reasonably well. It seems to me that a fairly ideal process for managing Debian development would have the people who are capable of the hard coding doing so and some people who haven’t got specific coding skills working on the packaging. I would be very interested in receiving patches related to the Debian packaging of the packages I “own” (in Debian it’s widely regarded that a man’s package is his castle) so that I can spend more of my time on the C coding. I’m not bothered about NMUs (a Non-Maintainer Upload - is when someone else uploads a new version of one of my packages to fix a bug). If anyone would like to NMU one of my packages they are welcome to do so as long as there is a suitable combination of bug urgency, simplicity of the fix, and lack of response from me. If someone wants to start NMUing my packages to fix bugs reported by the latest version of Lintian in Unstable (Lintian is the Debian tool to automatically check for packaging bugs) then that’s OK. Of course there are a variety of other situations that DDs sometimes find themselves in. There have been situations of overtly hostile upstream developers. I try and avoid associating with people who have certain difficulties in interacting with others. If someone is going to change their license and try to back-date the change or create a license that makes it difficult to distribute modified versions of the code then I’m inclined to avoid even using the software, let alone being involved in developing it. This means that the software that I use in any serious way has reasonable people doing upstream development who welcome new people to join their work.

• [1] http://blog.steve.org.uk/adopt_a_less_marital_tone.html


• [2] http://blog.andrew.net.au/2008/04/12#packging_requirements

Share This

Acme::Eyedrops allows you to 'design' your Perl programs (if you have any; you'd better not). Basically, given a Perl program and a "shape" file, it produces a perl program that visually resembles the given shape and behaves like the former program. Here's my favorite example:

    ''=~(        '(? '        .(' '         '%')        .('['        ^'-')
    .(' '         '!')        .(' '         ',')        .'"'.        '\\$'
    .'=='        .('['        ^'+')        .(' '         '/')        .('['
    ^'+')        .' '        .(';'        &'=')        .(';'        &'=')
    .';-'        .'-'.        '\\$'        .'=;'        .('['        ^'(')
    .('['        ^'.')        .(' '         '"')        .('!'        ^'+')
   .'_\\ '      .'(\\$'      .';=('.      '\\$= '      ."\ ".(      ' '^'.'
  ).((' ')     '/').').'    .'\\"'.+(    ' '^'[').    (' ' '"')    .(' ' '/'
 ).('['^'/')  .('['^'/').  (' ' ',').(  ' ' ('%')).  '\\".\\"'.(  '['^('(')).
 '\\"'.('['^  '#').'!!--'  .'\\$=.\\"'  .(' '^'[').  (' ' '/').(  ' ' "\&").(
 ' '^"\[").(  ' ' "\"").(  ' ' "\%").(  ' ' "\%").(  '['^(')')).  '\\").\\"'.
 (' '^'[').(  ' ' "\/").(  ' ' "\.").(  ' '^"\[").(  '['^"\/").(  ' ' "\(").(
 ' ' "\%").(  ' '^"\[").(  '['^"\,").(  ' ' "\!").(  ' ' "\,").(  ' ' (',')).
 '\\"\\ '.+(  '['^"\+").(  '['^"\)").(  ' ' "\)").(  ' ' "\.").(  '['^('/')).
 '+_,\\",'.(  ' '^('[')).  ('\\$;!').(  '!'^"\+").(  ' '^"\/").(  ' ' "\!").(
 ' ' "\+").(  ' ' "\%").(  ' '^"\[").(  ' ' "\/").(  ' ' "\.").(  ' ' "\%").(
 ' '^"\[").(  ' ' "\$").(  ' ' "\/").(  '['^"\,").(  ' ' ('.')).  ','.((' ')^
 '[').("\["^  '+').("\ "   '!').("\["^  '(').("\["^  '(').("\ "^  '[').("\ " 
 ')').("\["^  '/').("\ "^  '[').("\ "   '!').("\["^  ')').("\ "   '/').("\["^
 '.').("\ "   '.').("\ "   '$')."\,".(  '!'^('+')).  '\\",_,\\"'  .'!'.("\!"^
 '+').("\!"^  '+').'\\"'.  ('['^',').(  ' ' "\(").(  ' ' "\)").(  ' ' "\,").(
 ' ' ('%')).  '++\\$=" )'  );$:=('.')^  '~';$~='@'   '(';$^=')'^  '[';$/=' ';

First of all, congratulations Steve!
Debian Project Leader Election 2008 Results
The winner of the election is Steve McIntyre.

Security and languages
Meanwhile, Steve Kemp confirms my preference (prejudice?) that Debian maintainers and sponsors must have an understanding of the language used for their packages. (I do not maintain or sponsor KDE, Python or Mono packages for this reason - my C++ knowledge is too patchy to do more than a few queries of the apt C++ interface and I wouldn't understand a single line of python or mono source code.)
Andrew Pollock thinks that all C bugs are upstream bugs.
"Any bug in the software packaged is inherently an upstream bug, and the problem of the upstream author" - noting that he also has a good relationship with upstream and feels competent to apply and refit patches. I must say, I feel that this not something I could consider doing myself or recommending to anyone as sponsor.
Steve Kemp is naturally taking the security point of view and I fully agree that understanding the infamous Smashing The Stack For Fun And Profit (the code itself may need a few updates to work but it still explains the issues) is part of the job of any maintainer or sponsor handling a package that contains a setuid or setgid binary.
I'm upstream for some of my Debian packages and one, in particular, has known issues with static buffers which I inherited from the old upstream. Most of those have been removed but some are embedded a little too deeply into the codebase and it will take time to remove them all. (The ones I know about are tagged in the doxygen output of the source code.) My other programs use GLib dynamic string allocation / parsing instead of calling strcpy and friends directly.
I don't think it is fair or reasonable to maintain a package in a state that would require a new upstream release to fix a critical security bug. Equally, not being able to fix such a bug by creating the patch yourself (e.g. when upstream is not contactable) is also, IMHO, sub-optimal. (The security team are busy enough as it is without being required to write the patches as well.) As I've found with one of my own upstream packages, removing or protecting static buffers is not necessarily trivial and just extending the buffer is usually insufficient. Poor code design or code that is simply very old and stale can be hard to update. (Removing one static buffer required a patch/RCS commit changing some 300 lines in 6 source files during the development of one of my packages.) Changing the buffer behaviour can also cause mysterious bugs elsewhere - in the case of the package referred to above, inability to read or write its own data files and likely corruption of existing files. Thankfully, that application is never going to be one that needs setuid or setgid and is already in a much better state than it was in the Etch release so I'm working on fixing the other buffer issues but without the urgency that would otherwise be necessary.
I'm still learning about improving the security implications of my own code - I would certainly not be happy maintaining a package that uses a root process or a daemon that was written in a language that I simply don't understand, no matter how good my relationship with upstream. IMHO, the problem with security bugs is that the person writing the patch often has to understand the language and the package at a fairly deep level if the fix is not to cause bugs elsewhere in the application. Fixing a static buffer by breaking the application isn't good but then neither is leaving a Debian security bug open whilst waiting for upstream to create a suitable patch for your own Debian package. The problem gets worse if the security bug is architecture-specific or the fix causes bugs that only appear on certain architectures. There are some things that matter in Debian that simply do not matter as much upstream - if a security bug lands in that gap, the Debian maintainer must be able to solve the problem in Debian - at least, that is how I see it.

Limited Liability Partnerships are a relatively new company form here, but it has some interesting opportunities for cooperatives. I work for one (TTLLP) so I've gathered some useful links:- uniteddiversity LLP (some of those behind The Open Coop) Limited Liability Partnerships @ Co-opNet Chris Cook's web site appears to include contributions from 2amase's Bev Meldrum. At least I think it's Chris Cook's web site... 2amase LLP's web site forwards to http://www.thetoolfactory.com/Contact.htm which says they have a Plymouth office, but says nothing about their current status. They're listed on uk.coop and again Sticking LLP into the uk.coop search is amusing. Companies House - Formation and Names - GBLLP1 and Administration and Management - GBLLP2 The governing laws are Limited Liability Partnerships Act 2000 and BIM72505 - Partnership Act 1890 Any feedback you have on the above would be helpful. Anyway, hope that helps. Let me know how you get on with a comment, please, or if the new LLP needs a web site or hosting... ;-)

The latest news related to the Beijing Olympic games is that Kevin Rudd (our Prime Minister) has said “It is absolutely clear that there are human rights abuses in Tibet. That’s clear-cut; we need to be upfront and absolutely straight about what’s going on,” - stating the obvious really. If that was all that happened then it wouldn’t be particularly interesting. The paper version of “The Age” quotes George Bush as seconding Kevin Rudd’s statement. I believe that this is quite significant. Bush is well known for being stupid, the fact that he is now following the example of someone else who is doing good things is a very positive thing for the world. When John Howard was our Prime Minister we had an idiot (Howard) following an even bigger idiot (Bush) and the result was not good. Kevan Gosper (an Australian IOC board member) said “They just take their hate out on whatever the issues are at the time, and that hate against the host country is being taken out on our torch“. People who are totally corrupt sometimes seem confused when other people are motivated by moral principles, maybe we have a culture clash between the corrupt IOC board and the attitudes of most people in the rest of the world (I can’t think of any other way to map Kevan’s statement to reality). Mr Rudd has confirmed that Chinese “security guards” (soldiers) will not be permitted to operate in Australia to protect the Olympic torch from protesters, but the “security guards” have been operating in the UK. I read about this on the web site of The Age, but I won’t link to them because they have a lot of broken links with the following explanation - I am not going to link to sites that are so transient in nature (linking to The Age would lower the quality of my blog). Incidentally does anyone know of a news service in Australia that has reliable pages which stay online? We could not find the page you requested. This is often because older content has been removed from our site. In most cases you can still find the item via our archive service, News Store, where you can buy articles for a small fee. It also has the following text which indicates that the most visible problem is probably transient, but the fact that they deliberately break links is unacceptable to me: If you reached this page from a link on our site, please contact the webmaster (choose Technical faults) and tell us the address of the faulty page and the address shown for this page. The MSN article about the meeting between Bush and Rudd also had an interesting quote from Nancy Pelosi (speaker of the house in the US congress) [1]. She said “As I said in India last week where I met with His Holiness the Dalai Lama, if freedom-loving people throughout the world do not speak out against China’s oppression in Tibet, we have lost our moral authority to speak out on behalf of human rights anywhere in the world” and that the IOC made a mistake in awarding the games to China. Pelosi is not known for being left-wing (the US Democratic party is centrist/right by the standards of most democracies) so it’s interesting to see her take a stand on this issue. Erich Schubert has written about this, he points out that the Olympics are not about sports [2]. Well of course the Olympics are about money, drugs, and sports-science! I’m not sure that I agree with Schubert and Pelosi, the Chinese Olympics has focussed a lot of international attention on what China is doing - this has to be good for human rights. The Olympic games are a white elephant, running them costs a huge amount of money and there is no evidence that they actually make money for the host country once the opportunity costs are taken into account. Maybe we should give the Olympics to Zimbabwe or the Sudan next?

• [1] http://www.msnbc.msn.com/id/23845275/


• [2] http://blog.drinsama.de/erich/en/2008040901-boycott-olympia.html

Share This

I had an "Aha!" moment today when I came to a Wittgensteinian realization that while the sense of a piece of code corresponds to the formal behaviour of that code, the meaning of the snippet is the set of possible contexts where this code could be used. This idea has changed my view of teaching programming (I have been teaching Python in a local school for a couple months now). This attitude is nothing new, but for some reason I have not come across it, or rather, I have never seen it applied. (The fashionable problem-based learning thing has some similarities, but isn't quite it.) Having an idea to start from, it was not hard to find good articles expanding the idea. I especially liked Robert Strandh's short writeup on idioms and Elliot Soloway's Learning To Program = Learning To Construct Mechanisms And Explanations (1986). Experienced programmers will not learn much, but anyone dealing with CS education, teachers and students alike, ought to have a look. The moral is that emphasis should be placed on reading exemplary code ("experienced programmers do X this way") rather than definitions ("function Y does Z"). Programming seems to be closer to language use than to mathematics, and teaching methods should reflect that.

In my previous satire about SCO UnixWare, some SCO people of course didn’t think it was very nice. So, I guess I need to explain more about why I wrote the “review” the way I did. But, first the comment: Obviously any human being can recognize satire. There is obvious motivation on behalf of SCO’s PR department (correct me if I am wrong on where this comment originated; I did just some basic Google lookups, and also, this is a PR tactic known as “dead agenting”) to ignore the fact that this was clearly a satirical review. I would say, “perhaps SCO doesn’t understand why it is criticized,” but I believe it is obvious that they know why people are being critical and satirical of their company and their efforts. I would like for everyone to think, for a moment, about how things could be if SCO didn’t take the litigious strategy that they have taken over the past 6 years. SCO UnixWare could have remained a successful product, and could have in reality become a major asset to the open source world. SCO could have been the good guys here, but instead they chose a path of litigation instead of innovation. In the Open Source and Free Software world, innovation is what is seen as important. Companies may be in some sense rival to each other, but when it comes down to it, everyone appreciates and respects the work that everyone else contributes to the ecosystem. When people do not contribute in a positive way, or worse, betray their peers like SCO has done, it opens them up for criticism. As I see the situation, I think that SCO’s current tactics as a company represent those of someone who is paranoid. People who are paranoid attack first, instead of defend their position. So, while I am sure this is a pointless question, I believe it must be asked anyway: “What would SCO UnixWare have been like if they did not take a litigious strategy against Linux users?” If you look at it like this, it doesn’t really matter if we’re right, or SCO is right on who has the basic cases (well, it does, but we all know how that’s going to come out anyway). Why does SCO keep pursuing a strategy of litigation when the feasibility of this strategy is at best, unknown? To some extent, I think it is now a matter of morale. After all, it’s bad if you have to admit that the strategy you have taken for the last six years, was wrong. In some ways, you could say that SCO’s current strategy is cult-like. Furthermore, if any SCO people are interested in doing an interview about this whole matter, I encourage you to comment back, and I’ll be happy to publicize SCO’s viewpoint of this. It’s only fair.

Dear lazyweb: I claim to know quite a bit about the IPv6 theory, but I lack experience. I have a couple of hosts out there which are already properly IPv6-addressable and work, but I don t have a network scenario. Unfortunately, I also don t have a lot of time available for this right now. I was thus wondering if anyone of you knew of a document that explained the Debian way of

• how to add IPv6 to an existing network, using addresses determined from the IPv4 address.
• how to convert this into a network with custom addressing.
• how to connect this network to one of my IPv6-addressable hosts via a tunnel and set up the routing/advertising to make the hosts on my home network globally addressable.

I know of documents like Juliusz Getting IPv6 connectivity under Linux (linked from the Debian IPv6 project page, and of course the work by Peter Bieringer (with whom I ve worked previously), but I have not found a concise explanation of how to set it all up with minimal hacks on a Debian system. If noone has such a document, I might have to bite the bullet. Ping me if you want to cooperate. Let me know! NP: The Phoenix Foundation: Pegasus Update: From Waikato, Matt Brown sent this howto on 6to4. I sent back a small number of corrections and hope he ll incorporate them soon. On a related note, I am making good progress getting my Debian systems linked up to the future. I used the excellent SixXS tunnel broker to route 2^80 addresses to my home router and set up another tunnel to one of my native IPv6 hosts in the net. I also added 6to4 to two of my servers. This should give me enough for further experimentation, and eventually for netconf testing. I ve been keeping notes and you can expect a document with simple explanations for everything that I did. But before that, I want to get behind some kernel bugs related to netfilter, such as state INVALID matching valid packets in kernel 2.6.24 and before and conntrack failing to treat ICMP replies as RELATED with kernels 2.6.18 and 2.6.22. The latter seems fixed in 2.6.24, which isn t backported yet, but which we can expect to be in Etch-And-A-Half and Debian lenny. Stay tuned

OK, been quiet for a few days, at least on the blog, but in accordance with typical behaviour (for me at least) a quiet blog means a lot of things going on elsewhere. The smallest was a fix for deb-gview - combining a fix for opening files in the current working directory with a fix for the imminent dpkg 1.14.17 which modified the .changes file format a bit. That was relatively easy and I've uploaded 0.2.1 to unstable. gvfs hasn't made testing yet so there's no point in waiting for deb-gview to migrate before 0.2.1.
The largest change? Depends how you define large:

1. Large number of changes to package files - emdebian-tools 1.0.0
2. Large effect on Emdebian workload - dpkg 1.14.17

dpkg
dpkg bugs closed - emdebian-tools 1.0.0 pending - dpkg-shlibdeps is now able to look into directories containing libraries used by cross-built binaries provided that the right environment variable are set. Closes: #453267. dpkg-buildpackage will set PKG_CONFIG_LIBDIR (but not override an existing value) in case of cross-compilation so that pkgconfig finds .pc files in the directory specific to the target architecture. Closes: #439979.
These two changes will have a major effect on the overall workload required within Emdebian and give us a sane cross-building environment in Lenny which is ABSOLUTELY $^ @&*! FANTASTIC. Currently, 1.14.17 is in experimental but I've installed it on my system for testing purposes so that I can complete emdebian-tools 1.0.0:
emdebian-tools 1.0.0
Now here, I'm making some progress. A bug has been bothering me for some time with how emdebian-tools needs a Debian primary mirror to calculate various dependency information and other apt cache stuff whilst taking into account the host architecture. Simon and I now think that we can do the dependency stuff with a continually updated dpkg-cross repository and I can use libcache-apt-perl for the rest. So whereas dpkg-cross might still exist into Lenny, it is looking like apt-cross might not - at least not as an application. However, I'm not taking that step with emdebian-tools just yet. In the meantime, I'm simply using debconf to replace the automated selection of a Debian Primary Mirror and passing that mirror to apt-cross - something I should probably have setup a while ago.
As well as that bug fix, I've added a check to emchain so that users are warned if they don't actually need to run it, added the mirror support to the various scripts and removed the workarounds now fixed by dpkg.
'dpkg-buildpackage -a' is usable for nearly all packages once you have dpkg-dev >= 1.14.7. emdebuild >= 1.0.0 is only necessary IF:

1. You want to modify/update Emdebian patches (not just apply them) - i.e. if you have commit access to Emdebian SVN.


2. You need the one remaining wrapper: 'X-Build-Cross-Libtool: yes' which is my next main target. This is a package-specific problem and each incidence needs a package-specific solution via an appropriate patch. As such, the wrapper is likely to stay in place in emdebuild for some considerable time - at least until someone can rebuild the entire archive with a test that can identify which packages are still affected.


3. You want the build checks currently implemented by emdebuild but which I plan to spin out during the life of emdebian-tools 1.x. I want to standardise those build checks and abstract them into possibly a lintian-compatible check set.

Also, there should now be no need for any wrapper scripts that anyone may have devised to mangle LD_LIBRARY_PATH or PKG_CONFIG_LIBDIR - indeed,
explicit support for these within dpkg means that it is to be considered harmful from now on to touch these variables, except possibly in some specific corner cases.

Via Lifehacker, legal cost-free books under copyright from Wowio. This is a great idea, and I give it even odds for being the future of books. (Or at least, part of books’ future).

What is WOWIO?
WOWIO is a new kind of online bookstore that enables readers to download ebooks for free, using commercial sponsorships to compensate authors and publishers. Readers get free ebooks. Sponsors get a powerful new channel to communicate their message to precisely the people they want to reach. Publishers get a new means of distributing their books, expanding their readership, and monetizing their intellectual property.

Does WOWIO use any kind of digital rights management (DRM)?
Since anyone can defeat the most “sophisticated” DRM with the print screen button, we believe that technology-based DRM is essentially a fraud. Our approach takes the market incentive out of misbehaving, rewards people for doing the right thing, and tries to stay out of the way of honest users. To help keep everyone honest, however, readers must authenticate their identity and agree to a licensing agreement when they set up their account. Then, each ebook is serialized with the reader’s authenticated name and a unique serial number, as well as other less visible markers. WOWIO will immediately terminate the account of anyone caught illegally distributing ebooks, and will prosecute serious offenders.

Technorati Tags: Wowio, Books, DRM, Digital Rights Management, Copyright

Share This

Due to falling behind a bit I quickly uploaded the latest upstream of the 96.43.05 and 71.86.04 legacy packages. They have very little changes in terms of bug fixing.

I switched from Pine to Mutt as my primary email client around the time I decided to become a Debian developer, because Pine's PGP support was abysmal (it also beat building Pine packages by hand all the time). The other bonus feature was it threaded emails, which made it easier to follow mailing lists. It's been a very gradual learning process since I switched, and I certainly don't consider myself to be a Mutt power user. I initially really hated it, I think largely because of the concept of "old, unseen" messages, versus "new" messages, and the behaviour of the Tab key. Once I unset the mark_old variable, it got a lot more tolerable. I think at some point I either plagiarised someone's .muttrc from the Internet, or sat down with the manual (or possibly a bit of both) and came up with a config that I could live with, and it's been workable ever since. One problem I (more recently) started having was that when I had 200-odd unread emails in my inbox, which has been pretty common occurrence in the last couple of years, and someone replied to an email in an old thread, because I wasn't necessary scrolling through all 200-odd emails (as new, unthreaded emails usually sorted chronologically at the bottom of my inbox), I'd miss the fact that the email had arrived, often for extended periods of time. I was lamenting this problem to Sarah over dinner last night, and saying how I preferred Gmail's behaviour, where the position of a thread in the inbox was determined by the date of the most recent email in the thread. I figured Mutt must have a sort option to be able to deal with this, and so I went rummaging in the manual last night, and discovered the sort_aux configuration variable. I've set that to last-date-received, and now I'm very pleased. I should never miss an email again. Of course, I should really try practising Inbox Zero, then it wouldn't be an issue.

In case anyone out there is using my dcmd script, I'll note that it's now included in devscripts (starting with version 2.10.20). The devscripts version doesn't behave differently when called as dscp or drsync, I have the following aliases to get the old behavior:

alias dscp='dcmd scp'
alias drsync='dcmd rsync -av'

As always, feedback welcome.

The first democratic elections were held in Bhutan yesterday. This is an important step on the transition from absolute monarchy to constitutional monarchy, for the small himalayan kingdom which I already blogged quite a lot about. Sorry for that, I fell in love with that country. The 47 seats of the National Assembly were to be filled in by a two-round vote: voters first vote for parties (two of which registered: DPT and APP). The two winning parties (well, there were only two, so....) then field candidates in the consistuencies. As anyone can see, there's still some work to do to reach the democracy we all experience in the so-called western countries. As usual, this is the bhutanese way to do things: slowly, at their own pace, but consistently. Just compare this with their giant northern neighbour who's currently in the news for their democratic behaviour in Tibet... Ass BBC News says on their web site, "At a time when the future of democracy is uncertain in several countries in South Asia, Bhutan may be heading in the right direction.". And, remember, we're talking about a country who made the choice of Free Software, also..:-)

Zack, Wouter: Yup, Perl 6's scheme changes to reduce confusion to the programmer and to make the language better Huffman coded. Why?
As for the programmer, it comes out of observation - Changing the sigil depending on what you are expecting to get back (i.e. a hash has a '%' sigil, but if you only want one value off it, you use the '$' sigil, as it indicates a scalar variable) confuses more often than it helps - Specially newcomers. Besides, it will be easier for the interpreter itself - The sigil will become an invariant but required part of the variable name itself. Hence, Martin will be happier, as there will no longer be different namespaces under which to store your variables. Oh, BTW, Martin: Not only Perl behaves this way. Ruby also uses that concept - There, you have local variables (no sigil), instance variables ('@'), class variables (ugly '@@') and global variables ('$'). I remember in old (Quick GW)BASIC you had numeric variables (no sigil) and string variables (postfix sigil '$') as well. Any others?
Now, about the Huffman coding part, WTF?
It is one of the design goals of Perl 6 to make the most often used operators be the shortest, so you, programmer, don't wear out your keyboard and lose your valuable fractions of seconds typing i.e. '->' for a method call when you can just type a '.' - Similarly, currently you have to type too many characters for the (too common) dereferencing - If you have a reference to a hash of arrays of arrays of objects on which you want to call methods, you have to do $something-> key [0][0]->boo - Whereas with Perl 6 you will only have to do $something key [0][0].boo
Anyway, I cannot elaborate much further, as I've been -at best- just a bystander. But yes, large changes loom in Perl's future. Let see what comes on...
And when. Sigh.

One of the challenges maintaining the Debian archive kit (dak) is dealing with Debian-specific requirements: fundamentally because there are a lot of them, and they can get quite hairy – yet at the same time, you want to keep them as separate as possible both so dak can be used elsewhere, and just so you can keep your head around what’s going on. You can always add in hooks, but that tends to make the code even harder to understand, and it doesn’t really achieve much if you hadn’t already added the hook. However, dak’s coded in python, and being an interpreted language with lots of support for introspection, that more or less means there’s already hooks in place just about everywhere. For example, if you don’t like the way some function in some other module/class works, you can always change it (other_module.function = my_better_function). Thus, with some care and a bit of behind the scenes kludging, you can have python load a module from a file specified in dak.conf that can both override functions/variables in existing modules, and be called directly from other modules where you’ve already decided a configurable hook would be a good idea. So, at the moment, as a pretty simple example there’s an init() hook invoked from the main dak.py script, which simply says if userext.init is not None: userext.init(cmdname). But more nifty is the ability to replace functions, simply by writing something like:

# Replace process_unchecked.py's check_signed_by_key
@replace_dak_function("process-unchecked", "check_signed_by_key")
def check_signed_by_key(old_chk_key):
    changes = dak_module.changes
    reject = dak_module.reject
    ...
    old_chk_key()

That’s made possible mostly by the magic of python decorators – the little @-sign basically passes the new check_signed_by_key function to replace_dak_function (or, more accurately, the function replace_dak_function(...) returns), which does the dirty work replacing the function in the real module. To be just a little bit cleverer, it doesn’t replace it with the function we define, but its own function with simply invokes our function with an additional argument to whatever the caller supplied, so we can invoke the original function if we choose (the old_chk_key parameter – the original function takes no arguments, so our function only takes one). Right now, we don’t do much interesting with it; but that should change once Ganneff’s little patch is finished, which should be RSN… Hopefully, this might start making it easier to keep dak maintained in a way that’s useful for non-Debian installs – particularly if we can get to the point where hacking it for Debian generally just implies changing configuration and extension stuff – then we can treat updating all the real scripts as a regular software upgrade, just like it is outside Debian.