Search Results: "thb"

16 February 2010

Christian Perrier: Bug #570000

(you were awaiting this one, weren't you?) Ron Murray reported the Debian bug #570000 on Monday February 15th, against the gnome-keyring-daemon package. Bug #560000 was reported as of December 8th 2009. We're behind our "10,000 bugs in 2 months" pace by one week, so that's a small drop in the bug reporting rate, this time. I hope that people remember the Bug #600000 contest. Bets are closed now (the wiki page is still opened for modifications but I'll revert them if they are late bets). Being 30,000 bugs away from #600000, it's time to image when that bug could happen. The current "2 months+1 week/10,000 bugs" says it would happen around September 10th. With the "2 months/10,000 bugs" that would be August 15th, just after DebConf 10. The closest bet as of now seem to be either Miod Vallat or Kanru Chen. I probably lost already (I did bet June 30th) unless I imagine a very massive bug filing. Too bad Matt Arnold, Thomas Preudhomme, Nicolau Werneck and Odd Henriksen, you already lost!

25 November 2009

Russell Coker: Seatbelts and Transporting Computers

I ve just read an interesting post at Making Light about seat-belts [1]. In Australia seat-belt use is mandatory, you can be fined for failing to wear one and the police (who help clean up the mess when someone dies on the road) are apparently quite aggressive about enforcement. Even aside from the legal requirement the use of seat-belts is fairly ingrained in Australian culture, people tend to use them even when they won t get caught. One of the things I like to do in my spare time is to take unused computer gear from IT companies (which they regard as rubbish) and give it to home users for recreational and educational use. Due to that and my work for some smaller IT companies I ve helped many people load computer gear into their private cars and observed that most people will not take adequate care unless I coerce them. A CRT monitor tends to be large and heavy, you wouldn t want to get hit in the back of the head with one at 60Km/h. With some combinations of monitor and car you can fit a monitor in the front passenger foot-well, but usually the only place a monitor will fit is the back seat. The correct thing to do is to use the seat-belt to strap the monitor in place. It s most likely that the monitor stand (the only part that allows a seat-belt to be attached) would snap off in the event of a serious crash but this would at least slow the monitor down. Also don t put the monitor directly behind your seat if you can avoid it, put it behind the passenger seat. In a collision monitor might be able to push through your seat and cause you a back injury. Between 1992 and 2006 there were 78,000 acute computer-related injuries treated in US hospital emergency rooms [2]. The number of injuries caused by monitors peaked at 37% of the total in 2003 this was largely due to monitors falling on people. Even without the speed of a car a monitor can be a dangerous projectile. Hard drives have a lot of potential to cause damage, they are dense, hard, and the corners often aren t rounded. Storing them above the back seat behind the driver s head (as a friend once tried to do) is a really bad idea. Mythbusters showed that a box of tissues isn t going to kill you in a crash, but a hard drive is much more dangerous. The typical car glove box can store a few drives. If you need to transport a box full then the front passenger foot well is a reasonable place. If your car rolls then that would suck, but it seems that people usually die when they roll their car anyway so just try not to do that. A serious server (EG 2RU or bigger rack-mount) typically weighs 30Kg or more and is solidly constructed. The size and mass of such a machine makes it extremely difficult to safely store inside a car. The ideal place is the boot, but if that isn t an option then behind the passenger seat is the next best option. One final issue that I ve been wondering about is the safest option for laptops that are in use in a moving car. A 3Kg Thinkpad would have to hurt if it hit you in the back of the head at 60Km/h. The child-seat attachments are solid anchor points that can be used for other things. I wonder if a laptop security cable could be attached to one of the child seat points. According to an exhibit at a science museum I can throw a tennis ball at 115Km/h, so I presume that laptop security cables are designed not to break when someone swings the laptop at that speed. Therefore if a car was driving at a legal speed in Australia before crashing then a laptop security cable should be able to stop the laptop. Preventing the cable from injuring the passenger on the way would be the difficult part.

8 November 2009

Stephan Peijnik: Android, Mythbusters and openness

I have been reading a great many posts about Android lately, some consisting of criticism, some of praise and some simply addressing issues in the Android community . Let s have a look at those. Matt Porter s Android Mythbusters presentation and Harald Welte s reaction
I haven t seen the presentation live, but I had a look at the slides. Impressing work done by Matt putting all this information together. However, we all knew that Android only (ab-)uses Linux, without making use of the GNU userland for a long time, didn t we? In his presentation Matt has shown things such as Android s udev replacement that uses hardcoded values for device node creation and (on his blog) Harald has then come up with a statement I have found to be very strong:
The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!
Now both of these statements target technical details, but the root of the problem seems to be elsewhere. Where is my Android 2.0? Okay, that heading might not be making any sense in the context of this post at a first glance, but let me elaborate on that. Google and the Open Handset Alliance refer to Android as being an Open Source operating system, but the project is different from real Free Software projects: development takes place in a closed group and the results are shared with the community later on, when they are deemed to be ready. This means that innovation also takes place behind closed curtains and that the community is not involved in the actual development process at all. Lately we have seen the result of that, as Motorola is bragging about working close with Google on Android 2.0 ( Eclair ), but the AOSP source trees, open for everyone to have a look at, show no signs of version 2.0. In fact no changes that might even remotely suggest the release of a new major version have been made public in the past few weeks. So where is the openess there?
Actually, the Motorola Droid has already shipped with Eclair on 6th, but still, there is no indication that Eclair will be made available to the broader public. In short Android seems to be developed behind closed curtains, with hardly (read no) community input whatsoever and is sometimes released as Free Software, not what I would describe as an open development process. The Android Market problem As we have seen in the past Google is enforcing their copyright on proprietary applications that ship with pretty much every Android device, such as the Android Market. This has become really clear when Steve Kondik received a cease and desist letter when packing the Google-proprietary applications into his ROMs. Okay, it s Google s right to enforce their copyright and there is nothing wrong with actually doing so, the thing I really have a problem with is something else: the Market is proprietary. Now what this means should become rather clear. You can have an Android device without Google s proprietary bits, but with default settings you just do not have any way of installing additional software. In my opinion the Market should be freed by Google themselves, or the community has to react and come up with a free replacement to overcome the vendor lock-in. Oh, you might know a replacement called SlideMe (or Mobentoo) already. Well, that bugger is proprietary too, so not a solution at all. Nokia and Maemo to the rescue In most discussions about the openness of Android someone throws in Nokia and Maemo, as a solution to the dilemma. Reading all those positive comments I simply had to give it a try, but all my hopes were destroyed within a few minutes. Let s start with the good news and let alone the reason why my hopes were destroyed for another minute or two. Maemo is based on Debian GNU/Linux and various Free Software components, such as GTK+, gstreamer, esd and friends. Most of the system is Free Software which is a good thing(tm) and reading all of this really got me into Maemo. Okay, some applications seem to be proprietary, but I am sure that could be fixed rather easily, so I could once for all use a truly open phone. and then came the SDK installer shell script:
#!/bin/sh
# Copyright (C) 2006-2009 Nokia Corporation
#
# This is proprietary software owned by Nokia Corporation.
#
# Contact: Maemo Integration <integration@maemo.org>
# Version: $Revision: 1110 $
Now there is one question you should ask yourself: Why would someone trying to promote his platform as being open make the *installer* script for its SDK proprietary? Come on, it s an installer script, how much of your secret juice could be in there? What s the problem with people modifying it and working on this installer script in an open development environment? I had high hopes for Nokia actually doing a bit better than Google, but it seems they ve failed to do so. It may be me overreacting, but a proprietary SDK installer shell script scares me enough not to install the SDK and have a look at it for now nor to think about buying a Maemo-based device in the near future. Please Nokia, either get the facts straight or provide us with a free SDK to your free & open platform. So, in short, Google is bad at working with the community and creating a truly open development process, and Nokia simply fails in terms of not scaring off prospective developers for their open platform with the proprietary SDK installer. Do you have any solutions in terms of an open phone environment, apart from what OpenMoko has come up with?

5 June 2009

Andrew Pollock: [life] Oh noes, my first cavity!

I've always prided myself in the fact that I didn't have any fillings. That's about to change, sadly. One of the teeth at the back, top right of my mouth has a deep valley, which makes it hard to get at with a toothbrush, and there's a small cavity at the bottom of that. Dentist trips for me have always just involved the cleaning and scaling and an exam. Aside from having my wisdom teeth out (which I had done under general anaesthesia) I've never had a dental procedure before. Eeek.

30 March 2009

Russell Coker: Links March 2009

Cory Doctorow has written a column for The Guardian titled You shouldn t have to sell your soul just to download some music [1]. One really interesting point he made was The same companies that spent decades telling lawmakers that they were explicitly not the guardians of the morality of the young that they couldn t be held accountable for sex, drugs and rock n'roll, for gangsta rap, for drug-fuelled dance-parties did a complete reversal and began to beat their chests about the corrupting influence of downloading on the poor kiddies . The pt4me2 organisation advocates that the Victorian government spend more money on public transport infrastructure [2]. Recently the congestion on Melbourne roads has been getting worse, the costs of private car parks in the central city area have been increasing, and during peak hours all public transport is over-crowded. Some significant improvements are needed, and more trains, trams, and buses are the only possible way of coping with the number of people working in the city. Also there s the issue of suburbs that lack any public transport, I wouldn t want to live near one of those areas when petrol hits $8/L (as the CSIRO predicts for 2018). Michael Tiemann writes about Microsoft s latest patent attack against Linux [3]. He doesn t pull any punches which is a very noteworthy thing. It s pretty rare to see someone in a senior position in a company blog in a way that makes any significant comment about another company. Dan Ariely gave an interesting Ted.com talk about Our Buggy Moral Code [4]. One of the points was that people who declare themselves to be atheists are less likely to cheat when asked to swear on a bible first, another was that if someone who is identified as a member of the same group cheats then others will follow, but if an outsider cheats then they won t. It seems that if you want to minimise cheating then you want to have only outsiders be seen to do it, and you want everyone to swear to follow some sort of moral code. Flame has written a good rant titled Anarchy is Dead about the lack of popular outrage against the Australian government s censorship plans [5]. Rolling Stone magazine has a good article about the US banking crisis [6]. A moderate amount of bad language, but no more than is deserved. Amazing video of rounding up sheep that are fitted with LEDs at night [7]. Here s an interesting TED talk by Saul Griffith about using kites to generate electricity [8]. Unfortunately he didn t give much engineering information, it was more of an executive summary of what he has done. He claims that if a wartime level of effort was put in place then wind could supply all the electricity needs of the US within 10 years. Adam Savage (of Mythbusters fame) gave a talk for TED about his obsession with the Dodo [9]. One thing that surprised me is how his manner in that talk differed from his appearance in Mythbusters. It seems that most of his crazy antics in Mythbusters are an act to entertain the audience. The information about the dodo was really interesting too. He then went on to talk about his recreation of the Maltese Falcon. His work can serve as inspiration for other geeks who want to try sculpting.

19 March 2009

Uwe Hermann: Using Debian GNU/Linux on the Lenovo IdeaPad S9e netbook

TuxMobil - Linux on Laptops, Notebooks, PDAs and Mobile Phones Lenovo Ideapad S9e netbook I recently got my hands on a Lenovo IdeaPad S9e netbook for a short amount of time (I don't own it), so I did a few tests with Debian unstable (more or less Lenny right now) and a Linux 2.6.28 kernel on it, see results below. The machine type is 4187-42G, and it features an Intel Atom N270 CPU (with HyperThreading) at 1.6 GHz, 1 GB of DDR2 RAM, an 80 GB SATA drive, an 8.9" WSVGA 1024x600 (glossy) screen, VGA port, LAN, wifi, bluetooth, 2xUSB, SD card slot, PCI ExpressCard slot, built-in microphone, and a webcam. BIOS You can enter the BIOS by pressing F2, the boot menu by pressing F12 during boot. Booting from USB works fine on this netbook. There's a Splashtop installation on the netbook (called "Lenovo Quickstart" here) which you can disable in the BIOS. Installation There's no CD-ROM drive, so the simplest way is to use a USB thumb drive for installation. Here's how you can prepare one containing a Lenny installer (assuming your USB thumb drive is /dev/sda):
  $ wget http://cdimage.debian.org/debian-cd/5.0.0/i386/iso-cd/debian-500-i386-netinst.iso
  $ wget http://ftp.nl.debian.org/debian/dists/lenny/main/installer-i386/current/images/hd-media/boot.img.gz
  $ gunzip boot.img.gz
  $ dd if=boot.img of=/dev/sda1
  $ mount -t vfat /dev/sda1 /mnt
  $ cp debian-500-i386-netinst.iso /mnt
  $ umount /mnt
If the above USB thumb drive doesn't boot correctly (which it did not in my case: GRUB error 17) it's probably because of a messed-up MBR. This is how you can fix it:
  $ apt-get install mbr
  $ install-mbr /dev/sda
 Lenovo Ideapad S9e Debian installation Then insert the USB thumb drive in the Lenovo IdeaPad S9e, choose USB boot in the BIOS, and start the installer. Most of the process works as usual, the only small difference is that you might want to load the "parted" installer module in order to resize the Windows-partition on the disk (if you want to keep it) to make space for Linux. The second (fat32) partition seems to keep a restore image and/or the Splashtop stuff, not sure. Audio Works out of the box using the snd_hda_intel driver. The hardware is onboard audio in the southbridge (82801G / ICH7) and uses the Realtek ALC269 codec. If some programs don't have working audio, try modprobe snd-pcm-oss. Built-in microphone Untested so far. Bluetooth Works out of the box using the bluetooth and btusb driver. The laptop's Bluetooth device is USB-attached internally and shows up in lsusb as:
  $ lsusb
  Bus 003 Device 002: ID 0a5c:2150 Broadcom Corp.
  $ dmesg
  usb 3-2: Product: BCM2046 Bluetooth Device
After modprobe btusb you can use hcitool / hciconfig etc. as usual, and/or enable more related stuff with /etc/init.d/bluetooth start. Sensors The lm-sensors script detects the lm75, eeprom, i2c-dev, and i2c_i801 modules. The following is the 'sensors' output:
  $ sensors
  acpitz-virtual-0
  Adapter: Virtual device
  temp1:       +36.0  C  (crit = +95.0  C)    
The hard drive temperature can be viewed with:
  $ hddtemp /dev/sda
  /dev/sda: FUJITSU MHZ2080BH G1: 44  C
HPET The Intel ICH7 southbridge in this laptop supports High Performance Event Timers (HPET) which allows for more power savings and thus improved battery life.
  $ dmesg   grep -i hpet
  ACPI: HPET 3F6E1E41, 0038 (r1 INTEL  CALISTGA  6040000 LOHR       5A)
  ACPI: HPET id: 0x8086a201 base: 0xfed00000
  hpet clockevent registered
  HPET: 3 timers in total, 0 timers will be used for per-cpu timer
  hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
  hpet0: 3 comparators, 64-bit 14.318180 MHz counter
You can check the wakeups-per-second with powertop. SD card slot Works out of the box. It seems to be attached via USB internally (usb-storage driver).
  $ lsusb
  Bus 001 Device 004: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device
PCI ExpressCard slot Untested so far. ACPI Works fine, see comments for "acpitool" output. Network card Works out of the box using the tg3 driver.
  $ modprobe tg3
  tg3.c:v3.94 (August 14, 2008)
  tg3 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  tg3 0000:02:00.0: setting latency timer to 64
  eth0: Tigon3 [partno(BCM95906) rev c002 PHY(5906)] (PCI Express) 10/100Base-TX Ethernet 00:11:22:33:44:55
  eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[0]
  eth0: dma_rwctrl[76180000] dma_mask[64-bit]
Touchpad Works out of the box, both in X as well as in the console using gpm.
  $ dmesg
  Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04731/0xa40000
Suspend-to-disk and suspend-to-RAM I'm using the hibernate Debian package. You can explicitly force the usage of either method in /etc/hibernate/hibernate.conf by uncommenting the respective lines.
  TryMethod disk.conf
  # TryMethod ram.conf
Suspend does not yet work out of the box, however, as the machine is unknown:
  $ s2ram -n
  Machine unknown
  This machine can be identified by:
      sys_vendor   = "LENOVO                          "
      sys_product  = "418742G         "
      sys_version  = "Lenovo                  "
      bios_version = "14CN51WW  "
  See http://suspend.sf.net/s2ram-support.html for details.
After a few test I found that s2ram -f -a 3 works fine (tested from console only so far). Now this needs to be integrated upstream and in the Debian package (I'll file a bug report). Update: Submitted bug #520848, and an email to the upstream mailing list. Wireless There doesn't seem to be a mainline driver for the Broadcom BCM4312 wifi card in the laptop, yet:
  $ lspci -nn
  05:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
Neither the b43 nor the b43legacy drivers work as of 2.6.28. For now, one of two possible options is to build a (partly non-free) driver provided by Broadcom from source (option 2 would be to use ndiswrapper, I guess, but that's untested):
  $ wget http://people.debian.org/~adamm/kernel/linux-kbuild-2.6.28_2.6.28-0.1_i386.deb
  $ dpkg -i linux-kbuild-2.6.28_2.6.28-0.1_i386.deb (currently needed in unstable due to bug #518115)
  $ apt-get install build-essential linux-headers-2.6.28-1-686
  $ mkdir temp; cd temp
  $ wget http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86_32-v5_10_79_10.tar.gz
  $ tar xfvz hybrid-portsrc-x86_32-v5_10_79_10.tar.gz
  $ make -C /lib/modules/ uname -r /build M= pwd  clean
  $ make -C /lib/modules/ uname -r /build M= pwd  modules
If that worked, you can load the driver via:
  $ rmmod bcm43xx; rmmod b43; rmmod b43legacy (you could also permanently blacklist these modules)
  $ modprobe ieee80211_crypt_tkip
  $ insmod ./wl.ko
  $ dmesg
  wl: module license '' taints kernel.
  wl 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
  wl 0000:05:00.0: setting latency timer to 64
  eth1: Broadcom BCM4315 802.11 Wireless Controller 5.10.79.10
You can now run iwconfig, iwlist, etc. from the command line, or use some GUIs such as kwifimanager. In order to disable wireless, run:
  $ rmmod wl
So far, I only tested WEP (but not WPA). CPU frequency scaling Works out of the box using the acpi_cpufreq driver. Use cpufreq-set -c 0 -g performance if you need full CPU power, cpufreq-set -c 0 -g powersave otherwise. Use -c 1 to do the same with the other CPU/core. PC speaker Works fine out of the box using the pcspkr module, tested with beep. Graphics card Works out of the box using the intel X.org driver.
  $ xrandr
  Screen 0: minimum 320 x 200, current 1024 x 600, maximum 1024 x 1024
  VGA disconnected (normal left inverted right x axis y axis)
  LVDS connected 1024x600+0+0 (normal left inverted right x axis y axis) 195mm x 113mm
     1024x600      60.0*+
     800x600        60.3  
     640x480        59.9  
  TV disconnected (normal left inverted right x axis y axis)
DRI works out of the box with the (mainline, open-source) driver:
  $ glxinfo   grep direct
  direct rendering: Yes
If you attach an external monitor or projector, you can enable it using xrandr as usual:
  $ xrandr --output VGA --auto
You can also use a dual-head setup by adding this to your "Screen" section in /etc/X11/xorg.conf:
  SubSection "Display"
    Virtual 2048 2048
  EndSubSection
After restarting the X server, you can play with xrandr and move the external screen (VGA) "below" the laptop's LCD screen (LVDS) for a simple dual-head setup. The GUI tools arandr or grandr are probably a bit simpler to use than plain command line xrandr. USB Works fine, of course. The only small problem is that there are only two USB ports, more would have been better. Disk drive Works fine, it's an 80 GB SATA drive. Webcam Works out of the box using the uvcvideo driver.
  $ lsusb
  Bus 001 Device 005: ID 5986:0141 Acer, Inc
  $ modprobe uvcvideo
  uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0141)
  input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/input/input9
  usb 1-3: New USB device found, idVendor=5986, idProduct=0141
  usb 1-3: New USB device strings: Mfr=3, Product=1, SerialNumber=0
  usb 1-3: Product: Lenovo EasyCamera
  usb 1-3: Manufacturer: BISON Corporation
You can use luvcvideo for webcam viewing. Battery Lasts for ca. 3.5 hours, probably less if the system is under high load. Special keys Fn+CursorUp / Fn+CursorDown (brightness), Fn+ESC (enable/disable webcam), Fn+F1 (sleep mode), Fn+F2 (enable/disable TFT backlight), Fn+F6 (enable/disable thouchpad), Fn+F7 (Num lock), Fn+F8 (scroll lock), and Fn+F11 (F12 key) all work fine. Fn+F3, Fn+F5, Fn+F9, Fn+F10, and all other special keys are untested. LEDs The power, disk activity, CAPS lock, Num lock, and battery charging LEDs all work fine out of the box. lspci -tvnn
  -[0000:00]-+-00.0  Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac]
           +-02.0  Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae]
           +-02.1  Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6]
           +-1b.0  Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8]
           +-1c.0-[0000:02]----00.0  Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713]
           +-1c.1-[0000:03-04]--
           +-1c.2-[0000:05]----00.0  Broadcom Corporation BCM4312 802.11b/g [14e4:4315]
           +-1d.0  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8]
           +-1d.1  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9]
           +-1d.2  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca]
           +-1d.3  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb]
           +-1d.7  Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc]
           +-1e.0-[0000:06]--
           +-1f.0  Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9]
           +-1f.1  Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df]
           +-1f.2  Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4]
           \-1f.3  Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da]
cat /proc/cpuinfo See comments. Resources All in all it's a really nice hardware, and it works (more or less) flawlessly without much hassle with recent distros/kernels. Update 2009-03-22: Updated various sections, added more info. Added resources section.

12 March 2009

Daniel Stone: public service announcement

This is a public service announcement: depth and bpp are different.

Depth refers to the number of significant bits (usually colour-significant, i.e. R + G + B bits for RGB modes) per pixel. bpp, i.e. bits per pixel, refers to the number of bits used altogether for pixel storage. Ignoring alpha, the usual configuration of your framebuffer will be depth 24 (8 bits each for R, G and B), but 32bpp: 8 unused bits at the top. 24bpp and depth 24 means that there are no unused bits, and that four pixels will occupy 96 bits (12 bytes), and not 128 bits (16 bytes), as there would be in 32bpp. (Thankfully, no-one actually uses 24bpp in the real world.) That is all.

28 December 2008

Christian Perrier: Bug #510000

Nicola Benaglia reported bug #510000 on Sunday December 28th. As bug #500000 was reported as of Sep 24th 2008, this marks a considerable slowdown of our bug reporting rate: between bugs 400000 and 500000, it always took us nearly exactly two months to have 10000 bugs reported. Here, we needed more than 3 months! This is a 50% drop in the bug reporting speed. I think we can conclude this is a very good illustration of the considerable drop in the development of Debian, while everybody is awaiting for the release of Lenny. You still have a few days to correct your bet for bug 600000 date. Ah, and the very same day, the result for the very controversial vote about firmwares has been published. Even though it is very hard to interprete, I think that the very very low rating of option 1 (worded as "Reaffirm the Social Contract" but indeed meaning "let's be Free Software Zealots and nitpick every single bit of firmwares so that we can be sure to never release Lenny") clearly shows that Debian developers still have their feet in reality. So, now let's release the bloody thing...and prove the world we still exist...

4 December 2008

David Welton: The Economics of Programming Languages - in the 1950's

I was having a look at this paper on the development of Fortran: http://www.softwarepreservation.org/projects/FORTRAN/paper/p165-backus.pdf (which I found here ) And I noticed the following quote:
1.2. The Economics of Programming Another factor which influenced the development of FORTRAN was the economics of programming in 1954. The cost of programmers associated with a computer center was usually at least as great as the cost of the computer itself. (This fact follows from the aver- age salary-plus-overhead and number of programmers at each center and from the computer rental figures.) In addition, from one-quarter to one-half of the computer's time was spent in debugging. Thus programming and debugging accounted for as much as three-quarters of the cost of operating a computer; and obviously, as computers got cheaper, this situation would get worse. This economic factor was one of the prime motivations which led me to propose the FORTRAN project in a letter to my boss, Cuthbert Hurd, in late 1953 (the exact date is not known but other facts suggest December 1953 as a likely date). I believe that the economic need for a system like FORTRAN was one reason why IBM and my successive bosses, Hurd, Charles DeCarlo, and John McPherson, provided for our constantly expanding needs over the next five years without ever asking us to project or justify those needs in a formal budget.
As Hal Varian says, "Ignore basic economic principles at your own risk. Technology changes. Economic laws do not." I would continue to bet on programming languages that save programmers time, or otherwise make them more productive.

David Welton: The Economics of Programming Languages - in the 1950's

I was having a look at this paper on the development of Fortran: http://www.softwarepreservation.org/projects/FORTRAN/paper/p165-backus.pdf (which I found here ) And I noticed the following quote:
1.2. The Economics of Programming Another factor which influenced the development of FORTRAN was the economics of programming in 1954. The cost of programmers associated with a computer center was usually at least as great as the cost of the computer itself. (This fact follows from the aver- age salary-plus-overhead and number of programmers at each center and from the computer rental figures.) In addition, from one-quarter to one-half of the computer's time was spent in debugging. Thus programming and debugging accounted for as much as three-quarters of the cost of operating a computer; and obviously, as computers got cheaper, this situation would get worse. This economic factor was one of the prime motivations which led me to propose the FORTRAN project in a letter to my boss, Cuthbert Hurd, in late 1953 (the exact date is not known but other facts suggest December 1953 as a likely date). I believe that the economic need for a system like FORTRAN was one reason why IBM and my successive bosses, Hurd, Charles DeCarlo, and John McPherson, provided for our constantly expanding needs over the next five years without ever asking us to project or justify those needs in a formal budget.
As Hal Varian says, "Ignore basic economic principles at your own risk. Technology changes. Economic laws do not." I would continue to bet on programming languages that save programmers time, or otherwise make them more productive.

23 October 2008

Chris Lawrence: Bust a move

I enjoyed last night’s episode of Mythbusters for a variety of reasons. For starters, I now have Smart Board Envy™, projectiles and explosions are always fun, and seeing Adam, Jamie, and Kari drunk was a hoot. The social scientist in me, though, really enjoyed the “beer goggles” experiment. In fact, the show, edited down to just include that section, would make a great primer on “how social scientific experiments work” for my undergraduate methods course when I teach it again, presumably next fall. On the other hand, I was less thrilled with the “sobering up” experiment, but the comedy factor of drunken Adam trying to run on a treadmill without a handrail, with all-too-predictable results, made up for the scientific shortcomings therein.

27 September 2008

Christine Spang: finally found a decent DAP

I recently bought a 4GB Sansa Clip to solve the problem where once-a-week or so I want portable music or podcasts and don’t have any: namely, at the gym, occasionally when walking somewhere, and on trains and buses. I’ve been looking for something exactly like this for ages—small, attachable for use during exercise, enough space for a few hours of music/audio, OGG support, and not necessarily much more than that. Basically, an iPod Shuffle that plays OGG and doesn’t involve dealing with Apple. For the longest of time, this was pie-in-the-sky nonexistant. After a few weeks of using the Clip, I’m extremely pleased so far. The battery life is much longer than I’d ever want to listen to music for continuously (they claim 15 hours, and I haven’t gotten it down to less than half charge yet). It’s light in the hand but not too flimsy in feel, the clip makes it easy to attach to e.g. shorts, the interface is easy to use, and the sound quality is good. After upgrading to the latest firmware, it plays OGG as well as MP3. Both Rhymthbox and Banshee work for transferring files to it. I think my biggest complaint so far would be that the audio jack doesn’t fit in as securely as it could, which sometimes manifests as sound skipping and can be fixed by making sure the headphones are completely plugged in. Seriously, it was funny when my Walkman skipped during runs in 2003, but I hope I’m past that phase of life at this point. At any rate, it doesn’t happen all that often, so it’s more of a minor annoyance than anything. And well, the firmware isn’t free—but hey, can’t have everything.

18 September 2008

Gunnar Wolf: Almost 0.5Mbugs

I was already used to regularly receiving Bubulle's bug 500000 contest reports. Lately, he has been busy pushing translators to get d-i in shape - But expect notices from him soon! Right now, we sit at 499416 bug reports so far registered in the Debian BTS. We are really close to the half megabug mark!

5 September 2008

Matthew Garrett: Power management and graphics

It's the X Development Summit in Edinburgh this week, so I've been hanging out with the graphics crowd. There hasn't been a huge amount of work done in the field of power management in graphics so far - Intel have framebuffer compression and there's the lvds reclocking patch I wrote (I've cleaned this up somewhat since then, but it probably wants some refactoring to avoid increasing CPU usage based on its use of damage for update notifications). That still leaves us with some fun things to look at, though.

The most obvious issue is the gpu clock. Intel's chipset implements clock gating, where unused sections of chip automatically unclock themselves. This is pleasingly transparent to the OS, and we get power savings without any complexity we have to care about. However, there's no way to control the core clock of the GPU - it's part of the northbridge and fiddling with the clocking of that would be likely to upset things. Nvidia and Radeon hardware is more interesting in this respect, since we can control the gpu clock independently of anything else. The problem is trying to do so in a reasonable way.

In an ideal universe, we can change these clock frequencies quickly and without any visual artifacts. That way it's possible to leave it in the lowest state and clock it up as load develops. There's a couple of problems with this - non ideal hardware, and the software in the first place. Jerome's been testing a little on Radeon and discovered that changing the memory clock through Atom results in visual corruption. It's conceivable that this is due to some memory transaction cycles getting corrupted as the clock gets changed. If we could ensure that the reclock happens during the vertical blank interval, that's something that could potentially be avoided (of course, then we have the entertainment of working out when the vertical blank interval actually is when you have a dual head output...). The other problem is that 3D software tends to consume as many resources as are available. Games will produce as many frames per second as possible. Demand-based clocking will simply ramp the gpu to full speed in that situation, which isn't necessarily what you want in the battery case (as the number of frames per second goes up, so does the cpu usage - even more power draw) but is probably pretty reasonable in the powered case.

Handwavy testing suggests that this can save a pretty significant amount of power, so it's something that I'm planning on working on. Further optimisations include things like making sure that we're not running any PLLs that aren't being used at the time (oscillators chew power), not powering up output ports when you're not outputting to them and enabling any hardware-level features that we're currently ignoring. And, ideally, doing all of this without causing the machine to hang on a regular basis.

31 August 2008

Christian Perrier: Will Kartik win?

The 500000th bug day is coming. Some of you may remember the contest I launched last year for people to bet on the day bug #500000 would be reported. The bug rate in Debian is about 1000 bugs in 6 days from my survey. So, as we're now at about #497300, bug #500000 should happen in 14 days. It seems that Kartik Mistry is about to win the contest. Indeed, he will if the bug is reported between Sept. 11th and Sept. 17th which probability is very high. Folks, prepare to send cheers to India! Unless the bug rate increases a lot and Miguel "xerakko" Gea wins. Miguel, I watch you: no MBF for you! I definitely lost when Aug. 22nd came. I was betting on a small rate increase which indeed did not happen. You can start now computing the #600000 bug day. There *will* be a contest for it...unless I launch one for bug #1000000...:-)

22 May 2008

David Pashley: Apache 2.2 auth_ldap config

Apache 2.2 changed the way you configure LDAP authentication. mod_auth_ldap was replaced with mod_authnz_ldap, so don't forget to enable the new module and disable the old one. Because I'll always forget, here's the new style config.
AuthType basic
AuthName "admin"
AuthBasicProvider ldap
AuthLDAPUrl ldap://ldap.example.com:389/ou=people,dc=example,dc=com?uid?sub
AuthLDAPGroupAttributeIsDN off
Require ldap-group cn=systems,ou=groups,dc=example,dc=com
AuthLDAPGroupAttribute memberUid
The sections in bold are the sections I had to change from the 2.0 config.

5 March 2008

Steve Kemp: One of the four beasts sang "come and see".

As many of you might not know I love steam. Steam power, specifically. Steam engines represent one of the most interesting engineering developments in history as far as I'm concerned, (closely followed by the accurate mechanical clock). Why? When I was a kid I had a computer. Each part of it was labeled and described in a manual. I knew what it was. I understood how it worked. I could build one myself if I had the time and re$ources. Nowadays? Hell no. Sure I can assemble the different components, but I can no longer visualize the whole entity, and I couldn't build one from scratch. I'm amazed at youngsters (~18 yrs old) who can understand a modern PC. Me? I do, but only barely, and that is primarily because I've watched the transition: Hercules Graphics -> CGA -> VGA -> SVGA -> & etc. Coming in cold? Right now? I'd be lost. I'm impressed (saddened? That this stuff isn't more accessible?) that people can pick up technology and understand it, without having watched the developments along the way. "Southbridge"? "Northbridge"? "APIC"? It's the same with everything. Fixing a car engine? These days? With electronics? Hell no. My (non-existant) car breaks, I'd be fucked. I can strip a simple engine. I could repair it if I had to. I could build a steam engine. I could, given a suitable template and collection of eye-glasses, build a mechanical clock. But computers? Modern Cars? Aeroplanes? More complex than a simple person like me can understand. And somehow I think that's a bad idea. It almost reminds me of the old Asimov stories where only computers could design new machines. People just didn't undestand them anymore.   So, in conclusion. I have new steam car. It works, as you can see in this adhoc video. (Randomly captured by my partner whilst I was too busy squee'ing. Excuse the quality and lack of editting. Notice too that I've removed the seats for the test drive, just to give me a safe place to pick it up without burning my fingers!) Lets hope the rise of the machines is soon, otherwise mankind will have collectively lost all knowledge of things less advanced than hot & cold electricity and the microprocessor. (As you can tell it is late and I've just had many beers and a beautiful curry. All is well! Thanks for reading!)

27 December 2007

Miriam Ruiz: SMV Video Format

Some small portable MP3 players also allow reproducing images and videos (does anyone know why they call them MP4 players?), but they need the latter to be in some funny format called SMV (for devices with SigmaTel chipset. Other devices use different formats, such as AMV for devices with Actions chipset, MVS for those with Sunplus chipsets, MTV, DMV or ASF). SMV seems to stand for “SigmaTel Motion Video”, and was developed by SigmaTel Inc to allow users to transform common PC video files and watch them on their portable multimedia players (PMP). I’ve been trying to find out how to convert videos to this format for a while, to be able to watch them in a small gadget I bought some time ago, but haven’t been able to do so from Linux yet. All the converters seem to be privative, and just for Windows, although they seem to work with wine according to some reports I’ve read on the net. I’m not putting any closed-source software in my lappy anyway, so that’s not an option for me. I recently found a web page of someone developing a conversion tool for SMV called smvconv, based on mplayer and ffmpeg and released under a MIT/X11 license. It’s just a small C program and a shell script, and seems to be in a very preliminary stage, but the most important part is that he has also published the structure of SMV files, which seem to be, in fact, quite a simple format composed of some headers, a WAV audio file and some JPEG frames: An SMV file has three sections, concatenated together:
  1. An IMA ADPCM .wav file, with header.
  2. An SMV header.
  3. A number of .jpeg files, with headers, each prepended by a 24-bit (3-byte) little-endian value representing the size, and buffered at the end with nulls, so that they are at predictable locations (the jpeg modulo). SMV is a constant-bit-rate format, but the underlying format (jpeg) is not. Proprietary encoders -according to smvconv’s author- probably make up for this by encoding at various qualities until a jpeg of the proper size is made.
The SMV header is a magic string in ASCII (”SMV002000″) followed by a number of 24-bit (3-byte) little-endian values representing the width, height, header length (in 3-byte words, starting with some magic “002″), some apparently constant value (1), the jpeg modulo, fps, number of frames. some apparently constant values (a 1 and a 0), the number of frames per jpeg, and 4 padding values (65793 == 0×010101). The default qualities seem to be 35kBps (”High”), 25kBps (”Medium”) and 16kBps (”Low”). Lets hope to have some working converter soon, so we can use this feature in those cheap players. I don’t remember where I put the USB connector for mine, but as soon as I find it -it seems to be non-standard, so no way to replace it with a new one, AFAIK- I’ll start experimenting with it.

29 November 2007

Eddy Petri&#537;or: I thought that was Debian's 50000

Phew, Rob, I thought that was Debian's 50000th bug!

Fortunately, I haven't lost the bet!

5 November 2007

Uwe Hermann: Recent LinuxBIOS progress

LinuxBIOS ROM Chip Logo Since the "World's First Motherboard Using LinuxBIOS Released" hype at the beginning of this year (which was incorrect btw; it was not the first supported desktop board, there were many others before), LinuxBIOS hasn't been in the news very much. That doesn't mean that there was no progress, however. We've been working hard behind the scenes to improve the LinuxBIOS code, add support for new chipsets and boards, and advance the upcoming next-generation LinuxBIOSv3 version which will brings lots of great improvements in various areas. Here's a random collection of stuff that happened in the last few months. New chipsets:
  • AMD K8 / NVIDIA MCP55, contributed by Yinghai Lu of AMD
  • VIA VT82C686A/B southbridge, contributed by Corey Osgood
  • AMD Geode LX / CS5536, contributed by Marc Jones and Jordan Crouse of AMD
  • Intel 810 northbridge, contributed by Corey Osgood
  • AMD K8 / VIA K8T890 / VT8237R, contributed by Rudolf Marek / Corey Osgood
  • AMD K8 / SiS761GX / SiS966(L), contributed by Morgan Tsai of SiS
New mainboards:
  • Sun Ultra40, contributed by Ronald G. Minnich (LinuxBIOS project founder)
  • K9SD Master-S2R (MS-9185), contributed by Bingxun Shi of MSI
  • K9SD Master Series (MS-9282), contributed by Bingxun Shi of MSI
  • GIGABYTE GA-M57SLI-S4, contributed by Yinghai Lu of AMD
  • NVIDIA l1_2pvv, contributed by Yinghai Lu of AMD
  • Supermicro H8DMR, contributed by Yinghai Lu of AMD
  • Tyan S2912, contributed by Yinghai Lu of AMD
  • Tyan S1846, contributed by myself
  • AMD Norwich (AMD Geode LX reference platform), contributed by Marc Jones and Jordan Crouse of AMD
  • IGEL Winnet III thin client, contributed by myself
  • ASUS A8N-E, contributed by Phillip Degler
  • IEI JUKI-511P, contributed by Nikolay Petukhov
  • IEI ROCKY-512, contributed by Nikolay Petukhov
  • AMD DB800 (a.k.a. Salsa), contributed by Marc Jones and Jordan Crouse of AMD
  • ASUS MEW-VM, contributed by Corey Osgood
  • Artec Group DBE61, contributed by Marc Jones and Jordan Crouse of AMD
  • PC Engines ALIX.1C, contributed by Ronald G. Minnich
  • MSI MS-6178, contributed by myself
  • MSI MS-7260 (K9N Neo), contributed by myself
  • IGEL-316 thin client, contributed by J rgen Beisert
  • AXUS TC320 thin client, contributed by J rgen Beisert
  • GIGABYTE GA-2761GXDK (Churchill), contributed by Morgan Tsai of SiS
  • And a bunch of older Intel 440BX based boards, contributed by myself with some help by testers via IRC: ASUS P2B/P2B-F/P3B-F, A-Trend ATC-6220, AZZA PT-6IBD, Biostar M6TBA, Compaq Deskpro EN SFF P600, GIGABYTE GA-6BXC
  • ASUS A8V-E SE, contributed by Rudolf Marek
Note that not all of these may be 100% supported, some may still be work in progress with some TODO items left... Check the LinuxBIOS wiki or ask on the mailing list for details. The future Most work will probably go into LinuxBIOSv3 in the future, in order to make it suitable for productive use.
Of course, work on new chipsets and boards will continue, too. For example the VIA CN700 chipset (plus Jetway J7F2WE board using it) is being worked on right now, probably also several others I don't know about. Call for board testers If you're interesting in trying out LinuxBIOS, please check the list of supported motherboards. If your board is not listed there, but the chipset is already supported we can probably add support for your board relatively easy with some testing help from you. Please contact us on IRC or preferrably on the mailing list if you want to help get your board supported! An (incomplete) list of good candidate boards for future support is available in the wiki. Thanks! We're very grateful for the many contributors who have helped us with testing and fixing existing code, or who even contributed code for new chipsets and motherboards. Thanks a lot! Many thanks especially to all hardware vendors who have been supporting us or even actively contributed by submitting code for their chipsets or boards (recently or in the past), including AMD, SiS, VIA, MSI, Tyan, Artec Group, and many others. Your efforts are very appreciated. Thanks!

Next.

Previous.