>> Тестирования кем, на чём и в соответствии с чем?  И есть ли это всё у coreboot-чиков?..
> разработчиками проекта. соотвествия найденым не стыковкам в документации.
> У них что возможности разработать тестовую библиотеку нету? Я фигею дорогая редакция...

Лучше спросить в http://www.opennet.me/opennews/art.shtml?num=34510

> [...] хорошо - функция якобы должна писать в регистры - заменяем
> функции записи в железо на функции записи в некоторый массив -
> дальше сравниваем значения массиа в эаталоном.

Где им брать эталон, чтобы получить равноценную замену?

> Когда срывались сроки по Черному рыцарю - одна не без известная вам
> контора просидела 2-3 недели

Не припоминается, Вы слишком хорошего мнения о моей осведомлённости. :)

> будем дальше сравнивать ?

Да, можно сравнивать сколько угодно.  Но лучше сошлюсь на http://morky.livejournal.com/155567.html и добавлю, что как авральщик с некоторым стажем целиком и полностью подтверждаю выводы в окрестностях фразы "У нас украли деньги и время".  Кстати, в 2007 был принят и ФЗ про трёхгодичные госконтракты, помнится... но тут же "началось".

>> Действительно сконцентрированного внимания при работе, по общению с самыми разными
>> опытными и очень опытными разработчиками -- может быть часа четыре в сутки.
>> Если два-три в "полном погружении" -- уже неплохо.
> Некоторые могут работать и больше - постоянно переключаясь между разными задачами.

Это редкость, и такие люди тоже выгорают -- т.е. наступает момент, когда никакими деньгами, бонусами, убеждениями человека уже не удержать в компании.

> А иногда над одной. Возможно зависит от людей и задач.

Да, конечно.  Тут могу в очередной раз порекомендовать Johanna Rothman "Manage It!" -- толковая тётка и книжка тоже честная.  Про multitasking там отдельно разобрано вместе с соображениями по части точек переключения задач, чтоб хоть не так "кэш" убивало переключениями контекста.

>> А у таких тычков обычно полезность около нуля, проверено.
> Глядишь - задумается. А если разжевывать до полных мелочей - это начинать
> с леккций по PSP/TSP, Scrum, Agile - затянется очень на долго.

Ой, я Вас умоляю.  Это же насколько надо не слышать "заказчика", чтоб вместо применения к его обстоятельствам пытаться впарить ему свои воззрения и при этом ещё говорить про эджайл.  Да и долгие лекции по нему немного странны, поскольку вообще-то слушать людей и не пытаться сделать в сторонке всё по бумажке, а потом уверять, что они так и хотели -- это естественно для любого порядочного разработчика, IMNSHO (если надо, могу посоветовать пару людей, умеющих _краткие_ лекции по agile/scrum).

Собственно, "противоположный" waterfall -- это плод коллективного умопомрачения при участии манагеров и военных; Ройса, который предупреждал о _рискованности_ проиллюстрированной схемы, поняли как _предлагающего_ эту самую схему и не выслушали до конца: http://pascal.gugenberger.net/thoughts/waterfall-accident.html

PS: s/:/;/ по последнему абзацу.