Мне кажется, вы все-таки смотрите слишком однобоко. Если оставить в стороне ситуации типа кто-то переходит с чего-то, и рассмотреть абстрактного разработчика в вакууме, который осваивает это все с нуля, то объяснить ему поведение снэпшотов в MVCC, и как с ними правильно работать, на мой взгляд, в разы проще («всегда будь готов к тому, что записывающая транзакция при коммите может обломиться, и её надо будет повторить»). А вот с блокировками надо писать статьи, подобные этой, где детально разбирается поведение блокировщика — кто там на что берет какой лок — разные уровни изоляции etc.
При этом снэпшоты обеспечивают поведение от оптимального до «good enough» в большинстве случаев без каких-либо приседаний вообще. С блокировками, опять же, надо очень внимательно продумавать, какие уровни изоляции где использовать, и как все это будет взаимодействовать друг с другом.
Ну это вами же описан классический случай подхода, «не надо RTFM, разберемся по ходу дела». Но я, опять же, не вижу принципиальной разницы с таким же переходом в обратную сторону, когда человек с MVCC переходит на блокирующий сервер и получает дедлок в той ситуации, которая успешно разруливается MVCC. И в том, и в другом случае опасность в том, что на это можно нарваться не сразу, а погодя (в продакшне, например). Но когда нарываешься, то диагностика в обоих случаях вполне однозначная.
Насколько мне известно, нексусы все же получают прошивки первыми, но GPE-девайсы тоже в этом смысле не страдают — например, 4.4 они получили в конце ноября 2013-го, при официальном релизе 31 октября.
Да и sizes тоже не относится — это же не размер элемента, а размер картинки, которая является источником. Т.е. это просто метаданные файла, вынесенные в тег.
На днях довелось пообщаться с людьми из коммьюнити scientific Python, в т.ч. Оливье Гризелем и Брайаном Грейнджером. Так вот, в дискуссии на аналогичную тему, они сделали такое интересное замечание: производительность — это хорошо, но в рамках научных исследований важно, чтобы читатели всего этого дела могли потом легко разобраться в коде и воспроизвести те же подсчеты. Поэтому зачастую лучше использовать более медленный numpy вместо всякой экзотики, просто потому, что его знают и понимают все в данной области.
Я недавно делал доклад на похожую тему — тоже с разбором полетов кода на чистом питоне, с постепенной заменой кусков на плюсы, и там же сбоку numpy для сравнения — только там задачкой было множество Мандельброта. И в числе прочих вариантов на плюсах там был вариант на C++AMP. Так вот, прирост производительности там был очень серьезный, где-то на порядок относительно многопоточной версии на PPL.
Если вам принципиальна именно чистая ОС из коробки (с обновлениями etc), то посмотрите на девайсы с Google Play Experience — у Moto G, например, экран 4.5"
У нексусов как-то по жизни не очень с камерой, похоже. У меня был самый первый нексус, а потом Galaxy, и у обоих качество фоток было ниже среднего по больнице.
Ну, в большинстве случаев стандартное поведение с откатом и повтором вполне устраивает. Что важнее — оно более интуитивно понятно, и тяжелее выстрелить себе в ногу дедлоком.
Нет, не указывает. Это указывает на то, что очевидные способы определить килограмм через что-либо еще без привязки к эталону (например, как «масса N атомов вещества X») на практике пока не позволяют достичь требуемого уровня точности по сравнению с эталоном.
Вроде бы все логично. Четыре движка с УВТ разнесены по сторонам в виде X для максимальной маневренности (поворот осуществляется за счет разной тяги, это очень четко видно в сериале, когда они летают). При этом X вытянут, чтобы в одной плоскости маневренность была чуть повыше — это для быстрого ухода. У движков есть сопла спереди для более быстрых поворотов и полетов задом, и боковые сопла для стрейфинга — опять же, в боевых сценах это все активно используется и показывается. Кабина в центре, вокруг которого все это чудо вращается, чтобы минимизировать воздействие на пилота
Сам пилот размещен в кабине «полустоя» (если смотреть спереди), с присогнутыми коленями — в отсутствие силы тяжести сидение ничего не дает, а с другой стороны при прямом ускорении, такая поза лучше всего помогает выдерживать перегрузки (как в ракетах сегодня, где космонавты при взлете лежат горизонтально, перпендикулярно вектору тяги, и лицом вперед).
Единственное, что непонятно — зачем распорки, на которых двигатели, скошены назад…
При этом снэпшоты обеспечивают поведение от оптимального до «good enough» в большинстве случаев без каких-либо приседаний вообще. С блокировками, опять же, надо очень внимательно продумавать, какие уровни изоляции где использовать, и как все это будет взаимодействовать друг с другом.
3.5 заменяет собой 3.0 и 2.0, но не 1.1 и 1.0.
Если вы имели в виду что-то другое — поясните, пожалуйста.
Вроде бы все логично. Четыре движка с УВТ разнесены по сторонам в виде X для максимальной маневренности (поворот осуществляется за счет разной тяги, это очень четко видно в сериале, когда они летают). При этом X вытянут, чтобы в одной плоскости маневренность была чуть повыше — это для быстрого ухода. У движков есть сопла спереди для более быстрых поворотов и полетов задом, и боковые сопла для стрейфинга — опять же, в боевых сценах это все активно используется и показывается. Кабина в центре, вокруг которого все это чудо вращается, чтобы минимизировать воздействие на пилота
Сам пилот размещен в кабине «полустоя» (если смотреть спереди), с присогнутыми коленями — в отсутствие силы тяжести сидение ничего не дает, а с другой стороны при прямом ускорении, такая поза лучше всего помогает выдерживать перегрузки (как в ракетах сегодня, где космонавты при взлете лежат горизонтально, перпендикулярно вектору тяги, и лицом вперед).
Единственное, что непонятно — зачем распорки, на которых двигатели, скошены назад…