За 15 лет с Linux я понял одну неприятную вещь: **часть настроек нужна была не системе, а моему ощущению контроля**.
Когда-то я тоже жил по схеме: i3, polybar, тонкая настройка `vimrc`, скрипты на каждый чих, автопереключение всего при подключении монитора. Это выглядит как инженерная дисциплина, но часто превращается в отдельный проект по обслуживанию рабочего места.
Сейчас у меня Fedora почти без кастомизации: GNOME, браузер, редактор, видео для демо — и всё работает. Не идеально в эстетическом смысле, зато предсказуемо.
Это очень похоже на типовой битриксовый проект: можно собрать архитектуру из десятка самописных надстроек, а потом годами поддерживать саму обвязку. А можно оставить только то, что реально влияет на бизнес\-процесс, и не трогать лишнее.
__Антиошибка недели__: не путать удобство с количеством настроек.
Иногда лучший `тюнинг` — это убрать тюнинг.
Когда-то я тоже жил по схеме: i3, polybar, тонкая настройка `vimrc`, скрипты на каждый чих, автопереключение всего при подключении монитора. Это выглядит как инженерная дисциплина, но часто превращается в отдельный проект по обслуживанию рабочего места.
Сейчас у меня Fedora почти без кастомизации: GNOME, браузер, редактор, видео для демо — и всё работает. Не идеально в эстетическом смысле, зато предсказуемо.
Это очень похоже на типовой битриксовый проект: можно собрать архитектуру из десятка самописных надстроек, а потом годами поддерживать саму обвязку. А можно оставить только то, что реально влияет на бизнес\-процесс, и не трогать лишнее.
__Антиошибка недели__: не путать удобство с количеством настроек.
Иногда лучший `тюнинг` — это убрать тюнинг.
Один из показательных эффектов LLM-петли: если оставить две модели общаться друг с другом без внешней рамки, разговор быстро уезжает от смысла к самоподтверждению.
Я у себя в проектах это называю **антиошибкой автоматизации**: система начинает не решать задачу, а _обслуживать собственный ответ_. В исходном кейсе из такой «свободной беседы» сначала вырос сырой концепт `рефлексивного ядра`, а позже — уже более любопытная идея про `мета-внимание`.
Схема простая:
`вопрос` → `ответ модели` → `ответ на ответ` → `усиление внутренней логики` → потеря внешней привязки.
Для 1C-Битрикс это очень знакомый паттерн. Тот же эффект ловится в чат-ботах, автогенерации контента, помощниках для саппорта и даже в интеграциях, где нет жесткого контроля контекста. Если не задать ограничения, модель начинает красиво, но бесполезно «докручивать» сама себя.
Вывод практический: LLM нужна не свобода, а _границы, проверка и внешний якорь_. Иначе вместо архитектуры получаем самореференсный шум.
Я у себя в проектах это называю **антиошибкой автоматизации**: система начинает не решать задачу, а _обслуживать собственный ответ_. В исходном кейсе из такой «свободной беседы» сначала вырос сырой концепт `рефлексивного ядра`, а позже — уже более любопытная идея про `мета-внимание`.
Схема простая:
`вопрос` → `ответ модели` → `ответ на ответ` → `усиление внутренней логики` → потеря внешней привязки.
Для 1C-Битрикс это очень знакомый паттерн. Тот же эффект ловится в чат-ботах, автогенерации контента, помощниках для саппорта и даже в интеграциях, где нет жесткого контроля контекста. Если не задать ограничения, модель начинает красиво, но бесполезно «докручивать» сама себя.
Вывод практический: LLM нужна не свобода, а _границы, проверка и внешний якорь_. Иначе вместо архитектуры получаем самореференсный шум.
В начале июня я снова увидел старую картину: массово начали сбоить не только самодельные обходы, но и решения на связке `xray + VLESS + REALITY`.
С инженерной точки зрения это выглядит как _волна ограничений_, а не как единичная ошибка у провайдера. Когда ломается сразу несколько независимых реализаций, обычно проблема сидит не в клиенте и не в одном сервере, а в **логике фильтрации на стороне сети**.
Что важно для нас, интеграторов и админов: такие вещи редко чинятся «обновите конфиг». Нужно смотреть на схему целиком — точки выхода, TLS-поведение, последовательность рукопожатий, устойчивость к активной проверке.
Я бы описал это так: сначала система пропускает привычный трафик, потом начинает выборочно резать подозрительные паттерны, и уже после этого ломаются даже аккуратно собранные связки. Типовой кейс из инфраструктуры, где ограничения идут не в лоб, а по признакам.
Если у вас в проекте завязано что-то критичное на нестандартных каналах связи, держите план Б. И да, проверяйте не только «работает/не работает», а __почему__ именно отвалилось. Это экономит часы на бесполезной переборке конфигов.
—
Чтобы быть в курсе рынка — подпишись на @affcareers_spb
С инженерной точки зрения это выглядит как _волна ограничений_, а не как единичная ошибка у провайдера. Когда ломается сразу несколько независимых реализаций, обычно проблема сидит не в клиенте и не в одном сервере, а в **логике фильтрации на стороне сети**.
Что важно для нас, интеграторов и админов: такие вещи редко чинятся «обновите конфиг». Нужно смотреть на схему целиком — точки выхода, TLS-поведение, последовательность рукопожатий, устойчивость к активной проверке.
Я бы описал это так: сначала система пропускает привычный трафик, потом начинает выборочно резать подозрительные паттерны, и уже после этого ломаются даже аккуратно собранные связки. Типовой кейс из инфраструктуры, где ограничения идут не в лоб, а по признакам.
Если у вас в проекте завязано что-то критичное на нестандартных каналах связи, держите план Б. И да, проверяйте не только «работает/не работает», а __почему__ именно отвалилось. Это экономит часы на бесполезной переборке конфигов.
—
Чтобы быть в курсе рынка — подпишись на @affcareers_spb
В проектах я часто вижу одну и ту же ошибку: люди недооценивают то, что «и у нас под боком не страшно». С живой природой это работает плохо.
Подборка про пауков европейской части России напомнила мне простой принцип архитектуры: __не ориентироваться на внешний вид__. Каракурт, тарантул, сольпуга и их менее известные соседи выглядят по-разному, но в задаче безопасности у них одна логика — держать дистанцию и не проверять на практике, кто из них «на самом деле неопасный».
В техподдержке и в проектах я бы сказал так: если объект системы помечен как рискованный, не пытаемся «быстро посмотреть руками». Сначала идентификация, потом регламент, потом действия. Иначе получаем лишний инцидент там, где можно было обойтись без него.
С природой, как и с интеграциями, лучше работает сухой подход: __сначала понять, потом трогать__.
Подборка про пауков европейской части России напомнила мне простой принцип архитектуры: __не ориентироваться на внешний вид__. Каракурт, тарантул, сольпуга и их менее известные соседи выглядят по-разному, но в задаче безопасности у них одна логика — держать дистанцию и не проверять на практике, кто из них «на самом деле неопасный».
В техподдержке и в проектах я бы сказал так: если объект системы помечен как рискованный, не пытаемся «быстро посмотреть руками». Сначала идентификация, потом регламент, потом действия. Иначе получаем лишний инцидент там, где можно было обойтись без него.
С природой, как и с интеграциями, лучше работает сухой подход: __сначала понять, потом трогать__.