Boost.ScopeExit існує так давно, що можна вважати стандартом... угу, він на макрі, і що з того.

Хотя по сложности такой ASIC наверное будет как современная видеокарта 😀

Именно. Потому такой вариант не учитывается.

Ведь он может самостоятельную ценность за пределами системы.

Кто «он»? Прошивка делается под конкретную задачу в конкретном изделии, перенос её под что-то другое почти всегда невозможен.

Назвіть ОС. Якщо Windows, там в деяких розкладках встановлено, що RAlt == Ctrl+Alt.

10 лет — большой срок даже сейчас.
Haswell-based Xeon в моём десктопе гоняет AVX в 3 раза медленнее, чем лаптоп на Core 12gen покупки прошлого года. Пора апгрейдиться...

На хорошем железе скорее всего будет хардварный акселератор.

Если раутер уровня хотя бы мелкой корпорации — безусловно. Но для домашнего у меня есть подозрение, что с современными мощностями процессоров и конструкциями сетевух они в эту сторону не думают. Прогнать даже гигабит с подменой двадцати байт в заголовках оно себе позволит. Ну, я могу раскрутить коробочку, но что я там увижу...

Flask :) Сам писал API.

Ну да, для Django там нет базы данных. Хотя могут и придумать. Табличка на одну запись «настройка WAN». И sqlite на флэшке.

Yocto — дистиллированное зло. Отрыжка кровавого Энтерпрайза в эмбеддед отрасли.

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

А ось що треба ще додати:

Частина робіт може бути виконана з FPGA, і написання прошивки для тої FPGA це специфічне програмування, яке теж входить в embedded. Це вже не ASIC, тому що ASIC ви не перепрограмуєте за межами тої малости, що він дозволив у регістрах. Вимагає окремих умінь.

Мабуть, у нас його мало, я зі всіх проєктів, де сам брав участь, тільки одного разу бачив щоб в ньому розробляли з FPGA. Може, тому Євген цього не згадав. Але використання готового, про яке я знав, що там FPGA — було більше одного разу.

Виглядає що «3.Embedded Linux kernel engineer», так як це людина, яка є і embedded розробником, і software engineer якщо треба.

Там же було сказано:

Кваліфікація: передбачає три ролі — схемотехнік, kernel engineer та software engineer.

Візьмемо раутер: у нього, наприклад, є веб-морда. Серверна частина, скоріше за все, буде на чомусь компільованому, але б я і Django не здивувався:) але там треба типового фронтендера що вміє в CSS, React і інші. Я серйозно — ось у мене зараз на виході TP-Link Archer C6, у нього типова single page application, тягне jquery, cryptojs, foldertree, excanvas і ще багато чого, що я з моїм розумінням вебу на рівні html3.2 не знаю, що воно і для чого. Вважати його embedded розробником? Я розумію, що приклад маргінальний, але саме на цьому ми можемо позначати межі неприйнятного.

Дивлюсь на той раутер далі. Модуль DHCP. Йому ніць не треба знати про ядро, крім того, що це Linux — там демон на порту 67 або через pcap. На чому зроблена мережевуха, яка версія ядра, звідки береться мак і все таке — йому до біса. Приходить на готове, виконує свою маленьку частинку.

Firewall, NAT. Тут дещо складніше, треба знати, цьому ядру давати iptables, nftables, чи щось інше.

Оновлення прошивки. Ось тут нарешті щось починається специфічне для конкретного заліза. Куди скласти які частини нової прошивки і як. Зазвичай є якась бібліотека з API. Хоча я бачив і варіант з демоном, який все знає і до якого ходять JSONʼом поверх чогось дивного:)

А тепер — трам-пам-пам — скоріш за все >90% всього зроблено не виробником конкретної моделі. Є референсне залізо і референсний софт від когось — фірма, яку можуть зовсім не вказувати і яка робить «болванки» для 20+ виробників. Вони покупають, доробляють під свої манери і смаки і викатують таку доробку. Той хто її робить — може не знати навіть яка система команд процесора. І таке траплялось. Ви не бачили, як в yocto три шари патчів модифікують якийсь компонент? Я з цим працював, і розплутував такі шари патчів, коли один десь треба було видалити, а всі інші ланцюгом за ним вже не накладались. «Повбивав би» (ц).

Ось таке воне промислове життя. Ну ніде там звідки взятись тому суперпуперфулстек знавцю всього від тонкощів перегріву конденсаторів і до останньої версії CSS. Забудьте.

В одному проєкті 4-го рівня за класифікацією автора статті — вендор заліза і по сумісництву хазяїн BSP навʼязав моніторинг стану заліза через зробленого на nodejs демона, який займав близько ⅓ прошивки. Коли прийшла вимога скоротити обʼєм, думаєте, змогли примусити його переписати на більш легке? Ні, замість цього наказали викинути Python з наших компонент, де на ньому була написана вся ініціалізація. А ще там на C писали (і регулярно крешились) там, де краще за все був би Go.

А в ще одному я бачив бінарник 250MB розміром. Це, типу, головний компонент. Звісно, C++ с зневаджувальною інфою, з мегатонною бібліотек від всіх кого завгодно, вивід ldd не вміщувався в 50 рядків, а ще щось довантажилось дінамічно.

Або просто дісципліни. Всюди де воно треба — флаг виконання ініціалізації, вихід з одної точки коду після мітки cleanup, під цею cleanup зачистка всього зробленого в функції. В MISRA десь так и вимагають.

Таки все вірно. (Я подумав спочатку придовбаться по дрібничках, але вони ніць не змінять у основі.)

Йооц, я його намагаюсь читати, але він — типовий показник того, що в формат чата упхати те, для чого треба форум — дає тільки щільний потік інформаційного сміття...

Эээ с учётом той сложности процесса, которая там происходит, ASIC будет содержать процессор из каких-то распространённых ISA, память программ, память данных и всё такое :)

www.computerenhance.com/...​code-horrible-performance
qntm.org/clean
habr.com/ru/post/189094
sergeyteplyakov.blogspot.com/...​2/review-clean-coder.html
www.youtube.com/watch?v=tD5NrevFtbU
www.youtube.com/watch?v=ZLxazlP7Ppo

Їх багато, це тільки де найбільш внятно описано.

Apple товстий, угу. Подивимось...

Про 100500 інших особливостей у мобільному звʼязку.

_Майже_ без альтернативи, угу.
Тільки монстри дозволили собі якийсь спротив. Чи ті, хто під цими монстрами.
Саме тому давати Qualcommʼу ще й Intel буде злочином.

Фігня в тому, что Qualcomm значно більший гопник, ніж Intel. Вони 20 років тероризують все виробництво мобільних телефонів і схожих пристроїв без альтернативи. Intel хоча б не монополіст, є багато інших ISA і на них роблять компʼютери. Тому саме цей напрям придбання тільки погіршить.

Большие ЕСки, не очень большие (на маленькую комнату) СМки. Первые персоналки, ещё не IBM PC (ДВК, Электроника-60 и пр. на «работе», Агаты в школе).
Наблюдая из сейчас понимаешь, что всё это имело основной проблемой отсутствие общей инфраструктуры и устойчивости хранения информации. Даже ленты и большие диски постоянно читались с проблемами, а дискеты так сыпались пачками. Перенести программу с ЕС на СМ или обратно даже в пределах одного языка — работа на недели и месяцы шлифовать все детали. Если вычислительная — новая проблема: плавающая арифметика у всех разная и что сходится на одной — может не сходиться на другой (сейчас IEEE754 всех расслабил). Даже кодировки в пределах латиницы и цифр надо было преобразовывать, EBCDIC не ASCII.
А когда в это начал врываться ещё и мир коммерческого софта с лицензиями — стало совсем плохо. FOSS был спасением, дал хоть какую-то общую надёжность (и переносимость, да).
Сейчас большинство этих проблем уже не поймут или не поверят.
Зато поностальгировать можно и заново переобдумать свои знания по основам...

Як вже сказали: зробити самому на двох модемах при наявності PSTN, через Укртелеком чи офісну АТС — не проблема.
Якість трафіку — непередбачувана. Компресії голоса можуть знизити якість хоч до 2400. Нижче — навряд чи.
Софт — робити з Linux/FreeBSD/etc.
Якщо UUCP — ставте uucp на обох боках, mgetty на сервері. uucico з обох сторін.
Якщо Fido — mgetty на ноді, ifcico для транспорту. Були інші мейлери, не памʼятаю назв.
Якщо IP, на боці сервера — mgetty, під ним pppd, iijppp, mpd (FreeBSD), навіть slirp. На клієнті те ж саме крім mgetty і slirp. Або ж вінда (якщо ще вміє).