И почему никто не вспомнил про тот инцидент в Блэк Меса с тележкой?

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

Моя любимая история геймдева про Блицкриг 2, уж не знаю, правда или нет. Читал когда-то давно в каком-то бумажном журнале, недавно нашёл в сети.

Ну, сделали и мы в Блицкриге эту самую ракету. Как и немцы, сделали ее уже ближе к концу проекта и соорудили на базе объекта "самолет". Но программисты несколько схалтурили и не пооткручивали у бывшего самолета подозрительную для баллистической ракеты функциональность. Оказалость, что если во время полета к цели начинал идти дождь или снег, то во-первых ракета говорила человеческим голосом "Fliege zuruck"(нем. лечу назад), а во-вторых разворачивалась и летела обратно на базу. Фигли там, погода то нелетная.

А еще был у нас замечательный юнит — отряд спецназовцев. Войска у нас могут получать в ходе миссии опыт, а за опыт дают всякие интересные способности. Так вот, донельзя прокачанные спецназовцы получали возможность маскироваться под вражескую пехоту. Достаточно было просто кликнуть в отряд неприятельских солдатиков, и наши бойцы переодевались в их форму. Можно было безнаказанно разгуливать по вражеской базе. Ну, до первого выстрела, конечно.

Но, беда в том, что в Блицкриге кроме собственно пехоты еще были всякие антуражные юниты, типа коров, свиней и собак. Выяснилось, что спецназ вовсе не чурается переодевания в бобиков и хавроний. Если учесть, что механизм этого самого переодевания несколько глючил и часть отряда можно было нарядить в одну форму, часть в другую, то можно было создавать совершенно безумные подразделения. Например, отряд из собак, свиней и панцергренадеров. Учитывая, что отряду можно отдавать всякие приказы типа "маршировать", "ползти" и т.д., то игроку предоставлялась уникальная возможность полюбоваться марширующими свиньями. Получалось это у них, впрочем, паршиво, потому что скелет свиньи не соответствует скелету пехотинца и выглядит это как отряд ездящих не попе хрюшек. А еще этот цирк-шапито можо было запихать в окоп. Сидят, значит, свиньи с собаками в окопе и периодически из него выглядывают.

И вот моё самое любимое:

Со свиньями был связан, кстати, еще один баг, из-за которого игра падала. В какой-то момент программисты что-то такое там подкрутили и свиньи перестали быть нейтральными, а обрели возможность принадлежать какому-то игроку. Управлять ими было нельзя, но формально они могли быть "наши" или "ненаши". Так вот свиньи роняли игру. Потому что видя неприятеля, патриотичная хавронья хотела дать врагу отпор и лезла за оружием, которого у нее естественно не было. Если мне не изменяет память, программисты исправили баг, просто выдав свинье пистолет Люгер без патронов. Визуально это никак не видно, но формально, теперь, видя врага, она лезет за оружием, видит что патронов нет и на этом успокаивается.

Я четыре года назад как-то попытался разъяснить путаницу с именами архитектур. Если кратко:

• x86 — Intel архитектура для 32-битных ПК, который сама Intel называет IA-32.
• x64, x86_64, x86-64 — расширение AMD64 для x86, сейчас идущее в большинстве процессоров для ПК.

Всё остальное надо называть своими правильными именами (POWER(3,4,5,…), IA-64, ARMv(7,8)), иначе очень сильно сбивает. Я вот, например, эту статью до конца прочитать не смог, потому что постоянно сбивался, куда и на что мигрируют, так и плюнул.

А в чём собственно разница между вирусом и не-вирусом

А это произрастает из принципиальной нерешаемости проблемы останова (the halting problem). Поэтому я совершенно не верю в эвристические механизмы детектирования и с подозрением (но и надеждой) отношусь к методам, основанным на симуляции в песочнице. Последние в конце концов упираются в то, что они настолько хороши, насколько хороши списки контроля доступа того, что каждому приложению можно и нельзя делать (SElinux, manifest etc.)

Очень хорошая картинка, спасибо. Стоит к ней приглядеться. Конечно же, после некоторой тренировки понятно, что знаки значат, особенно если прочувствовать, что скорости даны в милях/ч, а расстояния в милях и футах.

Конечно, STOP ни с чем не спутаешь. Но вот лишь некоторые различия, которые бросаются в глаза:

• знаки один и два вполне можно воспринять как указатели скорости. У нас указатели номеров дорог совсем другие и по цвету, и по форме, и буква в них включена, например M3, A101, E95.
• знак №15 — мне лично был непонятен на местности, пока не объяснили
• знаки 31 и 44 — аббревиатуры, непонятные без расшифровки
• знак 30 — у нас это "красный кирпич на палочке"
• знаки номер три и пять — вообще непонятно, что. У нас больница — это красный крест. И да, у нас есть потрясающий по понятности восклицательный знак "прочие опасности". Что-то опасное происходит, так что вы тут поосторожнее.

Не указаны знаки.

• Высота проезда (clearance): у нас знак, у них надпись

К чему я это всё: с любой адекватной сигнальной системой можно жить, но для дорожных знаков критически важно быть универсальными, т.к. неправильная их интерпретация может привести к неправильным решениям в условиях высоких скоростей.

Моё мнение: и американец, и европеец/русский, оказавшись впервые в чуждой ему системе дорожных знаков, будет не в состоянии их быстро и правильно интерпретировать без предварительной тренировки. Это как приехать в Англию и начать ездить по правой стороне дороги — далеко не уедешь. Но про это хотя бы многие знают.

Ну конечно же. Статья провокационная, поэтому и комментарии к ней такие же.

Да и первый пример, фактически, CGI-скрипт.

Это мог бы быть CGI-скрипт на Perl, на Bash, ну или программа на Си.
Да и для "обычных" двоичных программ точно так же обязан иметься загрузчик, который разберёт их структуру, поместит секции в память и передаст управление на точку входа. Но это не делает машинный код "языком разметки".

Смотря какая версия HTML.

Про то, что, казалось бы, простые языки разметки не так уж и просты, см. мой комментарий ниже.

Два контрпримера:

pshttpd — веб-сервер, написанный на Postscript 1) http://www.pugo.org/project/pshttpd/ 2) https://people.debian.org/~godisch/pshttpd/

basix — интерпретатор языка Basic, написанный на TeX: https://www.tug.org/TUGboat/tb11-3/tb29greene.pdf

Может быть и непривычные, но это языки программирования. Как и, например, Postscript, TeX. Ну или эзотерические языки вроде BF, лямбда-исчисление Чёрча или ДМТ.

И описывают на HDL не только синтезируемые описания, но также потактовые модели и верифицирующие модели.

Код inline-транслятора для ВМ готов: https://github.com/grigory-rechistov/interpreters-comparison/blob/master/translated-inline.c .

Производительность он пока что показывает хуже, чем оригинальный translated. При этом профиль VTune у них очень сильно отличается. У нового транслятора вылезли интересные эффекты вроде 4kB-aliasing и machine clears. Более подробный анализ я провесит пока что не успел, но, похоже, придётся оптимизировать операцию push, т.к. она вылезла вверх в профиле. Но надо разбираться.

Если очень кратко, то:

• Стандарт ACPI определяет интерфейсы управления энергопотреблением платформы (ЦПУ, материнская плата и периферийные устройства) для ОС.
• Стандарт определяет состояния энергопотребления и производительности: для системы в целом (S0-S5), процессора (C- и P-состояния; эта статья лишь слегка коснулась C-состояний), периферийных устройств (D-состояния).
• Стандарт не диктует обязательность реализации всех объявленных в нём режимов. Детали реализации режимов различаются для разной аппаратуры. Кроме того, операционные системы вольны реализовывать только некоторые из режимов сна.
• За засыпание отдельных устройств отвечают их драйвера. Но что-то подсказывает мне, что обеспечение корректной поддержки D-состояний не стоит в первом приоритете у драйверописателей. Поэтому то, насколько глубоко заснёт конкретный девайс, может отличаться на разных ОС или ревизиях одной ОС.

Про режимы энергосбережения попробую написать. Хотя я напрямую не работаю с ними, у меня под рукой есть довольно много публикаций на английском по этой теме (например, вот эта книга "Energy Efficient Servers. Blueprints for Data Center Optimization", бесплатная в PDF варианте). На русском, пожалуй, знаю только об одном бакалаврском дипломе (подготовленном в нашем отделе).

Тема, конечно, необъятная, учитывая, что в секторах серверов, десктопов и встраиваемых систем на основе IA-32 детали реализации могут очень сильно отличаться.

Спасибо!

Идея в том, чтобы оставить код переносимым, отдав компиляцию компилятору

Конечно же, это очень соблазнительно.

Вопрос — не пробовали делать псевдо-translated, копируя в буфер кода куски, ограниченные парами меток?

Я пытался реализовать немного другую технику и споткнулся о тот факт, что компилятор(ы) генерируют код совсем не так, как мне хотелось бы.
А именно, я попытался копировать тела функций с сервисными процедурами, конкатенируя их в блок трансляции. Помешали как минимум две проблемы.

1. Не существует портабельного (да и вообще хоть какого-то надёжного) способа определить длину тела функции в Си. Адрес начала функции получить тривиально, а вот конец — нет. Использование адресов меток вместо функций может быть и помогло; но я боюсь, что компилятор начнёт переставлять метки, объединять их и т.п., особенно на уровнях оптимизаций, отличных от -O0. Может быть, какие-то компиляторные барьеры расставить удастся, не знаю.

   
   
2. Тела функций не получается конкатенировать, так как в коде процедур точек выхода может быть несколько. Очень часто компилятор преобразует код вида

    void f() {
        if (a) {
            code1;
        } else {
            code2;
        }
    }

в следующий машинный код:

f:
cmp a, 0
je alternative
code1
ret ; <--- exit 1
alternative:
code2
ret ; <--- exit 2

В результате имеем две точки выхода из функции, тогда как нам вообще не требуется выходить из неё. А надо нам передать управление на инструкцию, следующую после её конца.

То есть, в промежуточном коде надо как-то найти все инструкции ret и заменить их на jmp single_exit. Что, согласитесь, нетривиально, учитывая различную длину ret и jmp.

Да и вообще, у каждой функции будет в общем случае различный пролог и эпилог, которые, опять же, нашей задаче только мешают. Может быть, указать компилятору, чтобы не генерировал пролог и эпилог функций? Но для GCC на x86 это не работает.

В общем, если компилятор не "приручен", то его вывод будет с трудом подвергаться дальнейшим трансформациям.

У меня студент в качестве задания сейчас пишет улучшенный вариант translated, который будет использовать предкомпилированные блоки кода для сервисных процедур. Посмотрим, получится ли что-нибудь стоящее.