sevka_fedoroff, так автор вопроса потому и написал "почти нормальная клавиатура". См. картинку в UPD, там как раз правильная модификация, с нормальными Ins/Del (на T61 именно такая; возможно, на фотке именно он, не разглядеть модель). А если речь о том, что на десктопных клавах блок PrintScreen/ScrollLock/Pause находится не над F10-F12 — понятно, что полного дубликата не получить, столько места на ноуте просто нет. Но хотя бы взаимное расположение клавиш внутри групп будет одинаковым, и это намного удобнее, чем на современных ноутбучных клавах.
Имеется в виду, классическая для десктопов. Очень удобно, когда расположение этих клавиш такое же, как на обычных клавиатурах. У меня самого́ T61 с правильной раскладкой (в т. ч. с нормальным Insert), и тоже теперь не знаю, что покупать ему на замену. :-( Сколько ноутбучных клав перепробовал, все эти жуткие цепочки PgUp/PgDn/Ins/Del/Home/End в один ряд ужасно некомфортны для использования. Не говоря уж о клавах, где они распиханы по разным углам или навешены на Fn.
Если сконфигурить с -opengl desktop, то это как раз и будет без ANGLE.
Теоретически, можно вообще без OpenGL, но на практике придётся разбираться в зависимостях и вручную исключать из сборки соответствующие модули, и то не факт, что получится.
А что такое $uid? И как вообще реализовано, что информация от разных uid'ов сыпется в один общий лог?
По логу видно, что некоторые «запросчики» (процессы?) не смогли получить flock, а какой-то другой «запросчик» наткнулся на уже обнулённый файл. Всё это наводит на мысль, что за спиной орудует ещё один точно такой же «запросчик», который выполняет ту же задачу (блокирует файл, не давая другим получить flock, читает его и обнуляет, что обнаруживается очередным «запросчиком»). Просто он почему-то не попадает в общий лог. Или попадает, но информация о нём перезатирается из-за race conditions. Не зная схемы, сложно делать выводы.
И вообще, вывод о том, что данные файла не обрабатываются, основан на проверке ожидаемого результата, или же просто из того факта, что в логе не появились четвёрки и пятёрки?
Для -static потребуется либо отказаться от ICU (-no-icu), либо скачать исходники ICU и скомпилять их тоже в статическом виде. ANGLE, вроде бы, тоже статику пока не поддерживает, обещают только в 5.1.0. То есть конфигуратору потребуется ещё указать флаг -opengl desktop и надеяться, что на целевом компе установлены драйвера с поддержкой OpenGL 2.0. (Впрочем, тут я точно не скажу, если QML не используется, возможно, фичи OpenGL 2.0 и не потребуются.)
Увы, получить доступ к корню не вышло. После включения SFTP в настройках DSM я смог туда зайти из Тотала, но в качестве содержимого мне тоже пришёл не корень файловой системы, а список самба-шар.
В инете много говорят об установке дополнительного сервера openssh-sftp, но это я не пробовал, игрался только со встроенным.
Даже если эта утилита не схавает дамп, базовый анализ в WinDbg очень легко провести самому: при открытии дампа он автоматом выдаст предположительного виновника и предложит провести более тщательный анализ командой !analyse -v, да ещё и подсветит её ссылкой. Достаточно щёлкнуть по ссылке, и команда выполнится, выведя более точную информацию о грохнувшемся драйвере в комплекте со стеком крэша. Большего обычно и не требуется. Хотя если в запросе участвует IRP-пакет (см. описание четырёх параметров BSOD-а, выданное в логе анализа), можно ещё выполнить команду !irp с этим пакетом, иногда оттуда можно вытащить полезную информацию о потенциальных виновниках крэша (какие драйверы участвуют в обработке пакета).
Да, единственное, — желательно перед вызовом WinDbg настроить системные отладочные символы, создав переменную окружения
_NT_SYMBOL_PATH=symsrv*symsrv.dll*c:\symbols*http://msdl.microsoft.com/download/symbols
(вместо c:\symbols можно указать любой локальный путь, туда будут скачиваться необходимые PDB-файлы). Впрочем, можно и в самом WinDbg это прописать, это уже на вкус.
Разве Хром работает в гуглоплюсе через HTML5? Я всегда был уверен, что Гугл в него просто впилил собственный плагин. Тем более, слышал, что в Хромиуме гуглоплюс-видео не работает, и якобы, именно из-за отсутствия в нём этого проприетарного плагина.
Бэктики можно вызывать в скалярном контексте, а можно в контексте массива. В первом случае весь вывод будет возвращён в виде сплошного текста, во втором — разбит на строки.
# Так всё в одной строке:
$out = `/usr/sbin/ipset -A $table_name $ip`
# А так всё в виде массива строк:
@out = `/usr/sbin/ipset -A $table_name $ip`
Как анализировать каждый из этих вариантов — зависит уже от того, может ли писать ipset что-то, кроме указанной ошибки.
Вряд ли будет так просто. Наверняка заголовки будут различаться в зависимости от размера образа, то есть перед сравнением нужно будет ещё подогнать размеры. И хорошо, если размер самого заголовка окажется фиксированным… Спецификаций формата VHD я пока не читал, а TIB и вовсе закрытый, и что там внутри — один Акронис знает.
MFC, как раз наоборот, всегда была одной из самых легковесных надстроек над WinAPI. В последних версиях она уже превращается в разжиревшего монстра, это верно, но даже сейчас, если не пользоваться новыми возможностями (типа риббонов), то размер остаётся приемлемым. Типичный размер приложения при статической компиляции (т.е. не требующей доп. библиотек) получается около 300 Кб: это что, неповоротливый гигант?! Так что обвинять её можно во многом: плохая архитектура, куча непонятных и неудобных макросов, недостаточный функционал и т.д., но никак не «гигантизм».
Проблема не в исходниках, а в незнании мной особенностей протокола. Запросто могло оказаться, что сервер сразу же высылает все оффлайн-сообщения клиенту при подключении, и нет никакой возможности сказать ему не делать этого — и тогда написание собственного клиента никак не поможет. Впрочем, если верить ответу чуть ниже, то, видимо, такие функции протоколом всё-таки предусмотрены…