Обновить
22
Кашлак Андрей@andreymal

Пользователь

1,1
Рейтинг
8
Подписчики
Отправить сообщение

Для меня как минимум неочевидно, являются ли перечисленные проблемы принципиально нерешаемыми. Но предположу, что они действительно нерешаемые — как мне быть, если я хочу, чтобы мой сайт был работоспособен без JS?

OpenAPI‑спецификации можно генерировать из аннотаций в коде. Конфигурационные файлы можно генерировать из шаблонов и рендерить.

Если файлы можно сгенерировать автоматически, значит этих файлов вообще не должно быть в репозитории

Автоматизация точно знает, как исправить проблему.

Не знает. Она идёт по пути наименьшего сопротивления и предлагает «исправление», призванное просто заткнуть линтер и потенциально делающее код более уродливым. Иногда предупреждения линтера — это повод для рефакторинга

автоматически исправлять нарушения правил линтинга при сохранении

По вышеупомянутой причине я эту фичу принципиально отключаю

автоматически извлекать ID задачи в Jira

Откуда возьмётся ID задачи, если его изначально нет?

ИИ не просто находит проблему, он ее решает

...неправильным способом. Спасибо, не надо

я автоматизирую решение или автоматизирую просьбу к кому‑то другому это решение реализовать?

Я автоматизирую поиск подозрительных мест в коде, на которые стоит обратить более пристальное внимание. Конкретные решения о том, что с этими местами делать, принимаются исключительно мной, а не линтером и тем более не ИИ

Ну и да, до CI это доходить изначально не должно, это должно подсвечиваться в IDE (не автоматически «исправляться» при сохранении, а просто подсвечиваться)

Почему портит?

Ну дум тоже делали на NeXT

Вы кстати не уточнили, какой доступ вы имеете в виду — физический или удалённый

«Доверенное» третье лицо, которому вы зачем-нибудь физически передадите устройство, просто зальёт вредоносную прошивку напрямую программатором в обход любых ролей (если только от этого нет какой-то аппаратной защиты)

Если предполагается только удалённый доступ, то наверно можно просто собрать для JetKVM кастомную прошивку с удалённым «Режимом разработчика», благо вроде как все исходники на гитхабе есть

А что помешает залить в Lantronix Spider вредоносную прошивку? У него есть какая-то защита?

Проблема в том, что при этом надо откуда-то заранее знать, как оригиналы выглядят и ощущаются наощупь. И даже если диск отличается от картинки оригинала, найденной в интернете, всё равно неочевидно, подделка или просто какая-то новая ревизия. Разве что утилиты вроде ssd-flash-id тыкать

Факап ладно, а остальные точно не подделки? У меня 970 EVO Plus работает уже пять лет без единой проблемы (или наоборот подделки работают лучше оригинала? 🤔)

Факты говорят сами за себя. Программист, не принимающий эти факты, будет вызывать сомнения в его адекватности

Rust существенно уменьшает вероятность возникновения уязвимостей, связанных с неправильной работой с памятью, поэтому навязывание раста — священный долг любого адекватного программиста

В общем опять вкусовщина, я работаю с россыпью файлов именно потому что мне так удобнее (особенно через Ansible-плейбук, чтобы с lineinfile не страдать)

Внутрь докера тащите специальные докерные иниты если сильно надо, а systemd для докера не задумывался

В crontab вообще нет синтаксиса

Именно в этом и проблема и именно поэтому systemd автоматически лучше

Для root crontab один.

В моей убунте сразу из коробки /etc/anacrontab /etc/cron.d, /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.hourly, /etc/cron.yearly — и я ещё не уверен, что это полный список конфигов крона (точнее анакрона в моём случае)

Развесистый, многострочный скрипт

Не скрипт, а параметры запуска исполняемого файла. Зачем этим исполняемым файлом делать bash, а не какой-нибудь /usr/local/bin/maintenance.sh — вопрос к тем странным людям, которые пихают bash в конфиги

systemd в системе запускать в принципе не надо

Разумеется надо, потому что в системе должны стоять какие-то система инициализации и менеджер процессов (хотя бы тот же несчастный sysvinit, если уж такая ненависть к systemd). В докере — не должны, потому что докер — сам себе система инициализации и менеджер процессов

кто и чем подписал

Это написано в DKIM-Signature

нет DMARC

А это видимо означает, что можно собирать домены с забытым DMARC и безнаказанно рассылать спам и, что более интересно, фишинг 🤔

Погодите, я не распутался, вот письмо одной из рассылок:

Delivered-To: мой-емейл@mail.ru
Return-path: <bounces+1234567-abcd-мой-емейл=mail.ru@sendgrid.net>
Authentication-Results: mxs.mail.ru; spf=pass (exim-mx-6d6fcdbc98-s2zl9: domain of sendgrid.net designates 168.245.123.138 as permitted sender) smtp.mailfrom=bounces+1234567-abcd-мой-емейл=mail.ru@sendgrid.net smtp.helo=o168245123x138.outbound-mail.sendgrid.net;
	 dkim=pass header.d=sendgrid.net
Received-SPF: pass (exim-mx-6d6fcdbc98-s2zl9: domain of sendgrid.net designates 168.245.123.138 as permitted sender) client-ip=168.245.123.138; envelope-from=bounces+1234567-abcd-мой-емейл=mail.ru@sendgrid.net; helo=o168245123x138.outbound-mail.sendgrid.net;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendgrid.net;
	h=date:from:subject:mime-version:to:content-type:
	content-transfer-encoding:cc:content-type:date:from:subject:to;
	s=smtpapi; t=1781038555;
	[тут-подпись]
Date: Tue, 09 Jun 2026 20:55:55 +0000 (UTC)
From: Libraries <notifications@libraries.io>
Subject: New release of lxml (7.0.0a2) on PyPI
Mime-Version: 1.0
To: мой-емейл@mail.ru

Во всех проверках домен libraries.io не упоминается вообще, и условие «подписывает его ВАШИМ приватным ключом» не выполняется. Так какого чёрта эта рассылка проходит все проверки и не улетает в спам?

(Или это работает чисто благодаря отсутствию DMARC-записи у libraries.io? Я немножко глупенький и заметил её отсутствие только после отправки комментария, да)

Синтаксис очень даже очевидный, всё распихано по отдельным параметрам, CamelCase названия которых говорят сами за себя и зачастую даже не требуют заглядывания в документацию, в отличие от мутной одной строки крона, которая заставляет сидеть считать пробелы

Использовать bash -c никто не заставляет (в кроне впрочем тоже)

crontab'ов может быть несколько, по которым придётся скакать, а systemctl list-timers, упомянутый прямо над вашим комментарием, не только покажет действительно все системные таймеры, но ещё и сам посчитает время их запуска, так что вам ничего понимать в принципе не надо, в отличие от мутного крона

Пытаться запускать systemd внутри docker в принципе не надо

Никакой, поэтому я вернулся на ext4

А причем тут небезопастная операция, если с их помощью можно просто мемори лик сделать?

При том, что утечка памяти штука хоть и обидная, но никак не нарушает упомянутый вами memory safety

ну не менее убогий чем drop

Более убогий чем drop, потому что drop автоматический, а defer надо не забыть самостоятельно написать

В расте даже этого не смогли.

Или просто никто до сих пор не отправил соответствующий фичреквест?

Но в целом и без специального синтаксиса можно жить, предупреждение тоже сойдёт https://github.com/rust-lang/rust/issues/83310

И как вы заставите другие крейты использовать ваш макрос?

И как вы заставите другие C#-библиотеки использовать синтаксическую конструкцию lock? Им никто не запрещает игнорировать существование части синтаксиса языка

serde, syn, thiserror, cxx и anyhow

Несмотря на их популярность, я читал немало ругани про них, так что кто знает, может, если бы их не было, кто-нибудь другой изобрёл бы что-нибудь ещё более крутое

А зачем запускать broot в кроме/таймере, тем более с --install?

У меня на домашнем компе установка 2020 года, таймер включен и о его существовании я узнал только из этой ветки на Хабре ¯\_(ツ)_/¯

1
23 ...

Информация

В рейтинге
2 115-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность