Re: GSoC?

[Dan Williams <dcbw redhat com>]

On Sun, 2010-03-21 at 09:31 -0400, Daniel Gnoutcheff wrote:
> Hello all!
> 
> Is N-M involved/interested in the Google Summer of Code this year? In
> previous years, I see that N-M participated in GSoC through the Linux
> Foundation. Will that be happening again this year?

I hope so :)  I've fired off an email to the right place to make sure we
get that cleared up before applications start getting accepted.

> If so, awesome! I've been wanting to apply to GSoC for a long time, and
> N-M is one project I'm quite interested in.

Rockin'

> Below, I have a few "preliminary project proposals". I'd be delighted if
> someone could let me know if any of these ideas are sensible. I plan to
> pick the best one and develop it into a full proposal.
> 
> Autobiography: CS major, math minor, working through my 3rd year. I
> spent my last two summers working on programming projects for professors
> through the Union College summer undergrad research program, the results
> of which are posted at [1]. I'm a major FOSS enthusiast, and for some
> time I've been itching to become a contributor; I'm interested in pretty
> much anything that will help free software succeed on the desktop. :) Up
> until now, however, academics have always gotten in the way, so I
> haven't managed to do much more than dabble in it (tracking down an
> elusive kernel regression [2] is my best accomplishment so far).
> However, I'm hoping that GSoC can give me the kick that I need. :)
> 
> Preliminary proposals follow:
> 
> 
> =============================
> 1. Improving DHCP lease reuse
> 
> This is essentially a continuation of what I started at [3].
> 
> NM already helps dhclient maintain separate lease databases for each
> connection, and this is already used to speed up lease renewal when
> connecting to a network we've seen before. However, dhclient also has
> support for testing and reusing unexpired leases in the case that we are
> unable to contact a DHCP server, and by making N-M more "correct" in its
> usage of dhclient, we can take advantage of this. This would make N-M
> really robust when dealing with DHCP servers, enough so to survive even
> the junk from my college's IT department. ("If anyone can get an IP out
> of those things, N-M will! So install Linux already!" :)

This would be good; though I'm not sure if there's quite enough on the
DHCP front to take up a whole summer.

> According to the dhclient-script(8) manpage, dhclient-scripts are
> expected to do things like return with nonzero exit status if the IP
> address we've been given is already used by someone else (e.g. as
> indicated by arping -D). And in the case where no DHCP server has been
> reached but unexpired leases are available, the dhclient-script is run
> (with $reason=TIMEOUT) and given a config from an unexpired lease, and
> the script check if the given config is usable (e.g. we can ping the
> specified router). This is the mechanism that dhclient uses to re-use
> existing leases when no DHCP servers are reachable. Currently, the
> "script" supplied by NM (callouts/nm-dhcp-client.c) unconditionally
> returns with exit status zero, so none of this happens yet.
> 
> 
> ====================
> 2. UserSettings work
> 
> We have a couple of problems with how user-specific connections are
> managed right now, particularly in that it doesn't work with fast user
> switching and in that it's tricky for apps to manipulate user-defined
> connections without actually being the NM user settings service. This
> project would be about addressing at least one of those problems.

Right; I've got ideas on how to fix both of these, but not enough time
to implement them.  Sounds like a perfect opportunity for SOC :)
There's various mails I've sent and stuff in the bugs for these that
explain how I'd go about it if if/when I have time, but if there are
better ideas bring those forward too.

These two items could certainly occupy you for the full summer.

> I would use the GSoC "community bonding" period as a chance to try and
> brainstorm up the best way to do this. I do share Andrey Borzenkov's
> concern [4] that the "standard" plan may lead to duplicated effort in
> each of the client apps (nm-applet, knetworkmanager, etc.), and in the
> case of fast-user-switching, I'm worried about what would happen if a
> bugged or malicious user settings service refused to give up
> org.freedesktop.NetworkManagerUserSettings when expected. However, if I
> don't get any good ideas by the time coding starts, I'd plan to follow
> the "standard" plan outlined in [5] and [6].
> 
> I'm pretty new to D-Bus, but I know from my summer research experience
> that I can get up to speed with such things pretty quickly, so I'm
> pretty sure I could do at least the fast-user-switching half of this.
> 
> 
> ============================
> 3. Noncellular modem support
> 
> This technology is indeed quite obsolete in many circles, but there are
> a considerable number of people still stuck with it, either because they
> can't afford anything better or because they are in an area where
> old-school dial-up is the only 'net connection available. Last fall, I
> volunteered for an organization that "recycles" old computers and gives
> them away to people in need [7], and of the people we give computers to,
> the majority are dial-up users. I'm hoping to convince this organization
> to install GNU/Linux on the machines they give out, and having
> first-class noncellular dial-up support in N-M would be a major help. :)
> 
> I admit that, out of all my proposals here, this is the project I have
> the least background knowledge for; I don't know very much about how
> these old-school modems work. However, I do have tons of hardware to
> test with, coupled with a definite willingness to teach myself all about
> it. :)

This is also something that could take a full summer, and would be quite
useful.  I'm a bit torn here though, because I know #2 is useful to many
more people than #3, but #3 is also useful to a number of people who
need the functionality very much.  I personally don't have a dialup line
to test with so I could only get so far.  But this is also another good
project.

Dan