Пустая трата времени, если на диске есть области с «плавающими» дефектами (когда сектора в определенной области то читаются, то нет). Мало того, что на проверку времени уйдет масса, так еще и часть секторов из нестабильных областей заюзается — со всеми вытекающими.
Ну, dd с опцией conv=noerror тоже не запиливает диск. Для моих целей (слить по-быстрому образ диска, игноря ошибки) dd вполне подходит. Понадобится что-то более сложное — тогда и буду использовать что-то более сложное. :)
Нет. Беды вылезают тогда, когда кончился резерв секторов (это сотни или даже тысячи секторов). Пока резерв есть — каждый диск чинит сам себя, и обычный рейд на них работает прозрачно.
В теории все так.
На практике нечитаемый сектор далеко не сразу подменяется резервным. Какое-то время он болтается в pending reallocated sectors. А уж когда там его контроллер соблаговолит переназначить, зависит от многих факторов. У меня в экспериментах такие вот «недопереназначенные» сектора висели по полгода (и что характерно — все это время не читались). Лучший способ заставить контроллер переназначить такой сектор — это попытаться что-нибудь туда записать напрямую. Есть, конечно, и специальные команды для этого, но они вендор-специфик.
Преимущество только одно — dd есть в любом дистрибутиве, а ddrescue надо ставить.
Ну и, если честно, возможности ddrescue мне показались излишними: какие стратегии чтения, какие карты? Задача была — прочитать образ диска «в лоб», а если что-то прочитать не удалось — забить болт непрочитанное место в образе нулями. С этой задачей dd справляется неплохо.
Скрипты, наверное, выложу на гитхаб попозже — сейчас я от них далеко. :)
Джентльменский набор — это smartctl, dd, scrounge-ntfs и hdparm.
smartctl позволяет проконтролировать количество бэдов.
dd позволяет сдампить образ диска для последующего выдирания с него файлов (если указать параметр conv=noerror). Также dd позволяет быстро найти сбойный сектор на диске (читаем все подряд блоками по 4 кб, при сбое чтения — dmesg|tail и смотрим, в каком физическом секторе произошел сбой).
hdparm позволяет переписать этот сектор и заново проверить его (и окружающие сектора) более пристально.
scrounge-ntfs — прекрасная утилита, умеющая выдирать файлы из образов дисков c NTFS. К сожалению, в 32-битном Debian она собрана неправильно (без -D_FILE_OFFSET_BITS=64), в результате чего практически неюзабельна. Приходится вытягивать исходники и собирать с нужными флагами.
Badblocks, к сожалению, при большом количестве бэдов может работать неделями, так что я ее пощупал и отказался от нее.
Ну, qmake тоже не сахар. Пока весь проект можно описать переменными — все прекрасно, но если вдруг всплывает что-нибудь нестандартное или грабель какая — пока найдешь решение, облысеешь до самых подмышек.
А в CMake меня умиляет то, что некоторые модули работают не совсем стандартно. Например, модуль Threads — внезапно! — не выставляет переменную THREADS_FOUND. Некоторые модули выставляют в переменной DEFINITIONS голые дефайны, а некоторые (wxWidgets, например) зачем-то прихреначивают в начало -D. Со списоком библиотек, помнится, тоже были похожие глюки. А что самое забавное — в разных версиях CMake поведение может быть разное, ибо баги исправляются.
О, некромантия над битыми дисками — это моё, это я люблю. :)
Но ваше решение, как уже справедливо заметил sysd, не очень: винда может вдруг решить, что файлы на диске слишком фрагментированы, и перенесет заглушки в другое место.
Что касается бэдов. Если они появляются в малом количестве и редко, то лучший способ — заставить контроллер диска подменить их. Я лично использую для этого пару скриптов и утилиту hdparm под линуксом (конкретно — команды --read-sector и --repair-sector). Причина проста: посекторная проверка большого диска может занять пару суток. Под линуксом у меня круглосуточно крутится NAS, а виндовую машину приходится выключать на ночь, так что выбор платформы очевиден.
Если битых секторов становится слишком много и подменять их становится нечем, или если битые сектора появляются слишком часто, то проще такой диск разобрать на магнитики.
Впрочем, если хочется помучиться, то можно попытаться использовать помехоустойчивое кодирование (тот же код Рида-Соломона). Тогда можно подобрать параметры кодирования таким образом, что файл(ы) можно будет восстановить даже после выпадения нескольких подряд идущих секторов. Правда, придется заморочиться со специальными утилитами для кодирования-декодирования файлов на ненадежном диске. А в идеале — вообще наваять помехоустойчивую файловую систему. :)
На КДПВ — угашенный алкоголик. К чему бы это? Неужто расширения настолько сильно влияют на психику?
Отличный вариант для оттачивания навыка восприятия речи на слух. Благодаря технологии распознавания текста, с помощью этого аддона можно перевести в аудио любой текст в вебе.
Так себе вариант, если быть точным. Начитанные роботом тексты бездушные и безликие, зачастую — с неправильной интонацией. Да и с произношением слов не все бывает хорошо.
Гораздо лучше — аудиокниги, начитанные живыми людьми. Еще лучше — инсценировки и фильмы, т.к. с ними процесс «оттачивания» наиболее приближен к реальности.
Удобный словарь для Firefox Quantum. Работает очень просто – по двойному клику на слово на странице показывается перевод.
Если уж быть совсем точным, то не перевод, а толкование.
Я не согласен, что спор бессмысленный. Он скорее однобокий: мы обсуждаем некого абстрактного кандидата без привязки к коллективу и проекту.
Это хорошо, что вы упомянули про заграницу. Там действительно работают по-другому. Но дело тут не только в менталитете (в конце концов, там и наши эмигранты работают в больших количествах — и ничего, менталитет не мешает). Мне кажется, дело скорее в отношениях между работодателем и работником.
Вот как я это себе представляю (для сферы IT):
В Европе работодатель хорошо защищен социально, но при этом понимает, что социалка зависит и от его активности тоже. Отсюда — крепкие профсоюзы, а работодатели идут на компромиссы.
В Америке с работником «договариваются» зарплатой. Работник хорошо впахивает потому, что деньги нужны, работодатель хорошо платит потому, что иначе хорошие работники разбегутся.
У нас, к сожалению, социальной защищенности нет. Т.е. каждый работник по сути сам за себя. Но и с зарплатами не фонтан — ибо конкуренции не так уж и много. Вот и получается с одной стороны — имитация рабочего энтузиазма, а с другой — имитация заботы о работнике и «коллективные ценности».
Определить возможность такой оптимизации, вероятно, сможет и «генератор» типа CMake-а, но не факт что у него получится сгенерировать соответствующий билд файл для нижележащей билд системы, в которой существуют свои ограничения.
Для большинства испробованных мной билд-систем (UNIX Makefiles, Ninja, разные версии Visual Studio) полученная система сборки вполне «соответствующая».
А «генератор» ограничен воможностями нижестоящей билд системы и какой бы замечательный билд файл он не сгененрировал нижестоящая тулза может подпортить все дело. Вы сами же писали, что, к примеру, NMake будет строить в один поток и генерптор ничем помочь тут не сможет, он свою работу уже сделал.
На практике все не так уж плохо, как в теории. Большинство нижележащих билд-систем умеет собирать в параллель — причем CMake генерирует для билд-системы качественные файлы, позволяющие максимально эффективно использовать параллельную сборку. NMake, который не умеет в параллельную сборку — это эдакий курьез.
Но, как я уже писал, для CMake было бы неплохо добавить небольшой(?) дополнительный шаг, чтобы вместо генерации файлов для билд-системы пошла собственно сборка. И тогда, глядишь, для большинства пользователей вообще отпадет необходимость в генерации лишних файлов.
Профессионал часто оказывается с трудных характером, склочный,
Это можно определить на собеседовании, разве нет?
амбициозный,
А это вот вообще ни разу не недостаток. Да, есть проекты (всякий maintenance), где амбициозность не нужна, а нужны другие качества. Но вот для стартапов амбициозность очень даже неплоха.
Задача рекрутера и собеседующих — определить, подходит ли данный конкретный человек к вашему конкретному проекту. В том числе психологически.
Не за что, ваш К.О.
будет вечно шантажировать уходом,
Если ваш проект не подходит для «звезд» — возможно и будет. С другой стороны, если гражданин в проекте прижился и «расцвел», то он один в случае чего сможет вытянуть на себе весь проект.
тянуть лямку на себя, спорить, что его решение самое лучше, что это он тут все сделал, а чем вы занимались?
Это вы описываете какого-то молодого да раннего звездуна, как мне кажется.
Я с трудом представляю себе опытного специалиста, который вдруг ни с того ни с сего вот так вот «зазвездился». Опытного — значит, поработавшего в разных проектах и разных коллективах. Такие люди, как правило, трезво понимают свою роль в коллективной разработке.
Будет подставлять коллег, не будет командной работы и духа, будет неуступчив.
Другими словами, bad team player & trouble maker.
Опять же, даже такому гражданину иногда находится применение — например, некая узкая зона ответственности, где он может в одиночку творить что ему заблагорассудится. Узкая — чтобы в случае чего эффект автобуса был не слишком большим. :)
Т.к. он профессионал он моментально напишет код, и остальные 7 часов будет почивать на лаврах ничего не делая, жалуясь, что задача написана криво, что пусть тестируют тестировщики.
По поводу «моментально напишет код» вспомнилась коронная фраза одного бывшего коллеги: «как мы все знаем, хороший программист работает от силы пару часов в день. Но это не повод уходить с работы в 12». :)
Не будет делиться знаниями и опытом.
Значит, менторство — не его. Ну и что? Кому-то ведь нужно и просто работать.
Не будет мыслить в интересах команды и клиента, а только в своих.
Опять же, зависит от проекта. Иногда клиентов-то и нет еще (я имею в виду всяческое RnD).
А для воспитания очень уж самовлюбленных граждан, бывает, применяют штрафы. Как регулярная мера они, конечно, сильно портят атмосферу в коллективе, но как разовая мера — очень даже помогают отдельным личностям приобщиться к проблемам клиентов на собственной шкуре. Ну и — если вдруг гражданин решит уволиться — туда ему и дорога, не так ли? :)
Только зависимости бывают разными, если, например, одна библиотека зависит от другой — КОМПИЛИРОВАТЬ их можно параллельно, а СОБИРАТЬ (линковать), только когда зависимая будет полностью готова.
Тип зависимости в билд-системах бывает только один: зависимость.
А вот строить графы зависимостей разные билд-системы могут действительно по-разному, это да. Что касается CMake, граф зависимостей он генерирует качественный — т.е. пока линкуется одна библиотека, в параллель будут исполняться другие таргеты, которые от нее не зависят.
А вот определить тип зависимости, думаю, под силу будет только целиковой билд системе.
Ошибаетесь (2). CMake вполне себе полноценная билд-система в том плане, что он строит полное дерево зависимостей. Только в отличие от «целиковой» билд-системы, CMake полученное дерево зависимостей не начинает исполнять на конкретных файлах, а дампит в виде файлов сборки для более простых билд-систем.
Кстати, было бы действительно неплохо добавить в CMake режим сборки — скажем, в виде фейкового «генератора». Все равно там уже есть подпорки для системы сборки — режим -E, исполняющий некоторые команды кросс-платформенно.
Ну и, конечно, во главе угла, сохранность и конфиденциальность информации компании, устройства могут и подвергаются атакам, да они элементарно могут быть где-то оставлены или забыты. В данном случае это большой человеческий риск.
Другими словами, ваша статья — не о том, что во главе угла. А ведь было бы неплохо почитать о методах защиты данных в устройствах, находящихся в личном пользовании, но используемых по работе.
И не совсем понятно, что имеется в виду под «человеческим риском». Риск раскрытия персональных данных? Риск увольнения при утере CYOD-устройства? Что?
Не могу утверждать какой makefile сгенерирует для такого случая CMake, но, вероятно, здесь будет происходить последовательная сборка с расспаралеливанием только внутри построения A, B, C.
Ошибаетесь.
CMake сгенерирует файл, который будет параллелить не зависящие друг от друга таргеты.
Другое дело, что кроме CMake нужно учитывать и ту билд-систему, под которую CMake генерит файлы. Например, если это будет ninja, то билд больших проектов будет чуточку быстрее, чем если это будет gmake. Просто потому, что ninja — проще, и не пытается найти на файловой системе кучу несуществующих файлов (полюбоваться, сколько всякого говна ищет по всему диску gmake, можно, проанализировав вывод gmake -d).
Да, возвращаясь к CMake. Если сгенерировать под виндой мейкфайлы для NMake, то мы автоматически получим однопоточную и жутко тормозящую систему сборки, ибо nmake параллелит плёхо. Но это не дефект CMake, а особенность целевой системы сборки (NMake).
У automake есть пара фатальных недостатков. :)
Во-первых, не кроссплатформенный: заставить его работать под виндой — это тот еще квест.
Во-вторых, сборка плохо параллелится: максимальная единица сборки — это подкаталог. Т. е. пока все файлы в подкаталоге не соберутся, сборка дальше не пойдет. Если в проекте множество мелких подкаталогов, теряются преимущества параллельной сборки.
Помнится, делал бенчмарки по сборке одного и того же проекта тремя системами: automake, scons и cmake. Билд-сервер был многоядерный (ЕМНИП 32 ядра), но сами ядра — не очень быстрые. Так что преимущества параллельной сборки были очень видны. Подкаталогов было не очень много (с десяток; в основном там собирались статические библиотеки). Результаты были такие:
— хуже всех — Automake. За счет того, что каждый подкаталог собирается отдельно, приходилось ждать, пока в каждом подкаталоге соберутся все исходники и слинкуются в библиотеку.
— второй по скорости — CMake (генерировались UNIX Makefiles). На «холодном старте» он проигрывал SCons из-за наличия фазы проверки системы и генерации мейкфайлов. Но и при пересборке проекта из-за пары изменившихся файлов он на пару-тройку процентов проигрывал SCons. Подозреваю, что это из-за ставшего слишком хитромудрым GNU make, который на каждое правило проверяет по десятку файлов.
— Лидером стал SCons. Помню, меня это тогда весьма удивило, потому как в то время на каждом углу писали, что scons очень медленный.
Существуют некие современные «заменители» make-а: типа ninja и jam, но сути они не меняют — это очень низкоуровневые инструменты.
Самый главный заменитель make'а — это, наверное, все-таки gmake (GNU make). И я бы не сказал, что он уж очень низкоуровневый. На нем много чего хитрого наваять можно.
Ninja — это вообще промежуточная система сборки. Где-то читал, что автор рассчитывал в основном на генерируемые файлы сборки, а не на писанные вручную.
CMake — [средневековье] первая попытка уйти от низкоуровневых деталей make-а.
Они вроде как со SCons'ом появились почти ноздря в ноздрю.
Но, к сожалению, далеко уйти не удалось — движком здесь служит все тот же make для которого CMake генерирует огромные make-файлы на основе другого текстового файла с более выскоуровневым описанием билда.
Вовсе не обязательно. CMake может генерировать файлы под довольно широкий спектр сборочных систем — включая майкрософтовский MSBuild, майкрософтовский же nmake, ту же ninja и еще много подо что.
Основное преимущество CMake в том, что он позволяет выжать из нативной системы сборки все возможное (ну, по мере сил), но при этом не заморачиваться с ее тонкостями.
Из недостатков CMake — убогий удивительный язык описания билда, довольно многословный и местами неочевидный.
SCons — [новые времена] самодостаточная, кросплатформенная билд система, написанная на Python. SCons одинаково хорошо справляется как с Java так и с C++ билдами. Зависимости хидеров для инкрементальной сборки отрабатываются корректно (насколько я понял создается некая база данных с метаданными билда), а на Windows «без бубна» работает MSVC.
У SCons ранних версий были проблемы с производительностью. Авторы захотели «надежно» отслеживать изменения файлов, поэтому вместо проверки даты-времени последней модификации они сравнивали хэш первых нескольких килобайт файла (ЕМНИП, первых двух или четырех). Потом, слава аллаху, сделали этот режим опциональным.
А еще у SCons, когда я его использовал, были нетривиальные требования к версии питона. С 3-й версией он вываливался с ошибкой, да и вторая подходила далеко не всякая.
Gradle [современность] — у меня уже был позитивный опыт использования Gradle для Java и Kotlin проектов и я возлагал на него большие надежды.
Т. е. в итоге вы остановились на том, с чем уже успешно работали. Ожидаемо, но хотелось бы увидеть сравнение билд-систем немного пошире и поглубже. :)
Как оказалось, в Gradle пошли дальше и реализовали возможность выкладывать C++ артефакты в Maven Repository!
Это здорово, если человек знаком с java и maven. А если у меня кровавый энтерпрайз, JRE на машине не установлен, никакого maven и в помине нет (зато есть subversion) — насколько мне поможет gradle?
Естественно, что всю низкоуровневую работу по конфигурированию компилятора и линковщика для работы с внешним компонентом Gradle берет на себя. Вам достаточно заявить о своих намерениях использовать такую-то библиотеку с такой-то версией из такого-то репозитория.
А если его понятия о том, с какими опциями собирать проект, не совпадают с корпоративными? Насколько сложно поменять опции компилятора и линкера?
Особенно это актуально для MSVC потому что по умолчанию в результате релизного билда Вы получите «жирный», не эстетичный бинарь с дебажной информацией и статически прилинкованной стандартной библиотекой.
Ну, статически прилинкованная стандартная библиотека не так уж жирна по нынешним меркам. Сколько там — килобайт двести? Это ж ни о чем. :)
Гораздо страшнее то, что в большинстве сторонних библиотек стандартная библиотека прилинкована динамически. В результате при попытке все собрать до кучи вылезает длинная простыня маловразумительных ошибок линкера.
Кстати, а как насчет сборки инсталляторов под винду и готовых пакетов (rpm, deb, etc) под линукс? В CMake что-то такое есть, но пощупать нормально так и не удалось.
Для этого мной в Mash был добавлен класс TCriticalSection.
И все? Ни семафоров, ни условных переменных (conditional variables), ни атомиков?
Как-то маловато.
Также возникли вопросы по примеру использования:
proc CriticalThreadedProc():
while true:
Sleep(3000)
CSect -> Enter() // рекурсия поддерживается? Т.е. если я уже лочил CSect в данном треде - сработает или зависнет?
// а если тут у нас злобный джуниор вписал return - кто будет секцию разлочивать?
CSect -> Leave()
gc() // а если в вызывающей функции есть временные переменные - все, им кирдык?
end
end
ЕМНИП, даже в 95-й уже использовались свои 32-битные драйвера дисков в защищенном режиме. Разве что расчет на загрузку в «чистом» режиме ДОС.
В общем, статья полна деталей, какие операции буткит делает, но почти нет информации, зачем он это делает и почему именно так, а не иначе.
Непонятно, в чем смысл ставить хуки на int 13h и int 15h. Ведь любая современная ОС работает в защищенном режиме процессора, т. е. после загрузки ОС никто эти хуки не вызовет.
В теории все так.
На практике нечитаемый сектор далеко не сразу подменяется резервным. Какое-то время он болтается в pending reallocated sectors. А уж когда там его контроллер соблаговолит переназначить, зависит от многих факторов. У меня в экспериментах такие вот «недопереназначенные» сектора висели по полгода (и что характерно — все это время не читались). Лучший способ заставить контроллер переназначить такой сектор — это попытаться что-нибудь туда записать напрямую. Есть, конечно, и специальные команды для этого, но они вендор-специфик.
Ну и, если честно, возможности ddrescue мне показались излишними: какие стратегии чтения, какие карты? Задача была — прочитать образ диска «в лоб», а если что-то прочитать не удалось — забить
болтнепрочитанное место в образе нулями. С этой задачей dd справляется неплохо.Джентльменский набор — это smartctl, dd, scrounge-ntfs и hdparm.
smartctl позволяет проконтролировать количество бэдов.
dd позволяет сдампить образ диска для последующего выдирания с него файлов (если указать параметр conv=noerror). Также dd позволяет быстро найти сбойный сектор на диске (читаем все подряд блоками по 4 кб, при сбое чтения — dmesg|tail и смотрим, в каком физическом секторе произошел сбой).
hdparm позволяет переписать этот сектор и заново проверить его (и окружающие сектора) более пристально.
scrounge-ntfs — прекрасная утилита, умеющая выдирать файлы из образов дисков c NTFS. К сожалению, в 32-битном Debian она собрана неправильно (без -D_FILE_OFFSET_BITS=64), в результате чего практически неюзабельна. Приходится вытягивать исходники и собирать с нужными флагами.
Badblocks, к сожалению, при большом количестве бэдов может работать неделями, так что я ее пощупал и отказался от нее.
А в CMake меня умиляет то, что некоторые модули работают не совсем стандартно. Например, модуль Threads — внезапно! — не выставляет переменную THREADS_FOUND. Некоторые модули выставляют в переменной DEFINITIONS голые дефайны, а некоторые (wxWidgets, например) зачем-то прихреначивают в начало -D. Со списоком библиотек, помнится, тоже были похожие глюки. А что самое забавное — в разных версиях CMake поведение может быть разное, ибо баги исправляются.
Но ваше решение, как уже справедливо заметил sysd, не очень: винда может вдруг решить, что файлы на диске слишком фрагментированы, и перенесет заглушки в другое место.
Что касается бэдов. Если они появляются в малом количестве и редко, то лучший способ — заставить контроллер диска подменить их. Я лично использую для этого пару скриптов и утилиту hdparm под линуксом (конкретно — команды --read-sector и --repair-sector). Причина проста: посекторная проверка большого диска может занять пару суток. Под линуксом у меня круглосуточно крутится NAS, а виндовую машину приходится выключать на ночь, так что выбор платформы очевиден.
Если битых секторов становится слишком много и подменять их становится нечем, или если битые сектора появляются слишком часто, то проще такой диск разобрать на магнитики.
Впрочем, если хочется помучиться, то можно попытаться использовать помехоустойчивое кодирование (тот же код Рида-Соломона). Тогда можно подобрать параметры кодирования таким образом, что файл(ы) можно будет восстановить даже после выпадения нескольких подряд идущих секторов. Правда, придется заморочиться со специальными утилитами для кодирования-декодирования файлов на ненадежном диске. А в идеале — вообще наваять помехоустойчивую файловую систему. :)
Так себе вариант, если быть точным. Начитанные роботом тексты бездушные и безликие, зачастую — с неправильной интонацией. Да и с произношением слов не все бывает хорошо.
Гораздо лучше — аудиокниги, начитанные живыми людьми. Еще лучше — инсценировки и фильмы, т.к. с ними процесс «оттачивания» наиболее приближен к реальности.
Если уж быть совсем точным, то не перевод, а толкование.
Это хорошо, что вы упомянули про заграницу. Там действительно работают по-другому. Но дело тут не только в менталитете (в конце концов, там и наши эмигранты работают в больших количествах — и ничего, менталитет не мешает). Мне кажется, дело скорее в отношениях между работодателем и работником.
Вот как я это себе представляю (для сферы IT):
В Европе работодатель хорошо защищен социально, но при этом понимает, что социалка зависит и от его активности тоже. Отсюда — крепкие профсоюзы, а работодатели идут на компромиссы.
В Америке с работником «договариваются» зарплатой. Работник хорошо впахивает потому, что деньги нужны, работодатель хорошо платит потому, что иначе хорошие работники разбегутся.
У нас, к сожалению, социальной защищенности нет. Т.е. каждый работник по сути сам за себя. Но и с зарплатами не фонтан — ибо конкуренции не так уж и много. Вот и получается с одной стороны — имитация рабочего энтузиазма, а с другой — имитация заботы о работнике и «коллективные ценности».
Для большинства испробованных мной билд-систем (UNIX Makefiles, Ninja, разные версии Visual Studio) полученная система сборки вполне «соответствующая».
На практике все не так уж плохо, как в теории. Большинство нижележащих билд-систем умеет собирать в параллель — причем CMake генерирует для билд-системы качественные файлы, позволяющие максимально эффективно использовать параллельную сборку. NMake, который не умеет в параллельную сборку — это эдакий курьез.
Но, как я уже писал, для CMake было бы неплохо добавить небольшой(?) дополнительный шаг, чтобы вместо генерации файлов для билд-системы пошла собственно сборка. И тогда, глядишь, для большинства пользователей вообще отпадет необходимость в генерации лишних файлов.
Это можно определить на собеседовании, разве нет?
А это вот вообще ни разу не недостаток. Да, есть проекты (всякий maintenance), где амбициозность не нужна, а нужны другие качества. Но вот для стартапов амбициозность очень даже неплоха.
Задача рекрутера и собеседующих — определить, подходит ли данный конкретный человек к вашему конкретному проекту. В том числе психологически.
Не за что, ваш К.О.
Если ваш проект не подходит для «звезд» — возможно и будет. С другой стороны, если гражданин в проекте прижился и «расцвел», то он один в случае чего сможет вытянуть на себе весь проект.
Это вы описываете какого-то молодого да раннего звездуна, как мне кажется.
Я с трудом представляю себе опытного специалиста, который вдруг ни с того ни с сего вот так вот «зазвездился». Опытного — значит, поработавшего в разных проектах и разных коллективах. Такие люди, как правило, трезво понимают свою роль в коллективной разработке.
Другими словами, bad team player & trouble maker.
Опять же, даже такому гражданину иногда находится применение — например, некая узкая зона ответственности, где он может в одиночку творить что ему заблагорассудится. Узкая — чтобы в случае чего эффект автобуса был не слишком большим. :)
По поводу «моментально напишет код» вспомнилась коронная фраза одного бывшего коллеги: «как мы все знаем, хороший программист работает от силы пару часов в день. Но это не повод уходить с работы в 12». :)
Значит, менторство — не его. Ну и что? Кому-то ведь нужно и просто работать.
Опять же, зависит от проекта. Иногда клиентов-то и нет еще (я имею в виду всяческое RnD).
А для воспитания очень уж самовлюбленных граждан, бывает, применяют штрафы. Как регулярная мера они, конечно, сильно портят атмосферу в коллективе, но как разовая мера — очень даже помогают отдельным личностям приобщиться к проблемам клиентов на собственной шкуре. Ну и — если вдруг гражданин решит уволиться — туда ему и дорога, не так ли? :)
Тип зависимости в билд-системах бывает только один: зависимость.
А вот строить графы зависимостей разные билд-системы могут действительно по-разному, это да. Что касается CMake, граф зависимостей он генерирует качественный — т.е. пока линкуется одна библиотека, в параллель будут исполняться другие таргеты, которые от нее не зависят.
Ошибаетесь (2). CMake вполне себе полноценная билд-система в том плане, что он строит полное дерево зависимостей. Только в отличие от «целиковой» билд-системы, CMake полученное дерево зависимостей не начинает исполнять на конкретных файлах, а дампит в виде файлов сборки для более простых билд-систем.
Кстати, было бы действительно неплохо добавить в CMake режим сборки — скажем, в виде фейкового «генератора». Все равно там уже есть подпорки для системы сборки — режим -E, исполняющий некоторые команды кросс-платформенно.
Другими словами, ваша статья — не о том, что во главе угла. А ведь было бы неплохо почитать о методах защиты данных в устройствах, находящихся в личном пользовании, но используемых по работе.
И не совсем понятно, что имеется в виду под «человеческим риском». Риск раскрытия персональных данных? Риск увольнения при утере CYOD-устройства? Что?
Ошибаетесь.
CMake сгенерирует файл, который будет параллелить не зависящие друг от друга таргеты.
Другое дело, что кроме CMake нужно учитывать и ту билд-систему, под которую CMake генерит файлы. Например, если это будет ninja, то билд больших проектов будет чуточку быстрее, чем если это будет gmake. Просто потому, что ninja — проще, и не пытается найти на файловой системе кучу несуществующих файлов (полюбоваться, сколько всякого говна ищет по всему диску gmake, можно, проанализировав вывод gmake -d).
Да, возвращаясь к CMake. Если сгенерировать под виндой мейкфайлы для NMake, то мы автоматически получим однопоточную и жутко тормозящую систему сборки, ибо nmake параллелит плёхо. Но это не дефект CMake, а особенность целевой системы сборки (NMake).
К вам никогда не прибегал заказчик с горящими глазами и «небольшими уточнениями» к ТЗ? Еще прибежит. :)
Во-первых, не кроссплатформенный: заставить его работать под виндой — это тот еще квест.
Во-вторых, сборка плохо параллелится: максимальная единица сборки — это подкаталог. Т. е. пока все файлы в подкаталоге не соберутся, сборка дальше не пойдет. Если в проекте множество мелких подкаталогов, теряются преимущества параллельной сборки.
Помнится, делал бенчмарки по сборке одного и того же проекта тремя системами: automake, scons и cmake. Билд-сервер был многоядерный (ЕМНИП 32 ядра), но сами ядра — не очень быстрые. Так что преимущества параллельной сборки были очень видны. Подкаталогов было не очень много (с десяток; в основном там собирались статические библиотеки). Результаты были такие:
— хуже всех — Automake. За счет того, что каждый подкаталог собирается отдельно, приходилось ждать, пока в каждом подкаталоге соберутся все исходники и слинкуются в библиотеку.
— второй по скорости — CMake (генерировались UNIX Makefiles). На «холодном старте» он проигрывал SCons из-за наличия фазы проверки системы и генерации мейкфайлов. Но и при пересборке проекта из-за пары изменившихся файлов он на пару-тройку процентов проигрывал SCons. Подозреваю, что это из-за ставшего слишком хитромудрым GNU make, который на каждое правило проверяет по десятку файлов.
— Лидером стал SCons. Помню, меня это тогда весьма удивило, потому как в то время на каждом углу писали, что scons очень медленный.
Самый главный заменитель make'а — это, наверное, все-таки gmake (GNU make). И я бы не сказал, что он уж очень низкоуровневый. На нем много чего хитрого наваять можно.
Ninja — это вообще промежуточная система сборки. Где-то читал, что автор рассчитывал в основном на генерируемые файлы сборки, а не на писанные вручную.
Они вроде как со SCons'ом появились почти ноздря в ноздрю.
Вовсе не обязательно. CMake может генерировать файлы под довольно широкий спектр сборочных систем — включая майкрософтовский MSBuild, майкрософтовский же nmake, ту же ninja и еще много подо что.
Основное преимущество CMake в том, что он позволяет выжать из нативной системы сборки все возможное (ну, по мере сил), но при этом не заморачиваться с ее тонкостями.
Из недостатков CMake —
убогийудивительный язык описания билда, довольно многословный и местами неочевидный.У SCons ранних версий были проблемы с производительностью. Авторы захотели «надежно» отслеживать изменения файлов, поэтому вместо проверки даты-времени последней модификации они сравнивали хэш первых нескольких килобайт файла (ЕМНИП, первых двух или четырех). Потом, слава аллаху, сделали этот режим опциональным.
А еще у SCons, когда я его использовал, были нетривиальные требования к версии питона. С 3-й версией он вываливался с ошибкой, да и вторая подходила далеко не всякая.
Т. е. в итоге вы остановились на том, с чем уже успешно работали. Ожидаемо, но хотелось бы увидеть сравнение билд-систем немного пошире и поглубже. :)
Это здорово, если человек знаком с java и maven. А если у меня кровавый энтерпрайз, JRE на машине не установлен, никакого maven и в помине нет (зато есть subversion) — насколько мне поможет gradle?
А если его понятия о том, с какими опциями собирать проект, не совпадают с корпоративными? Насколько сложно поменять опции компилятора и линкера?
Ну, статически прилинкованная стандартная библиотека не так уж жирна по нынешним меркам. Сколько там — килобайт двести? Это ж ни о чем. :)
Гораздо страшнее то, что в большинстве сторонних библиотек стандартная библиотека прилинкована динамически. В результате при попытке все собрать до кучи вылезает длинная простыня маловразумительных ошибок линкера.
Кстати, а как насчет сборки инсталляторов под винду и готовых пакетов (rpm, deb, etc) под линукс? В CMake что-то такое есть, но пощупать нормально так и не удалось.
И все? Ни семафоров, ни условных переменных (conditional variables), ни атомиков?
Как-то маловато.
Также возникли вопросы по примеру использования:
В общем, статья полна деталей, какие операции буткит делает, но почти нет информации, зачем он это делает и почему именно так, а не иначе.