Thursday 19 February 2009 at 2:51 pm
So there was a recent thread on the Destop Architect's forum, where Dan Kegel discussed the idea of silent upgrades (for Security, at least).
I for one, am not very fond of the idea. Updates/Upgrades (Security or Features) are something which should be done with some Human Intervention. But still it is not an idea to be completely ruled out. Free Software is about choice. There definitely are use cases where Silent Updates look a good choice. With a carefully crafted policy, this could really help achieve the ultimate goal that Dan was looking after. Closing down vulnerabilities asap.
One of the concerns I had was that a mere upgrade is not what can protect vulnerabilites. Standard Package Managers will do the job of updating the vulnerable libraries with the newer patched ones. But they don't come into effect untill re-loaded. Take the browser as an example. It is vulnerable. You silently got it updated by your distro's package manager. But still it is vulnerable. For the patches to be effective, the browser needs a re-start.
In Debian, you could attain Silent Upgrades with some settings defined in apt.
apt ships a /etc/cron.daily/apt script.
So with the following in place:
APT {
Get {
Assume-Yes "true"; Upgrade "true";
}
}
So, with the above settings in place, one can achieve Silent Updates. This ofcourse comes with an assumption that you are not on a Rolling Release of Debian.
But my focus was about getting those patched libraries/binaries effective. So here's the cooled feature of Debian, which has been there for years. apt/dpkg allows you the debconf interface. And there you can set the priority of messages/questions that you'd like to see. So assume that your remote machine, that you access through ssh, has a sshd vulnerability:
Debian updates the sshd package
It'll ask you (Depending of debconf priority), whether it should restart the sshd daemon
And thus you get a patched sshd package, installed, with the patch effective.
I haven't tried but I believe, if you don't install debconf, dpkg/apt will go with the default action that is defined in the package by itself.
So with all this in place, Debian has a very nice approach to package management. I haven't come across a similar interface in any other non-Debian derived distribution.
Wednesday 18 February 2009 at 12:38 am
Now that Lenny is released, we see a lot of reviews around the world. I think most of the reviewers do an unfair comparison for Debian.
I followed Heise Online's review and see that they are comparing Lenny to Ubuntu/Fedora/openSUSE.
IMO, the philosophy behind Debian Stable is very different than that of Fedora/openSUSE/Ubuntu. Fedora/openSUSE are more focused to bring you the latest and greatest. The same applies to Ubuntu (Excluding the LTS release). These are releases where they are targetting users as Beta Testers. And that's good. It brings a good final Stable Release product. But comparing Debian to them is not really correct.
Debian Stable's Release Policy is very well defined. It'll be released when it is ready. A lot has improved there. And also the "Codename and a half" are a very good add-on to the existing process.
Debian Stable should actually be compared against - RHEL/SLES/UBUNTU LTS
Debian Testing should be compared against - Fedora/openSUSE/UBUNTU
This is something reviewers should be educated about. And they should keep this in mind during their reviews. Debian Stable is designed with stabiilty in mind. The focus is more on the Server side.
Sunday 15 February 2009 at 5:27 pm
Amazing Moments
Debian Lenny has been released.
Go, grab now.
Thursday 12 February 2009 at 2:21 pm
So my friend game me a cute little birthday present, a Motorola S9 Bluetooth Headset.
Making it work under Linux was not very difficult but still has to catch-up in terms of utils.
To make the headset work, I just had to run a scan on the Linux host, and get the hw address and specify it in .asoundrc.
pcm.bluetooth {
type bluetooth {
address = xx.xx.xx.xx.xx
description "Motorola S9 Bluetooth Headset"
}
}
And then to play a file, like in mplayer, you just specify the alsa device.
mplayer -ao alsa:device=bluetooth foo.ogg
KDE's Phonon currently doesn't show the Bluetooth Headset even if it is paired.
PulseAudio doesn't work good. (I couldn't make it work in my limited attempt)
Tuesday 10 February 2009 at 10:07 pm
IMO, Linux Distributors should seriously think about Role Based Operations for their distributions.
Every linux user is going to be using his copy of the distribution in a different way. But from the distributor's point of view, it should boil down to:
Desktop Users
Laptop Users
Server Users
Currently, some of the distributions apply this thought only to packages. For example, Ubuntu rolls out a desktop flavor and a server (generic) flavor of its kernel package. I think the distributions need to think broad and realize that NOT One Size Fits All.
Currently, In Debian, the debian installer can detect what kind of hardware you are installing it onto and come up with a base installation proposal. d-i should extend this to configuration modes. For example, if the installation is being done on a laptop, as many as possible services should be configured to start from inetd and not as an ever running daemon.
Here's an example. I love Deiban. :-) They package the entire set of dictionaries. I love to have a handy copy of all the dictionaries in just a couple of megs. And I don't have to worry about the dictionaries being outdated. As soon as a new udpate is out, Debian gets it.
Here's where I see the problem. The dictionary service is something I use in a very limited fashion. Maybe once a day? But still, that _once a day_ usage is important to me.
But this is what my system reports with dictd running:
rrs@champaran:~$ cat /tmp/dictd.memstat | grep dict
1392k: PID 9665 (/usr/share/dictd/bouvier.dict.dz)
176k: /usr/sbin/dictd 9665
2340k: /usr/share/dictd/bouvier.dict.dz 9665
132k: /usr/share/dictd/bouvier.index 9665
196k: /usr/share/dictd/vera.dict.dz 9665
128k: /usr/share/dictd/vera.index 9665
292k: /usr/share/dictd/foldoc.index 9665
2148k: /usr/share/dictd/foldoc.dict.dz 9665
1064k: /usr/share/dictd/freedict-eng-hin.dict.dz 9665
420k: /usr/share/dictd/freedict-eng-hin.index 9665
1064k: /usr/share/dictd/freedict-hin-eng.dict.dz 9665
1228k: /usr/share/dictd/freedict-hin-eng.index 9665
13212k: /usr/share/dictd/gcide.dict.dz 9665
3860k: /usr/share/dictd/gcide.index 9665
560k: /usr/share/dictd/jargon.dict.dz 9665
44k: /usr/share/dictd/jargon.index 9665
10508k: /usr/share/dictd/moby-thesaurus.dict.dz 9665
532k: /usr/share/dictd/moby-thesaurus.index 9665
9248k: /usr/share/dictd/wn.dict.dz 9665
3004k: /usr/share/dictd/wn.index 9665
--------
164444k
Wow!!! That's a good chunk of memory that my dictionary service is using even while I use this service just once a day.
And here's what the output is when I disable my dictd and configure it to run from inetd.
rrs@champaran:~$ cat /tmp/inetd.memstat
--------
109920k
So that brings us to a saving of (164444KiB - 109920KiB) 54524KiB, roughly around 50 MiB of RAM. :-) Sweet.
Point to note is that this is just one service. There can be many more like this. Potential candidate that I can think of right now, from the ones that are installed on my box, are CUPS, Mailserver et cetera.
IMO, it is not just Code Optimization that helps. Some thoughts like these can also help us in many ways.
A lot of people talk about power savings, just think, how much battery power can be conserved with these services were running through inet than always running.
