I disagree with Lars.
Respect needs to be earned. It should not be a default,
and it should not be demanded either on one's own behalf
or for others, or you are conflating it with something
incredibly ignoble.
When you do not respect someone, and you show that
person respect, you are being deceitful. Of this
I disapprove.
On a private mailing list there was some discussion, and I had an
outburst. Summarising very roughly, someone said bad things about
their competitor, without (at first) offering any justification.
Here's a version of my outburst, edited to remove references to
the actual topic and identifyable people. I thought it might amuse
me in fifty years or so to see how full of myself I was.
The relationship between Debian and Ubuntu has been the subject of many
vigorous debates over the years, ever since Ubuntu s launch in 2004.
Six years later, the situation has improved and both projects
are communicating better. The Natty Narwhal Ubuntu Developer
Summit (UDS) featured like all UDS for more than 2 years a Debian
Health Check session where current cooperation issues and projects are
discussed. A few days after that session, Lucas Nussbaum gave a talk
during the mini-Debconf
Paris detailing the relationship between both projects, both at the
technical and social level. He also shared some concerns for Debian s
future and gave his point of view on how Debian should address them.
Both events give valuable insights on the current state of
the relationship.
Lucas Nussbaum s Debian-Ubuntu talk
Lucas started by introducing himself. He s an Ubuntu developer since 2006
and a Debian developer since 2007. He has worked to improve the collaboration
between both projects, notably by extending the Debian infrastructure to show
Ubuntu-related information. He attended conferences for both projects
(Debconf, UDS) and has friends in both communities. For all of these reasons,
he believes himself to be qualified to speak on this topic.
Collaboration at the technical level
He then quickly explained the task of a distribution: taking upstream
software, integrating it in standardized ways, doing quality assurance on
the whole, delivering the result to users, and assuring some support
afterward. He pointed out that in the case of Ubuntu, the distribution
has one special upstream: Debian.
Indeed Ubuntu gets most of its software from Debian (89%), and
only 7% are new packages coming from other upstream projects (the
remaining 4% are unknown, they are newer upstream releases of software
available in Debian but he was not able to find out whether the Debian
packaging had been reused or not). From all the packages imported from
Debian, 17% have Ubuntu-specific changes. The reasons for those changes
are varied: bugfixes, integration with Launchpad/Ubuntu One/etc., or
toolchain changes. The above figures are based on Ubuntu Lucid (10.04) while
excluding many Ubuntu-specific packages (language-pack-*, language-support-*,
kde-l10n-*, *ubuntu*, *launchpad*).
The different agendas and the differences in philosophy (Debian
often seeking perfect solutions to problems; Ubuntu accepting
temporary suboptimal workarounds) also explain why so many packages are
modified on the Ubuntu side. It s simply not possible to always do the
work in Debian first. But keeping changes in Ubuntu requires a lot of work
since they merge with Debian unstable every 6 months. That s why they have
a strong incentive to push changes to upstream and/or to Debian.
There are 3 channels that Ubuntu uses to push changes to Debian: they
file bug reports (between 250 to 400 during each Ubuntu release cycle),
they interact directly with Debian maintainers (often the case when
there s a maintenance team), or they do nothing and hope that the Debian
maintainer will pick up the patch directly from the Debian
Package Tracking System (it relays information provided by patches.ubuntu.com).
Lucas pointed out that those changes are not the only thing that
Debian should take back. Ubuntu has a huge user base resulting in lots of
bug reports sitting in Launchpad, often without anyone taking care of
them. Debian maintainers who already have enough bugs on their
packages are obviously not interested in even more bugs, but those who are
maintaining niche packages, with few reports, might be interested by the
user feedback available in Launchpad. Even if some of the reports are
Ubuntu-specific, many of them are advance warnings of problems
that will affect Debian later on, when the toolchain catches up with
Ubuntu s aggressive updates. To make this easier for Debian maintainers,
Lucas improved the Debian Package Tracking System so that they can easily
get Ubuntu bug reports for their packages even without interacting with
Launchpad.
Human feelings on both sides
Lucas witnessed a big evolution in the perception of Ubuntu on the Debian
side. The initial climate was rather negative: there were feelings of its work
being stolen, claims of giving back that did not match the observations of
the Debian maintainers, and problems with specific Canonical employees
that reflected badly on Ubuntu as a whole. These days most Debian developers find
something positive in Ubuntu: it brings a lot of new users to Linux, it
provides something that works for their friends and family, it brings new
developers to Debian, and it serves as a technological playground for
Debian.
On the Ubuntu side, the culture has changed as well. Debian is no
longer so scary for Ubuntu contributors and contributing to Debian is The
Right Thing to do. More and more Ubuntu developers are getting involved in Debian
as well. But at the package level there s not always much to contribute, as
many bugfixes are only temporary workarounds. And while Ubuntu s
community follows this philosophy, Canonical is a for-profit company that
contributes back mainly when it has compelling reasons to do so.
Consequences for Debian
In Lucas s eyes, the success of Ubuntu creates new problems. For many
new users Linux is a synonym for Ubuntu, and since much innovation happens
in Ubuntu first, Debian is overshadowed by its most popular derivative.
He goes as far as saying that because of that Debian becomes less
relevant .
He went on to say that Debian needs to be relevant because the
project defends important values that Ubuntu does not. And it needs to
stay as an independent partner that filters what comes out of Ubuntu,
ensuring that quality prevails in the long term.
Fixing this problem is difficult, and the answer should not be
to undermine Ubuntu. On the contrary, more cooperation is needed. If
Debian developers are involved sooner in Ubuntu s projects, Debian will
automatically get more credit. And if Ubuntu does more work in
Debian, their work can be showcased sooner in the Debian context as
well.
The other solution that Lucas proposed is that Debian needs to
communicate on why it s better than Ubuntu. Debian might not be better for
everybody but there are many reasons why one could prefer Debian over
Ubuntu. He listed some of them: Debian has better values
since it s a volunteer-based project where decisions are made publicly
and it has advocated the free software philosophy since 1993. On the other hand,
Ubuntu is under control of Canonical where some decisions are imposed, it
advocates some proprietary web services (Ubuntu One), the installer
recommends adding proprietary software, and copyright assignments are
required to contribute to Canonical projects.
Debian is also better in terms of quality because every package has a
maintainer who is often an expert in the field of the package. As a
derivative, Ubuntu does not have the resources to do the same and instead
most packages are maintained on a best effort basis by a limited set of
developers who can t know everything about all packages.
In conclusion, Lucas explained that Debian can neither ignore Ubuntu
nor fight it. Instead it should consider Ubuntu as a
chance and should leverage it to get back in the center
of the FLOSS ecosystem .
The Debian health check UDS session
While this session has existed for some time, it s only the second
time that a Debian Project Leader was present at UDS to discuss collaboration
issues. During UDS-M (the previous summit), this increased involvement
from Debian was a nice surprise to many. Stefano
Zacchiroli the Debian leader collected and shared the
feedback of Debian developers and the session ended up being very
productive. Six months later is a good time to look back and verify
if decisions made during UDS-M (see blueprint)
have been followed through.
Progress has been made
On the Debian side, Stefano set up a Derivatives
Front Desk so that derivative distributions (not just Ubuntu)
have a clear point of
contact when they are trying to cooperate but don t know where to start.
It s also a good place to share experiences among the various
derivatives. In parallel, a #debian-ubuntu channel has been started on OFTC (the
IRC network used by Debian). With more than 50 regulars coming from both
distributions, it s a good place for quick queries when you need advice
on how to interact with the distribution that you re not familiar
with.
Ubuntu has updated its documentation to prominently feature how to
cooperate with Debian. For example, the sponsorship process
documentation explains how to forward patches both to the upstream
developers and to Debian. It also recommends ensuring that the patch
is not Ubuntu-specific and gives some explanation on how to do it (which
includes checking against a list of common packaging
changes made by Ubuntu). The Debian Derivative Front Desk is
mentioned as a fallback when the Debian maintainer is unresponsive.
While organizing Ubuntu Developer
Week, Ubuntu now reaches out to Debian developers and tries to have
sessions on working with Debian . Launchpad has also been extended to provide a list of bugs with
attached patches and that information has been integrated in the Debian
Package Tracking system by Lucas Nussbaum.
Still some work to do
Some of the work items have not been completed yet: many
Debian maintainers would like a simpler way to issue a sync request (a
process used to inject a package from Debian into Ubuntu).
There s a requestsync command line tool provided by the ubuntu-dev-tools package (which is available in Debian) but it s not yet usable because
Launchpad doesn t know the GPG keys of Debian maintainers.
Another issue concerns packages which are first introduced in Ubuntu.
Most of them have no reason to be Ubuntu-specific and should also end up
in Debian. It has thus been suggested that people packaging new software
for Ubuntu also upload them to Debian. They could however
immediately file a request
for adoption (RFA) to find another Debian maintainer if they
don t plan to maintain it in the long term. If Ubuntu doesn t make
this effort, it can take a long time until someone decides to reintegrate
the Ubuntu package into Debian just because nobody knows about it.
This represents an important shift in the Ubuntu process and it s not
certain that it s going to work out. As with any important policy change,
it can take several years until people are used to it.
Both issues have been rescheduled for this release cycle, so they re still on the agenda.
This time the UDS session was probably less interesting than the
previous one. Stefano explained
once more what Debian considers good collaboration practices: teams
with members from both distributions, and forwarding of bugs
if they have been well triaged and are known to apply to Debian. He also
invited Ubuntu to discuss big changes with Debian before implementing
them.
An interesting suggestion that came up was that some Ubuntu developers could
participate in Debcamp (one week hack-together before Debconf) to work
with some Debian developers, go through Ubuntu patches, and merge the
interesting bits. This would nicely complement Ubuntu s increased presence
at Debconf: for the first time, community management team member Jorge Castro was at DebConf 10 giving a talk on
collaboration between Debian and Ubuntu.
There was also some brainstorming on how to identify packages where the
collaboration is failing. A growing number of Ubuntu revisions (identified
for example by a version like 1.0-1ubuntu62) could indicate that no
synchronization was made with Debian, but it would also identify packages
which are badly maintained on the Debian side. If Ubuntu consistently has
a newer upstream version compared to Debian, it can also indicate a
problem: maybe the person maintaining the package for Ubuntu would be better
off doing the same work in Debian directly since the maintainer is lagging or not
doing their work. Unfortunately this doesn t hold true for all packages
since many Gnome packages are newer in Ubuntu but are actively maintained
on both sides.
Few of those discussions led to concrete decisions. It seems most
proponents are reasonably satisfied with the current situation. Of course,
one can always do better and Jono Bacon is going to ensure that all
Canonical teams working on Ubuntu are aware of how to properly cooperate
with Debian. The goal is to avoid heavy package modifications without
coordination.
Conclusion
The Debian-Ubuntu relationships used to be a hot topic, but that s no
longer the case thanks to regular efforts made on both sides. Conflicts
between individuals still happen, but there are multiple places where they
can be reported and discussed (#debian-ubuntu channel, Derivatives
Front Desk at derivatives@debian.org on the
Debian side or debian@ubuntu.com on
the Ubuntu side). Documentation and infrastructure are in place to
make it easier for volunteers to do the right thing.
Despite all those process improvements, the best results still come out
when people build personal relationships by discussing what they
are doing. It often leads to tight cooperation, up to commit rights to the
source repositories. Regular contacts help build a real sense of
cooperation that no automated process can ever hope to achieve.
This article was first published in Linux Weekly News. You can get my monthly summary of the Debian/Ubuntu news, all you have to do is to click here to subscribe to my free newsletter.
5 comments Liked this article? Click here. My blog is Flattr-enabled.
The Ubuntu Technical Board is currently conducting a review of the top ten Brainstorm issues users have raised about Ubuntu, and Matt asked me to investigate and respond to Idea #25301: Keeping the time accurate over the Internet by default.
My first reaction was "hey, that's odd - I thought we already did that?". We install the ntpdate package by default (although it's deprecated upstream in favour of other tools, but that shouldn't be important here). ntpdate is run from /etc/network/if-up.d/ntpdate, in other words every time you connect to a network, which should be acceptably frequent for most people, so it really ought to Just Work by default. But this is one of the top ten problems where users have gone to the trouble of proposing solutions on Brainstorm, so it couldn't be that simple. What was going on?
I brought up a clean virtual machine with a development version of Natty (the current Ubuntu development version, which will eventually become 11.04), and had a look in its logs: it was indeed synchronising its time from ntp.ubuntu.com, and I didn't think anything in that area had changed recently. On the other hand, I had occasionally noticed that my own laptop wasn't always synchronising its time quite right, but I'd put it down to local weirdness as my network isn't always very stable. Maybe this wasn't so local after all?
So, I started tracing through the scripts to figure out what was going on. It turned out that I had an empty /etc/ntp.conf file on my laptop. The /usr/sbin/ntpdate-debian script assumed that that meant I had a full NTP server installed (I don't), and fetched the list of servers from it; since the file was empty, it ended up synchronising time from no servers, that is, not synchronising at all. I removed the file and all was well.
That left the question of where that file came from. It didn't seem to be owned by any package; I was pretty sure I hadn't created it by hand either. I had a look through some bug reports, and soon found ntpdate 1:4.2.2.p4+dfsg-1ubuntu2 has a flawed configuration file. It turns out that time-admin (System -> Administration -> Time and Date) creates an empty /etc/ntp.conf file if you press the reload button (tooltip: "Synchronise now"), as part of an attempt to update NTP configuration. Aha!
Once I knew where the problems were, it was easy to fix them. I've uploaded the following changes, which will be in the 11.04 release:
ntp.conf files in ntpdate-debian./etc/ntp.conf file on fresh installation of the ntp package, so that it doesn't interfere with creating the normal configuration file.time-admin backend if it doesn't exist already.ntp.ubuntu.com then you'll have to change the value of NTPSERVERS in /etc/default/ntpdate. Furthermore, the time-admin interface is confusing and makes it seem as though the default is not to synchronise the time automatically; this interface is being redesigned at the moment, which should be a good opportunity to make it less confusing, and I will contact the designers to mention this problem. On the whole, though, I think that many fewer people should have this kind of problem in Ubuntu 11.04.
It's always possible that I missed some other problem that breaks automatic time synchronisation for people. Please do file a bug report if it still doesn't work for you in 11.04, or contact me directly (cjwatson at ubuntu.com).
Jon Downland is tinkering with Puppet,
and wrote a class with a package resource to install a bunch of packages, but
didn't quite like the way it was written.
The way that I'd achieve the same thing, and be slightly cleaner would be
something like this:
class jon-desktop $packages_to_install_by_default = [ 'icedove', 'git-core', 'vim-gnome', 'vinagre', 'build-essential', 'devscripts', 'subversion', 'git-buildpackage', 'mutt', 'offlineimap', 'ascii', 'gitk', 'chromium-browser', ] package $packages_to_install_by_default: ensure => installed,This way your actual package resource definition never needs to change. The variable you choose to use to define the list of packages to install can be abstracted away as much as desired.
Argh. So of course there's a difference between CONFIG_USB_SERIAL=y and
CONFIG_USB_SERIAL=m, and that would explain the behavior I'm seeing. Thanks
Ben
Hutchings.
I guess I'm recompiling my kernel again. Kill me now.
Seriously, the amount of yak shaving I'm doing these days...
So I discover this
CONFIG_USB_SERIAL_CONSOLE config option. I proceed to edit my
.config, throw it in there and rebuild my kernel. (For the record,
I hate building kernels). I'm about to reboot into said new kernel, and I
thought I'd just double check the resulting config-2.3.36 file to check that
CONFIG_USB_SERIAL_SERIAL did indeed get enabled. It's not there.
I spend a few minutes WTFing, and assume I've been an idiot and should have
run a make oldconfig or some such thing after hand-editing my
.config file. So I try that. The additional line vanishes again
afterwards. More WTFing ensues.
I fire up make menuconfig, and go looking for the menu entry for
the option. It's not there. The plot thickens.
I hand-edit drivers/usb/serial/Kconfig and change depends
on USB_SERIAL=y to just depends on USB_SERIAL, and rerun
make menuconfig, and lo and behold, the option appears!
So now I'm off rebuilding the kernel again.
Sigh.
As a first step on
the road to evaluating different configuration management systems, I set up
two VMs to test out puppet.
Puppet is conveniently packaged within Debian so client and server
installation was very simple. By default, puppet clients will look for a host
named puppet on the local network, so by naming the server sensibly the two
started talking to each other. puppetca --sign [client hostname] on the
server started the ball rolling.
My first test configuration was to add a user to the sudoers file. With
CF Engine 2, I would have achieved this by using editfiles to check for a
regular expression and insert a line if necessary. I stumbled across some
CF Engine-style definitions for puppet in a Debian Administration
article (taken originally
from puppet's own wiki, which have since been moved/deleted) and achieved it
using
append_if_no_such_line sudo:
file => "/etc/sudoers",
line => "jon ALL=(ALL) ALL"
jon ALL=(ALL) ALL, it won't match exactly and a
duplicate line will be appended, whereas with CF Engine 2 I would have checked
for something like ^jon \+ALL=(ALL) \+ALL$.
I set up my work laptop as another test node, and used puppet to install some
packages that I commonly use:
class jon-desktop
package ['icedove', 'git-core', 'vim-gnome', 'vinagre', 'build-essential',
'devscripts', 'subversion', 'git-buildpackage', 'mutt',
'offlineimap', 'ascii', 'gitk', 'chromium-browser'
]: ensure => installed
puppet on
foreign networks (such as my home network). I would have assumed that, once
the strong SSL association had been made, the client would try to connect to
the FQDN of the server. This probably isn't a serious problem in practice,
as we probably won't need to rely on nodes off-site talking to the
configuration server, but I hope that the client doesn't trust any host that
happens to answer to puppet...
I fixed this by hacking my hosts file to include an entry for puppet. I
could maintain this hack using Puppet itself, which would protect me against
stale definitions if any renumbering takes place. I could also have added a
line
server = puppet.fqdn.example.org
/etc/puppet/puppet.conf, which is a more robust way of solving the
problem.
This week I had to write a little tool that would collect input on
different channels, via socket / netcat, via a http server, .... Calls
for a parralel Design -- Maybe a good place to write something real in
Erlang. While erlang itself was really nice
to write -- I do like Prolog as well as the bunch of functional
languages -- doing networking in erlang seems a bit special, the
interfaces just aren't thin wrappers around the libc stuff.
Getting a Socket Text interface
What sounds like a easy challenge to accomplish was actually harder
than expected. All I found was some way to pass binaries representing
erlang code over a socket and evaluating it remotle. While it's nice
that such things are as easy to do as they are it doesn't help me with
my task of moving simple strings.
start() ->
ok, Listen = gen_tcp:listen(51622, [binary, packet, 0 ,
reuseaddr, true ,
active, true ]),
spawn(fun () -> accept_loop(Listen) end).
accept_loop(Listen) ->
ok, Socket = gen_tcp:accept(Listen),
accept_loop(Listen),
handle(Socket)
handle(Socket) ->
receive
tcp, Socket, Bin ->
io:format("~p~n", binary_to_list(Bin));
tcp_closed, Socket ->
Buffer
end.
spawn() at the right place. The right place is not
the handle(Socket) but the accept_loop(Listen) because the process
that called accept will receive all the tcp messages.
This last part was quite obvious after finding the documentation of
the active, _ properties for the socket. always here means that
you'll receive all data from the socket as erlang Messages, once
delivers one package and waits until it is activated again and false
requires calling a method -- this would have been possible as well
when forking handle(Socket).
The web server
Ok we also want a webserver. We do not want to run some
webapplication inside appache or so, just do some post/get and simple
pages. Erlang here provides a built-in httpd with some mod_esi
that calls some function depending on the URL used. It doesn't do
anything fancy like templating or DB backends or stuff, just taking
strings and building the http answers.
Unfortunately there are no examples around and basically noone seems
to be using this combination (apart from some hacks like mine
probably). So as I needed to get some additional information into the
handler function (a Pid to connect to some service), I, as a novice,
just couldn't find a way. Asking on IRC the solution was rather
simple: Just using erlang's process registry. For more complex stuf
gproc might prove usefull here.
Result
I guess I've got a huge step farther in programming erlang now. The
manpages are easily found by your search engine -- for python I have
to either walk through the (well structured) online documentation or
search for the right link in the search results, for erlang they're
typically first. Also
Joe Armstrong's Books
as proven usefull. The most dificult part probably is getting around
all the nice extras you can do (transfering functions over sockets et
al) and find out how to do the thing you need.
A few weeks ago it became apparent to me that I may end up having to run
Windows on my work PC. We're getting new machines soon with Vista images
preloaded. There's a Linux image option (of unknown base, but possibly
Ubuntu), but I've kinda been assuming that I could
continue in my current approach - I run Debian, and accept that IT won't give me any
support in doing so other than caring about the hardware. Seems like a
reasonable deal to me. Except it requires an infrastructure that's
platform agnostic, and that's the problem. There's a danger our new bug
tracking system is much, much happier in IE than anything else. That's
kinda a problem if I can't access it. The event last week was around a
web streamed meeting, which is annoying but not as critical.
I was unhappy at this realization. Very unhappy. And yet I had trouble
finding the words to explain why. I don't do Linux advocacy these days
(I'm not sure I ever really did). I probably gave up at the point my
parents' bought a replacement machine for my mother while I was living
in England and went for a Windows box (she'd been running Debian)
because "they had knowledge of that in the house given I wasn't around".
And then promptly rang me after it arrived to ask how to configure
networking.
Anyway. If I can't come up with some decent reasons about why I run
Linux over Windows then I can't justifiably complain if I end up with a
Windows desktop. So I think I need to collect together some thoughts
about it. I'll try to break them up into a bunch of separate posts
rather than one huge dump that no one will read.
Let's start with the obvious:
Familiarity
This was the first question a coworker asked; is it because you're used
to Linux? And it would be untruthful to say that doesn't play a part.
I've been running Linux on the desktop for the past 12 years or so
(well, I had few years running FreeBSD on my primary desktop too, but
close enough). The only time I've ended up with a Windows desktop was
when I worked for Aviva. I don't currently have a working Windows
install anywhere. I have little experience of working with Windows these
days. I mean, I can do it, but I don't find it comfortable (to the
extent that I managed about 3 hours when I ended up with a Windows
desktop back in August before installing Debian on it).
That's the argument often used to stay with Windows (as per my parents,
above). And it's not accurate. Why did I try Linux in the first place,
and stick with it long enough to get to this point?
Guillermo Garron of Go2Linux enjoys a lot the People behind Debian interviews that I make. That s why he interviewed me (with somewhat similar questions) and published the result on his blog.
Click here to read the full interview. I speak of my Debian projects, of the Ubuntu-Debian relationship, and more.
The question that I would like to highlight is What s the biggest problem of Debian? . I answered this:
Our project identity is somewhat minimalistic. It evolves around the social contract and the Debian Free Software Guidelines. Both documents answer the question of what we re doing but we lack a clear answer to the question of how we re supposed to work towards our goals. It would be great if Debian could agree on some principles concerning topics like goal setting, collaboration, team work, politeness, respect. We could then advertise those and build on them while recruiting volunteers.PS: The interview also hit LinuxToday.
No comment Liked this article? Click here. My blog is Flattr-enabled.
It was unfortunate when Sony decided to pull out the Other OS support from PS3. One of the reasons of convincing myself to buy it was this feature. With that feature gone, the PS3 stood as nothing much but mostly a media center and an occasional game box.
But with the Move, I think they have compensated it. It is a greatly engineered product with very good accuracy. It has been a week and I've been thoroughly enjoying it. I liked the packaging too. One single compilation of Sports Center contains like 5 games in it. Just the Table Tennis alone is worth it. But there are more that I need to try.
Another surprising factor was pricing. United States pricing for the starter pack is expensive than at what I got here. This was something I didn't expect at all.
Thank you Sony for creating a good product.
A continuation of my intermittent series on Emdebian. This time covering how Emdebian changes component behaviourin Emdebian Grip.
deb http://www.emdebian.org/grip squeeze main dev debug java doc
The screenshots.debian.net site is a public repository of screenshots taken from applications contained in the Debian GNU/Linux distribution and its derivates like Ubuntu.
It was created by Cristoph Haas to help people get an impression of what a certain software will look like on your desktop before you install it. Everybody can take screenshots and upload them through the upload form. So far there are about 3100 screenshots, which is actually a small number if you consider Debian Squeeze contains about 15000 source packages
After I hacked a bit on KSnapshot, the KDE snapshot tool, Sune asked me to add an export to screnshots.debian.net command. I had not thought of it before but that looked like a great idea, it would make the process or taking-screenshot, visit-upload-form, upload-each-screen so much easier!. So I started to develop my first KIPI plugin.
Here is the resulting Debian Screenshots plugin, as you would use it in KSnapshot:
Being a KIPI plugin, it is available not only from KSnapshot but also from Digikam, Gwenview and the other applications which support KIPI plugins:
Which makes me think: what about having a debshots (the software powering screenshots.debian.net) installation over at kde.org and have screenshots for all the KDE applications? What do you think? Promo team? Sysadmins? Setting it up shouldn t be difficult: I m no Python or Pylons expert (I m more of a Ruby and Wt C++ guy 
and got it running in a VM in an afternoon, even solving some SQLAlchemy 0.6 issues.
My name is Pau and I am a software developer at Arisnova, a Spanish company specialized in Linux and Windows software development for the supervision and control (SCADA) of industrial environments.
In Debian, I am the maintainer of:
Hace ya alg n tiempo escrib sobre el uso de libpam-ccreds y libnss-db para conseguir la implementaci n de un servicio de cach de credenciales. Sin embargo, hace casi un a o revisit el producto Likewise Open, en un proyecto grande de autenticaci n de Linux contra un Active Directory de Microsoft, o contra un dominio Windows desarrollado con Samba.
En realidad Likewise Open elimina la incertidumbre de un setup artesanal de cach de credenciales, siempre y cuando el equipo se est loggeando contra un dominio Windows.
Si usted tiene la necesidad de integrar una distribuci n de Linux moderna (una versi n reciente de Debian, Ubuntu, Fedora, por ejemplo) con un dominio Windows servidor por un Active Directory o por Samba, mi recomendaci n es que use Likewise Open. Likewise es libre, abierto y gratuito, y viene en los repositorios de muchas distribuciones, o se baja de la p gina Web de Likewise.
Tiene dos versiones (paquetes), likewise-open-gui y likewise-open; el primero instala el segundo y ofrece una interfaz gr fica sencilla para unir el equipo al dominio. Solo se requiere el nombre del dominio, el nombre del equipo (se toma de hostname) y el usuario y la clave de un usuario que pueda agregar equipos al dominio.
Como siempre, la resoluci n del dominio se hace consultando al DNS provisto en la configuraci n de red (u otorgado por el DHCP) por ciertos registros SRV, para obtener la IP de uno de los controladores de dominio, y luego ciertas conexiones a algunos puertos del controlador de dominio. Por lo tanto es importante que, si va a probar este escenario en una m quina virtual, la conexi n est en modo puente con la red en la que se encuentra el controlador de dominio.
Una vez que el equipo se une al dominio, se crea la cuenta de m quina en el controlador de dominio, y al cerrar la sesi n, ya pueden ingresar a Linux los usuarios del dominio, usando la sintaxis DOMINIO.AD\usuario o DOMINIO\usuario (formas largas y cortas) y la contrase a del dominio. Las pol ticas de inicio de sesi n y contrase as ser n respetadas.
Tambi n se puede usar domainjoin-cli para unirse por CLI.
Obviamente, Likewise ya ofrece el servicio de cach de credenciales y de cach de usuarios y grupos (importa los grupos del dominio) y lo hace de forma transparente.
Por ello, en muchos casos yo recomendar a que si tienes un OpenLDAP y quieres hacer cach con pam-ccreds y nss-db, haz un upgrade de OpenLDAP a un dominio usando Samba y usa Likewise. Ahorra muchos dolores de cabeza.
En Likewise Open no hay soporte para GPOs. En ning n caso funcionar n las GPO que se hacen para Windows, pero en versiones pagadas de Likewise hay una funci n que a ade nuevas GPO para GNOME y otras aplicaciones. No he probado estas funcionalidades.
bash (<= 2.7) to check all version of bash in the universe with version greater than 2.7.Next.