Hi,
M wrote (01 Apr 2011 22:26:33 GMT) :
> 30.03.2011 21:24, intrigeri пишет:
>> At the end of the day you're probably right, but I'd like to see this
>> decision based on things a bit more convincing than "is definitely
>> harder", see what I mean?
>>
>> Of course, a custom application would need to rewrite some wheels GDM3
>> already has, that is the bits that are common to every display
>> manager. On the other hand, I'm for example wondering, among those
>> interfaces:
>>
>> 1. GDM greeter <-> the rest of GDM
>> 2. {GDM, other display manager} <-> the rest of the desktop stack
>>
>> ... which one has the best documented API with planned backward
>> compatibility?
>>
>> Arguments based on other criteria are obviously welcome as well.
> As you said: custom app means additional code which re-implements dm
> parts.
I must admit I don't really know what the DM's job is in Tails
context, so I fail to see what parts shall be rewritten:
- we don't need remote login (XDMCP et al.)
- we don't need multi-user support
- we don't need user/password input or authentication/PAM support
either, only automated login.
I therefore have the vague feeling Tails actually does not need any DM
at all, hence the "no DM, only a tails-greeter X application"
proposal. So... what would be the job accomplished by a DM (whichever
it is) in Tails?
> More code means harder maintenance. That's the downside. As for
> upside - I do not see any :-)
You provided the upside argument -and also answered my above question-
yourself a few lines bellow: "unstable interface for greeter".
> Speaking of interfaces - I see only 2 choice for dm to plug into:
> - GDM http://projects.gnome.org/gdm/
> - LightDM http://www.freedesktop.org/wiki/Software/LightDM/Design
> GDM:
> + default in debian\ubuntu
> + stable code base
> + big established community
> - unstable interface for greeter
> - big code-base
> LightDM:
> + stable and documented interface for greeter
> + small code-base
> - lack of community a.t.m.
> - only planned for inclusion into ubuntu\debian
> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-desktop-n-display-manager
> Personally I think that better design of LightDM outweights its
> disadvantages
> considering that .deb packages might be obtained at
> https://launchpad.net/~robert-ancell/+archive/lightdm
Nice to see third-party Debian packages are already being worked on.
This is only a very small step on the road to "being usable in Tails",
though: for maintainability and security reasons, we don't want to
use/trust more and more third-party APT repositories and package
maintainers -aside of the Debian ones- than we currently do.
I've not checked what the quality of these packages is yet.
Do these packages depend on stuff that is not in Debian Squeeze, or
likely to be hard to get into squeeze-backport?
If you decide to go the lightdm way, someone (either you or someone
else) will definitely need to do whatever is needed so that we can use
it in Tails:
0. Make sure lightdm works on Debian Squeeze.
1. Fill a RFP Debian bug (is there already one?)
2. Find a Debian Developer or Maintainer willing to upload and
maintain the lightdm package in Debian, including
squeeze-backports; if needed, help making the currently existing
packages good enough for this to happen.
If you don't include this as part of your GSoC work, it means at the
end of the summer, your results won't be usable in Tails unless
someone catches the ball and deals with it. While this is not
necessarily a blocker, it would for sure make a lightdm-based proposal
less appealing to us. By writing this, I really don't want to
discourage you from using lightdm as a basis: I nevertheless have to
show you the big picture your proposal is supposed to integrate into.
> The major risk involved here is that it's a 1-man project but in
> worst case I think greeter might be ported from LightDM to GDM
> relatively easy (both use GObject and C).
How different are their greeter interfaces?
>> What do you think of this? Does it seem possible to you to
>> implement tails-greeter using tools that are usable as of today
>> (Debian Squeeze + squeeze-backports) only, in a way that makes it
>> easy later to port it to new settings interfaces?
> Definitely. This will involve extensive reading of gsettings porting
> guide and supplying .convert file to make future transition easier.
Ok. Do you intend to include this as part of your proposal?
>> Well, reading this I fear you start designing the whole thing
>> before doing anything practical. Of course you need to think and
>> show us a big picture at some point (e.g. as part of your GSoC
>> proposal to start with, and probably in a more detailed way in the
>> beginning of the 3-months coding time), but on the scheduling
>> topic, I think you'd better split your project into smaller parts,
>> and design documentation would be written before/while implementing
>> every such small part.
[...]
> More fine grained design will be defined by configuration options:
[...]
>> Right, you may have to pressure us a bit so that we make design and
>> UI decisions on a few planned features. [...]
> Fair enough, I should digg into available info on wiki and come with
> initial proposal - stay tuned :)
Right. As you said, this is needed to be able to propose us something
a bit more detailed.
>> I did not found what the "abovementioned test setting" refers to,
>> which makes it hard for me to understand this part of the schedule.
> I was referring to the first "additional option" we're requesting -
> not usual "login" and "password" but some TAILS-specific variable.
> It looks like I should start some wiki page with project description
> and glossary already - just to avoid confusion :)
Right. Please use our wiki to do so: it being usable offline is a
critical feature for some of us.
Feel free to add a "GSoC 2011" section at the end of the
todo/boot_menu wiki page, create a dedicated subpage or whatever. We
can always move it later if we find a more appropriate place.
>> Could you please clarify / elaborate what you mean with "iron out
>> process"?
> What tails-dev do when he suddenly realize that he need to add
> request for "option-n" into tails-greeter. I think this process
> needs to be formalized: the very least is some table on wiki page to
> fill, the best - some helper script which asks few questions and
> generate stubs, update todos, create bugs for tracking etc.
A "howto add a new option to tails-greeter" documentation aimed at
Tails developers may be enough. Beware not over-engineering a shinny
generic toolkit that would only be used two or three times.
>> A few remarks on week #7:
>>
>> 1. One week seems *very* short to me to do all this stuff, unless you
>> already are really at ease with code testing and Debian packaging.
>>
>> 2. I'd be much more comfortable with this schedule if you included (at
>> least unit-) testing as part of your code writing process.
>>
>> 3. The best way to have Tails developers (and users!) review and test
>> your work would be to have a branch in Tails Git repository where
>> you push your work; depending on how it presents itself, it may
>> deserve a Debian package (in this case, a dedicated repository
>> would be setup for tails-greeter, and a Debian package would be
>> pushed at least at milestone time to the Tails repository) or not
>> (in this case, you'd only work in the Tails Git repository).
>> In either case, you'll need to do some packaging/glue-ing work from
>> the very beginning and all along I think, rather than late in the
>> coding process as you are suggesting.
> I partially agree: I also think that code even in working repository
> supposed to be compilable and working most of the time so some test
> are definitely needs to be written "as-we-go".
Ok. So I guess this late scheduled week for testing will disappear
from your proposal.
> On the contrary .deb packaging seems like interesting but secondary
> task which should be done if time permits.
I'm not sure we've understood each other clearly on this topic.
Let me rephrase my point on this matter, just to make sure.
I don't care about Debian packaging per-se, and the point is not to
push your work into the Debian archive at all. As previously stated,
packaging your work as a Debian package might be the right tool to
include your work into Tails... or not.
What we *do* need, .deb or not, is to build a Tails image from your
branch and test the current state your work on a regular basis, e.g.
every two weeks. So glue-ing your work into Tails is no secondary
task and shall be done pretty early in your development process IMHO.
Whether the glue is provided by a .deb or whatever other tool that
proves to be more appropriate is relatively orthogonal to the
scheduling point I was making.
I hope I was clearer this time. Was I? If so, what do you think?
(I could understand if you did not feel like doing this glue-ing work
yourself, as it may need more knowledge of the Tails internals than
you can reasonably expect to acquire in the first few weeks of the
GSoC. Just tell us: we might either give you a hand on this precise
issue, or do the Debian packaging work ourselves; but this shall be
cleared out now.)
>>> week #8: fix last-minute bugs, do some human-testing if possible.
>>
>> What do you mean by "human-testing"?
> Try to build actual .iso and show to some people who are not
> tails-dev. Things which obvious to us might be tricky to people who
> are less involved with project development - thus it would be great
> to have "third-party" opinion. Of course it's only if everything
> else is completed in time including .deb packaging.
Same here: we'll want to build Tails ISO images and show your results
pretty early during the GSoC time. To spend 7 weeks writing stuff we
can't test in real conditions (i.e. show to non-tech-savvy people)
would be IMHO a recipe for disaster.
>> Some other things that are missing from your current proposal:
>>
>> - What programming language do you intend to use?
> Right now vala\genie seems like the ideal variant. Python is also an
> option. Plain old C - is the "last resort" variant :)
I would be more comfortable to mentor your work if you chose Python.
But if Vala seems much more appropriate to you, just use that.
Why does is seem "the ideal variant" BTW?
>> - The code sample you sent us is in Python. Is this the language
>> you are the best at? Could you provide some other code samples?
> Attached in simple multi-threaded server I've made ages ago as part
> of university programming course. I think I'm mostly proficient in
> C\C++ and Perl, Python comes pretty close to Perl.
(Perl is the language I would be the most at ease to mentor.)
What are the obstacles that prevent you from implementing
tails-greeter in Perl? Missing bindings? Binding on CPAN but not in
Debian? Other issues?
I'd anyway be glad to see what kind of Perl you write; as you do know,
there are plenty ;)
> I can make some test task to prove my skills if you'd like.
I'd rather not go this way.
>> - When will you learn how-to, and setup the needed environment to
>> build a Tails system in order to test your work in a realistic
>> environment?
> This is part of "community bonding" time - essentially a
> prerequisite to start actual coding.
Ok.
> I plan to update my application with all the tips and hints from
> this thread in next couple of days.
Glad to read this.
Bye,
--
intrigeri <intrigeri@???>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
| So what?
