К сожалению, ОС и много софта к планшетке написано известными криворучками из компании Google.

Прочитать запись полностью »

Третьего дня купил себе ееепад 32гб с докклавиатурой. Минусов немного, но некоторые могут показаться критичными.

1. Чтобы купить или скачать софт из ондроед-маркета, на текущий момент, необходимо, чтобы дефолтный гталк клиент был онлаен. В связи с тем, что это поделие не хочет быть онлаен по 80 или 443 порту, имеем разные сюрпризы на рабочих вайфаях.
2. Кстати, о вайфаях. На момент написания рецензии, ондроед 3+ ничего не знает про вайфай каналы выше 11. Якобы localization issue in USA. Остаётся непонятным в таком случае, как веризоновский iPad, купленный в США не имеет этих проблем. Желающие могут насрать в чатик в багтрак ондроеду.
3. Маркет показывает цену приложения в рублях по неведомому курсу. На самом деле, цена будет в валюте, которую указал издатель, и снимут именно эту сумму по курсу вашего банка.
4. Браузер. Дефолтный браузер — хром мобильный, одна штука. С ним всё почти хорошо, за исключением дурацкой привычки открывать табы на каждый чих. Не, может на мобиле я бы и оценил, но это же планшет.
5. Офисный пакет. Он ещё хуже, чем гуглодоки (например, вставка из внешних программ не пашет).  Но всё остальное бесплатное ещё хуже.
6. Пдфки читать дефолтным вьювером невозможно. Простые пдфки — лаг по секунде-две на страницу, сложные — по 3-5.
7. Переключение раскладки с дефолтной клавы вызывает диаложек, в котором надо выбрать нужную раскладку, а не листает установленные. Напрягает немного.
8. Видео. Вот табличка с 4pda. Сам не пробовал.

Вроде всё.

О плюсах:

1. У меня появился и нетбук, и планшет, как я и хотел.
2. Достаточно долго живёт на батарейке.
3. Неплохо выглядит.
4. На нём без рута есть рабочий досбокс (их тут два: один за два с половиной фунта стерлингов, второй не работает) и гемрб (такой порт движка балдурсгейта).
5. Если вы хотите потестить софтину перед тем, как честно купить, а триалов нет (как я дважды честно сделал), то надо всего лишь поставить галку, разрешающую ставить приложения в обход маркета.
6. В нём есть гпс, даже в самых простых моделях.

Обзор на хабре.

Для затравки загадка: почему Windows Vista и Windows 7 занимают по 20 и более гигабайт? Ответ в конце поста.

Итак, один из штатных троллей канальчека danvolodar сделал вброс на тему полугодовой давности. Тема следующая: разработчики glibc в линуксе привели поведение memcpy в соответствие со стандартом и всякий софт начал из-за этого падать (потому что клухацкеры полагались на недокументированное поведение). Для начала закопипастю свою позицию по данному конкретному случаю:

Есть много денег, как у Майкрософта — лепи костыль для каждого кулхацкера (как, например, поддержка SimCity и прочего). Нет много денег, как обычно, следи, чтобы документированное работало как работало. В целом, виноваты, кулхацкеры, использовавшие недокументированные фичи.

Теперь я свою позицию поясню. Потому что люди, с разработкой не связанные её не понимают.

У нас есть стандарт языка Си. Этот стандарт нужен не только для линукса на х86 и х86-64, но также и для линукса на всех остальных архитектурах, а также для Винды, юникса и прочих поделок. Это удобно. Ты пересаживаешься на новую ОС/другую архитектуру и ты знаешь, какого поведения ожидать от той или иной функции рантайма. Именно для этого стандарт и был создан. Поэтому, если находим баг в реализации стандарта, его надо исправлять. Обязательно. Или документировать различие, в случае если исправление нецелесообразно.

Тут сразу же встаёт проблема совместимости, когда сторонние разрабы-кулхацкеры, которые использовали твою реализацию стандарта, полагаясь на недокументированные бажные фичи, начнут плакать «аааа, у нас всё упало, верните как было». Так было, есть и будет. Разработчика-кулхацкера не интересует соответствие стандартам, его не интересует, что реализацию стандарта использует куча других людей. Ему нужно, чтобы его маленький хак работал и не надо было ничего делать. Вполне логичное поведение.

Эту проблему можно решать двумя способами.

1. Мы вносим в документацию изменение: «идите нахер со своими стандартами, у нас будет вот так». Этот вариант хорош тем, что не надо ничего делать. Плох тем, что наша реализация отличается от стандарта, новый человек будет неприятно удивлён, когда об этом узнает => кривая обучения становится круче. Надо знать не только стандарт, но и кучу маленьких хачков, прикрученных ради неумех.
2. Придумать способ сосуществования разных версий одного и того же модуля, даже если атрибут «версия» у них одинаковый. Это стоит а) денег (в виде работы проектировщиков, разработчиков и т.д.); б) места на жёстком диске юзера. Именно поэтому последние версии виндов так дохера занимают место.

Способ 2, реализованный в Майкрософте относительно прост и туп. При линковке в EXE записывается не только версия dll, но и хеш той конкретной длл, с которой мы линкуемся. А винда хранит кучу версий этот длл и умеет найти нужную дллку по хешу. В результате, у нас есть более новые версии библиотек с исправленными багами и старые версии библиотек для софта, который использует недокументированные фичи. Все довольны и счастливы. Почему так нельзя сделать в линупсе мне непонятно.

Способ 2, реализованный у Apple, проще и тупее. Там просто каждая программа таскает за собой все необходимые ей библиотеки с собой. И никаких проблем нет.

Вернёмся к нашим баранам. Предложенное Линусом решение — сделать memcpy алиасом memmove — абсолютно неприемлимо. Потому что, кроме 1% от всех десктопов, у Линукса есть ещё минимум 18% «встраиваемых устройств» (роутеры, свитчи, мобилы, пылесосы, станки, военные чипы всякие и пр.), которые ещё не вылезли в рай двухгигагерцовых процов и гигабайтов памяти. И, скорее всего, не вылезут. И им разница между memcpy и memmove важна и критична до сих пор. И эти 18% в абсолютном исчислении в разы больше, чем 1% от десктопов. Наиболее правильное решение в условиях линуксоидов (малый бюджет, етс) было предложено на рсдн тогда же, полгода назад:

1. На уровне молока матери билд-системы разделение на DEBUG и RELEASE билды, вместо самописных велосипедов в половине make-файлов.
2. За год до изменения модифицируем debug-версию memcpy(), чтобы там вылетал ASSERT() в случае пересекаюшихся буферов.
3. Даем девелоперам год на фикс. Пишем об этом явно и везде.
4. Спустя год, меняем release-реализацию.

Но линуксоидам же нахер не надо этого делать, им надо поорать друг на друга «ты мудак и твоя реализация говно». Это, кстати, показывает всю суть текущей реализации опен-сорца в большинстве проектов. Когда Линусу или ещё кому предъявляешь претензии (например, по дохера не закрытых критических багов годами), они говорят: это опен-сорц, возьми да исправь сам, а не хочешь — жри, что дают, бесплатно же. Когда же делаешь так с ними (см. разрабов glibc), то вой до небес: «как вы смели, моя софтинка падает, мне править некогда, вы — мудаки».

Теперь не менее важное, кто виноват в данном конкретном случае (в порядке убывания):

1. Те, кто посадил в 1993м году багу и 17 лет не правил.
2. Те, кто использовал этот баг.
3. Те, кто изменил поведение де-факто без оповещений заранее.

Ходил буквально вчера в кинотеатру посмотреть мультик. По рекомендации bolanoid решил сходить на Ранго. И, знаете, мультик не разочаровал даже в дубляже. Очень напомнил замечательный сеттинг Deadlands. А под кат засуну пару спойлеров (в виде, как всегда, криво написанной рецензии)

Прочитать запись полностью »

Да, оно круто. Это цензурно. Нецензурно — это ахуенно. Всем смотреть.

Обещанное продолжение про профайлеры. Начало тут

В предыдущей статье мы сделали дамп с помощью WinDbg. Далее, что с ним можно сделать? Наверно много, но меня интересовало только одно, а именно — память. Поэтому, я загнал дамп в .Net Memory Profiler.

Данный профайлер сказал мне, что из 7 гигов рама, у меня управляемой памяти всего 1.5 гига. Так как я был тупо уверен (без всяких на то указаний — это ошибка), что утечка именно в управляемой дотнетом памяти, то эту информацию я сразу отбросил и выкинул профайлер.

Пришлось гуглить и пытать по аське знакомых. Результаты:

“!eeheap -stat” — выдаст статистику по управляемым кучам. Предварительно надо загрузить расширение sos.dll. Посмотрев результаты, я понял, что управляемой памяти на самом деле всего полтора гига.

Дальнейшее было делом техники — зацепился из кода к GC Lua, стал выводить статистику по памяти в лог и убедился, что жрёт наш замечательный интерпретатор.

А вот пособие для нубов, как юзать WinDbg для отсечки утечек памяти.

Расскажу я вам сказочку о профайлерах. Их есть много, за каждый хотят обычно денег. Да, чуть не забыл — профилировать мы будем память.

Итак, условия задачи: есть 64битный (это важно) .NET процесс, штатный режим которого — 1-2 Gb Ram, иногда оно съедает 7-8 (больше на сервере нет просто). Задача: выяснить что же там такое, что сжирает эти лишние 6 гиг рама, найти и уничтожить, как обычно всё в общем.

На испытания поступили:

1. WinDbg + SOS (брать в составе нужного фреймворка) — брутальнейший отладчик от майкрософт с интерфейсом в духе «назад в 90е» и «я-vi», ибо практически всё управление через командную строку.
2. JetBrains dotTrace — новенький гламурный профайлер, писанный на шарпе, с блекджеком и шлюхами.
3. .Net Memory Profiler — понтов поменьше, чем у JetBrains, но интерфейс вполне приятный.

Я не буду рассказывать про все их фичи — желающие сами прочтут по ссылкам. Я лишь расскажу, как я ими пользовался.

Запустил я WinDbg, увидел аццкое окошко, кучу непонятных букв и мегамануал и понял, что этот звездолёт я освою только в крайнем случае. Ну уж если совсем жопа будет. И отложил его подальше, благо он бесплатный, лежит — жрать не просит. Далее шёл фаворит — dotTrace.

Фаворит заупрямился сразу — к работающим процессам он не аттачится, видите ли там API херовое, поэтому у них API своё и надо запускать процесс из-под него. Ну раз так — значит так, нам то, что. Запускаем, эмулируем ситуацию, делаем дамп. Доттрейс думал долго. Минут 15, но дамп сделал (честь ему и хвала). Но дальше — финиш. Открывать его он отказался, сославшись на «Not enough memory». Я тупо посмотрел на свободных 6 гиг рама и ещё 20 гиг свопа, почесал в затылке и написал в саппорт.

добрый день.
у меня есть пара вопросов по dottrace
есть дампы по 900 метров файлы, снятые с процесса, который жрал примерно 2 гига рама. записывались только сами объекты, без колстеков, гарбадж коллектора и финалайзер инфы.
пытаемся открыть версией 3.1 этот дамп на сервере (16 гб рама, вин 2003 р2 сп2 х64, 2 xeon каких-то). доттрейс падает с not enough memory.
что у нас не так?

Ответ меня сразил наповал:

слишком большой снепшот. dT 3.1 — 32-битное приложение, ей 16 физических гигов не сильно помогут

Как замечательно. Скромно умолчим, что качал я конечно версию, которая помечена на сайте как 64битное приложение. Для софта по 500 баксов за одно место, это несколько непонятно.

Ну, да ладно. Выкинув поделку от Jetbrains, я взялся за .Net Memory Profiler. Создателям возможная кривость Debugging API не помешала и профайлер умеет как цепляться к существующим процессам, так и запускать из под себя их. Поигравшись по мелочи с настройками, пытаемся сделать дамп процесса. Профайлер думал 2 часа, меня проклинали тестеры, но дамп сделать не смог. Стоит, правда, в два раза дешевле — 250 баксов.

Добрый коллега посоветовал для снятия дампа ClrDump, бесплатную тулзу от спецов по отладке. Тулза порадовала быстрой работой, произведя дамп в 0 (ноль) байт с процесса в 7 гигов. Немедленно была составлена жалоба в суппорт:

Hello.

I wonder why ClrDump produces dump of zero size? My process have 7 Gb of ram and I want to look why.

Command string: ClrDump 3684 sil.dmp Max.

What am I doing wrong?

There is enough space on HDD (about 100 Gb of free space)

Regards, Anatoly Popov.

Автор сначала вежливо ответил, что он в отпуске, но на следующей неделе рассмотрит проблему внимательно. Не обманул, но ответ уже не удивлял:

Hello Anatoly,

Is your process 64-bit? If so, ClrDump cannot create a dump for it (limitations of 32-bit DbgHelp.dll). Unfortunately, there is no 64-bit version of ClrDump (it was created when 64-bit systems were not widespread, and now I don’t have time to upgrade it).

As a workaround, it should be possible to write your own tool that would be built as 64-bit executable, load 64-bit DbgHelp.dll and create the dump. Three function calls are needed: OpenProcess (open the target process), CreateFile(create the dump file), MiniDumpWriteDump with the proper parameters to create the dump. I can send you a sample code if you want.

Regards,

Oleg

Но тут хоть претензий предъявить нельзя — тулза бесплатная, делалась для себя. Так что ладно.

А что же наш звездолёт, который WinDbg? Звездолёт отлично делает дампы со скоростью, примерно равной скорости записи на винт, работает как часы, даром, что бесплатный, древний, да от майкрософта.

Да, кстати, в Vista и 2008 сервере так трахаться не надо. Открываем Task Manager, тыркаем правой кнопкой в процесс, выбираем Create Dump, вуаля, всё готово.

Приятной вам работы.

Или может ли утопия стоить нескольких сотен миллионов человеческих жизней? Под катом спойлеры про фильм Watchmen (Хранители).

Прочитать запись полностью »