Спасибо, поправил статью по первым двум пунктам (добавил цитаты).
Вызывать в вашем юните mail с параметром -S sendwait. В чём проблема с KDE я не понял.
Чтобы включить "sendwait", нужно осознавать в чём тут фокус. Надеюсь что моя заметка сократит кому-нибудь время на дебаг. Проблема у меня на локалхосте (KDE) просто имеет ту же самую причину.
Удержать в голове все "нюансы" systemd для меня, например, как для "ассоциатива" — нереально. Пролистываю мануалы по мере возникновения задач, пропуская мимо всё не связанное. Постепенно число связей растёт. Как-то так… И вот тут — да, отношусь к systemd с некоторым скепсисом, как неплохо информированный оптимист. Кое-что — вот прямо очень удобно. К примеру, контрольные группы по CPU/blkio или навешивание приоритетов для OOM. С другой стороны, полностью динамический порядок запуска — полный кошмар при отладке. Или вот прохождение квеста "э, а где мой dmesg?". На стыке ядра (буфера 2к бывает маловато) и journald. …Что касается "очень старых систем", то они никуда не девались. Просто в новом-модном это называется "initrd"/"initramfs" и туда мало кто лазает. Да, там теперь "из коробки" дирижирует systemd. Но (к счастью) оставлена возможность запуститься в шелл и провести необходимые (ремонтные) мероприятия. Вплоть до "восхода солнца вручную".
Да, разумеется. Память подвела, однако. Больше 12 лет прошло с нашей последней встречи с "Фрюхой". * И я слегка польстил tc. Netgraph, ЕМНИП, даёт возможность состыковать вообще любого "ежа" с любым "ужом". А не только Ethernet манипулировать.
Да, но нет. Сначала борт вообще допустили только покататься по аэродрому. Потом — пролететь в метре. Ну и т.д.. Аналогично по двигателям, начинаем с моторесурса (число только что высосал из пальца) 50 часов, и далее доказываем возможность её увеличения. Авиация вообще предельно параноидальна в вопросах контроля надёжности. И приколы из других отраслей с "ускоренным старением" там почему-то не очень приветствуются. * Вот если дальше допуски не растут, то что-то пошло́ не так. ** На 3 км воздух ещё довольно плотный. И тёплый. Если на "крейсерском" эшелоне допустимые 0,75 М ≈825 км/ч (относительно воздуха!), то тащить 600 на 3000 выглядит достаточно правдоподобно.
Там КМК не финансы. (Лавка-то по факту государственная, как и "Арбуз", впрочем. Существовать будет, никуда не денется.) Пришли некие гении и хакнули регламенты ISO-9000. Которые про контроль качества. * А заодно принялись эффективно управлять инженерными кадрами. Кого там в РФ аутсорсили? Не прочнистов случайно? Я за этим краем глаза слежу, помню что что-то Боингу считали за символическую ЗП.
Но это не суть. В большие планеры сейчас умеют французы (офигенно), наши (неплохо) и, теперь, китайцы (пока х.з. как). А вот сделать удачный турбовентилятор — уже́ раздел инженерного искусства. (Пока) могут праттовцы, Ролс-Ройс и (со скрипом) пермяки. Общая проблема, как понимаю, в переходных режимах. Для которых нет рабочей мат. модели, и каждую новую модель двигла приходится доводить методом тыка. Многопараметрическая оптимизация, блин. И вот тут вообще вопрос, насколько удастся сохранить "школу". При том что это теперь "не круто".
На накладные расходы (в статье — достаточно "короткие" структуры, зато "дорогие" внешние вызовы) это заметно не повлияет. Лучше делать так, как более "читаемо".
В описанном случае проблемой было "да как это вообще сделать-то?!". Вышло вот так.
После получения понимания "как это работает", ничто больше не заставляет писа́ть сложные completion'ы на bash. Но, как всегда, есть нюанс: сложность в этом месте указывает на дефекты в проектировании интерфейса.
Задачу манипуляции с LUN успешно решают примерно все эксплуатанты ДЦ. Нюансы, традиционно, в контроле сложности. Кому-то хватает коммерческих вариантов, типа vSAN от vmWare. Кто-то сразу кидается делать GUI. В моём сценарии, абстракции добавляются по мере необходимости. Потому что "внутренние" задачи являются расходной частью бизнеса, ресурсы на них выделяются соответственно.
Есть "физический" слой, linux+multipath+qemu(libvirt). На первых порах его хватает, раскидать конфиги можно и каким-нибудь ansible/pdsh. И там же тяп-ляп пересканировать SAN.
Когда понятно что "всё", есть смысл обернуть конфигурацию каким-нибудь DSL. И организовать транспорт поприличнее, с контролем compliance. Это кардинально снизит "ошибки оператора" и позволит дотянуть до следующего "порога" (если бизнес не развалится).
Когда опять упёрлись (тратить ресурсы дорогих инженеров при наличии дешёвых стало накладно), оборачиваем имеющееся в очередную абстракцию. Здесь уже́ есть смысл потратить время на разложение операций по базисным функциям, обеспечить конкурентные изменения и контроль выпуска. GIT, так-то, был ещё на предыдущем шаге. Но вот здесь он прямо-таки играет всеми красками, да.
А вот вместо того чтобы тратить время на написание кастомного шелла, я его потратил на вкручивание json-интерфейсов ко всем модулям. На па́ру с обеспечением функциональности автодополнения/автозаполнения везде где это возможно. Когда/если встанет задача обернуть всё в GUI, программисту останется прокинуть сдизайненные (вот тут боюсь что им же) "окошки" к готовым и документированным интерфейсам.
Но это всё лирика. Системотехнике есть и без меня кому учить. Я просто иногда стараюсь показать интересные (ПММ) случаи. А в данном случае интересно как раз практическое применение bash-completion. Не на "всю катушку", но около того. При наличии как позиционных, так и "свободных" аргументов, включая "--ключ=значение".
Побуждения тут вполне корыстные. Когда очередной коллега попытается отпетлять от организации подсказок в CLI с аргументацией "отвяжись, не умею я в bash-completion", теперь можно ткнуть в ссылку. "Ну вот же «рыба», с разъяснениями."
Последнее обновление сисек ломает работу всех версий NetworkManager-openconnect кроме последней 1.2.10 (от 27.05.2023, ЕМНИП). Если речь про linux. Из командной строки и openconnect, и "родной" anyconnect работают.
Других проблем с anyconnect в РФ (и не только) коллеги не отмечали. Зато мне Мегафон отломал openVPN в сторону AS35000. Пришлось в ssh оборачивать (благо его отломать пока не додумались). Ломалось где-то по дороге Мегафон-Ростелеком-БМ18-моя_сеть. Что с моей т.з. опровергает один из тезисов выше (про то что ломали "по подсетям" а не чохом на DPI).
К сожалению, данная заметка Юлии чересчур поверхностная и может вводить в заблуждение.
Например, про вызов getaddrinfo(). Из "заметок на полях":
Если на запрашивающем хосте запущен nscd, все ответы кэшируются на 60с и подставляются в запросы "getaddrinfo()" через перехват стандартной функции. А этот глюкодром до сих пор стартует "искаропки" на моей любимой openSUSE. Но нет худа без добра: в 2016 году nscd помешал кой-чего проэксплуатировать. В том самом getaddrinfo() из тогдашней glibc. …Понятно что при этом RR ломается.
Сам getaddrinfo() таки делает RR. Но вот сюрприз: какой-то шибко-вумный программист разбил возвращаемые записи по "классам". Как я помню (сейчас лень искать), там как-то считается "удалённость" адресов и RR выполняется для "равноудалённых".
Вообще, касающиеся DNS RFC достаточно конкретные, но да, чересчур обширные. И продолжают выходить новые правки. И это весьма стимулирует "юных DNS-писателей" (сам такой, было дело) забивать на "ненужные" подробности. Как пример, яндексовские резолверы. (По-русски их принято писа́ть через "з", по аналогии с "резолюцией.) Кто-то когда-то написал как понимал, а потом видимо пошёл заниматься ещё чем-то. И теперь некому найти/исправить "вечный кэш" для glue-записей. (Моя контора посылала им разбор, но в итоге была послана обратно.)
Oops… Про RR держал в уме ещё вот эту заметку той же Юлии. Это там она жаловалась что "round robin DNS doesn’t work with getaddrinfo".
У них нет эффекта памяти, который представляет собой вредный процесс, вызывающий частичные циклы заряда/разряда, в результате которых батарея теряет ёмкость.
"Кто за кем стоял?"
Ощущение такое как будто гугло-перевод отредактирован гуманитарием.
С точки зрения пожарной безопасности, РБМК "прекрасны" этим (цитата из Вики)
Основу активной зоны РБМК-1000 составляет графитовый цилиндр высотой 7 м и диаметром 11,8 м, сложенный из блоков меньшего размера, который выполняет роль замедлителя.
…И этим, заодно:
период полураспада ¹⁴C составляет 5730 лет
С поправкой на всякие насверленные каналы, "на пальцах" выходит от 10 тонн продуктов сгорания. Без кислорода и "всякого-тяжёлого" (я не химик и не распишу из чего там ещё получались газы и золи). Автоматизированную систему тушения проектировать не стали (ТБМ).
В общем, "из нашего времени" мне ближе мнение тех специалистов которые основным фактором ставят административный. Система управления страной с 1960х практически лишилась "коротких" обратных связей и к 80-м были накоплены критические ошибки. В частности, позволившие начать эксплуатацию зафэйленного проекта (о наличии ПОС в процессе регулирования скорости реакции было известно).
Нет. Термостаты достаточно инерционны и неплохо пропускают скачки́ давления.
Так что, одно другое не отменяет.
С сечениями — да. Когда вся разводка сделана O16 (потому что дёшево), отбор в любой точке вполне ожидаемо кидает давление (мне это удобнее представлять электрическими схемами, где напряжение отображает давление воды, а сопротивление зависит от сечения трубы /ну и длины, конечно/).
По личному опыту, при таком способе валидации пендели практически неизбежны. Потому что "глаз замылен" и пропускается нечто, кажущееся очевидным. Насколько это мотивирует сотрудников и к каким комплексам приведёт, лучше расскажут профессиональные психологи.
Решается элементарно. По готовности документации, тех. процесс начинает вводить в эксплуатацию новый человек/коллектив. По возможности, хорошие исполнители, но без инициативы.
В процессе ответа на вопросы исправляется документация. И, почти всегда, сама внедряемая технология. Автор статьи достаточно подробно расписал почему и привёл примеры из своей области.
Уупс… Это в каком, простите, месте, "plain" LVM не умеет делать снапшоты etc.?
Конечно, если забить всю VG — то таки да. Но так-то — нет.
Т.н. "thin provisioning" — он немного не про это. Его лучше рассматривать как аналог QCOW, но с минимальным "нижним слоем". (По сравнению с "толстой" ФС под QCOW. Хотя там можно и "гибрид" на LVM собрать. Если очень надо.)
Снимки в LVM, они не вполне QoW. Там, "на пальцах", что-то типа "журнала наоборот". Когда что-то записывается в "основной" том, в "снимок" записывается то что было до этого. Отсюда и такая просадка при подключении снимков/thin provisioning.
И да. Путать управлятор томами (LVM) с любой RW-ФС — достаточно серьёзное заблуждение. Подумайте, почему в распределённой RW-ФС обязателен надёжный "фенсинг" (подсказка: не превратить данные/метаданные в фарш). А вот LVM (но не thin, по той же причине) вполне может обойтись гораздо более "слабым" shared-механизмом. (Не рушить сбойнувшую ноду любой ценой, а спокойно дождаться ремонта.)
P=U*I в замкнутой цепи. Когда цепь замкнута чьей-то тушкой, кроме поражения нервной системы (тут да, почти только от тока зависит т.к. сопротивление на коже и "внутри" обычно отличается на порядки), также выполняется работа по запеканию (P*t). Иногда именно она определяет полученные травмы.
Вероятность того что через человека потечёт ток определённой силы растёт с увеличением напряжения. Как крайний пример, был знакомый с допуском на 10кВ, неудачно (с летальным исходом) махнувший рукой в опасной зоне ТП.
Для УЗО:
Если "сдёргивается" как релюха, при бо́льшем напряжении сработает от меньшего тока.
К дет.дому/беспризорникам 1920-х восходит. Скорее всего.
Царёв, Князев, etc. — соответствующие крепостные крестьяне в роду.
Королёв, Капустин, Алмазов etc. — давали при приёме в детский дом. Когда фамилия была неизвестна, придумывали как умели.
То что я запомнил из объяснений "старшего поколения". Сам в вопросе не копался.
PERIBOARD-517 W — Wired Waterproof
"На глаз" — почти она (только зачем-то длинный "CAPS").
Но я не сумел пройти квест "притащить это в РФ". Местные ебаи не показывают интересующую раскладку для РФ (и всякие посредники по этой причине тоже не фурычат). Подозреваю что вопрос решается постановкой прокси "там" (для этого нужно победить лень, через доламывание последней живой Mitsumi видимо).
Ниже IMO, в рамках имеющегося (радиотехнического) образования а не потому что я этим занимаюсь.
Да. Такая штука имеет крайне сомнительную перспективу в рамках тактики "ударить исподтишка и убежать". Сама тактика очень даже хороша (иногда, но не всегда). Но то что "рельсотрон" столько лет тянули именно на роль далеко-загоризонтного оружия, говорит скорее о сильной инертности мышления. (Возможны также мотивы не технического характера.)
Единственным неоспоримым достоинством очень-быстролетящей болванки является её низкая чувствительность к воздействиям, производимым современными автоматами ПВО. Вроде как отбиваться от пистолетных пуль чем-то вроде ракетки для пинг-понга. Отсюда легко вывести набор показаний к применению данного типа вооружений. А не наоборот.
Спасибо, поправил статью по первым двум пунктам (добавил цитаты).
Чтобы включить "
sendwait", нужно осознавать в чём тут фокус. Надеюсь что моя заметка сократит кому-нибудь время на дебаг. Проблема у меня на локалхосте (KDE) просто имеет ту же самую причину.Удержать в голове все "нюансы" systemd для меня, например, как для "ассоциатива" — нереально. Пролистываю мануалы по мере возникновения задач, пропуская мимо всё не связанное. Постепенно число связей растёт. Как-то так…
И вот тут — да, отношусь к systemd с некоторым скепсисом, как неплохо информированный оптимист. Кое-что — вот прямо очень удобно. К примеру, контрольные группы по CPU/blkio или навешивание приоритетов для OOM. С другой стороны, полностью динамический порядок запуска — полный кошмар при отладке. Или вот прохождение квеста "э, а где мой dmesg?". На стыке ядра (буфера 2к бывает маловато) и journald.
…Что касается "очень старых систем", то они никуда не девались. Просто в новом-модном это называется "
initrd"/"initramfs" и туда мало кто лазает. Да, там теперь "из коробки" дирижирует systemd. Но (к счастью) оставлена возможность запуститься в шелл и провести необходимые (ремонтные) мероприятия. Вплоть до "восхода солнца вручную"."Ты хитрый."©
Чтобы более-менее внятно ответить на вопрос, надо размотать пол-системы.
Вот так "в лоб" мы ничего не видим:
Но применив "магическое заклинание" "
systemctl --user status" (из-под активного пользователя), видим куст поназапущенного.В частности:
Подробности:
Видим, что некий "
systemd-xdg-autostart-generator" взял шаблон из "autostart/xswitcher.desktop". И сгенерил по своему усмотрению вот такое:Исходный шаблон (с ним всё скучно):
Таки да. Процесс (теперь) запускает именно systemd. Завернув в cgroup (подробности можно подглядеть в "
/sys/fs/cgroup").Вот такой шаблон:
Type=notify
Да, разумеется. Память подвела, однако. Больше 12 лет прошло с нашей последней встречи с "Фрюхой".
* И я слегка польстил
tc. Netgraph, ЕМНИП, даёт возможность состыковать вообще любого "ежа" с любым "ужом". А не только Ethernet манипулировать.Да, но нет. Сначала борт вообще допустили только покататься по аэродрому.
Потом — пролететь в метре. Ну и т.д..
Аналогично по двигателям, начинаем с моторесурса (число только что высосал из пальца) 50 часов, и далее доказываем возможность её увеличения.
Авиация вообще предельно параноидальна в вопросах контроля надёжности. И приколы из других отраслей с "ускоренным старением" там почему-то не очень приветствуются.
* Вот если дальше допуски не растут, то что-то пошло́ не так.
** На 3 км воздух ещё довольно плотный. И тёплый. Если на "крейсерском" эшелоне допустимые 0,75 М ≈825 км/ч (относительно воздуха!), то тащить 600 на 3000 выглядит достаточно правдоподобно.
Там КМК не финансы. (Лавка-то по факту государственная, как и "Арбуз", впрочем. Существовать будет, никуда не денется.) Пришли некие гении и хакнули регламенты ISO-9000. Которые про контроль качества.
* А заодно принялись эффективно управлять инженерными кадрами. Кого там в РФ аутсорсили? Не прочнистов случайно? Я за этим краем глаза слежу, помню что что-то Боингу считали за символическую ЗП.
Но это не суть. В большие планеры сейчас умеют французы (офигенно), наши (неплохо) и, теперь, китайцы (пока х.з. как). А вот сделать удачный турбовентилятор — уже́ раздел инженерного искусства. (Пока) могут праттовцы, Ролс-Ройс и (со скрипом) пермяки. Общая проблема, как понимаю, в переходных режимах. Для которых нет рабочей мат. модели, и каждую новую модель двигла приходится доводить методом тыка. Многопараметрическая оптимизация, блин. И вот тут вообще вопрос, насколько удастся сохранить "школу". При том что это теперь "не круто".
Да, так идеологически правильнее.
На накладные расходы (в статье — достаточно "короткие" структуры, зато "дорогие" внешние вызовы) это заметно не повлияет. Лучше делать так, как более "читаемо".
В описанном случае проблемой было "да как это вообще сделать-то?!". Вышло вот так.
После получения понимания "как это работает", ничто больше не заставляет писа́ть сложные completion'ы на bash. Но, как всегда, есть нюанс: сложность в этом месте указывает на дефекты в проектировании интерфейса.
Задачу манипуляции с LUN успешно решают примерно все эксплуатанты ДЦ. Нюансы, традиционно, в контроле сложности. Кому-то хватает коммерческих вариантов, типа vSAN от vmWare. Кто-то сразу кидается делать GUI.
В моём сценарии, абстракции добавляются по мере необходимости. Потому что "внутренние" задачи являются расходной частью бизнеса, ресурсы на них выделяются соответственно.
Есть "физический" слой, linux+multipath+qemu(libvirt). На первых порах его хватает, раскидать конфиги можно и каким-нибудь ansible/pdsh. И там же тяп-ляп пересканировать SAN.
Когда понятно что "всё", есть смысл обернуть конфигурацию каким-нибудь DSL. И организовать транспорт поприличнее, с контролем compliance. Это кардинально снизит "ошибки оператора" и позволит дотянуть до следующего "порога" (если бизнес не развалится).
Когда опять упёрлись (тратить ресурсы дорогих инженеров при наличии дешёвых стало накладно), оборачиваем имеющееся в очередную абстракцию. Здесь уже́ есть смысл потратить время на разложение операций по базисным функциям, обеспечить конкурентные изменения и контроль выпуска. GIT, так-то, был ещё на предыдущем шаге. Но вот здесь он прямо-таки играет всеми красками, да.
А вот вместо того чтобы тратить время на написание кастомного шелла, я его потратил на вкручивание json-интерфейсов ко всем модулям. На па́ру с обеспечением функциональности автодополнения/автозаполнения везде где это возможно.
Когда/если встанет задача обернуть всё в GUI, программисту останется прокинуть сдизайненные (вот тут боюсь что им же) "окошки" к готовым и документированным интерфейсам.
Но это всё лирика. Системотехнике есть и без меня кому учить. Я просто иногда стараюсь показать интересные (ПММ) случаи.
А в данном случае интересно как раз практическое применение bash-completion. Не на "всю катушку", но около того. При наличии как позиционных, так и "свободных" аргументов, включая "
--ключ=значение".Побуждения тут вполне корыстные. Когда очередной коллега попытается отпетлять от организации подсказок в CLI с аргументацией "отвяжись, не умею я в bash-completion", теперь можно ткнуть в ссылку. "Ну вот же «рыба», с разъяснениями."
Последнее обновление сисек ломает работу всех версий NetworkManager-openconnect кроме последней 1.2.10 (от 27.05.2023, ЕМНИП). Если речь про linux. Из командной строки и openconnect, и "родной" anyconnect работают.
Других проблем с anyconnect в РФ (и не только) коллеги не отмечали.
Зато мне Мегафон отломал openVPN в сторону AS35000. Пришлось в ssh оборачивать (благо его отломать пока не додумались). Ломалось где-то по дороге Мегафон-Ростелеком-БМ18-моя_сеть. Что с моей т.з. опровергает один из тезисов выше (про то что ломали "по подсетям" а не чохом на DPI).
К сожалению, данная заметка Юлии чересчур поверхностная и может вводить в заблуждение.
Например, про вызов getaddrinfo(). Из "заметок на полях":
Если на запрашивающем хосте запущен nscd, все ответы кэшируются на 60с и
подставляются в запросы "getaddrinfo()" через перехват стандартной
функции. А этот глюкодром до сих пор стартует "искаропки" на моей любимой openSUSE. Но нет худа без добра: в 2016 году nscd помешал кой-чего проэксплуатировать. В том самом getaddrinfo() из тогдашней glibc. …Понятно что при этом RR ломается.
Сам getaddrinfo() таки делает RR. Но вот сюрприз: какой-то шибко-вумный программист разбил возвращаемые записи по "классам". Как я помню (сейчас лень искать), там как-то считается "удалённость" адресов и RR выполняется для "равноудалённых".
Вообще, касающиеся DNS RFC достаточно конкретные, но да, чересчур обширные. И продолжают выходить новые правки. И это весьма стимулирует "юных DNS-писателей" (сам такой, было дело) забивать на "ненужные" подробности. Как пример, яндексовские резолверы. (По-русски их принято писа́ть через "з", по аналогии с "резолюцией.) Кто-то когда-то написал как понимал, а потом видимо пошёл заниматься ещё чем-то. И теперь некому найти/исправить "вечный кэш" для glue-записей. (Моя контора посылала им разбор, но в итоге была послана обратно.)
Oops… Про RR держал в уме ещё вот эту заметку той же Юлии. Это там она жаловалась что "round robin DNS doesn’t work with getaddrinfo".
Там и дальше есть перлы.
"Кто за кем стоял?"
Ощущение такое как будто гугло-перевод отредактирован гуманитарием.
С точки зрения пожарной безопасности, РБМК "прекрасны" этим (цитата из Вики)
…И этим, заодно:
С поправкой на всякие насверленные каналы, "на пальцах" выходит от 10 тонн продуктов сгорания. Без кислорода и "всякого-тяжёлого" (я не химик и не распишу из чего там ещё получались газы и золи). Автоматизированную систему тушения проектировать не стали (ТБМ).
Ч.Т.Д. Шпарит конечно не так лихо, но это в т.ч. заслуга большого объёма внутри термостата.
Нет. Термостаты достаточно инерционны и неплохо пропускают скачки́ давления.
Так что, одно другое не отменяет.
С сечениями — да. Когда вся разводка сделана O16 (потому что дёшево), отбор в любой точке вполне ожидаемо кидает давление (мне это удобнее представлять электрическими схемами, где напряжение отображает давление воды, а сопротивление зависит от сечения трубы /ну и длины, конечно/).
По личному опыту, при таком способе валидации пендели практически неизбежны. Потому что "глаз замылен" и пропускается нечто, кажущееся очевидным. Насколько это мотивирует сотрудников и к каким комплексам приведёт, лучше расскажут профессиональные психологи.
Решается элементарно. По готовности документации, тех. процесс начинает вводить в эксплуатацию новый человек/коллектив. По возможности, хорошие исполнители, но без инициативы.
В процессе ответа на вопросы исправляется документация. И, почти всегда, сама внедряемая технология. Автор статьи достаточно подробно расписал почему и привёл примеры из своей области.
Уупс… Это в каком, простите, месте, "plain" LVM не умеет делать снапшоты etc.?
И да. Путать управлятор томами (LVM) с любой RW-ФС — достаточно серьёзное заблуждение. Подумайте, почему в распределённой RW-ФС обязателен надёжный "фенсинг" (подсказка: не превратить данные/метаданные в фарш). А вот LVM (но не thin, по той же причине) вполне может обойтись гораздо более "слабым" shared-механизмом. (Не рушить сбойнувшую ноду любой ценой, а спокойно дождаться ремонта.)
Таки имеет. Для человека:
Для УЗО:
Если "сдёргивается" как релюха, при бо́льшем напряжении сработает от меньшего тока.
К дет.дому/беспризорникам 1920-х восходит. Скорее всего.
Царёв, Князев, etc. — соответствующие крепостные крестьяне в роду.
Королёв, Капустин, Алмазов etc. — давали при приёме в детский дом. Когда фамилия была неизвестна, придумывали как умели.
PERIBOARD-517 W — Wired Waterproof
"На глаз" — почти она (только зачем-то длинный "CAPS").
Но я не сумел пройти квест "притащить это в РФ". Местные ебаи не показывают интересующую раскладку для РФ (и всякие посредники по этой причине тоже не фурычат). Подозреваю что вопрос решается постановкой прокси "там" (для этого нужно победить лень, через доламывание последней живой Mitsumi видимо).
Ниже IMO, в рамках имеющегося (радиотехнического) образования а не потому что я этим занимаюсь.
Да. Такая штука имеет крайне сомнительную перспективу в рамках тактики "ударить исподтишка и убежать". Сама тактика очень даже хороша (иногда, но не всегда). Но то что "рельсотрон" столько лет тянули именно на роль далеко-загоризонтного оружия, говорит скорее о сильной инертности мышления. (Возможны также мотивы не технического характера.)
Единственным неоспоримым достоинством очень-быстролетящей болванки является её низкая чувствительность к воздействиям, производимым современными автоматами ПВО. Вроде как отбиваться от пистолетных пуль чем-то вроде ракетки для пинг-понга. Отсюда легко вывести набор показаний к применению данного типа вооружений. А не наоборот.