Talk:Getting started programming

merge with Developers program

Actually I think that both pages are a good starting point for splitting (not necessarily merging) a small core of introductory pages. Documentation, comm channels, the Developers program itself, links to other existing pages somehow 'duplicate' (ie: contacts, mailing lists, etc.) --Xavi 02:57, 16 April 2007 (EDT)

The point of this page is to provide a single URL to which I can direct new developers. Diffusing the information across the wiki is not desirable. I need something that tells a new developer everything they need to know to get started in 15 to 20 minutes. I'd like to get Developers program trimmed down so that it only has the information about resources available from the project (and how to get access to them). Developers by contrast is intended to be the beginning of a developer's "guide" for getting started.

I think I see your point and I'm totally for it. BTW, I didn't propose the 'merge'.

We are trying to cover a broad audience here, and from a translator PoV, I would really like some sort of general entry point to translate! :) If we could muster a couple of pages, each sort of targetting an intended audience, I think that would be a major thing. If not, well, we'll work on it... --Xavi 22:59, 18 April 2007 (EDT)

not merge, but factor out

How about extracting the FAQ section and place it in the Ask OLPC a Question about Software? It would be a good chance to update said page... ;) Cheers, --Xavi 22:06, 24 April 2007 (EDT)

dev environment proposal from ian bicking & co. at pycon, march 2007

At PyCon a few of us looked at the development environment and how newcomers could work on it (the people involved where: Michael Fletcher, John Hall, Brian Dorsey, and Jeff Younker and Frank Wilder for a short while). I've put this off a bit, but I wanted to write up our thoughts (unfortunately we didn't have real conclusions).

Goal

---

My personal goal is to be able to run a coding sprint, where people can show up and we give them CDs, USB sticks, etc., and they can get a running environment that they can develop on in a reasonable amount of time (half hour or so). I expect a variety of computers, and I don't want to depend on them having anything specific setup.

When I've done this in the past with professional programmers using software that is reasonably simple to setup, it can still be very hard.

I'd like it to be simpler than that, and right now it is much more

difficult.

I also want to setup a development environment people can use. There's a lot of things to learn at once, so I'd rather people just be able to use an editor they are familiar with, and other tools they know something about. Minimizing the number of novel things people have to deal with will allow them to actually pay attention to the important stuff (like writing code).

Ideas

---

I think sugar-jhbuild is pretty much right out; even if it was made perfect and totally self contained, I can't see people reasonably running it ahead of time, and it certainly takes too long to do at the sprint. One idea Michael has been working on is to do a complete build in a virtual environment, and then people can use that environment; either with something like VMWare, or potentially produce a live CD. I don't think the CD that is produced from the builds really makes sense -- doing stuff like hardware detection is really out of the scope of what OLPC should be concerned with. But if we can setup all the dependencies on something suited for a live CD, and install and pre-build parts for that CD, maybe that would be workable. That still won't give people the environment they are used to, unless they happen to be used to what we produce. (I think Michael is using Ubuntu?)

I'm more positive about emulation, as it's fairly reliable; i.e., qemu or the VMWare player. You could a hosted/sugar-jhbuild environment, or the actual build image. If you do a sugar-jhbuild environment, presumably people will use that environment for all their development, using whatever tools we put on there. They'll inherit any network settings and hardware support. Performance is a little slow; realistic for actually running the environment, somewhat tedious (but not unacceptable) when running development tools.

(Note: one issue with VMWare emulation is that currently networking doesn't work because of a missing driver, as noted here: http://dev.laptop.org/ticket/925)

Another option is using the builds themselves. The builds and the OLPC environment really isn't suited yet to doing development. I don't think that should be a blocker for people either (I'm not a big fan of eating your own dog food, at least not until much later in the process than we currently are).

One of the more hopeful options seems to be some kind of network drive, so you can edit files from the host environment. All testing would occur on the emulated image. Either the host or the image could have the server, with different tradeoffs.

sshfs was suggested. This is fairly difficult to setup on host computers, and while something like Nautilus might be easy to setup, many other tools won't work well. Another issue is that the host computer has to see the image on the network. I haven't tried VMWare; I get the impression it's fairly easy to set this up there. Setting this up under qemu is much harder, and it's not clear to me if it's reasonable at all under Windows. I'd really like this to be workable for Windows users. Of course, if the host can see the image there's no reason we could have many server options, including Samba and NFS in addition to ssh (all of which may not be part of the standard builds, but seems easy enough to add to a custom build).

Setting up a server on the host computer has its own issues, though it can be potentially easier -- servers require relatively little OS integration compared to a client. In that case, the host would run some server (NFS, ideally SMB could work), and the image would mount it. This avoids the emulation networking issues, but then we have to consider where to mount the share... can we overlay the entire filesystem?

Disk space on the image is a problem. It would be nice if people weren't constrained to 512Mb, so they could play around with larger things, even if those things can't be deployed in that form. It may not be an issue if all the development tools stay on the host system; but I don't think gcc will work well on the host system, as it's not the image's native gcc. Installing development libraries take a lot of space. OTOH, I'm much more interested in getting people writing Python code. But it would be nice if there was at least some story for how people could develop bits of C code (or Pyrex) if there are particular performance benefits in their application.

Sorry if this wanders, I've tried to include at least some of the bad directions and possible good directions and caveats in this, and the result is scattered.

drew einhorn's reply to ian's proposal

See:

   http://www.linux-live.org/

Needs some embellishments for our purposes.

Let's recap the scenario.

Assume we are out making a presentation,

introducing OLPC to folks who have maybe read some articles about it, maybe not.

We arehoping to recruit them as developers.

We have an hour or so.

For some hands on experience We have asked them to bring

    their laptops,
    and a usb flash drive

We don't have time for any complicated installation, and they have a random assortment of hardware, and operating systems.

Most of them have environments that are difficult, if not nearly impossible to work with.

In case they don't have enough free disk space, or there is some other problem installing an image on their hard drive

we bring a plain vanilla sever with a open shared network readonly filesystem.

In case of difficulty with their usb drive, or if they just forgot it.

We have available 1 GB usb flash $20-$30 from a reputable source they can borrow or purchase.

We give them LiveCd/Dvd.

   / is a unionfs of
       rw filesystem on usbdrive
       ro Mike's image ported to FC6, or
           just about any OS image for that matter
           but we don't care about that.

Mikes image might fit on compressed LiveDvd but won't fit on LiveCd

faster access to bigger images from readonly filesystem

    on harddrive, or
    network drive,

readonly

    last I heard linux did not reliably write to nfts
    we just don't want to risk it even with the
    ntfs-ng driver.   Some of the users may have
    extra fragile filesystem on odd vintage os.

Image on local file system for performance and independence

Image can be network filesystem if necessary.

After they go home they can solve the problems that required them to use the network filesystem

cryptographic signature verifies validity of image will verify lack of subtle problems case insensitive filenames, corrupted files, etc. if it's a PKI signature it fits the security model.

mike fletcher's reply

I think we can safely assume that almost *everyone* would be interested in a Developer's LiveCD that doesn't require installation and yet allows developers to work efficiently within the environment with all of their work saved to hard-disk/USB/whatever. Certainly anyone doing developer outreach type work, anyway.