TODO

Release Critical:
* bind the broadcast listener to fixed local port (8765) (otherwise not firewallable) (matz)
* chmod TMPDIR/native, as otherwise set umask prevent it from being readable by the client
   I'm wondering if it doesn't make sense to leave the daemon out of the game and let the
   client package the environment - it could either cache it in /tmp and leave a note in
   ~/.icecream or it packages it right into ~/.icecream and use e.g. the inode numbers of
   the compilers to verify it's the right environment - think NFS users changing machines.
   This would simplify some things and avoid the above bugs (and it would make it more
   convenient for users of /opt/gcc-cvs/bin too)
* Improve Documentation (cschum)
* make the protocol version an uint32, not a hand-build array.
* let the client specify it was compiled with recent compiler (supporting -param). If so,
  let the daemon compile with the options, otherwise leave them out. 

Akademy must have's:
* the scheduler with the newest protocol version wins
* only one scheduler within the same broadcast domain
* daemon: only accept connections from a sane net prefix (scheduler can determine
  this and send it out via confMsg) to avoid being exposed to the internet
* always re-discover scheduler after disconnect, don't just re-connect to the last
  one (for some reason I don't see why this happened, but it did)
* benchmark/testing jobs (broken machines with broken ram and broken network card on the
  icecream network destroy the fun and are not easy to find manually)

Random:
* Option -iiface to specify the interface[s] to listen on for the scheduler, or
  to use for the daemon.
* Don't explicitly forbid tunnels because it could be useful for things like
  vmware
* If someone calls a amd64 client on a host that runs a ia32 daemon and there are
  no other amd64 daemons in the farm, he will get no answer, but a timeout from
  scheduler (quite a corner case, but neat)
* use syslog
* Log problems found at some scheduler log - or even in the monitor. E.g. if a client
  can't reach a given daemon, it should be able to tell. Perhaps the scheduler can even
  disable that very host for some penalty time
* Reduce amount of force-waits, especially if they involve network latency (scheduler queries)
  and daemon context switches:
    - remove the need for EndMsg
    - do not ask the daemon about the first job (WIP dirk)
* if a compile job SIGSEGV's or SIGABORTs, make sure to recompile locally because it could
  be just a glibc/kernel incompatibility on the remote site
* Add heuristic which optimises for overhead-reduction. Statistics prove ( ;) ), that for
  e.g. linux kernel the file size varies a lot, and small jobs should be preferably compiled
  locally and bigger ones preferably remote.
* Split number of jobs into number of compile jobs (cheap) and number of non compile jobs (can
  be expensive, e.g. ld or meinproc). The reason is that multicore chips become more and more
  common. Today you can get quad cores easily and in some month we've 8 cores and several link
  jobs at the same time can pull down your whole system.
  (I can life with a hard coded number of one non compile job but others probably prefer a
  configurable number)

Suggestions from "Wilson Snyder" sicortex.com:
- Add ICECREAM_RUN_ICECCD to make the scheduler machine not run iceccd
- Have schedulers redudant - e.g. as in nmbd

Christoph Thielecke writes:
> 1) Problem von icecream: icecc hat /usr/bin/gcc-4.2 kopiert (ist aber ein
> Symlink auf den Hardening-Wrapper, der installiert war, siehe Listing
> unten). Kannst Du vieleicht eine Prüfung einbauen, ob gcc-x.y mit .real
> endet bzw der Wrapper ist?

Andi Kleen writes to protect against misconfiguration:
>generate somefile.h on the client with
>#if __GNUC__ != expected_major || __GNU_MINOR__ != expected_minor
>#warning blabla
>#endif
>and then run with
>-include somefile.h
> (this file needs to be in the environment created by create_env)