Нужно очень разное количество опыта для разных языков, чтобы допускать одни и те же ошибки. Иными словами, одни инструменты при решении какой-то задачи справляются лучше других в том, чтобы от какой-то ошибки программиста предостеречь.
Разработчик может захотеть выполнить какие-нибудь вычисления, не дожидаясь окончания отрисовки. Это бывает полезно, например, в играх.
По поводу потоков — можно либо заблокировать второй поток при попытке обратиться к DOM на запись, либо поставить запрос на изменение в очередь, либо даже начать исполнять его параллельно, если браузер так будет уметь (например, инвалидируя часть результатов первого расчёта прямо в то время, пока он выполняется).
Насчёт программируемого storage — тут есть разные направления.
Есть обратные активности, связанные с перенесением алгоритмов из storage в ОС, например host-managed SMR или файловые системы, требующие character-based MTD device для ручного управления страницами flash-памяти.
Я предлагаю вынести на отдельный процессор драйверы диска/сетевухи, а также драйверы файловой системы и сетевых протоколов.
Вы предлагаете использовать для это специализированные процессоры или процессоры общего назначения? Одинаковые или разные (одного типа для сети, другого для файловых систем)? Сложные (как современные процессоры общего назначения от AMD или Intel) или простые?
А что значит «то» или «не то»? Вот команда «ADD AX,BX» должна сделать «AX+=BX»; и именно это она делает. А каким из способов внутри себя она это делает — совершенно неважно.
«Не то» значит, что если мы сможем залезть внутрь, то обнаружим какие-нибудь трюки, при помощи которых процессор угадывает, что мы от него хотим, и использует это «знание» для того, чтобы наши программы работали лучше.
Это важно разработчикам процессоров. Они могут изменить внутреннее устройство (добавить регистров, поменять схему сумматора), но при этом оставить возможность выполнять инструкцию ADD AX,BX.
А вот здесь мне хотелось бы пруф с указанием конкретной модели диска/сетевухи и описанием того, как это работает.
Из интересного — Mellanox BlueField-2 I/O Processing Unit. Из более доступного — любая сетевая карта от Intel, предназначенная для серверов. Вторые, конечно, не являются программируемыми в смысле общего назначения, но опенсорсные драйвера ixgbe и i40e умеют попросить карточку складывать пакеты по некоторым правилам в различные очереди. BPF вполне можно назвать программированием — у LLVM/Clang даже есть соответствующий таргет.
Я предлагаю вынести на отдельный процессор драйверы диска/сетевухи, а также драйверы файловой системы и сетевых протоколов.
Это как раз и происходит. Прошивки SSD умеют разбирать MFT в NTFS и FAT, сетевые карты умеют разбирать UDP, TCP, 802.1q и ещё кучу всего. Просто производители не торопятся «пускать» внутрь своих железок всех подряд. Такое внутреннее ПО позволяет полчить конкуретное преимущество, скрыть детали реализации и быть совместимым с протоколами предыдущего поколения, или же просто дать возможность исправить ошибки обновлением драйвера и/или прошивки.
Современные процессоры мало чего общего имеют во внутренней архитектуре по сравнению с теми, с чьим поведением они совместимы. Чтобы такой глобальный рефакторинг был возможен, внутренняя (микро)архитектура процессора отвязана от предоставляемого пользователю (программисту) интерфейса взаимодействия (в первую очередь ISA) с ним через микрокод. То есть процессор реально исполняет совсем не то, что его попросила программа, а то, эффект от чего будет неотличим (кроме, может быть, производительности) от наивного исполнения программы при условии отсутствия в ней ошибок.
С операционными системами сложнее, но всё чаще встречаются примеры, когда производитель или ломает бинарную совместимость совсем, перекладывая эту проблему на компилятор, различные прослойки и пракладного разработчика, или засовывает внутрь новой ОС урезанную версию старой ОС.
То, что вы предлагаете, уже и так сделано — у нас есть процессор внутри диска, сетевой карты, каждый со своей памятью. Драйвера современных ОС умеют пользоваться возможностями этих процессоров и, в некоторых случаях, перепрограммировать их.
А существовали ли ошибки в GCC 10, которые были обнаружены/исправлены в ходе компилации его исходного кода с помощью GCC 10 с -fanalyzer? И было бы интересно сравнить долю ложных срабатываний на исходном коде GCC 10 у PVS-Studio и самого GCC 10.
В многозадачных ОС, использующих memory-mapped файлы и разделяемые библиотеки не так уж и просто посчитать потребление памяти группой процессов. Если один процесс потребляет 22 МБ, а другой — 43 МБ, то вместе они могут потреблять, например, около 49 МБ за счёт переиспользования страниц (например, кода).
Могу предположить, что при некоторой комбинации условий оптимизирующий компилятор может просто выкинуть этот memset, с помощью которого автор хотел «затереть» секреты.
Можно использовать Jabber: XEP-0313 решает проблему накопления истории.
Все остальные протоколы можно подключить с помощью транспортов (в том числе XEP-0100).
Синхронизировать историю на десктопе умеет Gajim, на Android — Conversations. Под Gajim также есть плагин, реализующий end-to-end шифрование, корректно работающее для нескольких устройств и offline-сообщений (XEP-0384). В Conversations уже всё встроено.
На compliance.conversations.im можно подобрать себе по вкусу сервер, поддерживающий всё, что захочется, если нет возможности поддерживать свой.
У такой схемы есть очевидный недостаток — при использовании чужих транспортов придётся доверять им свои учётные данные (credentials) и IM-трафик от внешних систем.
Из преимуществ — нет необходимости держать на мобильном устройстве несколько приложений, каждое из которых общается со своим сервером и тратит на это ресурсы (в основном заряд аккумулятора).
По поводу потоков — можно либо заблокировать второй поток при попытке обратиться к DOM на запись, либо поставить запрос на изменение в очередь, либо даже начать исполнять его параллельно, если браузер так будет уметь (например, инвалидируя часть результатов первого расчёта прямо в то время, пока он выполняется).
Пример переиспользования кода — валидация полей форм.
В rxvt работает как Alt, так и Alt+Shift (при этом окно не двигается, если WM двигает его по Alt).
Можно запустить сборку под трассировщиком (например), выхлоп которого странслировать в правильную систему сборки.
Ребёнок ещё не догадался подержать кнопку?Я буду обновлять комментарии перед отправкой.
Есть обратные активности, связанные с перенесением алгоритмов из storage в ОС, например host-managed SMR или файловые системы, требующие character-based MTD device для ручного управления страницами flash-памяти.
И есть активности, делающие storage более умным, всякие программируемые NVMe fabrics, например www.bittware.com/resources/building-nvme-over-fabrics
Вы предлагаете использовать для это специализированные процессоры или процессоры общего назначения? Одинаковые или разные (одного типа для сети, другого для файловых систем)? Сложные (как современные процессоры общего назначения от AMD или Intel) или простые?
«Не то» значит, что если мы сможем залезть внутрь, то обнаружим какие-нибудь трюки, при помощи которых процессор угадывает, что мы от него хотим, и использует это «знание» для того, чтобы наши программы работали лучше.
Это важно разработчикам процессоров. Они могут изменить внутреннее устройство (добавить регистров, поменять схему сумматора), но при этом оставить возможность выполнять инструкцию ADD AX,BX.
Из интересного — Mellanox BlueField-2 I/O Processing Unit. Из более доступного — любая сетевая карта от Intel, предназначенная для серверов. Вторые, конечно, не являются программируемыми в смысле общего назначения, но опенсорсные драйвера ixgbe и i40e умеют попросить карточку складывать пакеты по некоторым правилам в различные очереди. BPF вполне можно назвать программированием — у LLVM/Clang даже есть соответствующий таргет.
Это как раз и происходит. Прошивки SSD умеют разбирать MFT в NTFS и FAT, сетевые карты умеют разбирать UDP, TCP, 802.1q и ещё кучу всего. Просто производители не торопятся «пускать» внутрь своих железок всех подряд. Такое внутреннее ПО позволяет полчить конкуретное преимущество, скрыть детали реализации и быть совместимым с протоколами предыдущего поколения, или же просто дать возможность исправить ошибки обновлением драйвера и/или прошивки.
С операционными системами сложнее, но всё чаще встречаются примеры, когда производитель или ломает бинарную совместимость совсем, перекладывая эту проблему на компилятор, различные прослойки и пракладного разработчика, или засовывает внутрь новой ОС урезанную версию старой ОС.
То, что вы предлагаете, уже и так сделано — у нас есть процессор внутри диска, сетевой карты, каждый со своей памятью. Драйвера современных ОС умеют пользоваться возможностями этих процессоров и, в некоторых случаях, перепрограммировать их.
www.viva64.com/en/w/v597
Все остальные протоколы можно подключить с помощью транспортов (в том числе XEP-0100).
Синхронизировать историю на десктопе умеет Gajim, на Android — Conversations. Под Gajim также есть плагин, реализующий end-to-end шифрование, корректно работающее для нескольких устройств и offline-сообщений (XEP-0384). В Conversations уже всё встроено.
На compliance.conversations.im можно подобрать себе по вкусу сервер, поддерживающий всё, что захочется, если нет возможности поддерживать свой.
У такой схемы есть очевидный недостаток — при использовании чужих транспортов придётся доверять им свои учётные данные (credentials) и IM-трафик от внешних систем.
Из преимуществ — нет необходимости держать на мобильном устройстве несколько приложений, каждое из которых общается со своим сервером и тратит на это ресурсы (в основном заряд аккумулятора).