2006-11-28

Vendors

Posted in Computers, PlanetDebian at 21:52 UTC (+0000) by sven

BluWiki has put up a new Vendors page, which lists various (a lot of IMHO) vendors and their attitude to open source as a pos/neg sort of list. Quite interesting though still incomplete.

Steve Kemp’s weblog » Blame it on rock and roll

Posted in PlanetDebian at 04:29 UTC (+0000) by sven

Steve Kemp wrote an irssi script and accompanying utility to show facelets corresponding to IRC users, following an idea earlier mentioned by Lars Wizenius ,less than 5 hours earlier.

Wow, that certainly is a neat thing. There is one problem for me though: My Debian login is “sven”, while my usual IRC nick (oh well, since I’m actually rarely on IRC, speaking of “usual” is perhaps wrong) is “incase”, since the “sven” nick was already taken on both freenode and oftc. Any idea how to work around that?

Canonical and Debian – friend or foe?

Posted in Computers, PlanetDebian at 03:29 UTC (+0000) by sven

Pointed at the issues by Josselin Mouette’s post, I got aware of a list of issues posted by JP Rosevear, which is a reply to Mark Shuttleworths post to the opensuse mailinglist. Note especially point 2, which is: “Preventing the Debian GNOME maintainer from updating GNOME packages until after Ubuntu LSO had shipped because you had hired him.”

If this issue is true, it’s the worst thing I ever heard of regarding Canonical. I mean it’s bad enough that points 1 (“Having a stated policy of not funding any significant new software development because the Return on Investment is not good enough”) and 3 (“Not releasing any source code for launchpad/rosetta/malone to maintain a competitive advantage”) certainly are true (even though I can’t prove and therefor don’t 100% believe the second part of #3). But unless there is a very good reason to delay the submission of the patches developed to “upstream”, Debian.
It’s bad enough that Canonical hired the most active Debian Developers, depriving Debian of much of their time, while not really supporting Debian (i.e. while not actively submitting patches to Debian). It would have been better for the community if Canonical had hired less active DDs (or even non-DDs). Sure it would have been harder to select some sufficiently qualified people for the jobs, but the total outcome whould have been better IMHO (getting time from previously uninvolved people, while keeping the existing contributors).

Anyway, I really would like to know wether the mentioned point #2 is true, and if so wether any valid reason for doing so could be given before I set my opinion about this issue in stone.

One thing is sure however, I’m becoming more and more critical regarding Ubuntu and Canonical over time while I once hoped that the opposite would become true for those criticizing Canonical at that time. Actually I still hope so (and thus I hope reason to become less sceptical again).
Another thing is also sure: If Canonical wants to use Debian as a base for much longer, it should make damned sure to work with Debian more actively instead of seemingly working against it (more or less openly).

Update: As also pointed out in a comment below, a post by Scott James Remnant proves point 1 from the the aforementioned list and gives a further hint that point 3 might be true. More precisely it says “we have a policy of not doing our own software development, but only packaging what others have developed”, which probably means “not doing our own major software development”, since – as a comment to that post also says – Canonical did some software development, like launchpad/rosetta/malone and some other relatively small projects.

2006-11-25

live-cd-on-removable-disk

Posted in Computers, PlanetDebian at 02:06 UTC (+0000) by sven

Enrico said in live-cd-on-removable-disk:

Mostly it boils down to running the xorg-creation script at every boot time.

There are various tools to do that. Some are here, but there is surely more. (Enrico’s note: do we have anything in Debian that we can install and just does that?)

Well, Enrico, a tool I really grew fond of, which auto-configures X on Debian systems is xdebconfigurator, it lacks being auto-run on each system start, which I consider a feature on normal systems, but for your proposed usage (i.e. a portable USB-storage based Debian system), it would certainly be the right thing.

Essentially, it never failed on me. Except for VMware virtual machines, where all it did wrong was that it proposed too high resolutions which resulted from my dual-screen Windows setup I ran VMware on. You might want to give it a try.

2006-11-19

Why is VoIP/SIP so hard?

Posted in IT-Security, PlanetDebian at 08:47 UTC (+0000) by sven

Eric has asked: Why is video conferencing so hard?

Actually, I would extend that: Why is SIP so hard?

It’s far from being easy to find suitable SIP clients which support chat, voice calls and preferably also video calls. Preferably, I would obviously like to find versions of the same client for different operating systems, but I would actually accept any sufficiently stable clients. Currently, my research is focussed on a Windows client, but I will soon also need one for Linux. As of now, the client closest to what I would like seems to be CounterPath’s eyebeam/X-Lite, which supports chat, voice and video, including proper presence support, but it has several problems, the most annoying ones being a nice “little” memory leak (going from 50MB total size to 350MB total size within a few days without much SIP activity) and the fact that it sometimes uses up 100% CPU while putting itself to high priority, which makes it almost impossible to recover from this without a hardware reset.

I’m glad WengoPhone went GPL[*] for their 2.0 version. From what I saw, WengoPhone is quite promissing and the fact that it is now opensource makes it much more likely that it evolves quickly into a stable, portable and usable platform for SIP telephony.

Anyway, if someone knows good SIP clients, which support at least voice and IM/chat and run on Windows or Linux (preferably both), I would surely be interested.

[*] In case anyone wonders like I did: the source for the WengoPhone 2.0 pre-releases/release candidates is available only via a subversion checkout as described in their wiki.

2006-11-18

CDBS and kittens

Posted in Computers, PlanetDebian at 06:52 UTC (+0000) by sven

Steinar H. Gunderson wrote about CDBS once again, and I couldn’t agree more. CDBS introduces a lot of complexity for non-trivial packages, and it especially is basically undocumented. So what is CDBS’s value? For non-trivial packages, it is hard to use, since you basically need to decipher the CDBS code. For trivial packages however, it doesn’t add much value over dh_make. That’s actually sad: I like the general idea behind CDBS, but it is implemented badly IMHO. What it should do, if implemented right is to automate anything you want done on an easy package while providing and documenting (which includes consistently named hooks and options) all the interfaces needed to maintain non-trivial packages. Ideally, this would even include packages which need multiple build runs (like providing two differently configured versions of the same binary in two packages). But as said: It would need consistent names and proper documentation, and CDBS fails both currently. I however hope this improves in the future. Don’t ask me to work on this however, since personally, I’m quite happy using debhelper on my packages, since it is removing complexity (not typing work or lines of code) from debian/rules while keeping it obvious from that file what is done during a build.

I would really like to see the reasoning from Erich on why he thinks CDBS is NMU-friendly, since I don’t get why he thinks so from his blog post.

2006-11-13

Dual boot and full encryption

Posted in Computers, IT-Security, PlanetDebian at 18:32 UTC (+0000) by sven

I’m trying to set up a laptop which needs as much security and privacy as I can get. It turns out the main problem is that I want and need dual-boot: Windows XP Professional and Linux (Debian Etch). Now, Encrypting of all partitions used (except /boot of the Debian installation) is a must. Without dual-boot, this won’t be any problem, but not with the wish to dual-boot.

The Linux side isn’t a real problem, I simply use a dm-crypt’ed partition as the only “physical” volume in an LVM volume group, which contains three logical volumes: Swap, / and /home. This means I only need to enter my LUKS/dm-crypt password once during boot.

Shared partitions (shared between Windows and Linux) are also encrypted with dm-crypt/LUKS and decrypted by FreeOTFE (which is a really nice little OpenSource tool BTW), formatted as FAT32.

The Windows side on its own won’t be too much of a problem either, since BestCrypt, PGP Whole Disk Encryption as well as DriveCrypt PlusPack (this probably isn’t a complete list) allow encryption of the Windows boot partition, but at least the latter two need their pre-boot authentication part (which is needed to be able to decrypt the Windows boot partition) to be installed into the MBR.

Now, I wasn’t yet able to get Linux installed to the disk without breaking the Windows decryption. If anyone knows a program which allows encryption of the Windows boot partition and dual-booting into Linux, I would welcome a hint. Preferably, this solution should use grub as the primary boot manager.

2006-11-08

/usr/lib/X11/fonts/CID – Which fonts would go there?

Posted in Computers, PlanetDebian at 21:49 UTC (+0000) by sven

Today at work, I wondered about xfs, which logged the following warnings via syslog:

xfs xfs: ignoring font path element /usr/lib/X11/fonts/cyrillic/ (unreadable)
xfs xfs: ignoring font path element /usr/lib/X11/fonts/CID (unreadable)

After investigation, I found them to be configured in /etc/X11/fs/config, which look sane even though those paths don’t exist. However, searching through all the Debian packages available to my system (which include several non-free repositories), I was only able to find one package providing fonts in .../fonts/cyrillic, but none providing fonts in .../fonts/CID. I would be interested to know why that path was included in the default search path for xfs. Not even the evil msttcorefonts package installs any fonts in that path. Could anyone refer to anything that uses (or used) that path?

Granted, x-ttcidfont-conf refers to CID fonts, but no other package seems to mention them, so why is that path in the default config? I admit I’m quite puzzled.