顺理成章的，emDebian的重要优势就展现出来了，现在你用的CPU超出11个 Debian支持范围了吗？没有，那么你可以简单的通过 emDebian构建目标系统；你所需要的主体软件在Debian支持的官方和非官方近2万个软件以外吗？没有，那么恭喜你，明天就可以给老板交工了。当然，对于特定的软件，可能还是需要从源码来构建，不过同样的，我们可以将其生成Deb包，然后将配置加到emDebian工具集中，同其它所有软件一样的选取和配置。
emDebian的发展似乎不是想像的那么好，现在主页上的新闻更新还是去2004年的。
buildroot
emDebian实际上并不一定适合于资源非常紧缺的超小型系统，比如只有2M Flash的小型控制系统。另外发行版的软件通常会以通用代码来编译，例如，为了尽可能在各种X86平台上都能够安装，大多数发行版通常会以i686甚至 i386代码集来编译软件，可以使文件的通用性很强，但CPU的性能却不能发恢到最好（这就是为什么有时会看到一些厂商或爱好者发布PIII、PIV、 athlon等优化系统的原因），这对于嵌入式系统来说也不会是一件好事情。另外，没有源码的控制权，一些需要定制的东西也会变得难以实现，因此，从源码开始构建仍然有必要。
嵌入式Linux开发中使用的CPU速度往往向对不会太高，因此，尽可能提高代码的性能就非常必要。通常开发人员应该对该CPU的具体型号有一定的了解，以便启用编译器中对该型号的优化，以ARM为例，我们可以通过 -march=armv5te 和 -mtune=arm9tdmi 来对代码在ARM9上的运行进行优化。有时这些优化体现出来的性能改善是比较大的，我曾对比过一些复杂算法的代码优化前后的性能（执行速度），都有一定的提升。另外在PIV上测试过以i686和pentium4对一个语音编码算法进行优化，运算速度居然提高了几倍。
这种幅度的提升可能只是一个特例，这个算法有大量的复杂浮点运算，使用i386或i686指令集和使用更先进的PIV指令集编译出来的机器代码对于同一个运算的解释可能采用完全不同的指令来完成，因此性能提升较大就不足为奇了。同样这种代码，在ARM上通过ARM4和ARM5来优化后在ARM9上运行，却没有那么大的提升。看来对CPU的一定了解也应该是嵌入式系统软件设计者应该具备的能力。
那么又如何控制可执行文件的大小呢？除了却除软件中不需要的部份外，我们还应该考虑软件所引用的库文件。GNU的Glibc是一个非常宠大而完整的库，至少对于嵌入式系统来说，其体积显得过于大了一些。uClibc的提出较好的解决了这样一个问题。uClibc尽可能的兼容Glibc，大多数应用程序可以在很小或完全不修改的情况下就可能使用 uClibc替代glibc。通过uClibc来代替Glibc，可以在不改变应用程序功能的前提下，大大减少发布文件的大小，无论应用程序以静态链接来编译，还是以动态链接形式编译。