Так интересно именно в смысле прототипирования. Например какие материалы используются (насколько хорошо пластик так обрабатывать?), какие цены на станки подобные (лучше купить станок в команду разработки, как в случае с современными принтерами по пластику, или же выгоднее заказывать изготовление?), насколько ПО готово сразу изготовить деталь по модели и т.п.

Хотя вообще наверное это уже на отдельную статью тянет… Вот предположим требуется как прототипирование, так и мелкосерийное производство в одном комплексе. Причём итоговые устройства весьма и весьма дорогие. Какие у нас варианты есть?
Для пластиковых деталей:
— свой 3д принтер средней цены
— заказ стороннему производителю
Для металлических:
— заказ стороннему производителю
— свой фрезерный чпу станок (вот непонятно как по деньгам)
— свой 3d принтер (написал только для общности — по деньгам явно не проходит,)
Сумбурно конечно написал, но вроде понятно направление интереса, да? )

По поводу распила — да, не без этого. Но всё же там в итоге и исполнителю (я имею в виду естественно компанию) достаётся нормально. Главная проблема в том, что исполнителями частенько становятся совсем не лучшие, а выбившие заказ по всяким мутным схемам.

По поводу DARPA и возможностей нашего МО. Ну для начала у нас аналогом DARPA должен заниматься не MO (которое только заказывает готовую конечную продукцию), а руководитель ВПК, т.е. как раз Рогозин. И он вроде как обещался, но пока результатов не видно никаких. Далее, с учётом финансовой ситуации в США и у нас, ещё не известно где больше денег на перспективные проекты могут выделять в ближайшем будущем. Проблема совсем в другом. У нас все эти гос. конторы не готовы грубо говоря рисковать деньгами. В то время как DARPA — это по сути аналог гос. венчура и только и занята непрерывным риском. Который с головой окупается в случае успеха. А у нас чиновники пока готовы вкладывать только во что-то проверенное (с их точки зрения). В итоге мы можем отлично развивать то, в чём уже есть известный задел (ну там C-400 или T-50 и т.п.), но в сектора требующие реальных инновации не идёт практические ничего. Ну будем всё же оптимистами и понадеемся что Рогозин не совсем болтун. )))

Да, и наконец по поводу открытости результатов — не вижу в этом никакой особой надобности.

В каком смысле не стоит? ) Если суметь получить заказ, то там как раз всё очень шоколадно (ну разве что выплаты только раз в год, но это не важно). Вся проблема в том как у нас эти заказы выдаются (там далеко не конкурсы, как этой статье)… Хотя Рогозин в прошлом году и рассказывал что создаст «русскую DARPA», но что-то до сих пор ничего подобного не видно.

Что-то про фрезерование вы практические ничего не написали (во всяком случае в сравнение с информацией о принтерах). А например мне это было бы как раз наиболее интересно.

Ну так если бы это был предположим конкурс от наших военных (эх, мечты, мечты), то в чём была бы проблема? )

Эмм, а почему вы собственно считаете, что военная направленность продукта отталкивает разработчиков? Лично меня это наоборот только привлекает. Естественно подразумевая в данном случае разработку для военных не США, а наших.

Это речь только про часть финансирования. Здесь не учтены ни научные ФЦП, ни военные НИОКР, которые только увеличиваются. Так что указанное вами снижение говорит лишь о перераспределение средств от финансирования организаций, к финансированию конкретных результатов.

Что-то ваша «реальность» какая-то странная. Я раньше особое не интересовался, но сейчас глянул глянул в гугл и в первых же ссылках увидел только планы по увеличению финансирования науки:
news.kremlin.ru/news/18333/print — про Россию
www.itar-tass.com/c11/657779.html — про Китай

Наверняка если потратить время на серьёзный анализ, то найдётся ещё много стран только увеличивающих расходы на науку. Но уже даже этих двух достаточно, чтобы ваш тезис «во всем мире затраты на науку оптимизируют в связи с кризисом» оказался не верным. Ну так и где у нас в итоге авторская интерпретация, а где реальность? )

1. Вы написали так много, но так и не ответили на мой простой вопрос.
2. Я пока не понял, вы считаете что в данной статье есть какие-то не правдивые факты? Если есть, то укажите — всем будет реально интересно. Или же вы считаете что все указанные факты верные, но вам не нравится стиль их изложения?

Меня всегда поражала подобная логика (это я про негров). Вот смотрите, давайте предположим (это уже речь не про данную тему, а вообще про что угодно) что «у нас всё плохо» в какой-то области. И при этом «у них всё плохо» тоже. Т.е. это объективная реальность. Следует ли из этого, что мы не должны публиковать правдивые статьи о том что «у них всё плохо», пока не сумеем сделать «у себя всё хорошо»? ) Если следует, то обоснуйте почему. Если же не следует, то зачем вообще подобный комментарий здесь (да и вообще не редко его вижу в разных местах)?

По поводу ссылок на первоисточник я уже писал — их действительно сильно не хватает.

Интересно, почему у этой довольно информативной статьи (правда я бы к ней ещё обязательно добавил прямые ссылки на источники, чтобы можно было легко удостовериться в истинности изложенных фактов) стоит столько минусов, но при этом нет ни одного комментария, разъясняющего недостатки статьи?

Такое впечатление что статья не оставляет равнодушными, но прокомментировать читатели стесняются… Может потому что их оценка является исключительно эмоциональной, а вот своих фактов (которые полагалось бы указать в комментарии) просто нет?

Эммм, вы бы почитали вначале «параллельные» вашей статьи на хабре, хотя бы за последнюю неделю. Если сравнивать с ними (а там тоже всё далеко не идеально), то ваша статья является вообще никакой. Без обид пожалуйста, но у вас тут какой-то сумбурный неструктурированный поток отдельных тезисов из разных разделов безопасности. Причём ещё с какой-то непонятной системой оценок. Если бы я не был подробно знаком с данной темой, то я только больше запутался бы от вашего изложения.

Плата вполне нормальная. И даже цена более менее адекватная (не надо путать интегрированные встраиваемые решения и обычные материнки). Но в таком исполнение она должна была бы выйти года 3 назад. Тогда это было бы супер решение. А во второй половине 2013-го года это смешно на фоне решений от конкурентов.

Сейчас бы я с удовольствием взял за эти деньги полностью аналогичную плату на базе Clover Trail или Medfield. Ну естественно при условии что для них была бы реализована поддержка Linux, а не только Windows/Android.

Не могу ничего сказать про описываемое ПО, может оно действительно очень полезное. Но вот эта статья является классическим наукообразным впариванием, причём рассчитанным на незнакомую с IT аудиторию. Что-то типа «посмотрите какие мы тут мегакрутые вещи сделали (хотя речь о тривиальнейших вещах) — дайте новый грант». Не имею ничего против такого, но не пойму зачем ЭТО на хабре с его проф. аудиторией.

Уловил из статьи мысль, что социальные сети делают нас ближе к пещерным людям… В этом что-то есть. )))

Ну так это равносильно просто запуску — не было же орды запросов на сервер.

Вообще они там явно что-то накосячили. Достаточно взглянуть сколько занимает ресурсов тот же самый diff в самом mercurial.

А написана RB на Python.

Хм, я сам люблю серверные вещи на Питоне по быстрому делать. Он конечно не самый шустрый, но таких диких результатов что-то не припомню. Или взять тот же Django — весьма жирный фреймворк, а на 2 гигах вполне себе летать будет, если не орды пользователей.

Неслабые такие требования у системки… Т.е. я понимаю когда требуется много памяти под большую нагрузку. Но что бы даже не запускалось при двух гигах…

Интересно на чём оно такое написано.

Всё равно непонятно что за абстрагирование такое, если пул потоков и так уже выделен в отдельную абстракцию. В общем ни одного примера показывающего хотя бы минимальную полезность нескольких очередей (кроме случая с main ui, который является особым) я так не увидел.

Ну и соответственно если остановится на том, что нам не требуется много очередей, то по сути окажется что практически всё уже реализована в стандартной библиотеке.

Не реализованным остался только механизм обработки результатов выполнения дополнительных потоков в основном потоке (UI). В смысле в стандарте C++11 этого нет. В C++14 уже планируют добавить, в Boost'e уже сейчас есть. Ну и естественно можно плодить множество своих велосипедиков, как во всех этих последних статьях.

Вы похоже не понимаете что я спрашиваю. Я не спрашиваю зачем нам многопоточность или зачем нужны пулы потоков в принципе. Мне интересно почему мы не можем написать просто так (в вашей терминологии):

async_queue.async([=]{
    file_data = get_data_from_file( file_name );
    async_queue.async([=]{
        parsed_data = parse( file_data );
        main_queue.async([=]{
            update_ui_with_new_data( parsed_data ) ;
        });
    });
});

или вообще так:

async_queue.async([=]{
    file_data = get_data_from_file( file_name );
    parsed_data = parse( file_data );
    main_queue.async([=]{
        update_ui_with_new_data( parsed_data ) ;
    });
});

Т.е. зачем более одной очереди (отправку исполнения в UI поток рассматриваем как отдельный особый случай).

Ну и безотносительно всего этого… Создание/удаление потока имеют обычно ничтожные затраты на фоне самой задачи (уж точно на фоне перечисленных вами в последнем комментарии задач). И проблема у схемы «по потоку на задачу» совсем не с этим. А с тем, что если наплодить много активных потоков, то эффективность резко уменьшится за счёт накладных расходов на переключение контекста (вот это становится действительно затратная операция с учётом её частоты).

Да, и у вас совсем не легковесные потоки (которые coroutine или fiber), а именно пул потоков с очередями задач, Т.к. для легковесных потоков вам потребовался бы ещё какой-то механизм многозадачности (кооперативной как минимум, т.е. что-то типа yield).

Нууу хорошо, пусть один пул с несколькими очередями (хотя по сути это… ) в него. Всё равно не понятно зачем их несколько. Можно какие-то практические примеры? )

P.S. Как вы понимаете у меня вопросы/претензии не к вашему велосипедику, а к изначальной схеме…