Кто-нибудь пояснит как перебор хешей на видеокарте (кажется тема на столько заезженная, что где-то да лежит целая библиотека вида хэш→пароль, для всех алгоритмов) поможет взломать мой хабра-аккаунт?
3 вопроса: 1. Ну и что, много зарабатывает бот/код? 2. Если метод действительно рабочий и позволяет рубить бабло, зачем всем рассказывать? 3. Зачем забивать гитхаб сгенереным говнокодом?
Сегодня DeepSeek вполне сносно пишет на Rust и даже с какой-то попытки осиливает Zig. Я бы не сказал, что это плохой код, зачастую это код лучше чем напишет среднестатистический "кодер" с хабра.
Но это не имеет отношения к посылу статьи, который универсален к любой сфере: использовании ИИ вместо своего мозга ведёт к неизбежной атрофии последнего.
Рекомендации ВК очень редко попадают в мои интересы, а умная лента мало того что убила охваты в пабликах (что привело к массовым миграциям на ТГ), так ещё и мешает мне видеть полную картину, помещая в какой-то информационный пузырь.
Помню в Python по такой причине приходилось выключать GC и использовать только ref counter. По-сути получали странную версию Rust (это было до 2015 года релиза раста).
Интересный опыт :]
Я как фанат Rust на самом деле поддерживаю в вашем случае переход именно на Zig. Во многом пожалуй в как раз контексте поддержке кода (за что вас тут в комментариях пытаются критиковать). Тут я поддержу выбор Zig:
1) В эпоху LLM поддерживать код на Rust всё еще сложно, потому что нужно хорошо владеть приемами "борьбы с лайфтаймами" и в них придется погрузиться, чтобы хоть что-то поменять в проекте, когда это понадобится. То есть взять не раст-инженера и "побыстрому" посадить его на проект не получится.
А вот Zig в этом плане простой как веник. За пару дней можно выучить весь синтаксис языка, а дальше ну это по сути Си, только не Си. Я 100% уверен, что с минимальной помощью LLM на проект можно нанять PHPшера Perl-иста, и он разберется.
Огромное спасибо за ваш взвешенный комментарий! Приятно встретить человека, который понимает суть инженерных компромиссов. Вы правы в каждом пункте:
Ваша мысль про LLM и Rust — бьёт в точку, хотя изначально не планировал на этом акцентироваться. Zig действительно даёт:
✓ Предсказуемую кривую обучения
✓ Прозрачную интеграцию с C
✓ Минимальный cognitive overhead для новых разработчиков
P.S. Ваш комментарий — редкий пример того, как должно выглядеть профессиональное обсуждение технологий. Без холиваров, с пониманием реальных инженерных задач. Но вы рискуете быть заминусованым за непопулярное мнение :)
P.P.S. И да — вы точно описали мой опыт: имея базовые навыки в C, в Zig разобрался за пару часов. Первые шаги с Rust заняли недели. Но Rust я тоже люблю
OCVPN — это серверная часть VPN, она раздаёт доступ для аккаунтов. В штатном ocvpn есть такая функция: при подключении показать сообщение (появится в всплывающем окне) — это называется баннер. Штатная версия позволяет задать 1 статичный баннер через файл конфигурации сервера, ocserv.conf — этого не достаточно.
В данном проекте баннеры используются как способ доставки важной информации к пользователю: срок окончания подписки, какие-то сведения, etc.
Спасибо за интерес к деталям нашего выбора! Позвольте пояснить мой подход более развернуто:
1. О выборе языков в принципе
В профессиональной разработке существует 4 основных пути выбора языка: ✓ Личные предпочтения технического руководства ✓ Корпоративные стандарты и комплаенс ✓ Популярные заблуждения ("все пишут на X") ✓ Осознанный выбор под конкретные требования
Я выбрал последний путь.
2. О распределении языков в нашем проекте
Zig: для низкоуровневой части (модификация C-программы)
Идеальная совместимость с C ABI
Контроль памяти без сложностей Rust
Минимальные накладные расходы
Go: для вспомогательных сервисов
Удобен для concurrent-задач
GC не критичен для логирования
Быстрая разработка
PHP: основной бэкенд
Только немного подрпавил, так как удовлетворяет требованиям
3. О философии выбора
Я принципиально не утверждаю, что: ✓ PHP/Python "хуже" ✓ Zig/Rust "лучше"
Каждый язык имеет свою нишу:
Когда нужен контроль памяти — берем Zig/Rust
Когда важна скорость разработки — Go/Python
Когда работает legacy — не ломаем без нужды
Каждый случай выбора языка под проект заслуживает отдельного анализа. В моём сценарии: ✓ Модификация C-кода → Zig ✓ Высокоуровневые сервисы → Go ✓ Основной бэкенд → PHP
почему раньше был отдельный процесс на каждое vpn-соединение, а теперь один процесс для всех?
Вероятно моя формулировка в статье создала неверное понимание происходящего. Давайте разберём архитектурные изменения подробней.
1. Как было раньше:
На каждое подключение создавался отдельный процесс PHP
В каждом процессе загружалась вся кодовая база скриптов
Плюс работал основной процесс ocserv-worker → Двойная нагрузка на систему
2. Как сейчас:
Вся бизнес-логика встроена непосредственно в процедуру авторизации
Никаких дополнительных процессов не создаётся
Модифицированный ocserv-worker обрабатывает всё сам
P.S. Если бы я разрабатывал систему с нуля сегодня — возможно, выбрал бы другие инструменты. Но профессиональный подход — это работать с текущими реалиями, а не гнаться за мейнстримом
А что, можно его не использовать? О_О
Простите, а что вы знаете про вычисления?
Нейроморфные вычисления ложатся на троичную логику как песня. Но ведь это малочисленная, невостребованная сфера, понимаю
P.S. ну это не считая, того что "не-универсальная машина" успешно работала и с бухгалтерией и кристалографией
Кто-нибудь пояснит как перебор хешей на видеокарте (кажется тема на столько заезженная, что где-то да лежит целая библиотека вида хэш→пароль, для всех алгоритмов) поможет взломать мой хабра-аккаунт?
Два вопроса: на*** и зачем?
После слов:
> Десять лет в девопсе. Десять. И я гуглю
tar -xzf.Читать дальше не стал.
А ссылка на гитхаб будет?
3 вопроса:
1. Ну и что, много зарабатывает бот/код?
2. Если метод действительно рабочий и позволяет рубить бабло, зачем всем рассказывать?
3. Зачем забивать гитхаб сгенереным говнокодом?
Сегодня DeepSeek вполне сносно пишет на Rust и даже с какой-то попытки осиливает Zig. Я бы не сказал, что это плохой код, зачастую это код лучше чем напишет среднестатистический "кодер" с хабра.
Но это не имеет отношения к посылу статьи, который универсален к любой сфере: использовании ИИ вместо своего мозга ведёт к неизбежной атрофии последнего.
Рекомендации ВК очень редко попадают в мои интересы, а умная лента мало того что убила охваты в пабликах (что привело к массовым миграциям на ТГ), так ещё и мешает мне видеть полную картину, помещая в какой-то информационный пузырь.
Именно поэтому "чел" оставил бэкенд на "пхп".
Интересный опыт :]
Огромное спасибо за ваш взвешенный комментарий! Приятно встретить человека, который понимает суть инженерных компромиссов. Вы правы в каждом пункте:
Ваша мысль про LLM и Rust — бьёт в точку, хотя изначально не планировал на этом акцентироваться. Zig действительно даёт:
✓ Предсказуемую кривую обучения
✓ Прозрачную интеграцию с C
✓ Минимальный cognitive overhead для новых разработчиков
P.S. Ваш комментарий — редкий пример того, как должно выглядеть профессиональное обсуждение технологий. Без холиваров, с пониманием реальных инженерных задач. Но вы рискуете быть заминусованым за непопулярное мнение :)
P.P.S. И да — вы точно описали мой опыт: имея базовые навыки в C, в Zig разобрался за пару часов. Первые шаги с Rust заняли недели. Но Rust я тоже люблю
В каком-то смысле
:-D
OCVPN — это серверная часть VPN, она раздаёт доступ для аккаунтов. В штатном ocvpn есть такая функция: при подключении показать сообщение (появится в всплывающем окне) — это называется баннер. Штатная версия позволяет задать 1 статичный баннер через файл конфигурации сервера, ocserv.conf — этого не достаточно.
В данном проекте баннеры используются как способ доставки важной информации к пользователю: срок окончания подписки, какие-то сведения, etc.
Как мудро заметил один философ:"Когда дискуссия переходит на личности — это высшая форма технической аргументации".
Спасибо за ваш опыт и конструктивные замечания! Полностью согласен с вашими опасениями насчёт стабильности - это действительно важный аспект.
Но в этом проекте логика, которая вынесена на Zig, не будет меняться ближайшие 5-10 лет, за это время и rust успеет сломать совместимость.
И настолько конструктивное, что в качестве аргументов пошли минусы в карму (не от меня) :)
Вы совершенно правы — рассуждать о чужом бизнесе, не зная деталей, действительно несерьёзно.
А что если наши 100 пользователей — это:
VPN-инфраструктура для банковских отделений
Где каждый сеанс обрабатывает финансовые транзакции
С требованиями SLA 99.99%
Уже не так однозначно, верно?
Спасибо за интерес к деталям нашего выбора! Позвольте пояснить мой подход более развернуто:
1. О выборе языков в принципе
В профессиональной разработке существует 4 основных пути выбора языка:
✓ Личные предпочтения технического руководства
✓ Корпоративные стандарты и комплаенс
✓ Популярные заблуждения ("все пишут на X")
✓ Осознанный выбор под конкретные требования
Я выбрал последний путь.
2. О распределении языков в нашем проекте
Zig: для низкоуровневой части (модификация C-программы)
Идеальная совместимость с C ABI
Контроль памяти без сложностей Rust
Минимальные накладные расходы
Go: для вспомогательных сервисов
Удобен для concurrent-задач
GC не критичен для логирования
Быстрая разработка
PHP: основной бэкенд
Только немного подрпавил, так как удовлетворяет требованиям
3. О философии выбора
Я принципиально не утверждаю, что:
✓ PHP/Python "хуже"
✓ Zig/Rust "лучше"
Каждый язык имеет свою нишу:
Когда нужен контроль памяти — берем Zig/Rust
Когда важна скорость разработки — Go/Python
Когда работает legacy — не ломаем без нужды
Каждый случай выбора языка под проект заслуживает отдельного анализа. В моём сценарии:
✓ Модификация C-кода → Zig
✓ Высокоуровневые сервисы → Go
✓ Основной бэкенд → PHP
Вероятно моя формулировка в статье создала неверное понимание происходящего. Давайте разберём архитектурные изменения подробней.
1. Как было раньше:
На каждое подключение создавался отдельный процесс PHP
В каждом процессе загружалась вся кодовая база скриптов
Плюс работал основной процесс ocserv-worker
→ Двойная нагрузка на систему
2. Как сейчас:
Вся бизнес-логика встроена непосредственно в процедуру авторизации
Никаких дополнительных процессов не создаётся
Модифицированный ocserv-worker обрабатывает всё сам
P.S. Если бы я разрабатывал систему с нуля сегодня — возможно, выбрал бы другие инструменты. Но профессиональный подход — это работать с текущими реалиями, а не гнаться за мейнстримом