• Кодогенерация в Go на примере создания клиента к БД
    0

    С одной стороны кодогенерация позволяет видеть созданный код, с другой — мне приходится писать проекты типа
    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'ы). Посмотрите мои проекты выше — там много собрано костылей и боли.
    Первый — более старый и менее чистый но разносторонний, третий более новый и причесанный.

  • Пенсионный фонд продолжает миграцию на процессоры «Эльбрус». Работы идут четыре года
    +5

    Немного обидно за Сбер. Тем более, что в случае IT — это СберТех.
    Сам там отработал несколько лет: от инженера до начальника. Да, есть проблемы. Да, есть бюрократия. Да, есть неэффективность местами.
    Однако, масштаб организации настолько огромный (в штате десятки тысяч людей), что большинство хипстерских подходов не работают или вредят. Бюрократия внезапно превращается в полезный инструмент, который фильтрует и сглаживает резкие импульсы системы, сохраняя стабильность движения, а для стратегических проектов наоборот, пинает и поддерживает, даже когда интерес или средства закончились.
    При всей неоднозначнности Г.О. Грефа, то что он сделал со Сбером — достойно уважения и восхищения.
    К сожалению, внутренняя кухня Сбера совершенно не видна потребителем. За счёт этого кажется стагнация и волокита.
    Резюмируя: ИМХО, в Сбере есть очень много уникальных специалистов любого уровня и способных решить самые сложные проблемы.


    P.S
    К сожалению, сейчас в Сбере уже не работаю, но расстались мы в хороших отношениях

  • Ящик для хранения данных в go-приложениях
    +1

    leveldb для себя и S3 + redis для работы

  • Ящик для хранения данных в go-приложениях
    0

    В свое время у меня была задача сделать подключение в Go хранения данных в KV хранилищах. Долго не мог выбрать, и в итоге сделал "универсальную" обертку с несколькими бэк-эндами. https://github.com/reddec/storages
    Бонусом: всякая разная типо-безопасная кодогенерация. Возможно будет интересно.

  • 5 способов сделать Python-сервер на Raspberry Pi. Часть 2
    0

    В таком простом проекте даже bottle.py сойдёт. А как только перестанет хватать (что вряд-ли) на flask всего несколько минут мигрировать.
    И читать проще код будет, и функционала больше

  • tinc-boot — full-mesh сеть без боли
    +1

    Если включено локальное обнаружение пиров (tinc-boot включает его в конфиг) то будет напрямую общаться.


    Да yggdrasil я смотрел и даже немного участвую в разработке/обсуждении.

  • tinc-boot — full-mesh сеть без боли
    0

    Нет, отнюдь. PFS это серьезный довод, чтобы присмотреться к 1.1 (даже если он и не в релизе).

  • tinc-boot — full-mesh сеть без боли
    0

    Спасибо за детали.


    Не считая perfect forward security — это отсылка на CVE-
    2018-16758, которая исправлена после 1.0.34

  • tinc-boot — full-mesh сеть без боли
    0

    Можно пожалуйста доказательство того, что есть неисправленные уязвимости Tinc 1.0.36 и исправленные/недопущенные в 1.1? Это серьезное заявление, которое действительно имеет смысл в нашем обсуждение. Вы уже второй комментатор, который ссылается на это.


    1. Я не уловил, но как это относится к предмету обсуждения? Я же не свой VPN создавал, а обертку. Возможно вы имели ввиду, что есть другая функционально схожая обертка (для 1.0.x)? Буду признателен, если скинете ссылку.
    2. Как можно называть версию устаревший, если (а) обновления выходят регулярно, (б) нет другой версии этого же продукта в релизной версии? В Вашем примере про питон: версии py3-RC, не позиционировались как готовые решения для замены 2.7. Только с момента релиза.
    3. Тут есть фундаментальная проблема: с моей точки зрения, довод в пользу 1.0 — его стабильность и актуальность, 1.1 — не релиз (что подчеркивается на сайте). С одной стороны, я признаю Ваши аргументы в пользу 1.1 (функциональность, удобство и в целом более продуманный дизайн). С другой, Вы мои аргументы не признаете. Логический тупик для диалога. Ну или диалог превращается в монолог.
  • tinc-boot — full-mesh сеть без боли
    0

    Могу я Вас попросить все же не использовать подобного рода формулировки? "Фапать", "школьник" — не тот уровень диалога, который обычно ожидается на профессиональном ресурсе.


    Мне кажется есть определенного уровня недопонимание:


    1. Я не навязываю никому и ничего — есть проблема: сложность настройки Tinc 1.0 в ряде ситуаций. Одно из решений — tinc-boot.
    2. В статье однозначно описывается взаимодействие с Tinc 1.0. Смысл обсуждать 1.1 — если в статье в явном виде описано ограничение на 1.0? Это вне рамках текста. Если есть желание пообщаться — можно перейти в личные диалоги.
    3. Я обосновал свое решение относительно 1.0. Вы и некоторые другие с ним не согласились. С моей точки зрение имеется паритет мнений. Дальнейшее обсуждение не имеет смысла (как мне кажется).

    Я ни в коей мере не ограничиваю (и не навязываю) ни Вам лично, ни читателем единственное верное решение. Это сугубо личное решение каждого. Доводы "за" и "против" приведены. Далее — вопросы приоритетов и личных предпочтений.


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

  • tinc-boot — full-mesh сеть без боли
    0

    В целом я свою точку зрения высказал выше, но забыл добавить:


    • 1.1pre17 — вышла 11 месяцев назад
    • 1.0.36 — 3 недели назад. Часть комитов — бэкпорт из 1.1.
  • tinc-boot — full-mesh сеть без боли
    0

    1.1 безусловно шаг вперёд. Напомните, пожалуйста, когда они в релиз планируют вывести?
    Я то этого уже жду несколько лет.


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


    Так что либо кто-то принимает риск и пробует все новое (я так понимаю Ваш случай), либо кто-то (как я) используют проверенные решения и адаптируют их под нужные условия.

  • tinc-boot — full-mesh сеть без боли
    0

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

  • tinc-boot — full-mesh сеть без боли
    0

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


    Во-вторых, предположим будет возможность задавать сертификаты (это не сложно добавить). Тогда Вам либо (а) придется добавлять сертификаты в доверенные каждого устройства (при самоподписанном сертификате), либо (б) использовать честные сертификаты (let's encrypt например), что в Вашем контексте о роутере звучит необычно. С другой стороны, для серверов это имеет смысл.


    Реализовать несложно. Если Вас не затруднит, можете, пожалуйста, оформить это как feature request на github?

  • tinc-boot — full-mesh сеть без боли
    0

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

  • tinc-boot — full-mesh сеть без боли
    0
    1. Там зашифрованная передача. Я акцентировал внимание на этом в трёх местах в статье. Можно перед сервисом поставить ssl proxy (nginx..), если будет спокойнее.

    2, 3. Спасибо, так наверное можно сделать. Но нужно детально проработать

  • JustCode — скоростной браузер для бюджетных компьютеров и планшетов на Windows
    0

    del. Habr лаг

  • Почему SvelteJS возможно лучший фреймворк для новых веб-разработчиков
    +1

    Если кому интересно, то я делал не сложный ui на этом фреймворке: https://github.com/reddec/monexec-ui
    Это SPA UI для супервизора https://github.com/reddec/monexec


    В целом удобно.

  • Делаем мессенджер*, который работает даже в лифте
    +1

    Как прототип/идея весьма неплохо. N сессий тут решается простым KV хранилищем с ключом по ID клиента.
    А для синхронизации последнего отправленного сообщения (проблема "отправленного" и не пришедшего сообщения) можно использовать алгоритм из биржевого FIX. Он прост как две копейки и, по моему, отлично ложится на предложенную архитектуру.
    Не претендую на истинность, но я бы в свободное время поразмыслил над этим проектом

  • Проще, чем MQTT? MQTT/UDP
    0

    Идея отличная.
    Можете еще глянуть на эту статью https://habr.com/post/240053/ — там я описывал сходную идею на UDP multicast (не broadcast)

  • SPLUNK VS ELK?
    +2

    Работал и с тем и с другим на очень больших выборках.


    ELK непросто ест больше ресурсов: он их сжирает в разы(!) больше.
    На моих задача получалось соотношение: 1 инстанс splunk равен 3-4ем EL по производительности.
    Субъективно splunk сильно проще и гибче настраивается.
    Фатальным недостатком этого закрытого решения — космическая цена. Особенно для крупных компаний с большим объемом данных

  • Искусственный интеллект спасёт от ransomware
    0

    Товарищи из Acronis!
    Я уже год смотрю на True Image. Выглядит супер, репутация — отличная.
    Давно готов купить, но останавливает лишь одно: почему нет версии под Linux? Серверную не предлагайте, пожалуйста.
    Думаю немало разработчиков, а они прекрасно осведомлены о необходимости резервного копирования, используют Linux не только на серверах, но и как рабочие станции.

  • Очень легкая система мониторинга с Телеграмом и Консулом
    0

    Во-первых, спасибо за s6.
    Во-вторых, понятно, что задачу можно решить более одним способом.
    В-третьих, все-же сравните затраты на запуск одной команды или на оркестрацию целого вороха утилит. Это как Docker: можно без него, напрямую с cgroups и bridge-utils, но с ним немного проще =)

  • Очень легкая система мониторинга с Телеграмом и Консулом
    0

    Идея была именно такая (зашивать). Для мониторинга запущенных контейнеров "из-вне" лучше использовать Consul as-is.

  • Очень легкая система мониторинга с Телеграмом и Консулом
    0

    Имелось ввиду, что мы хотим передать другим людям (например админам) для дальнейшей эксплуатации готовый набор параметров и настроек.
    Грубый пример: перенос между стендами разработки и тестирования.

  • Очень легкая система мониторинга с Телеграмом и Консулом
    0
    К сожалению, не решает проблемы запуска одиночных сервисов
  • Очень легкая система мониторинга с Телеграмом и Консулом
    +1
    Куда тянет? Это на каком дистрибутиве нету питона из коробки?


    В образах для докера. Т.к. далеко не всем приложениям нужен питон для запуска, то большинство образов его в себя не включают. Например alpine.

    И не тянет php?


    Тут я вопроса не понял. Чутка деталей было бы отлично.

    Предполагаю, что речь шла про какой-то web UI, но зачем в мелкие контейнеры тянуть еще N утилит общего назначения?
  • Splunk — общее описание платформы, базовые особенности установки и архитектуры
    0
    Вполне возможно. 500ГБ данных за 6-8 часов (логи). В дальнейшем планировалось нарастить до 1-2ТБ. Данные поступают ежедневно.
    Мое мнение как инженера — очень качественный (скорость, удобство, возможности) продукт. Но бюджетом управляю не я)
  • Splunk — общее описание платформы, базовые особенности установки и архитектуры
    0
    Работал со Splunk. Система реально очень быстрая и удобная. «коробочный» ELK выдавал 1/10 скорости на том же оборудовании.
    Только один минус: стоит как крыло самолета. Может даже дороже
  • Наш офис не дом и не улица, наш офис теперь — SOCOCO
    +1
    Москва, 1 час на работу, 1.5 обратно. Пропуска и временной контроль. Хреновая столовая и отсутствие адекватных кафе рядом. Почти опен-спейс и шум.
    Я разработчик (т.е. рабочее место — только компьютер по факту) и если есть хотя бы тень надежды, что когда-нибудь компания, в которой я работаю, перейдет на такой режим, я буду безумно счастлив (и огромное количество моих коллег думаю тоже)).
    Вот эту боль я надеюсь решит Sococo или какие-нибудь еще альтернативы.

    P.S.
    Но для текущего места работы, это мечты укурившегося оптимиста
  • Flume — управляем потоками данных. Часть 1
    0
    Очередь сообщений будет копится в зависимости от типа источника. Например: для БД, транзакция означает откат и в БД, seda — аналог BlockingQueue с заданием лимитов. В каждом случае по своему.
    Если упрощено, то да, в большинстве случаев сообщение будет передано, когда абонент вернется в строй
  • Flume — управляем потоками данных. Часть 1
    0
    Мое мнение зиждется на беглом прочтении документации о Apache Flume и нескольких лет разработки на Apache Camel)
    Camel довольно таки универсальный инструмент для передачи, преобразования и маршрутизации сообщений откуда угодно, куда угодно и как угодно. С огромным набором готовых входов (Source в терминологии Flume), выходов (Sink в т. Flume) и преобразований. Важное отличие: надо кодировать (xml, DSL, java, scala, groovy) и одним конфигом как в Flume не обойтись.
    У меня создалось впечатление, что Flume это Camel, из которого выкинули все по-максимуму и дописали пару функций)) Но это чисто ИМХО.
  • Flume — управляем потоками данных. Часть 1
    0
    Спасибо за информацию. А это с Apache Camel слегка не конкурирует?
  • Обновления проекта Хостинг Кафе
    +1
    Может можно через премодерацию?
  • Обновления проекта Хостинг Кафе
    +2
    Первый раз о вас услышал. Молодцы! Но где вы были год назад… ((
    По делу:
    • Нужен пользовательский рейтинг и сортировка по нему
  • gRPC — фреймворк от Google для удалённого вызова процедур
    +4
    Меня, честно говоря, тоже сильно напрягает протокол HTTP/2. Да, я знаю, что за ним будущее. Но после поверхностной оценки RFC для него, мне стало не очень ясно, как впихнуть его поддержку во все популярные языки?
    Скажем, для базового уровня поддержки HTTP/1.0 нужна лишь базовая поддержка TCP и работа со строками в минимальном варианте. Это позволяет реализовать его хоть в IoT. С другой стороны, множественные потоки, приоритеты и т.п. ввергают меня в пучину ужаса, при мысли о том, как все это впихнуть в 32КБ памяти. А тот-же gRPC в этой области избавил бы от множества проблем…

    Поэтому, также прошу знающих людей разъяснить момент с альтернативным транспортом прикладного уровня.
  • Брокер сообщений для сервисной архитектуры на базе ZMQ — или отдых разработчика
    0
    Полностью согласен. Посему и написал just-for-fun) На работе все-таки используется IBM/Tibco, а для своих проектов RabbitMQ (в котором тоже есть грабли, но решаемые с меньшими трудозатратами).

    Приятно видеть еще одного ZMQ'шника. С библиотекой я знаком более трех лет, но не профессионально. Может статью набросаете? А то в русскоязычном сегменте по ZMQ удручающе мало информации.
  • Почему Go и Rust не враги, а друзья
    0
    Вот теперь жить можно, спасибо. А статьи на эту тему нет?
  • Почему Go и Rust не враги, а друзья
    0
    c archive это что вроде с расширением .a?
  • Почему Go обречён на успех (обновлено)
    0
    Софт: бэкенд веб сервисов, «умный дом», прикладная часть драйверов и т. п.. Проекты совсем разные (в т.ч. и заказчики).
    Пример:
    В одном проекте: сервис, обменивающийся данными по сети с полезной нагрузкой в виде строки (авторизационый сервис).
    В другом: схожий сервис, но данные не строковые, а различные числовые данные (int, uint, float и другие результаты замеров).
    В будущем третьем: сервис уже с пользовательским типом (драйверная обертка).
    Конечно, так или иначе это можно сделать. Но очень много одинаковых компонентов, отличающихся только типом в аргументах функций.