Всецело одобряя автора комментария замечу — что ИТ-это хорошо, но на большом количестве предприятий (не только оборонно-ракетных) не хватает инженеров, для которых ИТ важно, но является инструментом для решения прикладных задач. У нас в силу ряда причин (и зарплатных, и престижа профессии, и наличия интересных задач) — «ит для ит» получило хорошее развитие, а там где ИТ надо связать с проектированием и выпуском реальных объектов — все довольно кисло. Кое-что в этом направлении двигается (см. например недавние статьи о частичном автопилоте для комбайнов). Но есть представление, что все это «too little and too late», увы…
Нельзя писать абстрактные правила. Даже если для «повесить на стену» есть выжимка на листе A4 — где-то должен быть дизайн-документ с объяснениями, ради чего то, или иное правило вводится.
Крайне частая ошибка — это пытаться документом изменить практику разработки. Докладываю — практика документами не меняется! Даже, блин, в армии — начальство пишет документы про одно, в низах делается другое (хотя субординация, и «служи — по уставу!»). Очень советую почитать что-нибудь про change management: нужно, чтобы сначала появилась потребность в определенном правиле, чтобы эта потребность стала осознанной, чтобы были ресурсы для выполнения правила — и только потом можно писать правило в документ.
Обязательно проверяйте — если выполняя ваши правила можно устроить «итальянскую забастовку», значит — правила плохие (не жизненные, работать не нарушая их — невозможно) и их следует переделывать.
Тут не могу спорить, так как не владею информацией. По-моему сделать-то можно, а вот навесить шильдик совместимости нельзя без «отдать много денег» разработавшему консорциуму. Однако, патенты — это уже меньшее зло. Они действуют не везде, и имеют свои юридические ограничения (в частности, процедуру принудительно лицензирования). Опять же, для внутреннего использования собирать единичные экземпляры никто не запрещает.
Вот меня не очень интересует, почему (!) производитель это делает. Заставляет ли его так делать рыночная сила, флаги в модулях ядра, пункт в законе, или мужик с паяльником — какая разница? Итоговый результат один и тот же — спецификация физического подключения открыта и доступна. Я еще раз повторюсь, что не вижу разницы между физическим и логическим уровнем. Выпустили на потребительский рынок продукт — извольте спецификацию внешнего интерфейса! В случае с LGA еще можно сделать вид, что это внутренний интерфейс Intel, который используется исключительно для взаимодействия одного их оборудования внутри системы — с другим. В конце-концов, они разрабатывают и процессор, и чипсет для него. В случае с видеокартой, так не получится. Выше написали, что альтернатива NVIDIA — начать делать целиком закрытую программно-аппаратную систему (без опоры на Linux/GPL) и пытаться ее продавать. Тогда у меня лично никаких вопросов по интерфейсу к ней не будет.
Производитель в общем случае не обязан, и не имеет права знать (или ограничивать) покупателя в использовании вещи. Ну вас же не удивляет, что описывая электрический интерфейс — производитель указывает, что оно соответствует спецификации, скажем PCIx4? Это явным образом определяет геометрию и назначение контактов, тактовую частоту, протокол конфигурации устройства, и так далее. При этом вы можете выбрать любую материнскую плату с таким стандартом (или, если существующие не устраивают — сделать свою с необходимыми свойствами). Я не вижу большой разницы между физическим и логическим интерфейсом устройства. Оба они необходимы для того, чтобы устройство могло быть использовано по-назначению. Поэтому у производителя в конце-концов мытьем или катаньем останется три альтернативы: раздавать на недискриминационных условиях необходимую документацию, реализовать в аппаратуре хорошо определенный стандарт, или, гм, выложить опенсорсный драйвер и переложить эту обязанность на тех, кому больше надо. Насколько я понимаю, разработчики ядра Linux мягко принуждают товарищей к третьему варианту.
Я не настолько юрист по лицензиям, но разве тут были нарушены юридические контракты на код и соответствующие лицензии? Тогда надо в суд подавать, а не условия менять.
Подавать в суд — право, а не обязанность сторон. Гражданский кодекс допускает самозащиту прав у нас, и думаю примерно то же допускается у них, несмотря на другую правовую систему. То есть если разработчики пока считают, что флаги в подсистеме модулей Linux — достаточный стимул чтобы разрешить ситуацию — так тому и быть, наверно.
Про GCC другая ситуация. Все-таки он берет ваш (!) исходный код и транслирует его в машинные коды. Тут вообще может быть ситуация, что это не будет признано самостоятельным произведением — потому что механическое применение даже сложных правил — в общем случае не признается творческой деятельностью. Но разработчики GCC для бОльшей правовой определенности явно разрешили части своего кода появляться в результатах компиляции вашего — заранее отказавшись от всяких прав на результат компиляции.
А откуда производителю знать, как именно владелец собирается использовать приобретенное устройство? Вы когда металл покупаете — металлург же не спрашивает вас, как вы это собрались использовать — просто сообщает вам существенные свойства покупаемого полуфабриката (либо через бумажку с физ-хим свойствами, либо через указание well-known сорта стали). Полуфабрикат из кремния и радиокомпонентов сложнее — но принцип тот же. Покупателю либо сообщаются существенные свойства изделия в объеме, достаточном для самостоятельного использования (втч написания драйвера). Либо устройство реализует well-known API (к которому изготовитель может сделать документированные расширения, если ему это надо). «Спецификация с функциями и условия эксплуатации» — это, IMHO из другой оперы. Так можно обращаться с готовыми изделиями, которые уже содержат все нужные конечному пользователю функции и используются per se. Компонент, который может использоваться только в соединении с другими компонентами в составе сложного изделия — обязан быть документирован в достаточной степени, чтобы независимый производитель/пользователь мог такую интеграцию производить. По-моему, для всех остальных отраслей кроме ИТ — это совершенно не обсуждаемая норма. Даже хуже — на примере John Deere, оно пытается из ИТ распространиться на элементы материального производства. Надеюсь, что не получится!
— "… почему бы фанатикам просто не взять и не уйти на своё уютненькое идеологически стерильное Linux-libre"?
— Потому что люди и компании, вложившие свои ресурсы в создание Linux-фичей — делали это на определенных условиях (GPL). Позволить определенным компаниям использовать вложенные ресурсы для продвижения своих продуктов и софта, но при этом не соблюдать GPL — это нарушение контракта с предыдущими разработчиками. Понятно-дело, что в России такое — фактически обычай делового оборота. Но в устоявшихся, цивилизованных обществах с большим горизонтом планирования — так делать обычно не допускается… Ибо грозит утратой доверия и резким ростом тразакционных издержек — а именно это конкурентное преимущество они и не хотят потерять!
Скорее поддерживаю. Покупатель аппаратного устройства должен иметь право использовать его по назначению. Очевидно, что такое право подразумевает возможность разрабатывать ПО для этого устройства и использовать его со свободным программным или аппаратным обеспечением. Поскольку право, не обеспеченное встречной обязанностью — фикция: производитель обязан либо раскрыть детали реализации своего устройства в достаточной степени, чтобы можно было написать полнофункциональный драйвер — либо, если производитель не желает этого делать (конкурентные преимущества, коммерческая тайна, то-сё...) — предоставить реализованный исключительно внутри устройства публичный well-known API. Сдается мне, что выставление флагов в модулях GPL — более мягкая мера, нежели антимонопольное расследование или законодательное принуждение…
Я лично с большим вниманием прочитал гайды по CRM (начать можно с видео и статей Дениса Оканя (https://denokan.livejournal.com/). Там много интересного как раз о правилах и процедурах: зачем, почему, как учить, и т.д. Плюс даются паттерны, как обсуждать проблему в условиях высоких рисков и ограниченного времени, не скатываться в борьбу характеров, и т.д.
Из авиации же — «принцип черной кабины»: нормально работающая система не должна привлекать к себе внимание или требовать постоянных проверок. Однако, любые отказы и аномалии должны быть явно и однозначно обозначены персоналу.
У атомщиков я с удовольствием стащил понятие «максимальной проектной аварии (МПА)», и принцип построения системы защиты так, чтобы в случае МПА все были живы и здоровы. Оттуда же — аварийные действия персонала по приведению системы в безопасное состояние не должны требовать сложных решений и рассудочных действий. В идеале — нажал кнопку аварийной защиты — и оно само, уже тебя ни о чем не спрашивая — сбросит, заглушит, расхолодит, и т.д. Потом в спокойной обстановке будете разбираться, что к чему было…
Моя адаптация этого принципа в работу была примерно в 2004 году — инструкция по переводу довольно большой ИТ-системы на работу в резервном режиме (другой сервер, резервная серверная примерно в 20 км). Эта инструкция содержала два пункта: первый — зайти пользователем таким-то, пароль такой-то на сервер IP такой-то. Второй — выполнить команду такую-то, переход системы в резервный режим произойдет в течение 3-5 минут автоматически. И мне было не важно, кто будет это делать — программист, администратор, или хотя бы слесарь КиП: чье тело найдут по телефону, тот и будет делать! Не важно, хочет ли он спать, пил он вчера или нет, знает ли особенности системы, и т.д. — если команда прошла, остальное от него не зависит.
P.S. Реальный переход в резервный режим был один раз примерно за 6 лет работы.
Я бы с чисто практической точки зрения поменял первый пункт «Мы следуем принятым принципам, независимо от согласия с ними» на нечто близкое к традициям авиационных CRM (cabin resource management): «Выполняй, или объясняй». То есть если ты выполняешь принятые правила или процедуру — это по-умолчанию OK. И ты можешь отступать от утвержденной процедуры при условии (!) что можешь объяснить причину и цель такого действия. В идеале — до того, как выполнение нестандартной процедуры началось («брифинг»), но можно и после — если действие неотложное («сообщение о проблеме»). При этом, разумеется: «не успел», «не подумал», «думал, прокатит» и все в таком духе — надлежащими объяснениями не являются.
Это — с одной стороны, не лишает людей гибкости в реальных ситуациях, и дает понимание, что стандарт — не удавка, а лучшая практика. С другой стороны — заставляет давать обратную связь о ситуациях, когда стандарт оказался неприменим. И дальше можно решать — то ли это разовая ситуация, ради которой менять стандарт нет смысла (если в стандарте описать все что только можно — он будет незапоминаем, нечитаем и неприменим) — то ли ситуация частая/опасная/whatever — и ее надо пихать в стандарт, чтобы в следующий раз не экспериментировать наживую.
Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков. Они там по краю ходят — в том смысле, что можно одной простой ошибкой угробить сразу много народа. Поэтому жизнь их заставляет придумывать всякие интересные штуки для предотвращения неприятных ситуаций. Напрямую в разработку это, конечно, не перенести — иначе разработка упадет под гнетом предотвращения рисков и стоить будет о-го-го сколько! Но отдельные элементы — это прямо вот что доктор прописал. Особенно, для ответственных приложений и сервисов…
Блин, скачайте докер-образ Redmine, поставьте и посмотрите. Если речь идет о синхронизации работы сотрудников, должно хватить. Когда поймете, чего именно не хватает — пойдете по рынку смотреть предложения поставщиков. Считаю, что начинать надо с бесплатного, и желательно с OpenSource. Настаивать не буду, впрочем.
Тут важно понимать две вещи. Первое — Java Memory Model является попыткой абстрактно описать наиболее вероятные реализации аппаратных платформ. Она обеспечивает приемлемую производительность на существующих архитектурах, и (мы надеемся) даже на тех, которые еще не оформлены в реальных процессорах и машинах. Поэтому JMM не может делать предположение, что составные части процессора или разные процессоры имеют синхронизацию кэша (или она достаточно дешево работает).
Во-вторых, помимо кэша есть еще out-of-order execution. И вот с этим вы простой синхронизацией кэша ничего не сделаете. Ядро обязано переупорядочивать операции внутри своего конвейера так, чтобы с его (!) точки зрения результат был эквивалентен потоку изначальных операций. Но эта эквивалентность может (и будет) нарушаться с точки зрения соседних ядер. Например, выполняя последовательность операций A=A+1;B=5 ядро вынуждено упорядочить операции чтения и записи A (ну потому что иначе нельзя прибавить к нему единицу). Что касается присвоения B — оно (с точки зрения этого ядра) является чистым побочным эффектом, и его можно выполнить до присвоения A (например, пока АЛУ прибавляет единицу). А можно после. А другое ядро может выполнять свою, неизвестную первому ядру программу — где критично именно чтобы B записалось после A. Выявить такие зависимости в общем виде — невозможно. Поэтому появляются механизмы типа memfence, которые заставляют процессор гарантировать что до этой операции чтения все операции записи исполнены. Ценой просадки производительности, естественно. Java Memory Model своими happens-before задает правила, где мы жертвуем определенностью ради скорости, а где — наоборот.
А, да — еще третий фактор забыл — JIT. Например, имея последовательность операций A=A+B; A=A+C;A=A+D — компилятор и JIT в рантайме имеют по-умолчанию полное право один раз считать A в регистр, и сбросить его в память (не важно, в кэш или RAM) только после последнего сложения. Запрещать свосем это нельзя — ибо производительность. Вот и тут JMM задает пределы, до которых компилятор и JIT имеют право интерпретировать наши намерения. И в целом, сравнивая существующее положение с миром C++ — мы живем даже очень неплохо!
Вот я именно про это! Вы полагаетесь на код-ревью для обеспечения качества. При этом у вас нет гарантий, что ревьювер понимает точно, что вы написали. Что он с утра свеж и у него не болит голова, и т.д. Мы где-то в районе 2008 года поняли что в нашей сфере это добром не кончится — взяли в работу идеи testable design, и начали писать тесты. И теперь меня не очень интересует, замылился глаз у разработчика или нет. Если он замылился настолько, что это ломает normal execution path — тесты покажут. А искать глазами ошибки, которые не выявляются тестами — ну так себе занятие… И да, естественно — у нас написание тестов является обязанностью разработчика.
В моем понимании, code-review — это не процедура обеспечения качества ПО (на что почему-то часто надеются...). В отличие, например, от pair-programming. Потому что это же как скрытые работы в строительстве: если ты лично видел как бетон лили, и что в него клали — тогда можно ручаться за результат. А если тебе показывают уже готовое — то чтобы его освидетельствовать — это куча мала экспертиз и расходов… И можно так аккуратно дерьма внутрь наложить, что оно все-равно рухнет со всеми экспертизами и подписями… :-(
Что тогда дает ревью кода? По-моему, только обратную связь автору. То есть это в чистом виде инструмент обучения. Отсюда — нет смысла делать ревью на 5000 строк. Это никого и ничему не научит… Да и вообще, не следует давать малоопытным разработчикам писать большие куски системы. Код-ревью нужны в период адаптации (чтобы один залетевший дятел случайно не разрушил цивилизацию), и для воспитания джунов. На уровне миддла, разработчик уже должен сам устойчиво контролировать качество своего кода и уметь вовремя обращаться к старшим, если не очевиден наиболее уместный способ реализации той или иной фичи. А с третьей стороны, для обучения гораздо важнее обратная связь по ходу разработки, а не в конце. В программировании слишком много способов сделать работу неправильно и неэффективно, чтобы надеяться методом коде-ревью отучить разработчиков делать неправильно. Надо, наоборот, учить правильным и эффективным методам работы.
Ну, я бы аккуратно заметил что начало C++ было неплохое. Например, string после (const) char * гораздо более удобен. А вот cin-cout не зашли. Так и продолжили пользоваться printf-ом. Стандартные коллекции упрощают жизнь во многих случаях. Криками «ура» приветствовали ключевое слово «auto», потому что иначе определения итераторов и проч. всех достали. Почему-то умные указатели не зашли. Ну то есть понятно почему — динамического распределения памяти нет, в коллекциях хранятся исключительно указатели на уже созданные объекты.
Но и на чистом Си тоже вполне пишется, если не надо особых абстракций — а просто жесткую логику реализовать. Как подумаешь, сколько под это надо было раньше корпусов 74 (155) серии поставить… :-)
Надо смотреть реализацию mbtowc в glibc. Не занимался этим, честно! Но что-то мне кажется, что преобразование UTF-8 — wide char сложно заинлайнить. Особенно, с учетом ситуации что на вход имеют право поступать некорректные UTF-8 последовательности.
Ну тогда проблема, скорее всего, не в алгоритме расчета как таковом, а в преобразовании многобайтовых символов в wide-chars. Попытавшись подумать за разработчика стандартной библиотеки — у меня сходу нет хорошего решения. Будет приличное количество if-ов, таблицы в памяти, и т.д. То есть имеем сразу в кучу: промахи предсказателя ветвлений, срывы пайплайна, нелокальность данных, и т.д. И ладно бы мы сначала начитали эти символы в приложение, а потом начали с ними что-то разумное делать — потери растворились бы на фоне… А тут по-сути, чтение символа и его преобразование и есть вся работа. КПД хуже паровоза, нафиг…
Про coreutils — насколько я вижу, для UTF-16 он работает с той же скоростью что и для LC_ALL=«C». Разница в 4 раза возникает из-за символов переменной длины, следовательно. Интересно посмотреть, сохраняется ли она если дать на вход корректный UTF8-файл. Очевидно, что в бинарном файле по крайней мере часть попыток преобразования потока байт через mbrtowc завершаются ошибкой, и оно вынуждено восстанавливать контекст и/или запускать mbrtowc со сдвижкой на один байт, пока снова не запустится корректное преобразование.
Крайне частая ошибка — это пытаться документом изменить практику разработки. Докладываю — практика документами не меняется! Даже, блин, в армии — начальство пишет документы про одно, в низах делается другое (хотя субординация, и «служи — по уставу!»). Очень советую почитать что-нибудь про change management: нужно, чтобы сначала появилась потребность в определенном правиле, чтобы эта потребность стала осознанной, чтобы были ресурсы для выполнения правила — и только потом можно писать правило в документ.
Обязательно проверяйте — если выполняя ваши правила можно устроить «итальянскую забастовку», значит — правила плохие (не жизненные, работать не нарушая их — невозможно) и их следует переделывать.
Подавать в суд — право, а не обязанность сторон. Гражданский кодекс допускает самозащиту прав у нас, и думаю примерно то же допускается у них, несмотря на другую правовую систему. То есть если разработчики пока считают, что флаги в подсистеме модулей Linux — достаточный стимул чтобы разрешить ситуацию — так тому и быть, наверно.
Про GCC другая ситуация. Все-таки он берет ваш (!) исходный код и транслирует его в машинные коды. Тут вообще может быть ситуация, что это не будет признано самостоятельным произведением — потому что механическое применение даже сложных правил — в общем случае не признается творческой деятельностью. Но разработчики GCC для бОльшей правовой определенности явно разрешили части своего кода появляться в результатах компиляции вашего — заранее отказавшись от всяких прав на результат компиляции.
— Потому что люди и компании, вложившие свои ресурсы в создание Linux-фичей — делали это на определенных условиях (GPL). Позволить определенным компаниям использовать вложенные ресурсы для продвижения своих продуктов и софта, но при этом не соблюдать GPL — это нарушение контракта с предыдущими разработчиками. Понятно-дело, что в России такое — фактически обычай делового оборота. Но в устоявшихся, цивилизованных обществах с большим горизонтом планирования — так делать обычно не допускается… Ибо грозит утратой доверия и резким ростом тразакционных издержек — а именно это конкурентное преимущество они и не хотят потерять!
Из авиации же — «принцип черной кабины»: нормально работающая система не должна привлекать к себе внимание или требовать постоянных проверок. Однако, любые отказы и аномалии должны быть явно и однозначно обозначены персоналу.
У атомщиков я с удовольствием стащил понятие «максимальной проектной аварии (МПА)», и принцип построения системы защиты так, чтобы в случае МПА все были живы и здоровы. Оттуда же — аварийные действия персонала по приведению системы в безопасное состояние не должны требовать сложных решений и рассудочных действий. В идеале — нажал кнопку аварийной защиты — и оно само, уже тебя ни о чем не спрашивая — сбросит, заглушит, расхолодит, и т.д. Потом в спокойной обстановке будете разбираться, что к чему было…
Моя адаптация этого принципа в работу была примерно в 2004 году — инструкция по переводу довольно большой ИТ-системы на работу в резервном режиме (другой сервер, резервная серверная примерно в 20 км). Эта инструкция содержала два пункта: первый — зайти пользователем таким-то, пароль такой-то на сервер IP такой-то. Второй — выполнить команду такую-то, переход системы в резервный режим произойдет в течение 3-5 минут автоматически. И мне было не важно, кто будет это делать — программист, администратор, или хотя бы слесарь КиП: чье тело найдут по телефону, тот и будет делать! Не важно, хочет ли он спать, пил он вчера или нет, знает ли особенности системы, и т.д. — если команда прошла, остальное от него не зависит.
P.S. Реальный переход в резервный режим был один раз примерно за 6 лет работы.
Это — с одной стороны, не лишает людей гибкости в реальных ситуациях, и дает понимание, что стандарт — не удавка, а лучшая практика. С другой стороны — заставляет давать обратную связь о ситуациях, когда стандарт оказался неприменим. И дальше можно решать — то ли это разовая ситуация, ради которой менять стандарт нет смысла (если в стандарте описать все что только можно — он будет незапоминаем, нечитаем и неприменим) — то ли ситуация частая/опасная/whatever — и ее надо пихать в стандарт, чтобы в следующий раз не экспериментировать наживую.
Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков. Они там по краю ходят — в том смысле, что можно одной простой ошибкой угробить сразу много народа. Поэтому жизнь их заставляет придумывать всякие интересные штуки для предотвращения неприятных ситуаций. Напрямую в разработку это, конечно, не перенести — иначе разработка упадет под гнетом предотвращения рисков и стоить будет о-го-го сколько! Но отдельные элементы — это прямо вот что доктор прописал. Особенно, для ответственных приложений и сервисов…
Во-вторых, помимо кэша есть еще out-of-order execution. И вот с этим вы простой синхронизацией кэша ничего не сделаете. Ядро обязано переупорядочивать операции внутри своего конвейера так, чтобы с его (!) точки зрения результат был эквивалентен потоку изначальных операций. Но эта эквивалентность может (и будет) нарушаться с точки зрения соседних ядер. Например, выполняя последовательность операций A=A+1;B=5 ядро вынуждено упорядочить операции чтения и записи A (ну потому что иначе нельзя прибавить к нему единицу). Что касается присвоения B — оно (с точки зрения этого ядра) является чистым побочным эффектом, и его можно выполнить до присвоения A (например, пока АЛУ прибавляет единицу). А можно после. А другое ядро может выполнять свою, неизвестную первому ядру программу — где критично именно чтобы B записалось после A. Выявить такие зависимости в общем виде — невозможно. Поэтому появляются механизмы типа memfence, которые заставляют процессор гарантировать что до этой операции чтения все операции записи исполнены. Ценой просадки производительности, естественно. Java Memory Model своими happens-before задает правила, где мы жертвуем определенностью ради скорости, а где — наоборот.
А, да — еще третий фактор забыл — JIT. Например, имея последовательность операций A=A+B; A=A+C;A=A+D — компилятор и JIT в рантайме имеют по-умолчанию полное право один раз считать A в регистр, и сбросить его в память (не важно, в кэш или RAM) только после последнего сложения. Запрещать свосем это нельзя — ибо производительность. Вот и тут JMM задает пределы, до которых компилятор и JIT имеют право интерпретировать наши намерения. И в целом, сравнивая существующее положение с миром C++ — мы живем даже очень неплохо!
Что тогда дает ревью кода? По-моему, только обратную связь автору. То есть это в чистом виде инструмент обучения. Отсюда — нет смысла делать ревью на 5000 строк. Это никого и ничему не научит… Да и вообще, не следует давать малоопытным разработчикам писать большие куски системы. Код-ревью нужны в период адаптации (чтобы один залетевший дятел случайно не разрушил цивилизацию), и для воспитания джунов. На уровне миддла, разработчик уже должен сам устойчиво контролировать качество своего кода и уметь вовремя обращаться к старшим, если не очевиден наиболее уместный способ реализации той или иной фичи. А с третьей стороны, для обучения гораздо важнее обратная связь по ходу разработки, а не в конце. В программировании слишком много способов сделать работу неправильно и неэффективно, чтобы надеяться методом коде-ревью отучить разработчиков делать неправильно. Надо, наоборот, учить правильным и эффективным методам работы.
Но и на чистом Си тоже вполне пишется, если не надо особых абстракций — а просто жесткую логику реализовать. Как подумаешь, сколько под это надо было раньше корпусов 74 (155) серии поставить… :-)