Debian installer bof:
=====================
Problem definition: Debian is maintaining 2 sets of OSes: one with libc6 and
.deb packages, and one with busybox and udebs. This is a waste of time and
energy, plus d-i is becoming harder to modify.

Normal stuff:
- ncurse & graphical front end: what should we use
  - produces a json/yaml file to push to the installer program
  - any front-end can be written to write that yaml/json
- partitioning:
  - using parted & gparted as a first approach for the PoC
- networking: let's use normal DHCP and let the user configure manually through
 shell or network-manager
  - need to support: bonding, vlan
- case of cluster install automation: we need to support that
- support building cloud images

Name proposal: "ding" (as in d-i-ng) or "dial" (as in d-i alternative)

What if we move to dracut at the same time? ;)
-> there was was sort-of consensus to move to dracut (dc13), but things got stuck..

possible alternatives for Partman. 
kpmcore ? 
 - nope, too heavy on dependencies.

List of installers that derivatives use instead of D-I. 
1. Ubiquity
2. Live Installer (Linux Mint)
3. Calamares - debian live images also currently utilizes this.
4. BlankON installer (BlankOn Linux)


what is the actual problem that you would like to solve?
-> for me, it would be the udeb thing. the rest of d-i (using debconf, multiple
   backends/frontends, parted, etc.) are good.
-> I would 'rebase' d-i on a regular system and improve on that later, 2nd step.

Want to solve:
 - Partitioning. there's no good language to specify high-level partitioning use cases,
   eg: create these partitions over two disks on raid1
 - Elliminate the need for things like Calamares on the live image
 - Have generic framework for creating installers
 - Make something that is easy to contribute to