Comments 33
А как же pyinstaller? Он тоже позволяет сделать самораспаковывающийся архив, внутри будет Python и все библиотеки.
Есть на гитхабе проект, где в докере собирается всё под любую платформу - я собирал для Linux и Windows (под Wine).
Есть, конечно, нюансы. Оригинальный проект не обновлялся лет 5, но есть новые форки, и самому можно поправить для новых версий Python. Но 40 минут не хватит, это да.
Вместо pyinstaller решил исследовать pyoxidizer, и нам он понравился больше, о чём пишу в статье :)
При этом pyinstaller тоже отличный инструмент, просто он функционально примерно ту же нишу занимает что и pyoxidizer, так что решил не раздувать статью.
Да, первый раз читал статью с телефона, упустил этот момент. Однако, действительно, смущает дата последнего релиза - декабрь 2022.
Да, к сожалению мейтейнер немного сменил приоритеты и месяц назад даже начал искать нового мейтейнера проекта. Не думаю что проект пропадёт, пользователей много и качество его на высоте, но поглядим.
Да, pyinstaller классная вещь. А по проекту с докером не совсем понятно, зачем он нужен. Там конфигурации всего ничего. Сам так собираю бинарники под разные платформы.
Я бы выбрал pyinstaller.
pyoxidizer уже год как не обновляется, а в nuitka пока так и не завезли python3.12
Я бы выбрал pyinstaller.
pyoxidizer уже год как не обновляется, а в nuitka пока так и не завезли python3.12
обираться со старой glibc. Glibc имеет обратную совместимость — если что-то собрано на Ubuntu 17, на Ubuntu 20 оно тоже заработает. А вот обратное не гарантируется.
Они периодически ломают и обратную совместимость на уровне ABI. В общем случае можно ориентироваться на мажорную версию. Но в истории были нюансы. Подробнее тут https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html.
нужно быть осторожнее с лицензиями. Существуют такие лицензии, которые, например, разрешают использование в виде исходного кода, но не в виде статически слинкованного объектного файла. Не зная этого, условия можно случайно нарушить
Интересно, упаковка библиотек под LGPL в исполняемый файл вместе с приложением, будет автоматически триггерить требования этой лицензии, связанные с необходимостью раскрытия способа сборки (т.е. на практике - всех ваших исходников)?
Тут кстати pyinstaller таит в себе подвох - он под линуксом по умолчанию берёт с собой библиотеку libreadline - которая даже не LGPL, а GPL3. И весь код сразу попадает под copyleft требования GPL. Если не посмотреть, можно случайно попасть.
А PyOxidizer об этом наоборот подумал и имеет возможность поставляться с libedit.
С LGPL, учитывая требование возможности у пользователя заменить библиотеку под LGPL на самостоятельно скомпилированную, упаковка в один файл видится плохим вариантом у обоих тулов. Лучше поставляться папкой.
Почему мы все-таки пишем на Python?? ну вот такие мы .... (уровень развития).
можно например написать на Жаве, пихнуть все в JAR и дать клиенту. Но ... (уровень развития).
насколько я понимаю для .... (уровень развития) придумали Докер. ну или там VM. но ...
Правительство США: так, разработчики Америки, отныне мы рекомендуем Вам писать на Rust, вместо Java и Golang, поскольку он является более прозрачным и, следовательно, безопасным, в вопросах использования памяти!
Разработчик Kaspersky OS: так, разработчики России, сейчас я вас научу, как можно запихнуть ваш python код в экзешник и выполнить на любом компе!
Я ничего не упустил?
Если в первом абзаце вы ссылаетесь на доумент BACK TO THE BUILDING BLOCKS: A PATH TOWARD SECURE AND MEASURABLE SOFTWARE, то Rust в нем явно упоминается лишь один раз, а ваше толкование несколько "преувеличено":
The space ecosystem is not immune to memory safety vulnerabilities, however there are several constraints in space systems with regards to language use. First, the language must allow the code to be close to the kernel so that it can tightly interact with both software and hardware; second, the language must support determinism so the timing of the outputs are consistent; and third, the language must not have – or be able to override – the “garbage collector,” a function that automatically reclaims memory allocated by the computer program that is no longer in use.xvi These requirements help ensure the reliable and predictable outcomes necessary for space systems.
According to experts, both memory safe and memory unsafe programming languages meet these requirements. At this time, the most widely used languages that meet all three properties are C and C++, which are not memory safe programming languages. Rust, one example of a memory safe programming language, has the three requisite properties above, but has not yet been proven in space systems. Further progress on development toolchains, workforce education, and fielded case studies are needed to demonstrate the viability of memory safe languages in these use cases. In the interim, there are other ways to achieve memory safe outcomes at scale by using secure building blocks. Therefore, to reduce memory safety vulnerabilities in space or other embedded systems that face similar constraints, a complementary approach to implement memory safety through hardware can be explored.
Разумеется, преувеличено. Я и не скрывал иронии.
А к чему Ваша ирония?
К тому, что в современном мире IT набирает обороты тенденция отхода от языков с низким порогом вхождения, типа Java или Golang - в пользу языков с лучшим управлением памятью. И связано это с многочисленными инцидентами безопасности. Можно вспомнить истории с уязвимостями ЦПУ, когда можно было получить доступ к памяти устройства. Истории с размещением вредоносного кода в репозиториях сверхвысокоуровневых языков (NPM, PyPi). Истории с размещением вредоносного кода в библиотеках, входящих в состав дистрибутивов Linux. Даже, истории с санкциями, когда целому вендору закрывали доступ к репозиторию Google Play. Всё это как бы намекает на то, что вскоре может образоваться тенденция использовать языки с более прозрачным контролем памяти, или языки без обширных неконтролируемых репозиториев, пакеты в которых невозможно проверить ввиду их обилия.
Статья, безусловно, интересная. Просто иронично, что материал о сборке python приложений для их поставки на исполняемую машину, выходит в это время. И выходит из-под пера разработчика ОС, позиционирующейся, как безопасный аналог западных решений.
К тому, что в современном мире IT набирает обороты тенденция отхода от языков с низким порогом вхождения, типа Java или Golang - в пользу языков с лучшим управлением памятью.
Нет такой тенденции, достаточно посмотреть любую статистику по языкам.
И связано это с многочисленными инцидентами безопасности
И чем же управление памятью с GC хуже чем borrow check в плане безопастности? Если вы про недавние рекомендации вашингтона, то там речь шла про С++, если про отрывок выше, то там речь про системы реального времени для космоса, для которых важна детерминированость времени работы(space systems). Нет, CRUD микросервисы к таким системам не относятся.
Можно вспомнить истории с уязвимостями ЦПУ,
Можно вспомнить. И каким образом условный раст защитит вас от Spectre? Вы, видимо, не понимаете как работает side channel attack.
Истории с размещением вредоносного кода в репозиториях сверхвысокоуровневых языков (NPM, PyPi)
Буквально недавно была история размещения уязвимости в XZ, написано на С. Какая в принципе взаимосвязь между языком и аттакой на репозиторий?
Даже, истории с санкциями, когда целому вендору закрывали доступ к репозиторию Google Play. Всё это как бы намекает на то, что вскоре может образоваться тенденция использовать языки с более прозрачным контролем памяти
А причем тут гугл плей, санкции и контроль память?
Просто иронично, что материал о сборке python приложений для их поставки на исполняемую машину, выходит в это время
Иронично только то, что вы пытаетесь в иронию, допуская при этом в каждом свое предложении ошибочные и безграмотные утверждения и абсолютно не разбираясь в вопросе, о котором пишете.
Может, и не разбираюсь, но, если верить публикациям, и если это не первоапрельский розыгрыш, то та же корпорация Google уже форсирует переход на Rust в некоторых командах:
https://www.securitylab.ru/news/547188.php
https://www.opennet.ru/opennews/art.shtml?num=60556
А, учитывая письмо Вашингтона, это выглядит именно как следствие закручивания гаек безопасности в проектах американских компаний.
А ещё, я менее токсичен, чем вы. Несомненный плюс.
Первая статья "C++ в прошлом, Rust – наше будущее"
Вторая статья "Google выделил миллион долларов на улучшение переносимости между С++ и Rust"
Как это относится к "в современном мире IT набирает обороты тенденция отхода от языков с низким порогом вхождения, типа Java или Golang - в пользу языков с лучшим управлением памятью"
Или вы С++ ставите в один ряд с Java и Golang, не токсичный вы наш?
Google выделил миллион долларов на улучшение переносимости между С++ и Rust
Кстати, причины такой щедрости здесь недавно описывали: у Google Chrome, который в основном написан на C++, возникли проблемы с boringssl, после того как куски последней переписали на Rust. Команда не смогла с этим справиться в режиме обычного багфиксинга. Поэтому кто-то сверху решил закидать проблему деньгами. Речи о каких-то глобальных изменениях для Гугла естественно не идёт. В глобальном плане, разработку захватывают нейронки, а им в общем-то без разницы на каком языке сочинять код.
Прямым образом относится. Google переводит код с голанг - на раст, пока в блоге Касперского предлагают не рассматривать голанг, и информируют читателей, чем собрать исполняемый файл из пайтон-кода. Собственно, с этого и начинается ветка. Ну, почти: вместо тезиса о переписывании гуглом кода на "Ржавом", я упомянул комментарий АНБ относительно безопасных языков, новость о котором датируется примерно теми же датами, которыми датируются первые упоминания о вливании гуглом бюджета в переписывание кода на раст:
https://habr.com/ru/news/796901/
Хабр, видимо превратился в Одноклассники, если местным звëздам, залайканным пенсионерами, приходится объяснять каждый панч.
я упомянул комментарий АНБ относительно безопасных языков, новость о котором датируется примерно теми же датами
Лучше читайте первоисточники, а не интерпретации журналистов. Администрация Байдена агитирует за повышение безопасности софта на всех уровнях. Но ни кто до сих пор не понимает как и в чем эту самую безопасность измерять, чтобы в итоге решить повысилась она или понизилась и на что ушли бюджетные деньги.
Предыдущая попытка разработать такие методики ни к чему не привела. Это известная проблема, о чем собственно и упоминантся в докладе. Остальное там вода, про то как все страшно, и как бы стало все замечательно, если бы такие методики изменения все же появились.
По-моему, Касперский и Ко написал поболее программного обеспечения, чем правительсво сша.
Так что лучше верьте Касперскому.
(можно использовать как сарказм; а можно и не использовать)
Хочу заметить, что Касперский и Ко написали этот софт, преимущественно, на ЯП, созданных в США, либо, компаниями, работавшими на мин обороны США (AT&T), либо, на языках, компиляторы или интерпретаторы которых были написаны с помощью этих американских языков. Простой пример - язык C, созданный в Лаборатории Белла, которая вышла из AT&T.
Ого, окно Овертона в действии.
На мой взгляд, все, что в рамках 300 мс, нормально для консольного инструмента.
Серьёзно? Это же очень медленно! Даже 100мс уже неприятно ощущаются.
Сначала узкоспециализированный язык для инженеров становится мейнстримом, а потом оказывается что у него специфические проблемы потому что он узкоспециализированный язык для инженеров.
Вот не понимаю я этих новых тенденций тащить всякие жаваскрипты и питоны в каждую щель, а потом с этим всем героически бороться. Ну есть же жава, есть раст, есть .нет, ну зачем же продолжать есть кактус
Потому что это экономически выгодно. Если у вас есть инженер(сисадмин/девопс/named it), который хорошо знает инфраструктуру, то дешевле попросить его написать cli тул на чем он там может, хоть питон, хоть брейнфак, чем подключать программиста. Да, потом в каких-то случаях придется что-то менять. А может и не придется, может эти тулы напишут один раз и забудут - события будущего наступят неизвестно когда, а платить зарплату надо здесь и сейчас.
Без холивара «переписать все на Go»: проблема переносимости в Python и ее решение