Ну и почему они обходились достаточно дорого? Что конкретно не так с архитектурой
WSL1? Что делает трансляцию системных вызовов дорогой?
Возможно сами файловые операции обходились слишком дорого по сравнению с Linux.
Например, мне известно приложение (грубо говоря распаковщик архивов) которое изначально разрабатывалось на Linux, а потом было перенесено на Windows и там работало в несколько раз медленнее. И это исправили, барабанная дробь, пулом потоков для вызова CloseHandle. Потому что антивирус как раз в этот момент подключался в работу, а разработчики не ожидали что операция "закрыть дескриптор файла" может быть медленной и соответственно программа была не рассчитана на "зависание" в этой точке и ждала "закрытия файла" хотя могла бы читать следующий файл из архива использовать ЦПУ для "разжатия" и т.п.
И конечно в чем смысл транслятора системных вызовов если каждое приложение под него нужно адаптировать,
проще запустить в вирт. машине и игнорировать антивирусы.
Rocket.Chat баговал, уведомления не приходили вовремя
Года два-три назад ставил rocket.chat и с тех пор пользуемся. И особенно никаких багов не замечал, правда я с тех пор ничего не обновлял его.
Геморно было получать у Google/Apple токены для отправки сообщений и пересобирать приложения чтобы они работали с этими токенами, плюс у некоторых пользователей с не чистым Android были всякие спец. настройки по блокированию уведомлений и приходилось
им объяснять как включить оповещения rocket.chat. Но с тех пор никаких проблем не было.
Может я чего-то не понимаю, но получается что в разгар эпидемии, когда настолько возросла роль Amazon как способа получить предметы первой необходимости, человек который плохо разбирается в логистике Amazon (т.к. давно не принимал непосредственного участия в управлении, а в это время внедрили кучу IT систем, наняли кучу народа, о которых он в лучшем случае только слышал), каждый день отвлекает кучу народа от их прямых обязанностей?
Хотелось бы, если бы принесение Раст кода в Си++ проект не было бы такой болью (я так и не понял всего объема отжимания в Firefox).
А можно подробнее про "боль"? Я в паре своих проектов без проблем интегрировал C++ и Rust. В конце концов нужно то две команды: cargo build и cbindgen, чтобы собрать библиотеку на Rust и сгенерировать заголовочный файл для нее, в общем-то не сложнее использования Qt/moc.
Хм, а в C++ варианте шесть обращений к памяти в виде mov регистр, память или mov память, регистр, в то время как в Rust только пять плюс push/pop. Не знаю будет ли от этого быстрее C++ или Rust.
Ну это не совсем классическая «подписочная» модель насколько я понял их объяснения. Покупается текущая версия и возможность обновить ее в течение какого-то срока. После истечения срока купленной версией можно пользоваться без проблем она не превратиться в тыкву что ожидается от обычных подписок. То есть это обычная покупка софта и оплата какого срока его поддержки.
Ну, например, фронтенд компилятора не всегда может убрать весь оверхед?
Так-то и у хаскеля есть llvm'ный бекенд.
А зачем фронтенду вообще оверхед убирать? У него цель перевести язык "X" в llvm ir, а все оптимизации уже применяются llvm. И в отличии от хаскеля, я не вижу причин генерировать хуже llvm ir для Rust по сравнению с относительно одинаковой программой на C++. Основное отличии Rust от C++ — "borrow checker" вообще никак не влияет на генерируемый код, а все остальные отличия совершенно незначительны.
Э… Очень странный комментарий. У компилятора clang и компилятора rust один и тот же бекенд — llvm. Как можно уступать используя одинаковые оптимизации?
А потом малина повиснет, решит обновиться, упадет в kernel panic, сломает свою файловую систему
Вообще это все крайне маловероятные события. И они требуют неких действий, например подключить ИВЛ к сети (безумное действие?) для получения обновлений или писать логи в раздел с системой и примонтировать /tmp не "в ОЗУ" для потенциального ломания ФС и т.д.
Но вообще конечно сложно представить как можно сертифицировать такую систему без гарантий жёсткого реального времени можно использовать. Хотя бы real-time патчи наложили, если там действительно используют ядро linux из дистрибутива по умолчанию.
Или, если описываешь потом, ходить смотреть по коду
Так GUI для git все время показывает контекст, никуда ходить не надо.
Смотришь список коммитов для "interactive rebase", когда выбираешь что объединить, разъеденить и т.д. и т.п., нажимаешь Enter и видишь сбоку "diff". Переписываешь комментарий к коммиту, в правой половине экрана отображается "diff" и т.п.
Всегда доступен контекст, никуда ходить и смотреть код не надо.
Если бы я мог нажать на кнопку, и моя работа переструктурировалась бы на хорошие
коммиты — я бы на неё нажал.
Так есть же вроде. Конечно не из разряда "сделай мне все хорошо", но довольно удобно. По крайней мере в том GUI для git который я использую. Пара нажатий и какие-то коммиты объедены и для них переписан комментарий, какие-то изменены местами и т.д. и т.п.
Компиляторы со временем сделают ненужными специализированные статические
анализаторы, или будут вечно догонять?
ИМХО бессмысленно их противопоставлять. В самом начале статьи указано
ключевое отличие:
Я стремился к тому, чтобы -fanalyzer «всего лишь» удвоил время компиляции в качестве
разумного компромисса между дополнительными проверками. У меня пока не получилось
Даже если и получится, то при добавлении новых проверок (список сейчас какой-то очень маленький по сравнению с clang static-analyzer) время снова существенно возрастет,
вот это и отличие статического анализатора и компилятора и от этого никуда не уйдешь.
Больше статически проверок -> неудобно запускать во время компиляции -> используется
как отдельный компонент / статический анализатор
Большинство статических анализаторов созданы на основе существующих компиляторов, тот же PVS и все они отдельные инструменты, а не часть компиляторов.
Но не понимаю, почему вопросы с дебилами должны решать программисты.
Ну опять же специфика проекта (опять же воображение, так как я никак не связан с PVS): в теории можно иметь и в отделе поддержки людей хорошо знающих и разбирающихся в C++, но это немного дорого по-моему делегировать таким людям только поддержку, рационально на мой взгляд в случае такой предметной области распределить поддержку пользователей среди программистов-добровольцев.
Не требуется никакой приписки «и мы предполагаем, что поведёт оно себя вот так»
Это конечно из раздела "мое воображение", но оно может потребоваться при общении с клиентом, который скажет ваш инструмент пишет что здесь у меня "UB", а у меня все работает, в таком случае знание что "если собрать компилятором X с опциями Y, то UB покажет себя во всей красе" может сэкономить кучу времени на объяснения что такое UB и почему это плохо.
Из личной практики, как-то на ревью кода я пытался убедить что стоит все-таки писать va_end иначе это противоречит стандарту, а мне в ответ тыкали тем, что вот с данным компилятором и на данной платформе va_end это пустой макрос.
Но вообще скорее всего это вопрос в том числе и способ "повернуть" разговор на
тему как работает компилятор и какие у современных компиляторов есть оптимизации
использующие undefined/unspecified behaviour. Ведь эти грабли с неопределенным
порядком вычисления аргументов положили не просто для того чтобы сделать жизнь
пользователей C++ поинтереснее.
Стандартный ответ «не знаю, и предполагать не буду
Так у них же другая специфика по сравнению с другими фирмами использующими C++.
У них С++ это не только язык программирования, но и предметная область.
Почему бы не поставить например над телевизором небольшую камеру
Сам же умный телевизор
Так вроде все есть же, и камера встроенная в умный телевизор (для управления жестами конечно же)
и подключение этот телевизора к интернету (для доступа к контенту конечно же) и возможность обновлять прошивку не спросив владельца. Зачем какие-то еще камеры сверху ставить, все ноутбуки, планшеты, телефоны и умные телевизоры уже готовые устройства для слежки, причем пользователь их сам купил и подключил к глобальной сети.
А в чем проблема с qt http server? GPL 2 и 3 не обязывает открывать исходники если все крутиться на ваших серверах.
А какое отношение musl и uclibc имеют к suckless ?
Возможно сами файловые операции обходились слишком дорого по сравнению с Linux.
Например, мне известно приложение (грубо говоря распаковщик архивов) которое изначально разрабатывалось на Linux, а потом было перенесено на Windows и там работало в несколько раз медленнее. И это исправили, барабанная дробь, пулом потоков для вызова
CloseHandle. Потому что антивирус как раз в этот момент подключался в работу, а разработчики не ожидали что операция "закрыть дескриптор файла" может быть медленной и соответственно программа была не рассчитана на "зависание" в этой точке и ждала "закрытия файла" хотя могла бы читать следующий файл из архива использовать ЦПУ для "разжатия" и т.п.И конечно в чем смысл транслятора системных вызовов если каждое приложение под него нужно адаптировать,
проще запустить в вирт. машине и игнорировать антивирусы.
Года два-три назад ставил rocket.chat и с тех пор пользуемся. И особенно никаких багов не замечал, правда я с тех пор ничего не обновлял его.
Геморно было получать у Google/Apple токены для отправки сообщений и пересобирать приложения чтобы они работали с этими токенами, плюс у некоторых пользователей с не чистым Android были всякие спец. настройки по блокированию уведомлений и приходилось
им объяснять как включить оповещения rocket.chat. Но с тех пор никаких проблем не было.
Может я чего-то не понимаю, но получается что в разгар эпидемии, когда настолько возросла роль Amazon как способа получить предметы первой необходимости, человек который плохо разбирается в логистике Amazon (т.к. давно не принимал непосредственного участия в управлении, а в это время внедрили кучу IT систем, наняли кучу народа, о которых он в лучшем случае только слышал), каждый день отвлекает кучу народа от их прямых обязанностей?
А можно подробнее про "боль"? Я в паре своих проектов без проблем интегрировал C++ и Rust. В конце концов нужно то две команды:
cargo buildи cbindgen, чтобы собрать библиотеку на Rust и сгенерировать заголовочный файл для нее, в общем-то не сложнее использования Qt/moc.Хм, а в C++ варианте шесть обращений к памяти в виде mov регистр, память или mov память, регистр, в то время как в Rust только пять плюс push/pop. Не знаю будет ли от этого быстрее C++ или Rust.
Ну это не совсем классическая «подписочная» модель насколько я понял их объяснения. Покупается текущая версия и возможность обновить ее в течение какого-то срока. После истечения срока купленной версией можно пользоваться без проблем она не превратиться в тыкву что ожидается от обычных подписок. То есть это обычная покупка софта и оплата какого срока его поддержки.
Они что-то поменяли?
А зачем фронтенду вообще оверхед убирать? У него цель перевести язык "X" в llvm ir, а все оптимизации уже применяются llvm. И в отличии от хаскеля, я не вижу причин генерировать хуже llvm ir для Rust по сравнению с относительно одинаковой программой на C++. Основное отличии Rust от C++ — "borrow checker" вообще никак не влияет на генерируемый код, а все остальные отличия совершенно незначительны.
А можно расшифровать вашу фразу, что значит возражения не осталось?
Вот этот C++ код на Rust, выдает тот же ассебмлер что и C++:
https://rust.godbolt.org/z/Ze7HDG
Один в один, в чем вообще может быть различие между clang и rustc в таких же простых примерах, llvm и там и там, а все оптимизации в llvm
Э… Очень странный комментарий. У компилятора clang и компилятора rust один и тот же бекенд — llvm. Как можно уступать используя одинаковые оптимизации?
Вообще это все крайне маловероятные события. И они требуют неких действий, например подключить ИВЛ к сети (безумное действие?) для получения обновлений или писать логи в раздел с системой и примонтировать /tmp не "в ОЗУ" для потенциального ломания ФС и т.д.
Но вообще конечно сложно представить как можно сертифицировать такую систему без гарантий жёсткого реального времени можно использовать. Хотя бы real-time патчи наложили, если там действительно используют ядро linux из дистрибутива по умолчанию.
А в чем сложность с 40 файлами?
Буфер/окно с "diff" конечно прокручивается.
Так GUI для git все время показывает контекст, никуда ходить не надо.
Смотришь список коммитов для "interactive rebase", когда выбираешь что объединить, разъеденить и т.д. и т.п., нажимаешь Enter и видишь сбоку "diff". Переписываешь комментарий к коммиту, в правой половине экрана отображается "diff" и т.п.
Всегда доступен контекст, никуда ходить и смотреть код не надо.
Так есть же вроде. Конечно не из разряда "сделай мне все хорошо", но довольно удобно. По крайней мере в том GUI для git который я использую. Пара нажатий и какие-то коммиты объедены и для них переписан комментарий, какие-то изменены местами и т.д. и т.п.
ИМХО бессмысленно их противопоставлять. В самом начале статьи указано
ключевое отличие:
Даже если и получится, то при добавлении новых проверок (список сейчас какой-то очень маленький по сравнению с clang static-analyzer) время снова существенно возрастет,
вот это и отличие статического анализатора и компилятора и от этого никуда не уйдешь.
Больше статически проверок -> неудобно запускать во время компиляции -> используется
как отдельный компонент / статический анализатор
Большинство статических анализаторов созданы на основе существующих компиляторов, тот же PVS и все они отдельные инструменты, а не часть компиляторов.
Ну опять же специфика проекта (опять же воображение, так как я никак не связан с PVS): в теории можно иметь и в отделе поддержки людей хорошо знающих и разбирающихся в C++, но это немного дорого по-моему делегировать таким людям только поддержку, рационально на мой взгляд в случае такой предметной области распределить поддержку пользователей среди программистов-добровольцев.
Это конечно из раздела "мое воображение", но оно может потребоваться при общении с клиентом, который скажет ваш инструмент пишет что здесь у меня "UB", а у меня все работает, в таком случае знание что "если собрать компилятором X с опциями Y, то UB покажет себя во всей красе" может сэкономить кучу времени на объяснения что такое UB и почему это плохо.
Из личной практики, как-то на ревью кода я пытался убедить что стоит все-таки писать va_end иначе это противоречит стандарту, а мне в ответ тыкали тем, что вот с данным компилятором и на данной платформе va_end это пустой макрос.
Но вообще скорее всего это вопрос в том числе и способ "повернуть" разговор на
тему как работает компилятор и какие у современных компиляторов есть оптимизации
использующие undefined/unspecified behaviour. Ведь эти грабли с неопределенным
порядком вычисления аргументов положили не просто для того чтобы сделать жизнь
пользователей C++ поинтереснее.
Так у них же другая специфика по сравнению с другими фирмами использующими C++.
У них С++ это не только язык программирования, но и предметная область.
Так вроде все есть же, и камера встроенная в умный телевизор (для управления жестами конечно же)
и подключение этот телевизора к интернету (для доступа к контенту конечно же) и возможность обновлять прошивку не спросив владельца. Зачем какие-то еще камеры сверху ставить, все ноутбуки, планшеты, телефоны и умные телевизоры уже готовые устройства для слежки, причем пользователь их сам купил и подключил к глобальной сети.