Средства и методы разработки

[:||||||:] Если про теги, то современные адекватные редакторы такое умеют. Начиная от red hat sourcenavigator в доисторические времена. А "автоматический синтез исходников" -- попросту бред. Синтезатор вначале написать надо. Исходники-то проще. А в тех местах где нужно -- кодогенераторы и так есть. И, наверное, самое главное. Вы, как не программист, не понимаете, что программист мыслит в терминах используемого языка программирования. Он не мышкой крыжики в этой вашей БД тыкает. И есть другие языки, гораздо круче, чем ваши крыжики в БД, и где нужно -- используются и действительно облегчают труд (и из них может генерироваться код на C -- например есть компиляторы Scheme в C). Но в Linux всё так как есть далеко не просто так и нужно быть совсем наивным обывателем, чтоб считать иначе. И в любом большом программном проекте. Он не влезет в рамки никакой IDE, никакой волшебной БД. Скорей IDE с БД будут построены вокруг него, если требуется. Ещё раз -- вы не программист. Не пишите чуши. "Никакой условной компиляции". А где будет эта условность реализована? Вывод cpp тоже уже не содержит никакой условной компиляции... Всё в один файл. Вы вообще понимаете, что такое область видимости? Это куда более существенно, чем ограничение компилятора. Именно для этого существует разделение на модули в C. Как и в Pascal (Turbo-Pascal). Как и в доисторическом FORTRAN... "Если говорить об эмбеддерских проектах" -- если о них говорить, то голый ЦПУ без периферии скорей не нужен. Если не ассемблер и др. извращения. Если говорить о крупных embedded проектах, то скорей нужна сборка на ПЦ с симуляцией периферии на уровне интерфейсов прикладной программы (uart_read, uart_write()...), а не битов и регистров. Всё остальное про гигабайты и гигагерцы -- чушь. Для "сервера проектов" достаточно хиленькой машинки чаще. С существующими средствами разработки ПО. Гигабиты тоже не к месту: даже 100-мбитный ethernet даёт пропускную способность часто большую, чем нужно, данные обрабатываются дольше (компиляция, например). Сравнивать с сетевым диском виндов только не нужно. Он defective by design, на NFS всё достаточно быстро. Про RAM Drive сказочная чушь, основанная видимо на опыте работы с Widnows-98. Любая современная ОС ЛУЧШЕ ЮЗЕРА определяет где данным места. И существенной разницы, находится /tmp, например, в tmpfs или на реальном диске, нет (в первом случае выкинет в своп, во втором (не)закеширует в RAM...) Про интерфейсы с реализацией -- это не любой язык. Это огульная ООПщина без понимания зачем она нужна. В lisp или prolog могут быть очень отличные от C++ подходы. "Такое разделение позволит избежать проблем при падении девелоперской машины"... Классический подход позволяет избежать и кратковременного падения сервера, и позволяет работу в оффлайне с краткими соединениями. Без гигабитного ethernet. Через модем 9600 можно. "Латентность там будет 1-2 мкс" -- никогда не будет. Латентность обеспечивается конкретной программой, которая в условиях load average >=1 будет получать пакета с задержками в десятки мс. Это только пинги из ядра будут 1-2мкс. "Можно хоть пооператорную оплату вводить" -- это мега [:|||||:], описано в классической литературе чем кончается. оманда в десяток девелопеорв сможет ээфективно управляться к проектом класса "ядро линуха" -- бред, комментировать нечего. Ты масштабы не представляешь. Просто в башке не уместится. И самое главное, что когда сервак йопнется -- вот это будет радость.