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

Частина робіт може бути виконана з 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. Або ж вінда (якщо ще вміє).

більшість модемів у останні роки актуальності dialup вміли працювати напряму, без АТС.

Ні, це тільки ті що позначені «для виділених ліній» (leased line). Навіть старші моделі (як USR Courier) не всі таке уміли. Бо це розширений блок у схемотехниці модему.

Зазвичай у таких модемів ще були опції конфігурації активуватись без команди.

Проблема в тому, що поки ви не підкажете, який саме текст, ніхто не зможе навіть приблизно відповісти.

Яка мова? Для англійської проблеми флексій (як tie — tying, catch — caught) значно простіші ніж для української чи російської. Для китайської ще простіші. Але для всіх розбір вимагає розуміння семантики. Стандартів нема, або вони порушуються: хто каже про фіксований порядок у англійській, не впорається з «right you are» чи «so did I». А діалектні варіації? А описки і одруківки?

Які обмеження на кодування? Чи треба вираховувати випадки типу коли вci oднaкoві бyкви зaмiнeнi нa лaтинcькi? А коли не всі?

Це, можна вважати, ще не початок шляху, це тільки підготовка до початку ;)

Ніж uuid4 — ні. Ніж послідовні версії — да.
Але у всього є ціна.

Ось Розетка, наприклад, має публічно видимий номер замовлення.
Вже можна розібрати темп замовлень у всьому порталі.
Далі, наприклад, порівняти темп замовлень у звичайний період, перед чорною пʼятницею і після Нового року. З цього — вже ефективність самої Ч.П. Ці дані можна порівняти за різні роки. І так далі.
Тут можна продовжувати цілими сторінками.
OSINT — да, це ціла наука. І не обовʼязково це про розвідки країн: комерційна розвідка не менше, а часто і більше впливова.

Дещо некоректні деталі в історії.

> На сьогодні існує 8 версій формату UUID, при чому версія вказується в самому значенні й під неї відводиться 4 біти.

Це тільки в варіанті 2. А ще формально є інші варіанти. Від раннього DCOM залишилось, я чув, кілька UUID в використанні.

> після чого в 2005-му році з’явилася специфікація UUID від організації IETF (Internet Engineering Task Force), яку зараз всі й використовують, але вже зі 128-бітним значенням як ідентифікатор.

128-бітна версія була ще в DCE, на 1990 вже була. 64 біта це ще раніше. Специфікація від IETF тільки дала публічний вільно доступний стандарт (це суттєво, але не джерело!) існуючим форматам і правилам їх створення і використання. Всі 1-5 існували і широко використовувались до неї.

Про версію 1:

> Крім того, через широке застосування контейнерів і віртуальних мереж MAC-адреса могла бути неунікальною, що призводило до можливих колізій.

Щось слабо віриться, при генерації локального випадкового MAC складно зробити однакові. Хіба що ну дуже тупий генератор чи вибір фиксованих MAC зі значеннями типу «хост 1»...

Інше:

> Результати тестів показують, що використання UUID разом з ObjectId уповільнює продуктивність при вставці в 2-3 рази.

Це «разом». А замість — що буде?

> У Windows використовується термін GUID замість UUID, хоча це фактично те саме.

Різниця у серіалізації в бітовий рядок. Для Windows GUID воно стандартизоване у mixed endian (є поля big і є little). Для UUID стандартизовано big-endian. Хто його як зберігає — треба бути уважним.
Це ж треба тримати на увазі при отриманні з base64 формату.

Галушки!