Тимофей

На каждом Ethernet входе коммутатора стоит миниатюрный трансформатор для развязки сигналов, трансформатор это медная обмотка сопротивлением около пары ом. Поэтому каждая пара может звониться, это нормально. Прибор определяет КЗ по некоторому пороговому значению. Видимо так вышло, что у этого коммутатора на входе сопротивление ниже порога КЗ тестера. Кабель до квартиры и его штекер добавляют немного сопротивления и этого уже хватает, чтобы прибор не детектил КЗ

в консольной команде первое слово - это имя програмки, которую запускаешь.
остальные слова передаются програме в качестве параметров.

соответственно systemctl status ufw запускает systemctl и передает ей параметры status ufw - получаем статус работы сервиса ufw.service от менеджера системы.
а ufw status запускает ufw и передает ей параметр status - получаем "внутренний" статус работы непосредственно от ufw

Надо включить поддержку регистронезависимости при создании файловой системы
mkfs -t ext4 -O casefold /dev/диск
или позднее

umount /dev/диск
tune2fs -O casefold /dev/диск
mount /dev/диск

Затем установить у нужного каталога атрибут регистронезависимости
chattr +F /путь/к/каталогу

Помимо основной частоты 2кГц, меандр содержит кучу гармоник. Всё, что превышает половину частоты дискретизации, у вас теряется.

"Пузо" светодиода - паять обязательно.
К обратной стороне "звезды" - радиатор.
P.S. Обычно, в документации на светодиод всё написано. Или в отдельном разделе на сайте фирмы-производителя.

А зачем когда ты сам можешь все контролировать
Тут два основных паттерна
1 когда запросов мало и они простые и ты понимаешь как они работают и никаких косяков со странными данными из вне прийти не должно или ты это уже сам экранироовал , реально намного быстрее напрямую сделать чем вникать в орм
2 когда тебе в каких то частях нужен перформанс или когда орм генерит еретические запросы там где у тебя сложная логика и приходится их переписывать напрямую
Ну и забыл третье вкусовщина

Как гофер с 1.13 версии могу предложить следующие рассуждения:

1) Нормальная общепризнанная и безболезненная ORM отсутствует. Самая популярная - GORM, где-то на втором месте - ent. Обе в целом как-то соответствуют ожиданиям, но имеют свои особенности. Кто в GORMе делал джоин - в цирке не смеется.
2) Из за того что в большинстве нормальных проектов ORMы не используются очень быстро привыкаешь писать именно SQL. Ты ещё на стадии аналитики рисуешь все эти create table и select from в голове, потом просто вставляешь в код.
3) Производительность GORM сделала в мире го репутацию всем ORMкам как очень плохому решению.

Лично я делю всех гоферов на 4 типа: бывшие джависты, бывшие пхпшники, бывшие питонисты и непосредственно гоферы - те у кого го первый или основной язык. В большинстве наблюдаемых случаев ORM в го пытаются затащить бывшие джависты по старой привычке: вот у нас в спринге был ORM значит и здесь возьмём. Клинический случай - когда такой бывший джавист становится тим или тех-лидом и делает ORM обязательным. Сколько видел таких случаев - каждый раз в результате команда ходит плюётся.

Ну и да, есть ORMки основанные на генерации кода, но самая популярная - GORM основана на рефлексии и иногда магии, это очень сильно бьет по производительности и иногда может стать "бутылочным горлышком" приложения.

Почему некоторые решают рабоатать с бд на чистом sql

В целом есть несколько причин:
1) В целом ORM в го не очень удобные, тот же gorm особо не даёт выигрыша в простоте относительно sql
2) В целом запросы могут быть относительно простыми и ORM не нужна
3) Нет стандартной ORM по типу Hibernate, SQLAlchemy
4) В го у ORM есть ограничения,
5) Если ORM на основана на рефлексии то она будет медленно работать (привет gorm) даже для средненагруженных проектов, не говоря про highload

В целом многие используют штуки по типу sqiurell, и sqlc, т.к. они легче чем ORM и для ряда вещей упрощают код. Для миграций в большинстве проектов хватит go-migrate