Have you ever gone monastic, taken a step away from the rough tumble of life to throw yourself totally and completely in one or just a few things? I have been in this state a few times before, sometimes by my own volition, other times I was forced into such state, as when I spent nearly a year homebound, sick. The last time I went monastic, I did so to finish my dissertation in 2005 and it worked rather well. In fact, I recall those few months where I barely left home (and as result my PJs) with deep fondness. I just loved the intensity and simplicity of it all, which is why I loved my other periods of self-enforced solitude/simplicity and often yearn for those moments again. The pile of writing projects I am trying to complete (or start) are mounting and honestly, I want the pile to move from a mountain to at least a hill and in order to do so, I think I will have to retreat. So tonight, I declared that upon my return from PR, I will once again go monastic but given that I have a pretty demanding full time job, I can t really go full-on monastic. I can only go semi-monastic, shirking some of my extracurricular activities and duties but I still think that I can enter into a more seclusionary (I know not really a word) mode than has been my life for the last year. I will report back in a few months with a story of success or failure about entering Monastic Mode x

Well, I got the Dell Mini 9. Tiny little toy-looking laptop. It's too soon to tell if I'll like it. Or if my goal of using this as my only laptop, and primary work machine will succeed. But what a lot of firsts and changes! My first laptop with no moving parts. Yay! My first completely silent laptop. Double yay! First laptop I've bought with linux preloaded. The default Ubuntu load was ok. It also contains my name 886 times. :-) Scarily, it also runs bits of code I wrote for base-config. Installing Debian went ok, mostly, though wireless is a bit of a pain, and I have a strange problem with something fiddling with LCD brightness periodically. Oh, and SHDC cards make it crash on boot and resume. I've set up a page with the details, including how to fix the missing punctuation keys. I've switched to using white on black for my terminals, and run them full screen rather than tiled. Cause the screen is small, and doesn't handle large black expanses as well as I've been spoiled to expect by machines that cost three times as much. I like that netbooks encourage minimalism.

today: illegal graphology ; tomorrow: illegal facebook query Join two dots and obtain a line. The first dot. A few days ago, on the blog of an italian journalist I've found a reference to an old article about facebook originally from the guardian (even equipped with an italian translation, just in case ...). The article is quite long, but I found it a worthy read. (Well, at least it is one assuming you can skip over the initial rhetoric about "social networking = autistic geeks". Similar arguments were as annoying as untrue already 10 years ago about the Internet, and even more so 20 years ago about role playing games.) In the article you can find interesting facts about who are the creators of facebook and even more interesting ones about who has been more than happy to finance it more recently. All is topped with a fun re-reading of facebook's "privacy policy". The second dot. This late afternoon, speaking with Ralf in the lab, I got introduced to the practice of some companies to ask for an hand-written curriculum vitae as a regular practice to be considered as a candidate. Why so? Well, because they can then ask a graphologist to draw a psychological profile and take a more "informed decision" about whether to hire you or not (assuming you believe in graphology, of course). Sure, it's illegal. But still it seems to be common practice in Japan and a not yet completely vanished practice in specific employment fields in France. The line. Guess what? Tomorrow it will become easier (and already is for all the places where the facebook penetration is sky-rocketing): instead of paying a graphologist for a (possibly inaccurate) profile, you can just pay the faceboook guys to get a record of a lot of your private life wanderings, pictures, past relationships, ... Sure, it will be illegal. But still ..., and it will be way more efficient! I'm every passing day more and more proud of having closed my facebook account more than 1 year ago (and trust me: closing a facebook account ain't easy).

---

Now, anyone of you can drop by on my homepage, spot a shiny linkedin logo, and call me a cheap talker. I'd concur that in a sense every social networking has bad privacy implications, but that's trivial, we all know that. Still, I think linkedin is somehow better. Why? Because it is specifically geared toward professional information. While giving information to them, I'm usually thinking about my professional "figure" and I've high barriers that are likely to inhibit me to leak personal information, or at least make me think about that. On the contrary, with facebook you have low barriers and you are encouraged to provide personal information, and that's exactly the point of the facebook owners. (And here I'm even assuming you do have some barriers while providing information to facebook, which I'm convinced is not the case for most of its users.) I see a parallel with the early days of blogs, where the euphoria of blogging made a lot of people mistaking their public blog with their personal diary; stuff which will strike back. While experienced bloggers develop defenses against the initial foolish attitude, people do not develop similar defenses on facebook, because that defenses will defeat the purpose of the network.

I am quite sad to announce that I am discontinuing Adept development for good. Since Kubuntu will be changing its default manager to KPackageKit (I wish everyone involved good luck), I have no further motivation to work on Adept at all. I have mostly done the 3.0 overhaul since Jonathan Riddell is my friend, and I like to make my friends happy. However, since this is no longer a factor, and my time is likely better invested elsewhere, I am giving up altogether. Of course, if anyone steps up for maintainership, I will happily delegate Adept to them. It is in a relatively good shape these days, I hope. I will keep the source (darcs) repositories around as long as reasonably possible. If you are interested in taking over, even despite the Adept userbase declining sharply in near future, please drop me a mail. With Adept goes also libept, a more general-purpose library for working with APT. I will be around when people need me to fix it, but won t add anything on my own. I am not even sure what is Enrico s status on libept, but probably just consider libept as good as orphaned, too. On a more personal note, this closes a long (very long) chapter in my free software life. I d like to thank everyone involved with it, there have been many of you. Moreover, this apparently cuts the few remaining ties I had to KDE development community I will miss you. well, maybe one of those days UPDATE: No, this does not mean I am no longer friends with Jonathan. I don t know why, but already two people managed to read it that way. To put it in hopefully less ambiguous words: The fact that Jonathan is my friend is no longer a factor just because he does not need Adept anymore. Hope that helps.

The monthly board meeting of SPI will take place on irc.oftc.net #spi tonight (Wed 17 Dec) at 20:00 UTC. As it says in the meeting announcement, none of the officers have prepared their reports in advance and there are no proposed actions, so I guess it ll be a very short meeting. Disappointing. Watch the comments below this article for a link to the summary when posted.

I'm posting way too much to debian-vote right now, which I realize and which I'm going to try to cut back on. (I at least did start the lintian.d.o upgrade process today, so I got non-discussion Debian work done.) The reason why I keep reacting, though, is that I'm finding it frustrating that people seem to be asking the wrong question for resolving the firmware freeness argument. We currently have a strong disagreement over what the implications of the Debian Social Contract and DFSG should be for our release process. Some Debian Developers believe that releasing lenny as-is requires a special exception to the Social Contract. Some Debian Developers believe that releasing lenny as-is is consistent with the Social Contract. We've tried and failed to achieve consensus. That's the first point of my frustration: some people don't seem willing to accept that this has happened. They are apparently having a hard time understanding how anyone couldn't agree with them, and are therefore repeatedly reopening the discussion on which we don't have consensus. Once it's clear that consensus doesn't exist, this is very counter-productive. The discussion is futile, which frustrates people, and then in that frustration they become increasingly angry and harsh. Once consensus fails, all interesting decision-making processes start. A decision-making process basically reduces to "who decides?". When you have a dispute and consensus is not possible, some body has to make a decision. If people believe in the decision-making process, they can then support, or at least live with, the decision because they respect the process, even if they disagree with that particular outcome. The most important output of a decision-making process is closure: you stop debating and move on. If that doesn't happen, the decision-making process has failed, even if it makes a decision. Why does this all matter and why am I going on at such length about it? It's simply this, which I think is so important I'll highlight it:

Even people who strongly disagree on some issues can work together cordially and well in the same project provided that they can agree on a decision-making process in those areas where they disagree.

Agreeing on how decisions are made in Debian is important because that's how we continue to work together when we disagree (and we will disagree). If we can agree on how disputes are resolved, we can all respect and honor the outcome even if it isn't what we would have wanted, and then move forward. If we don't agree on how disputes are resolved, we'll keep re-arguing them rather than accepting the outcome. The discussions will get more heated, more people will get upset, and more people will not have fun working on Debian. What I've been trying to analyze on debian-vote is the "who decides" part of this question. We have a decision-making process outlined in the Debian constitution for non-technical decisions (of which this is one). That process is somewhat scattered through the document, but bringing it together in one place, it seems to go like this:

1. Developers are empowered to make decisions about their own work. That means that, according to the constitution, the primary people who get to decide how the SC and DFSG should apply are every Debian Developer in the tasks on which they're working.
2. The project leader can define an area of ongoing responsibility and delegate to a developer or a group of developers responsibility for making decisions in that area. There are two relevant delegations here. The ftp team has the delegated authority to determine what packages may enter Debian given, among other things, licensing and DFSG issues. The release team has the delegated authority to decide what goes into the next stable release and when that release happens. (Let's put aside quibbles over whether or not that authority was formally delegated; I think that we can all agree in practice that it's close enough.) The ftp team has accepted the relevant firmware packages into Debian main and hence have made a decision in their area of responsibility. The release team, through the lenny-ignore tag, has decided that the relevant packages can be part of the next release. Those are delegate decisions that have already been made, and neither of those teams seem to want to change their mind.
3. The final decision-making body in this case, therefore, is the developers at large, who can override any delegate decision via a GR. That's what Robert Millan proposed, although he doesn't seem to have realized he was doing that, and it's not marked as such on the ballot.

Now that this has happened, we all vote whether or not to override the delegate decision. The only option on the ballot that does so, by my reading, is the first one, so if the first option does not win the GR, the delegate decision is not overridden and both the ftp-master and release team decisions stand. This is why Further Discussion means we continue the release as previously planned. We have a decision-making process, which has been followed, and the current decision is to release including those packages. In order to change that decision, it has to be overridden. A result of Further Discussion on a GR means that GR does nothing, and hence the decision stands. The second point of frustration is the decision that option four on the ballot (delegate to the release team the power to make decisions about how DFSG issues affect what is included in the release) needs a 3:1 majority. They have already been delegated the authority to do that as part of their delegated authority to manage the release. The effect of option four on the project is therefore identical to Further Discussion; the only difference is whether we make a positive statement or fail to make a negative statement. It makes no sense to treat it as supersession of a foundation document when it just supports the existing decision-making process in the constitution. A third point of frustration is the apparent feeling that foundation documents like the DFSG are outside of the normal decision-making process described in the constitution. I can find no evidence of this in the constitution, but more fundamentally, the people arguing this are not stating what decision-making process they believe does apply other than "my view of the DFSG is obviously the only reasonable one and hence you should follow it." This reduces to a plea for consensus, which we've already established that we don't have, and hence, as mentioned above, is horribly unproductive to keep raising. There will never be a policy document that is so clear that everyone will agree on its implications in every situation. I find it much more useful to analyze governance processes by looking at who decides disputes rather than looking at position statements. The decision-making process is what will determine the outcome of all the really interesting cases.

I used to run a website for traveling by rail in the United States. I let it falter, and eventually took it down. But I still have the domain, and am working to bring it back as a wiki. The first step in that process was selecting which wiki software to use. I have a few requirements for the site:

• Availability of both WYSIWYG (friendly for beginners) and non-WYSIWYG editors
• A number of nice-looking themes to choose from
• Nice to have: a hierarchy or category system
• The ability to search within only a particular section or category in the hierarchy
• Easy to maintain software; not having tons of plugins to keep up-to-date for security
• Stellar spam prevention
• Nice to have: ability to redirect people to the new page after a rename

I m frustrated that there is no wiki out there that does all of these. There are quite a few that do all but one, but which one they omit varies. My two finalists were MoinMoin and MediaWiki. MoinMoin MoinMoin will let you easily define arbitrary categories (by creating a wiki page following a certain name). The search screen automatically presents checkboxes for restricting searches to a particular category. Some reviews have complained about its anti-spam features, but they are all talking about older versions and they seem to have done some work on this lately. MoinMoin has tons of features and is easy to set up and maintain. But here s where it falls down: themes. Over at moinmo.in, there is a theme market for themes. Only most of the themes there haven t been compatible with the current MoinMoin release since about 2005. Most of the rest have one download, then a long discussion page full of mixed bug reports, diffs, and non-diff edit this to make it work comments. Most of these don t state what version of the theme they apply to. Most themes won t work with current browsers and Moin releases without them. UGH. After discussing on #moin, I ll probably go in there and at least organize the ThemeMarket page by release. MediaWiki Then there s MediaWiki. It s got a lot of features, and a lot of complexity. It has no current WYSIWYG feature, though apparently there is work on one. MediaWiki has an amazing category system. It can generate sorted lists of pages in a category, supports subcategories, etc. Surprisingly, though, you can t search in just one category. (Though it might be possible indirectly via some syntax; not sure.) Searching in MediaWiki overall is less capable that in MoinMoin. MediaWiki does offer namespaces, and namespaces are the sole way of searching just one part of a site. They re used well over at, say, uesp.net. But namespaces are heavy-handed. You have to edit config files to define them, and they bring with them other associated namespaces for discussion and whatnot. It s not as easy as creating a category in MoinMoin, and might not scale well to lots of future categories. MediaWiki does appear to have good spam prevention, and support recaptcha. Conclusions I eventually selected MoinMoin and have set up most of my content in it. But now that I am to the point of selecting themes, I m having some second thoughts. I also looked at DokuWiki. Its design makes me nervous. The user list is stored in a single file. You can t search by category. You can search by namespace, but there aren t checkboxes for it in the search screen; you have to know the syntax. WYSIWYG is a plugin. Categories are a plugin. So too many plugins to maintain, and no real features above MoinMoin.

Rich Owings of GPS Tracklog offers advice on must-have and less-worthwhile features for an automotive GPS. I ll slightly dissent from Rich on the value of traffic information, although of the units I ve used the Dash Express has the only helpful implementation* of traffic I ve found so far and with Dash leaving the hardware business it s not clear that anyone will be filling the gap in the future although TomTom s HD Traffic is allegedly headed stateside in 2009. * Virtually all of the existing products focus on Interstates and other freeways, which might be helpful in really big cities where there are multiple freeway routes to the same destination, but isn t so helpful in the places I ve lived where the question is not which freeway should I take? but should I take the freeway or one of the 2 3 surface street options? Dash at least has some data on traffic on the surface street network but much of it relies on Dash getting more market penetration, which seems unlikely unless they ve hooked up with a major player like TomTom to provide traffic services going forward.

Following my previous post, today I began to turn my brand new Asus EEE PC 901 into a Debian Machine. At first I wanted to do all in one day, but since work is taking too much out of me (and everything seems to take more time than expected), I ll have to split this in different days So, first things first. I read Debian Wiki on the issue and began by doing the most important: backing it up. So I got a daily netinst iso, put it on a USB Pendrive and followed the tip on backup over the network using netcat. Easy and effective, and took only 8 minutes on the 901 (I think the 35 minutes described on the wiki were for models with slower NICs). From there, I had to decide which version of the installer I d use. I chose Standard, since I want an encrypted disk on my EEE. So I run the installer and, on the partition manager, I deleted /dev/sda1 (where Xandros was installed), turning it into a 300 MB /dev/sda5 (to use as /boot) and a 3 GB /dev/sda6 building a Logical Volume over an LVM Volume Group with it and /dev/sdb1 (where the user directory was), and enciphering it. This took a long time, since, I believe, random data were being written to the device to increase crypto strength. I left /dev/sda 2,3,4 as they were, since they can belong to the Asus EEE Recovering System (and they don t take too much space :-) ) Now base system is installed, and wired network works like a charm Next steps will have to wait until tomorrow.

I'm pleased to make Emdebian Grip unstable available - a smaller, binary-compatible, Debian without manpages, without unwanted translation files (uses Emdebian TDebs) and without package documentation. The current packages will be migrated into Emdebian Grip testing in due course and then be released alongside Lenny.
Emdebian now has two flavours with Grip taking the intermediate position in terms of size whilst retaining full compatibility with Debian. Grip "cherry-picks" packages from Debian but retains the unchanged Debian sources - the main binary and library packages will exist but -dev, -doc and -dbg packages may well be missing, as well as some of the more unusual OR dependencies).
I've just converted my Acer Aspire1 (i386) - running XFCE - from Debian Lenny to Emdebian Grip:
607 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 184MB of archives.
After this operation, 278MB disk space will be freed.
Yes, update 600 packages and have nearly 300Mb more free space - that's a 400Kb space saving per package, on average. Gaining 90Mb more free space than the total size of the download is nice too. Comparisons are after using 'sudo apt-get clean' to remove downloaded archives:
Debian Lenny:
/dev/sda1 7.1G 1.2G 5.6G 17% /
Emdebian Grip (unstable)
/dev/sda1 7.1G 919M 5.8G 14% /
I make that about 25% smaller and not all packages installed on the machine have been "gripped" - (about 100 remain, many of which I should probably remove anyway).
Method: See http://www.emdebian.org/grip/index.html.
Add the Grip source to /etc/apt/sources.list.d/
deb http://buildd.emdebian.org/grip/ unstable main
$ sudo apt-get update
$ sudo apt-get install grip-config
This is a very important stage - Emdebian Grip is still in development and with the Lenny freeze, a few wrappers and helpers are needed to allow smooth migrations between Debian and Emdebian - grip-config is Architecture:all and contains the relevant scripts. (grip-config is Priority: required so debootstrap picks it up by default - this also means that grip-config cannot be part of Debian.) grip-config also includes the same key as the emdebian-archive-keyring package used by all Emdebian repositories.
Only after grip-config is installed should you use:
$ sudo apt-get dist-upgrade
Note that this is a complete replacement, including libc6, apt, coreutils, dpkg and (on i386) the stock kernel. As such, it can take a while to complete the installation once the download is complete. (As ever, if the kernel is updated, ensure you reboot before you next suspend to disk - even the minimal "gripping" changes to the kernel package may confuse grub when deciding whether to use the suspended image.)
A few packages are currently behind Debian Sid (notably ncurses) and I'm working on the scripts to enable full update automation.
One other problem is that /usr/share/locale/locale.alias has also disappeared which compromises localisation support right now but that's fairly easy to fix. (langupdate is also missing so there is no effective localisation support right now - I need to cross-build langupdate for the grip architectures.)
Note that this test install adds the Emdebian Grip repository to the existing Debian sources and relies on the em[0-9] version suffix to implement the upgrade - packages that are behind Debian get left at the Debian versions, you can also use normal pinning.
$ apt-cache policy
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://buildd.emdebian.org unstable/main Packages
release v=0.1,o=Debian,a=sid,l=EmdebianGrip,c=main
origin buildd.emdebian.org
500 http://ftp.uk.debian.org sid/main Packages
release o=Debian,a=unstable,l=Debian,c=main
origin ftp.uk.debian.org
Pinned packages:
I've done some testing with debootstrap and a chroot works too - it should be possible to ally these packages with the normal Debian installer because there is no point "gripping" udebs that are already v.small and the packages that actually get installed are dictated by your choice of mirror. debian-live should be gaining support for Emdebian Grip in due course.
If someone fancies trying a test installation by choosing http://buildd.emdebian.org/grip as their mirror in d-i, let me know.
(Installing Grip is likely to result in further size gains as the Grip repository data does not support Recommends, so you don't have to try and get d-i to not use recommended packages).
Emdebian Grip (unstable) is now available for 7 architectures:
i386, amd64, arm, armel, mips, mipsel and powerpc.
(amd64 is only supported for debugging purposes, most of my development machines are amd64.)
Please report any and all bugs to the buildd.emdebian.org pseudo-package in the Debian BTS.
If you want more packages added, set up a Debian machine or chroot with all the packages you need (and only the ones you need) and send the
complete output of 'dpkg --get-selections' to the debian-embedded mailing list. Alternatively, file RFP bugs against buildd.emdebian.org at wishlist severity.
To see the current list of packages, use the search support
Headline packages:
coreutils, perl, python, apt, dpkg, grip-config, XFCE, debhelper, make, devscripts, sylpheed, iceweasel, drivel, xchat-gnome, gpe-tetris,
totem-gstreamer, liferea, thunar, evince, seahorse, gthumb, libsqlite3, pilot-link, python-gnome2, lua, tcl, gcc-4.3, binutils, libmysqlclient15off.
Currently, very few -dev packages exist in Grip. I'll make the emdebian-grip package available on Grip itself in due course so that new and bespoke packages can also be "gripped".
I'm migrating the current packages to Emdebian Grip testing soon and I'll be making a release of Emdebian Grip 1.0 (based on Debian 5.0 "Lenny") as well as Emdebian Crush 1.0 (based on Debian 5.0 "Lenny"), alongside the main Lenny release.
Finally, note that Grip is binary compatible with Debian - indeed, the binaries themselves are untouched - but bugs that appear in Emdebian Grip must only be filed against the buildd.emdebian.org pseudo-package. Right now, reportbug is not part of Emdebian Grip because I need a way of telling reportbug to only use the pseudo-package.
The main usability improvements will come in the development of Emdebian 2.0 (based on Debian 6.0 "Squeeze") - please consider Emdebian 1.0 as a "developer release", think back to what things were like with Slackware 1.0 or Debian buzz, rex or bo.
P.S. there is no concept of a release-critical bug in Emdebian Grip (at least, not yet) - the 1.0 release will happen as soon as Grip testing is in sync with the released Lenny (no matter what). Please do not file any bugs against buildd.emdebian.org with higher severity than important, it will just annoy people trying to fix RC bugs in Lenny.
If you are a maintainer in Debian and you inadvertently receive a bug report listed as 'found' in a version that ends in em[0-9], please reassign to buildd.emdebian.org, at severity no higher than important. Thanks.

So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others. SSD disk I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it s the second generation of Samsung SSD) and I m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds. X server The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It s possible to force the usage of the intel driver by adding a Driver intel line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn t use the Keyboard section of xorg.conf. You have to create /etc/hal/fdi/policy/10-keymap.fdi by using /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi as template and reload HAL then restart X. Wifi support The Intel 5100 Wifi chipset requires Linux 2.6.27 at least for the new iwlagn driver. This driver also needs a new firmware (the iwlwifi-5000 one) that is not yet integrated in the non-free package firmware-iwlwifi (see #497717). Sound support It works ok with alsa and the version integrated in linux 2.6.27 but it still has some rough edges when used in combination with the dock. Using the output jack connector on the dock doesn t stop the output in the integrated loudspeakers and the volume on that connector is so low that you could think that it doesn t work at all if you don t pay attention. Using the microphone works fine. For reference, if you play in the mixer, Front mic means the microphone connected on the dock while Mic means the one connected on the laptop. Each Analog loopback X option goes pairwise with the corresponding Input source X setting. In order for the recording to work, I have to set Digital Input Source to Analog Input , Digital must be activated and Input source 1 defines the default input used for the recording. Bluetooth support Contrary to the previous laptop, Dell offered no choice on the bluetooth chipset, they only propose the Dell 365 Bluetooth Card so I took it but it doesn t seem to work out of the box. In fact I can t even see it with lspci or lsusb so I wonder if they did something wrong during the assembly. Googling on the topic didn t gave me any good result, let me a comment if you know how to get this working. Update: so apparently the bluetooth component is there (ID 0a5c:4500 Broadcom Corp.), it just appears as an USB hub so it s somewhat difficult to guess that it s effectively a bluetooth card. Freezes, in particular with an amd64 installation I first installed the system in 64 bits mode (amd64 architecture) but I had very regular freezes of the system (I couldn t finish a single kernel compilation for example). Since I switched to an i386 installation, the system is more stable but I still get an occasional freeze every other day. It might be that a more recent kernel fixes this or maybe it will be fixed with a future Dell Bios update we ll see, but it s my biggest complaint with this laptop so far. Links Lucas Nussbaum bought the same laptop, you might want to read his remarks as well. More details Load the full article only if you want to see the lspci and lsusb output on this laptop.


rhertzog@rivendell:~$ lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 RAID bus controller [0104]: Intel Corporation Mobile 82801 SATA RAID Controller [8086:282a] (rev 03)
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
02:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05)
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
02:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22)
02:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
0c:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
Kernel driver in use: iwlagn
Kernel modules: iwlagn
$ lsusb
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 019: ID 046d:c03d Logitech, Inc. M-BT69a Pilot Optical Mouse
Bus 004 Device 018: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader
Bus 004 Device 017: ID 0424:2602 Standard Microsystems Corp.
Bus 004 Device 016: ID 0424:2502 Standard Microsystems Corp.
Bus 004 Device 007: ID 045e:00dd Microsoft Corp.
Bus 004 Device 006: ID 0c45:63fe Microdia
Bus 004 Device 004: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 003: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 413c:8162 Dell Computer Corp.
Bus 001 Device 004: ID 413c:8161 Dell Computer Corp.
Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0a5c:5800 Broadcom Corp.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Partagez cet article / Share This

Just seen on #gammu:

<nijel> do you have some usb-serial convertor?
<fenix> yes,
<fenix> i use a usb-serial convertor
<nijel> that might be a problem because cables which do not have manual switch [...]
<fenix> you mean ? i don't use usb-serial convertor
<nijel> what? sentence ago you wrote that you use it....
<fenix> i see . i don't use usb-serial convertor  do it .
<nijel> so how exactly is the phone connected? usb cable? serial cable? serial cable + usb-serial convertor?
<fenix> i use  a serial cable + usb-serial convertor
<nijel> fine, so the problem is most likely in the convertor - [...]
<fenix> my pc have a serial port , i will use it . thank you nijel

Why the hell do you use usb-serial convertor, which is usually piece of crap, instead of native serial port?

Bastian Venthur notices how the "How many bugs have you fixed today" question is used as a killer-argument against critism at the release-process.

I must confess that I also don't like this attitude of people to use such arguments as a form to silence others. It is something that only people should do, who enjoyed bad manners.
But OTOH it is really sad to see that always the same people are fixing rc bugs. I can only guess, but it seems like out of over 1000 developers eventually 100 are actively involved in the squashing of release-critical-bugs. That is a shame. And people who try to blame the release team for the consequences happening because of this only aren't really helpful, too. Its not like having a release team is meant to be a "5 people to rule/rescue the world" approach.

Bastian, the problem with your attitude is, that you adduct such arguments with it. If its not visible that you do anything more to get Lenny out, except pointing with the finger at the release team, saying "Ha! Ha!", and speculating how we will fail to release Lenny timely, then you shouldn't wonder. You should remember that you are a part of the "We", which is failing, when we as a project miss yet another release date.

And yes, I do agree that our release process is not really ideal and I think we should further push changes to optimize it (which already happened, given that the unblock-policy was way less strict as the years before), but where is your constructive contribution to that?

That is the sledgehammer argument people bring up when others dare to criticize the current release process. I think this question is nonsense. While the bug-fix rate was more or less the same since the last two releases, it looks like in this release we simply started the freeze with much more open RC-bugs than before (~3 times more RC-bugs than with Etch). So it was foreseeable that the freeze would take longer this time. We can t solve the problem by trying to fix bugs faster, we ve tried it several times with mediocre success. That doesn t mean we shouldn t keep up fixing bugs, but we should probably accept that a certain number of people can only fix a certain number of bugs in a given time. In our case roughly 30 RC-bugs per month. So what s the point of asking how many RC-bugs one has fixed? Does that mean only those are allowed to make suggestions, who fixed an RC bug? That pressure doesn t help anyone. I believe unstable being frozen for several months is a very important problem which can have drastic consequences regarding the number of our users, and we will not solve it by suggesting to fix our bugs faster.

So, in the Membership Status GR, we sent a clear message that we wanted those decisions to be postponed. Now, we have a responsibility to prove that we were not just rejecting any change, but that our vote was really a vote against the way those decisions were announced, and/or those particular decisions. I m convinced that our management of membership needs to be improved. I hope that in the next weeks/months, we will be able to discuss proposals about membership status. There s Joerg s, there s Lars , there s Raphael s, and there might be other ideas. Ideally, each of them would be discussed and improved separately (because we can t be expected to agree on one proposal right from the start), and finally we would get to vote on a coherent set of proposals (with an unbiaised ballot ;) to choose in which direction we want to change our management of membership. It would be great to use the DEP process or something similar for that. It is also interesting to compare this whole story with our current issue: a secretary that ignored valid criticism about a ballot and went on with asking to vote on it. In both cases, someone that is generally trusted and respected by the project made a mistake, and failed to acknowledge it, requiring strong actions from other DDs. I wonder how the secretary crisis will end

When I was little, we moved around a lot. One of the things I was almost most excited by was the first night in the new place. My sister and I would usually stay there on our own, on the floor or perhaps on a sponge. I've always found moving exciting, with the new possibilities that come with it.

I notice, though, that as I get older the camping gets progressively more 'yuppy'. We might bring food and snacks, or a radio, or a laptop. As we're waiting for our stuff to get here, we've got shiny new couches, a new bed for Leif, and a new dining room table and chairs. Pictures will come soon. =)

We're all settling in well. We've almost completed the basic tasks of becoming a citizen of Quebec again. The driver's licenses are changed over, Angie and Leif's medical applications are done (mine will be done tomorrow). We have updated library cards, are signing up for Communauto this week. And we have been served with our Welcome Tax

I've really appreciated being able to check in with new and old friends. It's weird timing because so many people are returning home for the holidays, but still good because it means that we have a bit of time to get settled.

So happy to be home! =)

Just a quick note that I was planning to write as soon as possible: I m (still) having fun with debian !. Yes, things go slowly, yes we consume a lot of energy to discuss again and again the same things.. But, hey, that s what I am proud of ! Somehow, I truly appreciate people with which I had strong disagreement. I didn t like the moments when this generated frustration for me, but when I look at the overall picture, I really believe there are not a lot of projects who can still go on *and* support the level of free speech and opinions that we have. Diversity of opinions is a difficult thing for big projects, and I am proud we can afford it ! "We will not hide problems from our users." is one of the most meaningful sentence I got from this project, and all of this makes real sense to me. It is democracy !

Wouter replies to my blog post:

Well, we did, and we did. It's just that in two years, several new kernel releases came out, and that also resulted in some new firmware blobs entering the kernel. This, in a way, is a relatively new issue.

Having said that, I do agree with his sentiment; even if they're new issues, they could and should have been fixed ages ago. As I said in my 'no more hitting' post, too.

Well, yes, even if those firmware blob bugs from Etch have been sorted out some time ago, the problem itself still exists: there will ever be new firmware blobs and apparently there was no way found in the past 2 yours to deal with that. Otherwise there wouldn't be a new GR about it - again. ;)

So, I think Wouter and I basically agree - and probably many others as well.

It would be really nice if Debian would find a solution that fits the users needs until the freeze of lenny+1 instead of fighting the problem with short time workarounds.
With solution I mean a proper way to enable the user to actually use the hardware s/he bought. I faced that kind of problem myself earlier this year when I realized that I couldn't install Debian on some new Dell T105 out of the box.

This unofficial GR was brought to you with the help of:

• Julio Bustamante
• Placebo
• Rebekah del Rio
• Sigur R s
• Queen
• Will Young
• Julie Andrews

From How to win online debates, by Adam Graham:

• Learn how to ridicule the beliefs of others: When you debate online, you can be quite contemptible in your choice of verbiage. Don t just respond to your opponents, ridicule them. If you merely respond, they can just fire back a response, but the ridicule will strengthen your argument and there s not really a good way to respond to being ridiculed.
• Repeat yourself: Keep going over the same ground over and over again. The most talented online debaters say the exact same thing repeatedly in a slightly different way. In doing so, they force their opponents to become equally repetitive, which can help you in winning the debate.
• Quote whole articles of more than a thousand words in their entirety. While in an offline debate, you couldn t stand up and read fifty pages of material, nothing stops you from doing so online. Thus, if you re not very good at forming logical arguments, all you have to do is quote others good arguments and thus you can bolster your weakness and outmatch your opponent.
• Remember that if your opponent quits debating you, you win. What will pay off most in repetitiveness, a snotty attitude, and writing posts that are so long that your opponent cannot respond to them unless he quits his jobs and dedicates his entire life to addressing your rants. If he says he s leaving because you re rude or repetitive, you ve really won because it shows how much you dominated the debate.

You won t really influence the direction of what people think on a given issue. The prize is the satisfaction that you won the debate. You beat that guy. You showed him who was right! Congratz! As the author of the article says, quoting the film War Games: A strange game. The only winning move is not to play.