WinAPI и POSIX , бой насмерть

[Qraizer]

Цитата D_KEY @ 02.05.21, 18:26

Это связано с инструментами, консервативными взглядами, или еще с чем-то, на твой взгляд?

Не отвечу на пацана, но если я правильно представляю ситуацию, так в итоге дешевле. Поясню, что итог складывается из многих факторов, и из качества документации далеко не в последнюю очередь. Для POSIX ОС требуется гораздо больше работы по квалификации процессов. К тому же стоимость владения лицензией винды ниже, и нередко ниже стоимости лицензий специализированного ПО под неё. Последнее в связи с рыночным спросом, естественно.

Цитата D_KEY @ 02.05.21, 18:26

Надежность и windows точно можно рядом ставить? Вообще не очень похоже.

Подумай сам. Если б Windows не имела бы преимуществ перед *nixами, MS бы давно сменила политику. Что касается безопасности и надёжности, потроллю немного, в манах по обеспечению того и другого при обсуждении той или иной уязвимости за POSIX ОС обычно читаешь "отключить", "отказаться от использования", "составить белый список и следить за логами", "заменить на новое" или там "пропатчить", и всё это примерно равномерно. А за Винду чаще всего "настроить" или "пропатчить". И лишь иногда что-то другое. В конце концов я не слышал, чтобы что-то из POSIX было сертифицировано по C2 Level, тогда как такие сертификаты имеют WinNT 3.5, 4.0 и 2000. Но это может быть связано с тем, что те просто не заморачивались, а если и заморачивались, то это отдельные специальные сборки, в широком кругу неизвестные. Впрочем, это тоже показатель.

Цитата D_KEY @ 02.05.21, 18:26

А это не сферический критерий. По крайней мере косвенно и в современном мире. Ядро linux того же разрабатывают специалисты со всего мира, из разных компаний, так же есть и энтузиуасты, что не всегда противоречит профессионализму.

Видишь ли, это вообще ничего не гарантирует. Вспомни недавние скандалы с Java-либами и github-ными открытыми преоктами. Сколько лет они лежали в открытом доступе, и всем было плевать, что там понаписано, так что бакдуры расползись по куче других проектов. Поймите, наконец, что качество кода не зависит от его открытости или бесплатности. Зато если код хорошо документирован, его всегда можно покрыть тестами и выявить несоответствия с описанием. И внезапно пофик на доступность сырцов.

Цитата D_KEY @ 02.05.21, 18:26

MS вполне выгодно. Развитие WSL это показывает. Да и такие штуки, как windows terminal, winget и пр. так же показывают, что люди идут в сторону близких к *nix решений.

Не-а. Банальная борьба за расширение рынка влияния. Если людям кое-что кое-где удобнее не как тут, а как там, давайте тут им сделаем так, как они там привыкли. В конце концов WinNT изначально, с 1993-го года (!), поддерживала POSIX и была сертифицирована на совместимость с ним. Поддержка была убрана лишь в WinXP. По очевидным, думаю, причинам. Нынче вот возвращают. Ничего особенного, обычный рыночный виток.

Сообщение отредактировано: Qraizer - 03.05.21, 15:53

[korvin]

Цитата Qraizer @ 03.05.21, 15:31

Видишь ли, это вообще ничего не гарантирует. Вспомни недавние скандалы с Java-либами и github-ными открытыми преоктами. Сколько лет они лежали в открытом доступе, и всем было плевать, что там понаписано, так что бакдуры расползись по куче других проектов. Поймите, наконец, что качество кода не зависит от его открытости или бесплатности. Зато если код хорошо документирован, его всегда можно покрыть тестами и выявить несоответствия с описанием. И внезапно пофик на доступность сырцов.

Да можно и не вспоминать, есть совсем недавний скандал:

Цитата

Исследователи из университета Миннесоты — Цюши У и Канцзе Лу в рамках исследования «небезопасности» OSS модели пытались выяснить, насколько вероятно намеренное добавление уязвимостей в проекты. Среди прочего патчи были отправлены в ядро Linux.

В результате код ревью прошли 4 патча, в том числе 3 содержащих уязвимости. Представители проекта Linux обратились с жалобой на исследование к администрации университета, однако не нашли поддержки. Потому было принято решение больше никогда не принимать патчи от людей из этого заведения.

P. S. Сам скандал не столько из-за результатов исследования, сколько из-за того, как они были опубликованы.

Сообщение отредактировано: korvin - 03.05.21, 15:53

[Qraizer]

Цитата shm @ 02.05.21, 19:40

Вот повезло, что я пишу с телефона и мне неудобно цитировать твои же предыдущие ответы. Кратко - ты сам предлагал их использовать две страницы назад для решения задачи на эвентах.

Та ладно, я сам процитирую.

Цитата Qraizer @ 30.04.21, 22:08

Цитата shm @ 23.04.21, 12:40

Собственно, эффективную (без пробуждения всех читателей при записи) и простую (сопоставимую по сложности с CV) реализацию писателей-читателей (можно без приоритетов) на евентах я бы тоже хотел увидеть.

Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.

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

Цитата shm @ 02.05.21, 19:40

Ты говорил, что это просто, но решения и даже ссылки до сих пор нет. Расцениваю как слив.

Ну естественно. Как же ещё это было расценить. Но намекну: тебе нужны события с автосбросом, которые не бинарные, а со счётчиком. Это семафоры. Но мой вариант использовал бы кольцевой буфер с тремя служебными полями индексов/указателей, для которых достаточно интерлокед операций. То, что непонимание с твоей стороны этой банальщины я ещё в апреле посчитал сливом, я писать не стал, просто предложил забить, но хозяин барин.

Цитата shm @ 02.05.21, 19:40

Мне вообще не особо понятно как мы перешли от обсуждения кривости архитектуры и примера с событиями к качеству и рискам. Ещё раз повторюсь, что на кривой архитектуре можно построить надёжное приложение (обычно подперев изрядным количеством костылей). Верно и обратное - на "совершенном" api построить нечто очень глючное. Короче смысла обсуждать этот аспект я вообще не вижу.

Та легко. Я указал объём и качество документации по WinAPI как огромное преимущество, ты с этой точкой зрения не согласился, предпочёв посчитать таковым открытость. Ты посчитал большое количество параметров или полей в структурах кривостью, я это назвал гибкостью. Тут мы, думаю, не договоримся, ибо это вопрос предпочтений, объективизмом и не пахнет. Но я хотя бы аргументировал, чем с моей точки зрения гибкость лучше.

Добавлено 03.05.21, 16:14

Цитата korvin @ 02.05.21, 20:49

API, у которого документация (да и которое, видимо само) больше чем все другие API вместе взятые — это жирность, а не гибкость. Гибкое API не нуждается в тоннах жира. Plan 9 API — гибкое, а WinAPI — жирное.

Ты ошибаешься. Документации никогда не бывает много, даже когда её много. Хотел бы я, чтобы было иначе, но увы. Типичнейший пример, притча по языцах:

const int *data;
/.../
long *header_ptr = (long*)data;

Почти наверняка без понимания того, что хотел написать программист, ты не сможешь определить, корректен ли этот код. Тут может быть три различных варианта того, что он хотел, но без пояснений выбрать правильный невозможно. Хоть усмотрись в этот код всеми четырьмя глазами, высмотри до дыр, не определишь. Это ставит огромный крест на код-ревью только лишь по коду. Если только не знать всю подноготную архитектуры кода, которая, конечно же, является документацией на проект. К слову, у нас в отрасли всегда есть множество уровней документации — системные требования, требования верхнего уровня, требования нижнего уровней (последние могут уходить вглубь на несколько уровней), описание проекта ПО, описание процесса сборки ПО, описание архитектуры ПО, совместимость с целевым вычислителем, анализ стратегии управления кешем, анализ использования стека, анализ наихудшего времени исполнения — и это только то, что под нашей сферой ответственности со стороны верификации. Конечно, наша отрасль весьма особенная, и отраслевые стандарты очень строги, но как раз это и показывает роль моего тезиса о роли количества и качества документации. При желании документацию можно сделать очень хорошей, было бы желание тратить на это ресурсы. У MS желание было.

Сообщение отредактировано: Qraizer - 03.05.21, 16:15

[D_KEY]

Цитата Qraizer @ 03.05.21, 15:31

Цитата D_KEY @ 02.05.21, 18:26

А это не сферический критерий. По крайней мере косвенно и в современном мире. Ядро linux того же разрабатывают специалисты со всего мира, из разных компаний, так же есть и энтузиуасты, что не всегда противоречит профессионализму.

Видишь ли, это вообще ничего не гарантирует. Вспомни недавние скандалы с Java-либами и github-ными открытыми преоктами. Сколько лет они лежали в открытом доступе, и всем было плевать, что там понаписано, так что бакдуры расползись по куче других проектов. Поймите, наконец, что качество кода не зависит от его открытости или бесплатности. Зато если код хорошо документирован, его всегда можно покрыть тестами и выявить несоответствия с описанием. И внезапно пофик на доступность сырцов

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

Сообщение отредактировано: D_KEY - 03.05.21, 16:19

[Qraizer]

Ой, пропустил.

Цитата D_KEY @ 02.05.21, 09:38

Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром

Нет. В 2001-ом в std ещё ничего для этого не было, тогда как мы, работая тогда в КБ на военку, постоянно были под возможностью того, что нас отрежут от буржуйских инструментальных средств. Даже OS2000 кто-то из наших занимался. Вот я и написал себе простую обёртку над объектами синхронизации, чтоб при необходимости можно было переписать реализацию под pthread. И даже переписал, но потом, уже там не работая. Поверхностно, т.е. на синтетике, прочекал под AstraLinux, был у нас дистр.

Добавлено 03.05.21, 16:22

Цитата D_KEY @ 03.05.21, 16:19

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

Ну так потребителю-то пофик. У него в ПО косяк, для негатива в адрес ПО этого ему будет достаточно.

[D_KEY]

Цитата Qraizer @ 03.05.21, 15:31

Цитата D_KEY @ 02.05.21, 18:26

Надежность и windows точно можно рядом ставить? Вообще не очень похоже.

Подумай сам. Если б Windows не имела бы преимуществ перед *nixами, MS бы давно сменила политику.

Во-первых, она меняет. Во-вторых, все преимущества лежат не в технической сфере

Цитата

в манах по обеспечению того и другого при обсуждении той или иной уязвимости за POSIX ОС обычно читаешь "отключить", "отказаться от использования", "составить белый список и следить за логами", "заменить на новое" или там "пропатчить", и всё это примерно равномерно. А за Винду чаще всего "настроить" или "пропатчить". И лишь иногда что-то другое.

Во-первых, ты продолжаешь сравнивать конкретную ОС со стандартами ОС Нужно взять какой-нибудь конкретный red hat и посмотреть на его примере.
Во-вторых, давай какой-то конкретный пример рассмотрим.

Добавлено 03.05.21, 16:27

Цитата Qraizer @ 03.05.21, 16:21

Цитата D_KEY @ 03.05.21, 16:19

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

Ну так потребителю-то пофик. У него в ПО косяк, для негатива в адрес ПО этого ему будет достаточно.

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

Ещё вот я сейчас работаю в двух системах, винда очень капризна А уж её обновления...

[korvin]

Цитата Qraizer @ 03.05.21, 15:52

Документации никогда не бывает много, даже когда её много.

Если документации требуется много, то это кривое API, а не хорошая документация.

Цитата Qraizer @ 03.05.21, 15:52

К слову, у нас в отрасли всегда есть множество уровней документации — системные требования, требования верхнего уровня, требования нижнего уровней (последние могут уходить вглубь на несколько уровней), описание проекта ПО, описание процесса сборки ПО, описание архитектуры ПО, совместимость с целевым вычислителем, анализ стратегии управления кешем, анализ использования стека, анализ наихудшего времени исполнения — и это только то, что под нашей сферой ответственности со стороны верификации. Конечно, наша отрасль весьма особенная, и отраслевые стандарты очень строги, но как раз это и показывает роль моего тезиса о роли количества и качества документации.

Это показывает лишь требования в вашей отрасли, а не во всех. Во многих других отраслях такая подробная документация в большинстве случаев — признак плохого кода/плохой архитектуры.

[D_KEY]

Цитата Qraizer @ 03.05.21, 16:21

Ой, пропустил.

Цитата D_KEY @ 02.05.21, 09:38

Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром

Нет. В 2001-ом в std ещё ничего для этого не было

Это понятно. Но я так понял, что вы продолжаете это использовать и для нового кода. Вот тут я бы задумался и на твоем месте пожалел бы своих коллег.

[shm]

Цитата Qraizer @ 03.05.21, 15:52

Но намекну: тебе нужны события с автосбросом, которые не бинарные, а со счётчиком.

Так и запишем, что на event'ах нормального решения для классической блокирующей очереди нет. Что я и пытался объяснить.

Цитата Qraizer @ 03.05.21, 15:52

Это семафоры.

На семафорах, действительно, можно. Но это вообще неинтересно и оффтоп. Их реализация в WinApi не так далека от классической и обсуждать тут особо нечего. Только это одни из самых тяжелых ядерных объектов синхронизации.

Цитата Qraizer @ 03.05.21, 15:52

Но мой вариант использовал бы кольцевой буфер с тремя служебными полями индексов/указателей, для которых достаточно интерлокед операций.

Для кольцевого буфера - да, достаточно. Но только для него самого. Есть определенные проблемы с расширением этого самого буфера при нехватке места, они решаемы, хотя и делает реализацию на порядок сложнее. Но такая реализация не решает проблему с усыплением читателя, если ему нечего делать. На фьютесах - это довольно красиво реализуется, а "родными" средствами winapi громоздко и запутанно (если постоянно не дергать тяжелые объекты синхронизации, которые поставят под сомнение вообще любой профит от atomic).
Qraizer, ты в это споре занимаешься классической демагогией:
1. явно не отвечаешь на заданные вопросы, некоторые просто игнорируешь;
2. уводишь обсуждение в другую сторону;
3. когда твой оппонент начинает возражать, ты начинаешь ссылаться на то, что имел ввиду вообще другое.
И да, из этого спора я не узнал ничего нового. Ну разве что про внутреннее устройство io_uring почитаю. Все перечисленные объекты синхронизации, включая семафоры, я знаю "изнутри". Более того, я их реализовывал, пусть и не оптимально (оптимальная реализация того же семафора потянет на целую научную работу). Я давно планировал выложить все на гитхаб и чуть позже сделаю это, чтобы не выглядеть балаболом (осдев у меня это чисто хобби). Тема с эффективной блокирующей очередью меня интересовала длительное время т.к. это ключевой аспект для реализации асинхронного io в ядре. В итоге я потратил на изучение готовых решений не мало времени. И я был рад увидеть тут какие-то интересные решения того, чего я не знаю / в чем заблуждаюсь. Но в итоге ты занял позицию, что твой оппонент просто нуб. Прости если тебя не понял, Александр. Но по мне это выглядит именно так.

Сообщение отредактировано: shm - 03.05.21, 18:39

[D_KEY]

Интересный контракт

Цитата

Заказчик
ФЕДЕРАЛЬНАЯ СЛУЖБА ПО ТЕХНИЧЕСКОМУ И ЭКСПОРТНОМУ КОНТРОЛЮ

Цитата

Выполнение работ по созданию технологического центра исследования безопасности операционных систем, созданных на базе ядра Linux, включая разработку проектной (технической) документации и создание программно-аппаратного комплекса центра исследования безопасности операционных систем

Добавлено 03.05.21, 18:38

Цитата shm @ 03.05.21, 18:29

Все перечисленные объекты синхронизации, включая семафоры, я знаю "изнутри". Более того, я их реализовывал, пусть и не оптимально (оптимальная реализация того же семафора потянет на целую научную работу). Я давно планировал выложить все на гитхаб и чуть позже сделаю это, чтобы не выглядеть балаболом (осдев у меня это чисто хобби).

Цитата

Ну разве что про внутреннее устройство io_uring почитаю.

Если доберешься, то напиши своё мнение, интересно.

Я не вчитывался в ваш спор, но если он про асинхронный ввод/вывод, то в windows же iocp используется, в основном? И не такая уж плохая штука, разве нет?

[shm]

Цитата D_KEY @ 03.05.21, 18:32

то в windows же iocp используется, в основном?

В основном - да. Все остальное использует ПО где нет нагрузки, а также всякие древние разработки (еще с win9x) или просто "топорные" порты с linux'а (вроде nginx под винду так и не имеет поддержки iocp). Но есть подозрение, что дебрях винды остался только iocp, а все остальное (всякие извращения с результатом io операции в оконном событии) реализуются уже поверх него.

Цитата D_KEY @ 03.05.21, 18:32

И не такая уж плохая штука, разве нет?

Штука неплохая. Если сравнивать с epoll, то более высокоуровневая. Поэтому на epoll реализовать iocp тривиально (что и делает wine), а в обратную сторону - фиг там. Что лучше - не знаю, скорее вопрос вкусовщины. Но явных архитектурных косяков как с теми же событиями в iocp я не знаю.

Сообщение отредактировано: shm - 03.05.21, 18:48

[D_KEY]

Цитата shm @ 03.05.21, 18:44

Если сравнивать с epoll, то более высокоуровневая. Поэтому на epoll реализовать iocp тривиально (что и делает wine)

А с обычными файлами как быть? epoll же с ним не работает (io_uring решает эту проблему, кстати).

[shm]

Если речь про то как wine решает проблему - не знаю. Но большое количество параллельных файловых операций - это скорее экзотика. Поэтому скорее всего просто закостылено, возможно, что даже на потоках.

Сообщение отредактировано: shm - 03.05.21, 19:58

[Fester]

Цитата D_KEY @ 02.05.21, 08:34

Если самолёты управляются софтом на windows, то мне страшно.

Не знаю как в самолетах, а вот блоки управления для автомобилей зачастую работают под embedded виндой. Во всяком случае, на прошлой работе мы делали инсталлер для некоторых блоков управления.

Цитата

Microsoft -Windows Embedded Automotive 7 is the OS for In Vehicle Infotainment (IVI) systems such as Ford Sync, Kia Uvo and Nissan Leaf. Most widely used car OS today.

Так что машины на винде есть А надежность софта там нужна не меньше, чем на самолете.

[korvin]

Цитата Fester @ 03.05.21, 20:17

Не знаю как в самолетах, а вот блоки управления для автомобилей зачастую работают под embedded виндой. Во всяком случае, на прошлой работе мы делали инсталлер для некоторых блоков управления.

Ты в какой-то неправильной Германии живёшь.
https://www.phoronix.com/scan.php?page=news...=BMW-Linux-2019
https://jobs.daimler.com/job/275774/infotai...d-engineer.html