А как, по вашему, побудить незадачливого пользователя, у которого все годами прекрасно работало, к тому, чтобы он воспользовался платными консультациями специалистов?
Если диск полностью здоров и не было ремапа ни единого сектора, резервные области будут пустыми. Если же ремап был, то в резервных областях хранятся актуальные данные, тогда как оригинальных секторах уже ничего не хранится по причине того, что оригинальные секторы повреждены и прочитать их не представляется возможным. Так что размер образа будет так или иначе соответствовать логическому размеру жесткого диска.
Есть нюанс — на StackOverflow очень не любят тех, кто хочет получить ответ на вопрос, ничего не сделав для получения ответа в свою очередь. Грубо говоря, вопрос «Как создать массив на основе другого массива только с отрицательными числами по модулю большими 10» не подойдет — его закроют, либо признают homework и не будут отвечать по существу, или в него никто не будет заходить в принципе. Если же хотя бы рассказать, что уже было сделано для решения этой задачи и что не получилось — например, непонятно, как определить модуль числа, или элементы записываются не туда, куда должны бы, или не получается создать результирующий массив — в этом случае ответ будет дан достаточно быстро, доброжелательно и по существу.
Если снять с этого 320 ГБ диска образ, он будет занимать ровно 320 ГБ — ни байтом больше или меньше. «Под терабайт информации» получается из-за того, что при восстановлении файлов, грубо говоря, перебирают различные варианты того, где файл начинается и где заканчивается, отсюда и видимое увеличение объема, тогда как на практике вся информация будет значительно дублировать друг друга. В вашем случае — чуть более, чем в три раза.
Интересно, есть ли способ в Mountain Lion выключить эту «проверку на совместимость с Retina» — меня бы, например, целиком устроили элементы интерфейса в два раза меньше, и не думаю, что меня одного. Должен бы быть, по идее…
Просто прекрасно, но либо я неправильно понял статью, либо не понимаю принципа работы ретины, и прошу это разъяснить.
Новые макбуки имеют хардварное разрешение (количество модулей, изменяющих свою светимость) в 2880х1800 пикселей, но при этом софтварное разрешение (пиксельная размерность экранного буфера) составляет 1440x900 пикселей — из-за downsampling в 4 раза.
Если нельзя использовать хардварные пиксели по одиночке, а только группами по 2х2 пикселя, то чем это эффективно отличается от монитора с обычным разрешением 1440х900?
Господа, а правильно ли я понимаю, что, фактически, retina-монитор отображает все так же, как монитор с плотностью пикселей меньше в 4 раза просто из-за того, что везде в обязательном порядке включен downsampling? В чем профит монитора сверх-высокого разрешения, если на него можно уместить даже меньше, чем на монитор «прошлого поколения»? :(
В своем аналогичном приложении я просто сделал несколько полей, одно из которых — sequence. В случае, если возникает стойкое желание сменить пароль, увеличиваем sequence на единицу и новый пароль готов.
Признаться, я больше думал не о потреблении памяти, которое даже в случае невообразимого разрешения 2880х1800x32b составит аж 20 MiB, сколько о вычислительных ресурсах, необходимых для отрисовки всяких анимаций, всплывающих окон с меняющейся полупрозрачностью отдельных регионов окна, градиентных кнопок, меню, аватаров и тому подобных вещей, которые в headless-конфигурации никто не оценит.
Ну или сесть один раз и сделать libqt-headless, как раз для таких случаев.
literacy.yandex.ru/?lang=ru&word=сольют ли мне карму за этот комментарий
Новые макбуки имеют хардварное разрешение (количество модулей, изменяющих свою светимость) в 2880х1800 пикселей, но при этом софтварное разрешение (пиксельная размерность экранного буфера) составляет 1440x900 пикселей — из-за downsampling в 4 раза.
Если нельзя использовать хардварные пиксели по одиночке, а только группами по 2х2 пикселя, то чем это эффективно отличается от монитора с обычным разрешением 1440х900?
Ну или сесть один раз и сделать libqt-headless, как раз для таких случаев.