Я большой поклонник Го, но очень настоятельно не рекомендую писать на Го shared library: рантайм Го может конфликтовать с рантаймом вызывающего языка (если конкретно - руби в моем случае) при увеличении стэка горутины. Возникает падение связанное с повреждением/порчей памяти.
Данная проблема известна довольно давно, но поскольку данное направление для разработчиков языка не является приоритетным - уже несколько лет остаётся не решенным. Мне не хватает времени для погружения в недра компилятора и создания соответствующего PR. Возможно кто-то, кому это критично сможет выделить ресурсы.
Если нужно вынести вычисления во что-то быстрое, то я бы порекомендовал использовать любые механизмы IPC (Unix sockets, напрямую stdin/stdout pipes, etc) и запускать модуль как отдельный подпроцесс. Или использовать языки с фиксированным стэком. В идеале вообще без рантайма. В крайнем случае - не использовать горутины в shared library.
Если кто-то будет писать свои кодогенераторы на основе разбора кода Го — будьте аккуратны, там много пограничных случаев (например встраивание типов, алиасинг и enum'ы). Посмотрите мои проекты выше — там много собрано костылей и боли.
Первый — более старый и менее чистый но разносторонний, третий более новый и причесанный.
Немного обидно за Сбер. Тем более, что в случае IT — это СберТех.
Сам там отработал несколько лет: от инженера до начальника. Да, есть проблемы. Да, есть бюрократия. Да, есть неэффективность местами.
Однако, масштаб организации настолько огромный (в штате десятки тысяч людей), что большинство хипстерских подходов не работают или вредят. Бюрократия внезапно превращается в полезный инструмент, который фильтрует и сглаживает резкие импульсы системы, сохраняя стабильность движения, а для стратегических проектов наоборот, пинает и поддерживает, даже когда интерес или средства закончились.
При всей неоднозначнности Г.О. Грефа, то что он сделал со Сбером — достойно уважения и восхищения.
К сожалению, внутренняя кухня Сбера совершенно не видна потребителем. За счёт этого кажется стагнация и волокита.
Резюмируя: ИМХО, в Сбере есть очень много уникальных специалистов любого уровня и способных решить самые сложные проблемы.
P.S
К сожалению, сейчас в Сбере уже не работаю, но расстались мы в хороших отношениях
В свое время у меня была задача сделать подключение в Go хранения данных в KV хранилищах. Долго не мог выбрать, и в итоге сделал "универсальную" обертку с несколькими бэк-эндами. https://github.com/reddec/storages
Бонусом: всякая разная типо-безопасная кодогенерация. Возможно будет интересно.
В таком простом проекте даже bottle.py сойдёт. А как только перестанет хватать (что вряд-ли) на flask всего несколько минут мигрировать.
И читать проще код будет, и функционала больше
Можно пожалуйста доказательство того, что есть неисправленные уязвимости Tinc 1.0.36 и исправленные/недопущенные в 1.1? Это серьезное заявление, которое действительно имеет смысл в нашем обсуждение. Вы уже второй комментатор, который ссылается на это.
Я не уловил, но как это относится к предмету обсуждения? Я же не свой VPN создавал, а обертку. Возможно вы имели ввиду, что есть другая функционально схожая обертка (для 1.0.x)? Буду признателен, если скинете ссылку.
Как можно называть версию устаревший, если (а) обновления выходят регулярно, (б) нет другой версии этого же продукта в релизной версии? В Вашем примере про питон: версии py3-RC, не позиционировались как готовые решения для замены 2.7. Только с момента релиза.
Тут есть фундаментальная проблема: с моей точки зрения, довод в пользу 1.0 — его стабильность и актуальность, 1.1 — не релиз (что подчеркивается на сайте). С одной стороны, я признаю Ваши аргументы в пользу 1.1 (функциональность, удобство и в целом более продуманный дизайн). С другой, Вы мои аргументы не признаете. Логический тупик для диалога. Ну или диалог превращается в монолог.
Могу я Вас попросить все же не использовать подобного рода формулировки? "Фапать", "школьник" — не тот уровень диалога, который обычно ожидается на профессиональном ресурсе.
Мне кажется есть определенного уровня недопонимание:
Я не навязываю никому и ничего — есть проблема: сложность настройки Tinc 1.0 в ряде ситуаций. Одно из решений — tinc-boot.
В статье однозначно описывается взаимодействие с Tinc 1.0. Смысл обсуждать 1.1 — если в статье в явном виде описано ограничение на 1.0? Это вне рамках текста. Если есть желание пообщаться — можно перейти в личные диалоги.
Я обосновал свое решение относительно 1.0. Вы и некоторые другие с ним не согласились. С моей точки зрение имеется паритет мнений. Дальнейшее обсуждение не имеет смысла (как мне кажется).
Я ни в коей мере не ограничиваю (и не навязываю) ни Вам лично, ни читателем единственное верное решение. Это сугубо личное решение каждого. Доводы "за" и "против" приведены. Далее — вопросы приоритетов и личных предпочтений.
Для меня лично, использовать в критичных местах (а вопросы безопасности я считаю критичными) версии продуктов, которые не помечены как стабильные не приемлемо. Можете считать это профессиональной деформацией.
1.1 безусловно шаг вперёд. Напомните, пожалуйста, когда они в релиз планируют вывести?
Я то этого уже жду несколько лет.
Смею заметить, Ваша фраза про кактус несколько категорична. У меня нет ни малейшего желания изобретать велосипед. Однако пользоваться продуктом в нерелизной версии в вопросах безопасности — неоправданный (для меня) риск.
Так что либо кто-то принимает риск и пробует все новое (я так понимаю Ваш случай), либо кто-то (как я) используют проверенные решения и адаптируют их под нужные условия.
Во-первых, все-же трафик зашифрованный и аутентифицированный, пусть и передаваемый по открытым каналам связи. Подменить или прочитать сообщение (не зная токен) нельзя.
Во-вторых, предположим будет возможность задавать сертификаты (это не сложно добавить). Тогда Вам либо (а) придется добавлять сертификаты в доверенные каждого устройства (при самоподписанном сертификате), либо (б) использовать честные сертификаты (let's encrypt например), что в Вашем контексте о роутере звучит необычно. С другой стороны, для серверов это имеет смысл.
Реализовать несложно. Если Вас не затруднит, можете, пожалуйста, оформить это как feature request на github?
Там зашифрованная передача. Я акцентировал внимание на этом в трёх местах в статье. Можно перед сервисом поставить ssl proxy (nginx..), если будет спокойнее.
2, 3. Спасибо, так наверное можно сделать. Но нужно детально проработать
Я большой поклонник Го, но очень настоятельно не рекомендую писать на Го shared library: рантайм Го может конфликтовать с рантаймом вызывающего языка (если конкретно - руби в моем случае) при увеличении стэка горутины. Возникает падение связанное с повреждением/порчей памяти.
Данная проблема известна довольно давно, но поскольку данное направление для разработчиков языка не является приоритетным - уже несколько лет остаётся не решенным. Мне не хватает времени для погружения в недра компилятора и создания соответствующего PR. Возможно кто-то, кому это критично сможет выделить ресурсы.
Если нужно вынести вычисления во что-то быстрое, то я бы порекомендовал использовать любые механизмы IPC (Unix sockets, напрямую stdin/stdout pipes, etc) и запускать модуль как отдельный подпроцесс. Или использовать языки с фиксированным стэком. В идеале вообще без рантайма. В крайнем случае - не использовать горутины в shared library.
Svelte может взять на себя обвязку (отслеживание свойств, стилизация и тп) и скомпилироваться в вебкомпонент. Как пример такого компонента: https://reddec.net/demo/github-card/ (исходный код https://github.com/reddec/github-card)
systemd-run делает это элементарно.
С одной стороны кодогенерация позволяет видеть созданный код, с другой — мне приходится писать проекты типа
https://github.com/reddec/struct-view,
https://github.com/reddec/jsonrpc2/tree/master/cmd/jsonrpc2-gen/internal или
https://github.com/reddec/godetector/tree/master/deepparser
А в большинстве случаев можно было бы обойтись generic/template. Надеюсь их все таки завезут при моей жизни в язык.
Если кто-то будет писать свои кодогенераторы на основе разбора кода Го — будьте аккуратны, там много пограничных случаев (например встраивание типов, алиасинг и enum'ы). Посмотрите мои проекты выше — там много собрано костылей и боли.
Первый — более старый и менее чистый но разносторонний, третий более новый и причесанный.
Немного обидно за Сбер. Тем более, что в случае IT — это СберТех.
Сам там отработал несколько лет: от инженера до начальника. Да, есть проблемы. Да, есть бюрократия. Да, есть неэффективность местами.
Однако, масштаб организации настолько огромный (в штате десятки тысяч людей), что большинство хипстерских подходов не работают или вредят. Бюрократия внезапно превращается в полезный инструмент, который фильтрует и сглаживает резкие импульсы системы, сохраняя стабильность движения, а для стратегических проектов наоборот, пинает и поддерживает, даже когда интерес или средства закончились.
При всей неоднозначнности Г.О. Грефа, то что он сделал со Сбером — достойно уважения и восхищения.
К сожалению, внутренняя кухня Сбера совершенно не видна потребителем. За счёт этого кажется стагнация и волокита.
Резюмируя: ИМХО, в Сбере есть очень много уникальных специалистов любого уровня и способных решить самые сложные проблемы.
P.S
К сожалению, сейчас в Сбере уже не работаю, но расстались мы в хороших отношениях
leveldb для себя и S3 + redis для работы
В свое время у меня была задача сделать подключение в Go хранения данных в KV хранилищах. Долго не мог выбрать, и в итоге сделал "универсальную" обертку с несколькими бэк-эндами. https://github.com/reddec/storages
Бонусом: всякая разная типо-безопасная кодогенерация. Возможно будет интересно.
В таком простом проекте даже bottle.py сойдёт. А как только перестанет хватать (что вряд-ли) на flask всего несколько минут мигрировать.
И читать проще код будет, и функционала больше
Если включено локальное обнаружение пиров (tinc-boot включает его в конфиг) то будет напрямую общаться.
Да yggdrasil я смотрел и даже немного участвую в разработке/обсуждении.
Нет, отнюдь. PFS это серьезный довод, чтобы присмотреться к 1.1 (даже если он и не в релизе).
Спасибо за детали.
Не считая perfect forward security — это отсылка на CVE-
2018-16758, которая исправлена после 1.0.34
Можно пожалуйста доказательство того, что есть неисправленные уязвимости Tinc 1.0.36 и исправленные/недопущенные в 1.1? Это серьезное заявление, которое действительно имеет смысл в нашем обсуждение. Вы уже второй комментатор, который ссылается на это.
Могу я Вас попросить все же не использовать подобного рода формулировки? "Фапать", "школьник" — не тот уровень диалога, который обычно ожидается на профессиональном ресурсе.
Мне кажется есть определенного уровня недопонимание:
Я ни в коей мере не ограничиваю (и не навязываю) ни Вам лично, ни читателем единственное верное решение. Это сугубо личное решение каждого. Доводы "за" и "против" приведены. Далее — вопросы приоритетов и личных предпочтений.
Для меня лично, использовать в критичных местах (а вопросы безопасности я считаю критичными) версии продуктов, которые не помечены как стабильные не приемлемо. Можете считать это профессиональной деформацией.
В целом я свою точку зрения высказал выше, но забыл добавить:
1.1 безусловно шаг вперёд. Напомните, пожалуйста, когда они в релиз планируют вывести?
Я то этого уже жду несколько лет.
Смею заметить, Ваша фраза про кактус несколько категорична. У меня нет ни малейшего желания изобретать велосипед. Однако пользоваться продуктом в нерелизной версии в вопросах безопасности — неоправданный (для меня) риск.
Так что либо кто-то принимает риск и пробует все новое (я так понимаю Ваш случай), либо кто-то (как я) используют проверенные решения и адаптируют их под нужные условия.
Спасибо! Увы, выборки по другим пользователям у меня нет.
Во-первых, все-же трафик зашифрованный и аутентифицированный, пусть и передаваемый по открытым каналам связи. Подменить или прочитать сообщение (не зная токен) нельзя.
Во-вторых, предположим будет возможность задавать сертификаты (это не сложно добавить). Тогда Вам либо (а) придется добавлять сертификаты в доверенные каждого устройства (при самоподписанном сертификате), либо (б) использовать честные сертификаты (let's encrypt например), что в Вашем контексте о роутере звучит необычно. С другой стороны, для серверов это имеет смысл.
Реализовать несложно. Если Вас не затруднит, можете, пожалуйста, оформить это как feature request на github?
Если скинете ссылки на какой-нибудь простой туториал по запаковке в openwrt, то я могу попробовать сделать в свободное время.
2, 3. Спасибо, так наверное можно сделать. Но нужно детально проработать
del. Habr лаг