Это где так? Обычно итерация происходит в одном из двух порядков:
В порядке добавления ключей.
В неопределённом порядке, оно же в порядке, в каком данные располагаются в map (т.е. по сути что‐то вроде «в порядке возрастания остатков от деления хэшей на размер map», если не учитывать коллизий).
Оба порядка — это «в каком порядке удобно делать итерацию при данной реализации map», и «в порядке возрастания ключей» удобно делать, только если map — это дерево вроде BTreeMap, а не хэш‐таблица.
Помимо этого есть lua, где таблицы одновременно ещё и массивы и другие языки со схожими идеями, где, в зависимости от ключа, значение окажется либо во внутреннем массиве, либо в хэш‐таблице, но даже у lua порядок никак не гарантируется даже для числовых индексов (вероятно, т.к. вы вполне можете засунуть числовой индекс в хэш‐таблицу, а не в массив).
Для того, чтобы показать на форуме, как вы можете написать рекурсивный макрос или ещё чего интересное, достаточно. Если нужно какой‐то доступ к сети, я бы смотрел так:
Есть ли готовые пакеты с решением проблемы? Я не уверен, как сформулировать такой запрос, но когда я искал, а что делают сервисы CI (а они по сути как раз запускают у себя недоверенный клиентский код, которому нужен интернет), я нашёл только что они либо закрытые, либо предполагают внутреннее использование (в смысле внутри компании (с закрытой регистрацией), разработчики не менее чем одного найденный OpenSource CI сервера вполне предполагает, что он будет торчать в интернет). Я ещё посмотрел в сторону OpenSource облаков, но они слишком сложные.
Если ничего не найдено, то можно попытаться сделать так:
Пускать контейнер «без сети». Нет сети — не нужны настройки firewall для контейнера, и соответственно, не нужно думать, как объяснить firewall’у, чего вы от него хотите, если вы хотите чего‐то вроде «не более N запросов в секунду от одного пользователя».
В контейнере подменить библиотеки, работающие с сетью, на что‐то, что будет заворачивать запросы в stdout/unix socket/…, что общается с сервером, запустившим контейнер. Если подменить библиотеки нельзя, можно сделать виртуальный сетевой интерфейс, который будет делать то же самое, но уже ниже уровнем.
На сервере уже реализовать собственно общение с интернетом, со сбором интересных метрик и со своими ограничениями — по сути firewall будет тут.
Мне кажется, такой вариант проще в реализации, потому что серверу, запускающему контейнер уже отлично известно, почему (по какому запросу) он его запустил, так легче собрать метрики с привязкой к контейнерам/пользователям/запускаемому в контейнере коду.
Пускать контейнеры с сетью, но разобраться, как с клиентским доступом к сети работают облачные провайдеры.
Контейнеры имеют тенденцию со временем становиться более безопасными и простыми в использовании. Тот же play.rust-lang.org просто запускает docker с --net none, здесь сложно что‐то забыть или неправильно настроить.
В МИФИ кажется подобный реостат стоит в пульте управления высотой АРСА (к счастью, не для собственно управления высотой, а для управления величиной смещения при отображении высоты — т.е. по сути для указания нуля). Очень неудобно: если проскочить нужное значение и сдвинуть барабан грубой подстройки, то с высокой вероятностью на обратном ходе вы опять проскочите. Проблема в том, что, во‐первых, я не знаю, когда именно точной подстройки станет не хватать и я начну крутить грубую. Во‐вторых, я достаточно хорошо представляю, насколько нужно повернуть, если подстройка только точная — но если я поверну именно настолько, я рискую нарваться на поворот грубой подстройки далеко за нужное значение, соответственно крутить приходится весьма осторожно — и я всё равно часто промахиваюсь в обратном направлении (грубая подстройка здесь очень грубая). В‐третьих, из‐за разной реакции на поворот и того, что реостат всегда находится в положении, близком к нужному, я не представляю, насколько нужно повернуть, чтобы грубая подстройка оказалась там, где нужно. Я подозреваю, было бы удобно, если бы точная подстройка охватывала бо́льший диапазон значений.
Ссылка точно актуальна не для всех, но (не)нормальность компиляторов тут не причём — компиляторы C будут реализовывать используемый в целевой системе C ABI, если только не смогут доказать, что компилируемая функция никогда не будет вызвана извне (включая из другой единицы компиляции того же проекта).
компилятор вполне проглотит if (1) {}. Следующее выражение в этом случае не станет условным, как в случае совсем без скобок, но вот, например, echo 'int main(void) { if (1) {} }' | clang -std=c99 -pedantic -Wall -Weverything -xc - даже не производит никаких предупреждений.
После некоторого размышления у меня появилось сильное подозрение, что семантика let foo = bar; — это «создать новое местоfoo и переместить в него объект из bar» (объект один и тот же, но его переместили), а не «создать новый объект foo и переместить в него данные из bar, bar удалить» (есть два разных объекта с непересекающимися временами жизни). Я не могу найти конкретных подтверждений в документации (но то, как про перемещения объектов значений рассказывает документация std::pin оставляет ощущение, что я скорее прав), но let foo = foo точно не запускает Drop::drop и при этом никаких конструкторов в Rust нет. Можете обосновать утверждение «let mut rect = rect создаёт новый объект»?
Это с точки зрения семантики языка. С точки зрения программиста это часто один и тот же объект, т.к. нет видимой разницы (разные адреса, если оптимизатор почему‐то не смог убрать перемещение, не считаются). Это особенно верно, если под rect у нас не простая структура данных, а что‐то вроде Box<Rectangle>: кого волнует, где в стеке указатель на Rectangle, если данные всё равно за указателем и никуда не двигаются?
Явно видно непонимание иммутабельности. К примеру,
let rect = Rectangle::new().set_width(10).set_height(20).build();
// rect.width = 15; // ошибка, так как rect неизменяемый после создания
Во‐первых, код не работает. Вы не можете скормить .build()&mut self вместо self, а именно первое возвращает .set_height. Во‐вторых, build полностью бесполезна. Иммутабельность относится к конкретному месту размещения, если вы владеете объектом, то вы всегда можете сделать его мутабельным. Реальная иммутабельность достигается инкапсуляцией и удалением из общего доступа методов, которые могут изменить состояние объектов. Соответственно в шаблоне создатель у вас должен был быть тип RectangleBuilder и тип Rectangle, и только первый должен иметь методы set_width. Соответственно, говорить «создадим иммутабельную структуру», не объясняя нигде, что она иммутабельная только пока в общем доступе нет методов, её изменяющих, некорректно. Напомню, что вот это вполне себе корректный код:
let mut rect = Rectangle::new();
rect.set_width(10);
let rect = rect.build();
let rect = rect; // То же, что и строчка выше.
// rect.set_width(20); // Не скомпилируется.
let mut rect = rect;
rect.set_width(30); // А теперь мы опять можем менять rect.
Остальная часть не лучше. Например:
Если создается экземпляр структуры с помощью let, все его поля будут неизменяемыми, если только каждое поле явно не объявлено как mut:
Можете показать, как вы объявляете поля структуры как mut? Только так, чтобы результат компилировался.
Или «создадим глобально доступный Arc»: «код, в котором Arc нигде не упоминается».
Иммутабельность в Rust в нескольких предложениях:
Если вы не объявили что‐то, как mut, то взятие исключающей (&mut) ссылки вам недоступно, как и всё, что требует её взятия.
Изменение значения требует такой ссылки (или возможности её взятия) или внутренней мутабельности в каком‐то виде.
Исключающая ссылка гарантирует только, что объект больше никому не доступен. Разделяемая ссылка (&) гарантирует только, что на объект нет исключающих ссылок. Иммутабельность здесь вообще не причём, ссылки исторически назвали неправильно, но большинство типов компилятор позволит менять только по исключающей ссылке.
Почему малварь? Малвари как раз совсем не нужно, чтобы вы её заметили. А вот ошибка в какой‐нибудь реализации пула процессов, не выявленная при тестировании — мне кажется, не менее вероятно, чем малварь. (Конечно, это может быть и малварь с ошибкой в реализации пула процессов.) bash_ps_aux в этом случае теоретически поможет — и, если вы как‐то всё‐таки смогли подключиться, то bash_ps_aux можно запустить, скопировав его код непосредственно в оболочку (с небольшими изменениями из‐за смены способа запуска).
А простыня на 32к строк не поможет, только если это 32к каких‐то случайных имён. Скорее всего, там будет много повторов, если не вообще 31к копий одного процесса — так что вы сможете понять, куда копать при расследовании.
Это, правда, не значит, что я считаю, что задача не разминка для ума — скорее всего, у вас или уже есть данные из других средств мониторинга, или вы уже знаете, кто виноват, т.к. как сами и запустили этот пул процессов в ходе его тестирования, или сервер был быстро и автоматически убит, или вы просто не можете подключиться, т.к. не подумали о необходимости постоянно держать сессию на случай исчерпания PID.
Не обязательно. У моего телефона (Ulefone Armor 20WT) нормальный безопасный пароль и доступ по отпечатку пальцев — и телефон периодически отказывается разблокироваться пока я не наберу пароль. И это не что‐то, что я специально настроил. И если я внезапно захочу набирать длинный пароль при каждом включении экрана мне достаточно удалить все отпечатки пальцев.
Этот же пароль используется для различных вещей вроде добавления новых отпечатков.
UTF-8 — вполне себе 8‐битная кодировка. Проблема легко пропадает, если основная (по числу пользователей) часть производителей ПО договариваются, что zip архив содержит имена в UTF-8 и модифицирует ПО соответственно. А т.к. имена в других 8‐битных кодировках с высокой степенью вероятности либо ASCII — валидный текст в UTF-8, — либо не валидный текст в UTF-8, то для открытия старых архивов вполне можно использовать локальную кодировку, если там не валидные имена. Всё ещё будут проблемы с открытием новых архивов в старых версиях ПО, но тут ничего сделать не получится.
Правда, я предпочитаю просто всегда использовать ASCII, так что понятия не имею, произошло ли что‐то подобное. Быстрое гугление показывает, что похоже вместо детектирования по невалидному UTF-8 в формат zip добавили возможность указания того, что используется UTF-8 — и произошло это ещё в 2006.
А зачем ИБП? Если ИБП не с двойным преобразованием, то ИБП в таком случае ничего не делает, кроме собственно обеспечения бесперебойного питания. Двойное преобразование тоже не имеет практического смысла при наличии разделительного трансформатора. Кстати, а ИБП или стабилизаторы напряжения с двойным преобразованием тоже должны давать нужную развязку (если отключить bypass и если производитель не решил, что одну из линий питания нужно пропускать напрямую).
Относительно стабильности температуры: олово плавится и позволяет сделать из себя перемычку даже на выставленных 210℃, мелкие резисторы и всякие многоножки типа QFP (и даже QFN, если, конечно, речь не про контакт под пузом) я обычно паяю при выставленных 240℃, танталовые конденсаторы (точнее, тот их контакт, что соединён с полигоном на том же слое) и гребёнки 2,54 мм для комфортной пайки требуют уже 250—260℃, для чего‐то вроде проводов с сечением 0,35 мм² лучше выставить 280℃. Это с жалом K («большой топорик»).
Нормальные индукционные паяльники тоже разогревают быстро. У меня YIHUA-900H, нагревает жало менее, чем за 10 с. Совместим с аналогичными индукционными паяльниками от Quick (их жала легче достать), теплового сопротивления на контакте нагревателя и жала нет, т.к. используется другой способ нагрева, температура по ощущениям стабильная, но сенсор (то ли обычная термопара, то ли терморезистор, вставляется в жало туда же, куда у обычных паяльников нагревательный элемент) всё же измеряет температуру основания жала, так что при смене типа жала температуру приходится менять. Плюсом то, что нагревается жало, а остальной металл нагревается от жала — впрочем, насколько я понимаю, если нагреватель встроить в жало, то будет примерно то же самое, с поправкой на то, что жалу будет легче нагреть подходящие к нему проводники.
Модифицированная синусоида — это частое явление при работе от недорогих ИБП, если они работают на батарее или являются ИБП с двойным преобразованием (т.е. работают либо в режиме сеть → постоянное напряжение → инвертор, либо батарея → инвертор). Правда, зачем запитывать паяльную станцию от ИБП мне не ясно, тем более что ИБП, рассчитанный на мощности, необходимые для нормальной пайки (т.е. для работы фена/стола для подогрева/ИК станции/печи — что‐то из этого, скорее всего будет) уже не такой уж недорогой и, скорее всего, будет иметь нормальную синусоиду.
А можно спросить, что не так с релизацией макета в KiCAD? По моему опыту проектирования дорожек с дугами у последнего KiCAD всё лишь немного хуже, чем у Altium 18 (не знаю, как у более новых) — т.е. не так удобно, как обычные дорожки под 45° из‐за того, что всякое перетаскивание не работает (точнее, производит дорожки под 45°), но если вы не собираетесь делать что‐то вроде ведения параллельно 32 дорожек от микросхемы A к микросхеме B, то неудобства не такие уж большие.
Или я бы даже сказал, что если вы можете всё развести где нужно с первого раза, так же с самого начала расставив компоненты как нужно, то неудобств особых и нет даже при 32 параллельных дорожках. Если у вас проект с пачкой современных многоножек, то с первого раза, скорее всего, ничего не получится. Но с плотностью трассировки в вашем проекте переразводок должно быть намного меньше.
Это где так? Обычно итерация происходит в одном из двух порядков:
В порядке добавления ключей.
В неопределённом порядке, оно же в порядке, в каком данные располагаются в map (т.е. по сути что‐то вроде «в порядке возрастания остатков от деления хэшей на размер map», если не учитывать коллизий).
Оба порядка — это «в каком порядке удобно делать итерацию при данной реализации map», и «в порядке возрастания ключей» удобно делать, только если map — это дерево вроде BTreeMap, а не хэш‐таблица.
Помимо этого есть lua, где таблицы одновременно ещё и массивы и другие языки со схожими идеями, где, в зависимости от ключа, значение окажется либо во внутреннем массиве, либо в хэш‐таблице, но даже у lua порядок никак не гарантируется даже для числовых индексов (вероятно, т.к. вы вполне можете засунуть числовой индекс в хэш‐таблицу, а не в массив).
Для того, чтобы показать на форуме, как вы можете написать рекурсивный макрос или ещё чего интересное, достаточно. Если нужно какой‐то доступ к сети, я бы смотрел так:
Есть ли готовые пакеты с решением проблемы? Я не уверен, как сформулировать такой запрос, но когда я искал, а что делают сервисы CI (а они по сути как раз запускают у себя недоверенный клиентский код, которому нужен интернет), я нашёл только что они либо закрытые, либо предполагают внутреннее использование (в смысле внутри компании (с закрытой регистрацией), разработчики не менее чем одного найденный OpenSource CI сервера вполне предполагает, что он будет торчать в интернет). Я ещё посмотрел в сторону OpenSource облаков, но они слишком сложные.
Если ничего не найдено, то можно попытаться сделать так:
Пускать контейнер «без сети». Нет сети — не нужны настройки firewall для контейнера, и соответственно, не нужно думать, как объяснить firewall’у, чего вы от него хотите, если вы хотите чего‐то вроде «не более N запросов в секунду от одного пользователя».
В контейнере подменить библиотеки, работающие с сетью, на что‐то, что будет заворачивать запросы в stdout/unix socket/…, что общается с сервером, запустившим контейнер. Если подменить библиотеки нельзя, можно сделать виртуальный сетевой интерфейс, который будет делать то же самое, но уже ниже уровнем.
На сервере уже реализовать собственно общение с интернетом, со сбором интересных метрик и со своими ограничениями — по сути firewall будет тут.
Мне кажется, такой вариант проще в реализации, потому что серверу, запускающему контейнер уже отлично известно, почему (по какому запросу) он его запустил, так легче собрать метрики с привязкой к контейнерам/пользователям/запускаемому в контейнере коду.
Пускать контейнеры с сетью, но разобраться, как с клиентским доступом к сети работают облачные провайдеры.
Контейнеры имеют тенденцию со временем становиться более безопасными и простыми в использовании. Тот же play.rust-lang.org просто запускает docker с
--net none, здесь сложно что‐то забыть или неправильно настроить.Чтобы это не было тоннелем можно, как написали выше, использовать контейнеры. Как пример успешной реализации: https://play.rust-lang.org (https://github.com/rust-lang/rust-playground), можете поискать уязвимости и сообщить разработчикам, если найдёте. Использует docker.
Изменение усилия заметно, но изменение не такое уж и большое, а грубая подстройка в этом приборе весьма грубая.
В МИФИ кажется подобный реостат стоит в пульте управления высотой АРСА (к счастью, не для собственно управления высотой, а для управления величиной смещения при отображении высоты — т.е. по сути для указания нуля). Очень неудобно: если проскочить нужное значение и сдвинуть барабан грубой подстройки, то с высокой вероятностью на обратном ходе вы опять проскочите.
Проблема в том, что, во‐первых, я не знаю, когда именно точной подстройки станет не хватать и я начну крутить грубую. Во‐вторых, я достаточно хорошо представляю, насколько нужно повернуть, если подстройка только точная — но если я поверну именно настолько, я рискую нарваться на поворот грубой подстройки далеко за нужное значение, соответственно крутить приходится весьма осторожно — и я всё равно часто промахиваюсь в обратном направлении (грубая подстройка здесь очень грубая). В‐третьих, из‐за разной реакции на поворот и того, что реостат всегда находится в положении, близком к нужному, я не представляю, насколько нужно повернуть, чтобы грубая подстройка оказалась там, где нужно.
Я подозреваю, было бы удобно, если бы точная подстройка охватывала бо́льший диапазон значений.
Ссылка точно актуальна не для всех, но (не)нормальность компиляторов тут не причём — компиляторы C будут реализовывать используемый в целевой системе C ABI, если только не смогут доказать, что компилируемая функция никогда не будет вызвана извне (включая из другой единицы компиляции того же проекта).
Не факт. Если вы пишете со скобками так:
то да, но вот так:
компилятор вполне проглотит
if (1) {}. Следующее выражение в этом случае не станет условным, как в случае совсем без скобок, но вот, например,echo 'int main(void) { if (1) {} }' | clang -std=c99 -pedantic -Wall -Weverything -xc -даже не производит никаких предупреждений.После некоторого размышления у меня появилось сильное подозрение, что семантика
let foo = bar;— это «создать новое местоfooи переместить в него объект изbar» (объект один и тот же, но его переместили), а не «создать новый объектfooи переместить в него данные изbar,barудалить» (есть два разных объекта с непересекающимися временами жизни).Я не могу найти конкретных подтверждений в документации (но то, как про перемещения
объектовзначений рассказывает документацияstd::pinоставляет ощущение, что я скорее прав), ноlet foo = fooточно не запускаетDrop::dropи при этом никаких конструкторов в Rust нет. Можете обосновать утверждение «let mut rect = rectсоздаёт новый объект»?Это с точки зрения семантики языка. С точки зрения программиста это часто один и тот же объект, т.к. нет видимой разницы (разные адреса, если оптимизатор почему‐то не смог убрать перемещение, не считаются). Это особенно верно, если под
rectу нас не простая структура данных, а что‐то вродеBox<Rectangle>: кого волнует, где в стеке указатель наRectangle, если данные всё равно за указателем и никуда не двигаются?Явно видно непонимание иммутабельности. К примеру,
Во‐первых, код не работает. Вы не можете скормить
.build()&mut selfвместоself, а именно первое возвращает.set_height.Во‐вторых,
buildполностью бесполезна. Иммутабельность относится к конкретному месту размещения, если вы владеете объектом, то вы всегда можете сделать его мутабельным. Реальная иммутабельность достигается инкапсуляцией и удалением из общего доступа методов, которые могут изменить состояние объектов. Соответственно в шаблоне создатель у вас должен был быть тип RectangleBuilder и тип Rectangle, и только первый должен иметь методыset_width.Соответственно, говорить «создадим иммутабельную структуру», не объясняя нигде, что она иммутабельная только пока в общем доступе нет методов, её изменяющих, некорректно. Напомню, что вот это вполне себе корректный код:
Остальная часть не лучше. Например:
Можете показать, как вы объявляете поля структуры как
mut? Только так, чтобы результат компилировался.Или «создадим глобально доступный
Arc»: «код, в котором Arc нигде не упоминается».Иммутабельность в Rust в нескольких предложениях:
Если вы не объявили что‐то, как
mut, то взятие исключающей (&mut) ссылки вам недоступно, как и всё, что требует её взятия.Изменение значения требует такой ссылки (или возможности её взятия) или внутренней мутабельности в каком‐то виде.
Исключающая ссылка гарантирует только, что объект больше никому не доступен. Разделяемая ссылка (
&) гарантирует только, что на объект нет исключающих ссылок. Иммутабельность здесь вообще не причём, ссылки исторически назвали неправильно, но большинство типов компилятор позволит менять только по исключающей ссылке.Почему малварь? Малвари как раз совсем не нужно, чтобы вы её заметили. А вот ошибка в какой‐нибудь реализации пула процессов, не выявленная при тестировании — мне кажется, не менее вероятно, чем малварь. (Конечно, это может быть и малварь с ошибкой в реализации пула процессов.)
bash_ps_auxв этом случае теоретически поможет — и, если вы как‐то всё‐таки смогли подключиться, тоbash_ps_auxможно запустить, скопировав его код непосредственно в оболочку (с небольшими изменениями из‐за смены способа запуска).А простыня на 32к строк не поможет, только если это 32к каких‐то случайных имён. Скорее всего, там будет много повторов, если не вообще 31к копий одного процесса — так что вы сможете понять, куда копать при расследовании.
Это, правда, не значит, что я считаю, что задача не разминка для ума — скорее всего, у вас или уже есть данные из других средств мониторинга, или вы уже знаете, кто виноват, т.к. как сами и запустили этот пул процессов в ходе его тестирования, или сервер был быстро и автоматически убит, или вы просто не можете подключиться, т.к. не подумали о необходимости постоянно держать сессию на случай исчерпания PID.
Не обязательно. У моего телефона (Ulefone Armor 20WT) нормальный безопасный пароль и доступ по отпечатку пальцев — и телефон периодически отказывается разблокироваться пока я не наберу пароль. И это не что‐то, что я специально настроил. И если я внезапно захочу набирать длинный пароль при каждом включении экрана мне достаточно удалить все отпечатки пальцев.
Этот же пароль используется для различных вещей вроде добавления новых отпечатков.
UTF-8 — вполне себе 8‐битная кодировка. Проблема легко пропадает, если основная (по числу пользователей) часть производителей ПО договариваются, что zip архив содержит имена в UTF-8 и модифицирует ПО соответственно. А т.к. имена в других 8‐битных кодировках с высокой степенью вероятности либо ASCII — валидный текст в UTF-8, — либо не валидный текст в UTF-8, то для открытия старых архивов вполне можно использовать локальную кодировку, если там не валидные имена. Всё ещё будут проблемы с открытием новых архивов в старых версиях ПО, но тут ничего сделать не получится.
Правда, я предпочитаю просто всегда использовать ASCII, так что понятия не имею, произошло ли что‐то подобное. Быстрое гугление показывает, что похоже вместо детектирования по невалидному UTF-8 в формат zip добавили возможность указания того, что используется UTF-8 — и произошло это ещё в 2006.
А зачем ИБП? Если ИБП не с двойным преобразованием, то ИБП в таком случае ничего не делает, кроме собственно обеспечения бесперебойного питания. Двойное преобразование тоже не имеет практического смысла при наличии разделительного трансформатора.
Кстати, а ИБП или стабилизаторы напряжения с двойным преобразованием тоже должны давать нужную развязку (если отключить bypass и если производитель не решил, что одну из линий питания нужно пропускать напрямую).
Относительно стабильности температуры: олово плавится и позволяет сделать из себя перемычку даже на выставленных 210℃, мелкие резисторы и всякие многоножки типа QFP (и даже QFN, если, конечно, речь не про контакт под пузом) я обычно паяю при выставленных 240℃, танталовые конденсаторы (точнее, тот их контакт, что соединён с полигоном на том же слое) и гребёнки 2,54 мм для комфортной пайки требуют уже 250—260℃, для чего‐то вроде проводов с сечением 0,35 мм² лучше выставить 280℃. Это с жалом K («большой топорик»).
Нормальные индукционные паяльники тоже разогревают быстро. У меня YIHUA-900H, нагревает жало менее, чем за 10 с. Совместим с аналогичными индукционными паяльниками от Quick (их жала легче достать), теплового сопротивления на контакте нагревателя и жала нет, т.к. используется другой способ нагрева, температура по ощущениям стабильная, но сенсор (то ли обычная термопара, то ли терморезистор, вставляется в жало туда же, куда у обычных паяльников нагревательный элемент) всё же измеряет температуру основания жала, так что при смене типа жала температуру приходится менять.
Плюсом то, что нагревается жало, а остальной металл нагревается от жала — впрочем, насколько я понимаю, если нагреватель встроить в жало, то будет примерно то же самое, с поправкой на то, что жалу будет легче нагреть подходящие к нему проводники.
Модифицированная синусоида — это частое явление при работе от недорогих ИБП, если они работают на батарее или являются ИБП с двойным преобразованием (т.е. работают либо в режиме сеть → постоянное напряжение → инвертор, либо батарея → инвертор). Правда, зачем запитывать паяльную станцию от ИБП мне не ясно, тем более что ИБП, рассчитанный на мощности, необходимые для нормальной пайки (т.е. для работы фена/стола для подогрева/ИК станции/печи — что‐то из этого, скорее всего будет) уже не такой уж недорогой и, скорее всего, будет иметь нормальную синусоиду.
Не заметил, что это перевод…
А можно спросить, что не так с релизацией макета в KiCAD? По моему опыту проектирования дорожек с дугами у последнего KiCAD всё лишь немного хуже, чем у Altium 18 (не знаю, как у более новых) — т.е. не так удобно, как обычные дорожки под 45° из‐за того, что всякое перетаскивание не работает (точнее, производит дорожки под 45°), но если вы не собираетесь делать что‐то вроде ведения параллельно 32 дорожек от микросхемы A к микросхеме B, то неудобства не такие уж большие.
Или я бы даже сказал, что если вы можете всё развести где нужно с первого раза, так же с самого начала расставив компоненты как нужно, то неудобств особых и нет даже при 32 параллельных дорожках. Если у вас проект с пачкой современных многоножек, то с первого раза, скорее всего, ничего не получится. Но с плотностью трассировки в вашем проекте переразводок должно быть намного меньше.