Значит вам повезло! По крайней мере до первого сервис пака такие проблемы были с некоторыми обновлениями — пруфлинк.
А вообще по поводу переноса профилей я подробно отписывался здесь.
Спасибо за статью! Я же всегда пользуюсь 5 способом и проблем не знаю. Очень люблю применять inline-block для верстки, особенно для вывода каталога товаров. Правда я чаще пишу так:
Item1
Item2
Пробелы внутри блоков уже схлопываются, а между ними их нет.
Ну сама то система не глюкнет. Проблемы могут возникать у сторонних программ, или замедления в работе. К примеру Total Commander при поиске файлов будет заходить рекурсивно в подпапки… Или при любой другой задаче когда рекурсивно сканируется файловая система)…
Junction points применять можно, у меня таким способом профили как раз перенесены на диск D:, но в реестре действительно надо в одном месте поправить путь, иначе некоторые обновления системы не смогут устанавливаться, т. к. WSU не умеет работать с точками монтирования правильно. (у меня была проблема, некоторые обновления не ставились). А делаются очень просто в Windows Vista/7: MKLINK /J «c:\Users» «d:\Users»
Возможно, но я сейчас проверил на упомянутой выше, они скопировались только если указать флаг /SC, иначе в скопированную папку можно будет рекурсивно входить до бесконечностипредела в 255 символов
А вообще способ сомнительный, куча программ при установке копируют свои библиотеки в систему (то есть для установки flash-player потребуется пересоздать образ системы на каждом компе), и так каждый раз. Кроме того нет защиты от вирусов (они могут запускаться, как указано выше из Автозагрузки).
Папку профилей /Users нельзя переносить в лоб, дело в том, что по мимо Junction points, там используются ACL ограничения прав некоторых папок. Если это проигнорировать, некоторые «умные» программы могут уйти в рекурсию.
Например, папка c:\Users\User\AppData\Local\Application Data\ в правах стоит ограничение чтения содержимого папки, т. к. это символическая ссылка папки на саму себя, то благодаря ограничению становится невозможным войти в рекурсию при сканировании файловой системы: c:\Users\User\AppData\Local\Application Data\Application Data\Application Data\…
Более того,xcopy не умеет копировать закрытые правами файлы и папки (даже с ключом /O), т. к. самому xcopy запрещены действия с ними теми же правами…
Как раз недавно пробовал FreeNAS 7, 8, 8 beta, 8.2 alpha для домашнего сервака… Семёрку использовать уже как то не хотелось, в чистой восьмёрке без бубна transmission и minidlna не поднять. Особенно огорчают системные требования для восьмёрки — МИНИМУМ 2 Гб памяти. Вот и остановился в итоге на Ubuntu Server, всё что нужно мне для дома имеется — софтовый Raid, samba с ACL и любые службы из репозитариев.
Ну эта рекомендация закрепилась уже как общепринятая (по крайней мере если у гугла спросите — в 95% случаев получите именно её). Хотя это только рекомендация (и скорее всего именно для нашего старенького аналогового телевидения), я, к примеру, в монитор смотрю с расстояния 1.5 диагонали.
По правилу «оптимальное расстояние для просмотра телевизора должно быть 3-6 его диагоналей», получается смотреть его надо с расстояния минимум 6.4 метра. Комната должна быть соответствующей. Правда исходя из диаграммы, с такого расстояния мы с трудом сможем отличить 720p от 1080p.
А давайте все проблемы решать так? Windows переименуем в Linux, ie6 переименуем в chrome, icq в jabber, mp3 в ogg и т. д.
По делу — не кому не советую делать то, что описано в статье. Это конечно хорошо, что всё откроется, но представьте теперь что может делать пользователь с этим файлом дальше? Возьмёт попытается отправить в Google Docs — косяк, или захочет открыть в какой-нибудь специфичной программе. Естественно у него ничего не получится, пользователь будет ругать разработчиков. Из таких идей и получается у нас потом неразбериха и путаница, когда разработчику приходится проверять, а действительно ли пользователь загрузил JPG, или это переименованная BMP…
Если задача только открыть файл — ну и отправляйте html/mht, всё откроется прекрасно.
То есть первое видео полнодиапазонное, но авторами задумано отображение узкого диапазона, и скрин показан уже масштабированного 16-235 => 0-255.
У второго видео на этапе обработки сжали диапазон, после чего делается обратное масштабирование 0-255 => 16-235=>0-255, получаем второй скрин с деталями в облаках.
Хотя более правильно было бы смотреть первое видео с отключённым итоговым преобразованием, получилась бы картинка как на втором скрине, но при этом мы не сужаем ещё больше диапазон.
Кажется я подозреваю в чём тут проблема. Тут как я понимаю два видео, первое обычное, как задумано авторами, второе получено масштабированием полнодиапазонного видео до 16-235, именно поэтому оно не контрастное.
Я сейчас взял первую картинку в фотошопе сделал Levels Output — 16, 235, и получил почти вторую картинку, кроме как раз деталей в облаках.
То есть — в принципе, ничто не мешает хранить в файле полный диапазон, но отображаться должен лишь диапазон 16-235 масштабированный до 0-255. Именно поэтому, как мне кажется, второе видео некорректно, хотя деталей да, несомненно больше. Для проверки, возьмите оба видео, и посмотрите их гистограмму, наверняка как раз у первого видео будет полный диапазон, а у второго — как раз узкий.
Огорчу вас, но формат Blu-Ray так же соответствуют стандарту BT.709, и также подразумевает узкий (16-235) диапазон. Ссылка на сравнение показывает лишь правильное преобразование YCbCr=>RGB и неправильное. В первом скрине диапазон 16-235 правильно масштабирован до 0-255, а во втором нет — остаются без изменений. Тем самым мы получаем, что чёрный цвет получается тёмно-серым (16), а белый — светло серым (235).
Подтверждение: раз, два.
Как было отмечено выше, только в новом стандарте xvYCC используется полный диапазон (к слову его поддержка в HDMI началась с версии 1.3).
По поводу современных телевизоров, только что попробовал воспроизвести на Asus O! Play Air и на lg 32lv3700. Как я и предполагал, они ведут себя по стандарту — масштабируют 16-235 в 0-255.
Мне тоже кажется использование полного диапазона более правильным, но, к сожалению, большинство фото/видеокамер снимают также в узком диапазоне. То есть, даже преобразовав его в полный диапазон, мы от этого ничего не выиграем (из 220 оттенков цветов мы не получим 256).
А вообще по поводу переноса профилей я подробно отписывался здесь.
<ul>
<li>
Item1
</li><li>
Item2
</li>
</ul>
Пробелы внутри блоков уже схлопываются, а между ними их нет.
бесконечностипредела в 255 символовНапример, папка c:\Users\User\AppData\Local\Application Data\ в правах стоит ограничение чтения содержимого папки, т. к. это символическая ссылка папки на саму себя, то благодаря ограничению становится невозможным войти в рекурсию при сканировании файловой системы: c:\Users\User\AppData\Local\Application Data\Application Data\Application Data\…
Более того,xcopy не умеет копировать закрытые правами файлы и папки (даже с ключом /O), т. к. самому xcopy запрещены действия с ними теми же правами…
По делу — не кому не советую делать то, что описано в статье. Это конечно хорошо, что всё откроется, но представьте теперь что может делать пользователь с этим файлом дальше? Возьмёт попытается отправить в Google Docs — косяк, или захочет открыть в какой-нибудь специфичной программе. Естественно у него ничего не получится, пользователь будет ругать разработчиков. Из таких идей и получается у нас потом неразбериха и путаница, когда разработчику приходится проверять, а действительно ли пользователь загрузил JPG, или это переименованная BMP…
Если задача только открыть файл — ну и отправляйте html/mht, всё откроется прекрасно.
У второго видео на этапе обработки сжали диапазон, после чего делается обратное масштабирование 0-255 => 16-235=>0-255, получаем второй скрин с деталями в облаках.
Хотя более правильно было бы смотреть первое видео с отключённым итоговым преобразованием, получилась бы картинка как на втором скрине, но при этом мы не сужаем ещё больше диапазон.
Я сейчас взял первую картинку в фотошопе сделал Levels Output — 16, 235, и получил почти вторую картинку, кроме как раз деталей в облаках.
То есть — в принципе, ничто не мешает хранить в файле полный диапазон, но отображаться должен лишь диапазон 16-235 масштабированный до 0-255. Именно поэтому, как мне кажется, второе видео некорректно, хотя деталей да, несомненно больше. Для проверки, возьмите оба видео, и посмотрите их гистограмму, наверняка как раз у первого видео будет полный диапазон, а у второго — как раз узкий.
Подтверждение: раз, два.
Как было отмечено выше, только в новом стандарте xvYCC используется полный диапазон (к слову его поддержка в HDMI началась с версии 1.3).