Продемонстрирован успешный запуск ядра Linux с rootfs-окружением из Debian на разработанном в 1971 году 4-разрядном процессоре Intel 4004, который считается первым коммерчески выпускаемым микропроцессором на одном кристалле. Процессор содержит всего 2300 транзисторов, поддерживает 46 инструкций и обеспечивает производительность на уровне 60 тысяч операций в секунду.

Так как архитектура Intel 4004 имеет серьёзные ограничения и может адресовать лишь 4 КБ постоянной памяти, вместо прямого запуска Linux была использована идея написания эмулятора процессора MIPS R3000, на котором может работать Linux. Работу усложняло то, что для Intel 4004 не существует и не может быть создано компиляторов для языка Си, поэтому эмулятор пришлось создавать на ассемблере. Таким образом, работа была организована так, что непосредственно на чипе Intel 4004 запускался эмулятор, который в свою очередь выполнял окружение на базе ядра Linux.

MIPS выбран как оптимальный вариант для эмуляции, укладывающийся в ограничения Intel 4004 и размер доступной памяти. Например, созданию эмулятора ARM мешал возникающий сдвиг операндов, RISCV - запутанные режимы адресации, x86 - большой расход памяти на декодирование инструкций, PPC - общая усложнённость эмуляции при небольшом размере памяти.

Для запуска программ на реальной системе Intel 4004 вначале была сформирована простейшая плата, состоящая из микропроцессора Intel 4004, тактового генератора Intel 4201, чипа оперативной памяти Intel 4002-1, размером 20 байтов, контроллера постоянной памяти Intel 4289 и микроконтроллера ATMEGA48, симулирующего постоянную память. В процессе развития проекта была подготовлена более сложная плата, дополнительно включающая память для размещения запускаемого в эмуляторе Linux-окружения и поддерживающая симуляцию постоянной памяти, используя SD-карту. Кроме того, для проведения экспериментов и упрощения разработки на современных системах был написан эмулятор чипа Intel 4004.
. . .
После внесения оптимизаций загрузка Linux в подготовленной конфигурации заняла более 8 дней. 

Компания Google подвела итоги инициативы по внедрению в Android методов безопасной разработки (Safe Coding), таких как использование языков программирования, обеспечивающих безопасную работу с памятью, применение статических анализаторов и проектирование API с оглядкой на безопасность. Изменения позволили снизить долю связанных с памятью уязвимостей в Android c 76% в 2019 году до 24% в 2024 году, что значительно ниже среднего показателя по индустрии - 70%.

Инженеры Google также сделали вывод, что основным источником проблем с безопасностью является новый код и поэтому внимание следует сосредоточить на модернизации методов разработки нового кода. Уже существующий код со временем становится более проверенным и безопасным (наблюдается экспоненциальная зависимость безопасности от времени), что делает не столь выгодными вложения в проекты по переписыванию существующего кода. Например, 5-летний код в среднем имеет в 3.4 раза меньшую плотность уязвимостей, чем новый код. Для проектов Android и Chromium благодаря внедрению методов безопасной работы с памятью разница составляет 7.4 раза.
. . .
В общем виде Google рекомендует не переписывать старый код, а сосредоточиться на написании нового кода на языках безопасно работающих с памятью и обеспечении переносимости между новым и старым кодом
. . .
Скорость и качество разработки увеличивается за счёт упрощения тестирования и смещения выявления ошибок на ранние стадии разработки, на которых ошибки становятся заметны ещё до того, как разработчик приступает к проверке кода. В качестве примера приводятся показатели отката изменений - для кода на Rust число откатов изменений в результате выявления непредвиденных ошибок в два раза ниже чем для кода на C++.

One cause of our feedback loop problem is that we’re bound up by the constraints of how other people implement their systems. For example - it might take AWS up to 10 minutes to provision an EKS cluster. The current tools can tell you if you have the syntax right, but they can’t tell you if it will work or not. To learn that? Gotta wait 10 minutes and pray for rain.

The other source of poor feedback loops is that we represent the definition of our infrastructure as code in the first place. This was a good idea at the time - we gained all the benefits of version control, we could do code review, build pipelines, and do continuous integration and delivery. But code is less malleable than data - it gets locked up behind syntax, it grows in complexity as the problem domain expands, as the abstractions pile up. It’s a static representation of a dynamic environment. With application code it works great - because the results are usually straightforward: an application artifact. But with infrastructure? It turns out to be a very awkward fit. It works, I’m not contesting that. But all you need to do to understand why it’s awkward is look at how hard we’ve pushed to effectively store and manage state, to artificially segment our infrastructure due to constraints of the implementation, and our failure to inspire our peers to work with us on complex infrastructure. It works, but it’s not nearly good enough.
. . .
We accomplish this in System Initiative by building models that exist at various levels of semantic scale, and then building interfaces that make sense at those levels. For example - your application likely has properties that are configurable, actions it can take (like being deployed or built) and infrastructure it requires. You can use the same fundamental system of digital twins we use for low level infrastructure and express the impact with relationships. Eventually[^2], we will provide a custom interface specifically for each job, built from the same underlying data and kept up to date through simple usage. By giving people a view into the data that best fits their needs, we enable them to work together - even when they’re just doing “their” part of the job.