Я пользовался подобным светильником, но у меня он давал большой блик/засвет на значительную часть экрана. Кстати, на фотке по вашей ссылке это хорошо видно: lemagazin.ru/photos/e-books/light/45624/P1040825.png
Динамический контраст отключается в настройках монитора (но, вроде бы, не на всех мониторах, где он есть, его можно отключить).
Dithering у себя на ноутбуке я отключил в настройках видеокарты (nvidia-settings в линуксе). Как это сделать в общем случаю, я не знаю.
Это зависит от фонового освещения — играет роль не абсолютная яркость монитора, а разница освещения монитора и фона за ним, т.е. монитор не должен быть ярко светящимся прямоугольником на темном фоне.
Были проблемы с уставанием глаз от монитора. Решились покупкой монитора с IPS-матрицей. При выборе модели и конкретного экземпляра руководствовался картинками с www.lagom.nl/lcd-test/ для настройки и оценки. Также желательно отключать dithering (который бывает static и temporal), динамический контраст и обращать внимание на мерцание лампы подсветки (особенно на малых значениях яркости).
И, конечно, освещение должно быть хорошим, особенно яркость света, падающего за монитор — яркость стены поверхности за монитором должна быть примерно равной яркости монитора.
На первый взгляд, кажется, что это связано с тем, что в некоторых режимах работы x87 FPU хранит данные и проводит вычисления не в double precision, а в extended precision. При выгрузке из регистра происходит сужение числа до double. Если же число не покидает регистры FPU, то оно так и остается в extended precision.
Более подробно это описано в en.wikipedia.org/wiki/SSE2#Differences_between_x87_FPU_and_SSE2
Всегда читаю все пользовательские соглашения, все договоры и прочие подписываемые мною электронные и бумажные документы. Иногда это оканчивается тем, что отказываюсь от использования продукта или услуги, если условия меня не устраивают.
Ваши выводы меня пугают, честное слово. Мне кажется, что они необоснованы.
>Что это — импринтинг, «git головного мозга», лень, попоболь — остаётся только гадать.
Зачем вы переходите на оскорбления людей? Разве вы не верите в то, что разумные люди способны сами посмотреть на инструменты и сделать свои выводы, основываясь на объективных и субъективных критериях?
Тот юз-кейс, на который рассчитан mq — это всего один из юз-кейсов для правильных бранчей. Остальные юз-кейсы mq не решает, да и само использование mq вносит неудобства, это ведь уже иная концептуальная модель.
Прости гитовские бранчи подходят во всех упомянутых случаях, а также во многих других. Да и с ними проще работать. Зачем менять более лучшее решение на более худшее?
1) Спасибо, я знаю, как бранчиться и мержиться в меркуриале :) По своему опыту могу сказать, что гитовские ветки — самые удобные. Опять же, это все субъективно.
2) Локальное переписывание истории нужно (про изменение публично-видимой истории речь не идет, конечно). Позволяет, например, коммитить периодически промежуточные результаты (особенно удобно при разных рефакторингах), а потом их объединить за один раз; позволяет отложить придумывание хорошего комментария к коммиту; позволяет подготовить «чистую» серию патчей перед мержем в upstream. Вообще, чем меньше надо думать о системе контроля версий, тем проще работать. В Git я не задумываюсь о последствиях локальных действий, потому что я _никогда_ не потеряю данные; в mercurial мне надо постоянно задумываться о «длинных» последствиях даже малейших действий.
3) А мне это доставляло проблемы, т.к. в некоторых проектах часть коллег сидели под виндой, а были русские имена файлов.
Я думаю, что многие согласятся, что кривая обучения у Git выше, чем у остальных популярных open-source VCS.
А вот после Git изучать другие DVCS может быть довольно больно, так как гибкость Git'а вырабатывает определенные привычки и формирует ожидания, которые не всегда оправдываются в случае других DVCS.
Это все субъективно. По моему мнению, mercurial наделен этими характеристиками в меньшей степени:
1) менее продумана модель бранчей и сопутствующие неудобства: сложнее делать топик-бранчи, экспериментальные бранчи
2) переписывание истории возможнр, но оно не удобно и не безопасно: в git есть reflog, который позволит откатить любое редактирование истории;
3) под виндой имена файлов сохраняются в репозитории в кодировке windows-1251, поэтому пользоваться одним репозиторием из разных ОС может быть проблематично.
>Должен ли я вызывать свой метод до или после оригинального? А как оригинальный метод поменяет состояние объекта? А не нарушу ли я чего-то?
Эта проблема присуща любому ОО-подходу: когда переопределяете/доопределяете функциональность, вы должны знать, как это отразится на состоянии объекта (если объекты мутабельны), на контрактах.
>Например, в более функциональных Лиспах большинство функций недеструктивны и не имеют побочных эффектов.
Да, CL достаточно далек от чистой функциональщины.
Dithering у себя на ноутбуке я отключил в настройках видеокарты (nvidia-settings в линуксе). Как это сделать в общем случаю, я не знаю.
И, конечно, освещение должно быть хорошим, особенно яркость света, падающего за монитор — яркость стены поверхности за монитором должна быть примерно равной яркости монитора.
Более подробно это описано в en.wikipedia.org/wiki/SSE2#Differences_between_x87_FPU_and_SSE2
>Что это — импринтинг, «git головного мозга», лень, попоболь — остаётся только гадать.
Зачем вы переходите на оскорбления людей? Разве вы не верите в то, что разумные люди способны сами посмотреть на инструменты и сделать свои выводы, основываясь на объективных и субъективных критериях?
Прости гитовские бранчи подходят во всех упомянутых случаях, а также во многих других. Да и с ними проще работать. Зачем менять более лучшее решение на более худшее?
2) Локальное переписывание истории нужно (про изменение публично-видимой истории речь не идет, конечно). Позволяет, например, коммитить периодически промежуточные результаты (особенно удобно при разных рефакторингах), а потом их объединить за один раз; позволяет отложить придумывание хорошего комментария к коммиту; позволяет подготовить «чистую» серию патчей перед мержем в upstream. Вообще, чем меньше надо думать о системе контроля версий, тем проще работать. В Git я не задумываюсь о последствиях локальных действий, потому что я _никогда_ не потеряю данные; в mercurial мне надо постоянно задумываться о «длинных» последствиях даже малейших действий.
3) А мне это доставляло проблемы, т.к. в некоторых проектах часть коллег сидели под виндой, а были русские имена файлов.
А вот после Git изучать другие DVCS может быть довольно больно, так как гибкость Git'а вырабатывает определенные привычки и формирует ожидания, которые не всегда оправдываются в случае других DVCS.
1) менее продумана модель бранчей и сопутствующие неудобства: сложнее делать топик-бранчи, экспериментальные бранчи
2) переписывание истории возможнр, но оно не удобно и не безопасно: в git есть reflog, который позволит откатить любое редактирование истории;
3) под виндой имена файлов сохраняются в репозитории в кодировке windows-1251, поэтому пользоваться одним репозиторием из разных ОС может быть проблематично.
Эта проблема присуща любому ОО-подходу: когда переопределяете/доопределяете функциональность, вы должны знать, как это отразится на состоянии объекта (если объекты мутабельны), на контрактах.
>Например, в более функциональных Лиспах большинство функций недеструктивны и не имеют побочных эффектов.
Да, CL достаточно далек от чистой функциональщины.