Та самая настройка Safari, из-за которой разгорелся спор
Две недели назад поклонников «яблочной» продукции удивила новость: новые MacBook впервые не получили рекомендацию от Consumer Reports для покупки.
Высочайшее качество ноутбуков Apple всем известно. Этой техникой пользуются лучшие хакеры, даже если приходится переустановить операционную систему. Не было ещё ни одного случая, чтобы ноутбуки не получили рекомендацию покупки Consumer Reports. Но это произошло с последней линейкой MacBook Pro из-за противоречивых результатов по времени работы от аккумулятора при открытии сайтов в браузере Safari.
Сразу закралась мысль, что тут какое-то недоразумение. Так оно и вышло — Apple нашла и исправила очень странный баг. Но теперь она упрекает «слишком умных» экспертов Consumer Reports, которым удалось проявить этот баг. Мол, у них неправильная методология. Кто прав?
Те результаты действительно оказались крайне странными. Судите сами. 13-дюймовый MacBook Pro с тачбаром проработал 16 часов в первом тесте, 12,75 ч во втором таком же тесте и 3,75 ч в третьем.
13-дюймовый MacBook Pro без тачбара проработал 19,5 часов в первом тесте и 4,5 часа во втором.
Для 15-дюймовой модели показатели составили 18,5 и 8 часов.
Тест состоит из бесконечного количества циклов по открытию 10 страниц в браузере, которые передаются с локального сервера по WiFi. Цикл начинается при полном заряде аккумулятора, а заканчивается при выключении ноутбука. Тест проводился на стандартном браузере (в данном случае это Safari) на ОС с последними патчами. Проверку начали несколько недель назад, потом продолжили после выхода macOS Sierra 10.12.2, но разницы не было.
Представители Consumer Reports пояснили, что обычно разница между результатами одинаковых тестов не превышает 5%, а здесь разница слишком велика.
Теперь в комментарии для прессы компания Apple пояснила, в чём дело: «Во время тестирования аккумуляторов в Consumer Reports использовались скрытые настройки для разработчиков вместо нормальных настроек, которые люди используют повседневно».
Речь идёт о настройке, которая отключает кэш в браузере. Эксперты авторитетного журнала специально отключили кэш, чтобы сделать результаты теста более реалистичными, потому что во время тестирования скрипт загружал один и тот же набор сайтов по WiFi. Если бы они оставили кэш включенным, то время работы от аккумулятора не показывало бы истинное положение вещей, потому что при загрузке сайта из кэша не задействуется передача данных по WiFi.
Загрузка сайтов с отключенным кэшем в браузере — вполне валидная и логичная методология тестирования.
Но здесь случилось непредвиденное. Как показало совместно проведённое расследование Apple и Consumer Reports, активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага, который перезагружал иконки (более подробное описание бага см. в комментарии пользователя foundout). Именно эта причина объясняет столь необычные результаты тестирования на время работы от аккумулятора.
При запуске тестов с нормальными настройками баг не проявляется.
В конце концов, сейчас компания Apple всё-таки исправила этот злосчастный баг, так что редакция Consumer Reports может ещё раз провести тестирование и присвоить ноутбукам MacBook заслуженный высокий рейтинг и рекомендацию о покупке.
Но Apple и Consumer Reports по-разному смотрят на проблему с тестами. Apple считает, что проблема в их методологии, а Consumer Reports говорит, что ноутбуки завалили тест из-за бага.
В защиту своей методологии Consumer Reports пишет, что они тестируют все ноутбуки единообразным способом. А поскольку невозможно эмулировать поведение пользователей — все используют ноутбук по-разному, то их тесты на время работы от аккумулятора не предназначены для того, чтобы быть прямой эмуляцией поведения пользователя. Вместо этого они спроектированы так, чтобы учитывать максимальное количество переменных и выдать результат, максимально приближенный к реальности при средней загрузке процессоров, памяти, приёмопередатчиков ноутбука и работе дисплея. «Этот тест служил хорошим показателем времени работы от аккумулятора на сотнях ноутбуков в наших рейтингах», — пишет Consumer Reports. Но только не для MacBook.
Исправление для браузера Safari опубликовано на сайте Apple Beta Software Program и доступно для участников этой программы. После бета-тестирования через несколько недель апдейт отправят на компьютеры всех пользователей через программу автоматического обновления. Возможно, исправление странного бага поможет тем пользователям, которые жалуются на форумах на слишком малое время работы ноутбука от аккумуляторов, что проявляется лишь эпизодически.
Некоторые баги в современном ПО настолько странные, что практически невозможно выявить их истинную причину и определить, когда они будут проявляться. Похоже, этот баг в Safari как раз из разряда таких.
Но стоит ещё раз обратить внимание, насколько профессионально работает PR-машина Apple. Специалисты преподносят ситуацию так, что дело вовсе не в баге Safari. По их мнению, у Consumer Reports проблема в методологии, а Apple помогла им выявить эту проблему, чтобы раскрыть глаза непутёвым и неразумным тестерам.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (106)
stalinets
11.01.2017 19:13+1«Нет смысла нанимать первоклассных специалистов и указывать им, что делать. Мы нанимаем первоклассных специалистов, чтобы они указывали, что делать нам» — вроде это слова Стива Джобса.
Его не стало — вот и результат.
Marsikus
11.01.2017 19:30+9Значит рекомендации к предыдущим макбукам надо отозвать и исключить из рейтинга Customer Reports, раз уж они тоже делались по «неправильной методике» ;)
herr_kaizer
11.01.2017 19:52-1> Этой техникой пользуются лучшие хакеры
Чего? Хакеры используют BackTrack какой-нибудь, а не наглухо проприетарным софтом, который ваши отпечатки пальцев с облаком синхронизирует.
zvirusz
11.01.2017 19:59+2> даже если приходится переустановить операционную систему
Противоречий никаких нет.dmitryredkin
11.01.2017 21:47+4У Линуса, например, макбук.
quwy
12.01.2017 02:32-7Так Лайнус ни разу не хакер.
dmitryredkin
12.01.2017 12:58+1Зависит от трактовки. Если в изначальном смысле, то самый что ни на есть.
ppl2scripts
11.01.2017 23:40+5Отпечатки не синхронизируются, они даже не читаются вне Secure Enclave процессора.
Для логина сенсор передаёт данные в Secure Enclave, и получает подписанный идентификатором процессора ответ о (не)совпадении.
St_androsik
12.01.2017 15:23Не синхронизирует, учите матчасть, ваши отпечатки устройство не покидают.
goodbear
11.01.2017 20:05+2PR-машина работает очень «профессионально» отвечая в стиле «сам дурак»?
Как по мне, так это весьма часто встречается и совсем не профессионально, в противном случае Consumer Reports уже изменили бы технологию тестирования.
A1MaZ
11.01.2017 22:24Баг, конечно, в сафари, даже непонятно что тут спорить. Но с другой стороны, если я правильно помню, то ребята из Consumer Reports утверждали, что их методика прекрасная и ничего они перетестировать не будут. А тут оказывается, что до этого они наклацали на свое усмотрение разные настройки.
A-Stahl
11.01.2017 22:25+2Они «наклацали» настройки согласно своей методике тестирования так же, как и при тестировании любых других ноутбуков.
outcoldman
12.01.2017 01:32Да, но они тестируют не так, как это будет делать обычный consumer. Видимо их тест это тупо перезагрузка одной и той же страницы с отключенным cache.
ClearAirTurbulence
12.01.2017 01:53+1Написано же, набор из нескольких страниц, перезагрузка с отключенным cache.
Было бы странно каждый раз сажать реальных пользователей и грузить реальные сайты сотнями, при этом, те должны бы между тестами оставаться статичными.
Иными словами, иная реализация крайне затруднительна, а использованная, применяемая униформно при тесте ноутбуков разных производителей, вполне объективно отражает возможности техники в условиях, максимально прилиженных к реальным.
Заметьте: раньше Эппл не жаловалась на условия тестирования их ноутбуков.outcoldman
12.01.2017 03:02Одна страница от нескольких отличается не сильно. В любом случае, это совсем не похоже на работу обычного пользователя. Не нужно сажать пользователя, один раз записать тест и использовать его постоянно. Производители часто делают много разного, чтобы пользователям было удобно, а не тестам. Chrome с его автоматической подгрузкой страниц, наверное, вообще убивают батарейку только потому, что кеш отключен, а браузер в пустую постоянно подгружает страницы, которые потом не используются.
3aicheg
12.01.2017 04:29Иными словами, иная реализация крайне затруднительна
Я не понял, а если сделать просто на странице автоперезагрузку по таймауту (как делают в самых простых веб-чатах, это ни разу не затруднительно и не требует никакого отключения кэшей) — это будет чем-то хуже? Страницу каждый раз совершенно новую генерировать, включая все стили и мелкую графику, как-нибудь даже детерминированно это можно сделать, чтобы все девайсы в совершенно одинаковых условиях.dzikar
12.01.2017 09:53Обновляться будет только не закешированная область. Внешний вид, картинки и тд, остануться на месте в кеше.
3aicheg
12.01.2017 10:07+1Я говорю, всё динамически генерировать, в том числе картинки и т. д. То, что на предыдущем обращении называлось
mymotherfuckingpicture0000024123412.png, при следующем обращении будет называтьсяmymotherfuckingpicture0000024123413.png, и прописано в динамически сгенерированном теле страницы будет под этим, новым, уникальным урлом, и отдаваться будет уже по этому, новому, уникальному урлу.dzikar
12.01.2017 10:10-1Вы представляете сколько это будет стоить?
mayorovp
12.01.2017 10:11А в чем проблема?
ClearAirTurbulence
12.01.2017 12:02Ну сделайте такой тест им бесплатно и предложите. Желательно так, чтобы тест выдавал на остальных сотнях ноутов, протестированных ранее, такие же результаты, как оригинальный.
Не хотите? А в чём проблема?3aicheg
13.01.2017 03:19Давайте даже скинемся и доплатим им, чтоб взяли. Вы лично сколько денег готовы пожертвовать?
T-362
12.01.2017 12:44+1Гораздо меньше, чем вы думаете. Требуется студент-ПХПшник с соответствующей оплатой, неделя времени, готовая реализация вихря Мерсенна или другого генератора псевдослучайных чисел и стак оверфлоу что-бы тырить готовые куски кода.
Chamie
12.01.2017 13:43-1И что он напишет? Сферическую страницу в вакууме, нагрузка на которой никак не будет коррелировать с уже проведёнными тестами?
mayorovp
12.01.2017 13:47Он напишет серверную часть, которая будет выдавать под множеством разных имен одну и ту же страницу. Точно ту же самую, которая использовалась в тесте ранее.
T-362
12.01.2017 14:04Точнее серверную часть, которая будет процедурно генерировать и выдавать предсказуемую страницу с контентом и картинками в зависимости от УРЛа.
mayorovp
12.01.2017 14:10Это уже необязательная фича.
T-362
12.01.2017 14:18Разве? Мне казалось что это и есть основное требование — что-бы у было много разных и повторяемых страниц с уникальным контентом возибежание кеширования. Короче — процедурная генерация полноценных страниц по сиду.
matshch
12.01.2017 14:29Достаточно генерации имён, чтобы браузер загружал файлы заново. Более того, можно вместо изменения имени просто приписывать параметр, типа index.html?1, этого достаточно, чтобы файл загрузился заново.
T-362
12.01.2017 14:50Слишком просто и неинтересно.А потом сафари втихаря «оптимизируют» для прохождения таких тестов, у них там и так эвристики понапихано для всех действий подряд — допишут еще. Любовь корпораций к махинациям в подсчетах попугаев общеизвестна.dzikar
16.01.2017 08:48Мне вот интересно, а как вы будете менять хэш тела? Так что что бы не городить огород, проще вырубить кеширование в браузере и не мучиться. Это тоже самое, что пытаясь сделать код для зажигания светодиода в пару строк. сделать его же, но в пару тысяч.
mayorovp
16.01.2017 09:21А зачем менять хеш тела? И что вы вообще имеете в виду под "хешем тела"?
dzikar
16.01.2017 10:07+2Честно, не выспался и ляпнул не в том смысле. Но подведу все свои написания под знаменатель или равно, смотря как посмотреть.
Проще, удобнее, понятнее обновлять одну и ту же страницу. Ну, а то, что есть галочка для разработчиков, которая отключает кеширование, не значит что кривые руки у создателей теста. Галочка есть? Есть. Каждый может её щёлкнуть? Каждый. Тогда в чём проблема обсуждаемая в данной дискуссии, не ясно, баг браузера. Сам же тест прост, прозрачен, не позволяет никому сказать что мухлевали. А кто проконтролирует кучу одинаковых страниц? Будут сравнивать их хеш? Но ведь странички разные должны быть что бы не кешировались, при том одинаковые. Проблема реализации, как никогда остро. Вроде всё просто, но на мой взгляд нуба, я бы не поверил тесту отличимому от постоянной перезагрузки одной и той же страницы, того же размера.mayorovp
16.01.2017 12:58А как вы будете контролировать что тест вообще проводился, а результаты не были взяты из справочника Потолоцкого? Да никак, либо поверите на слово или не поверите.
Вот и с однаковыми страницами так же. Можно при желании код сервера открыть, но даже это не обязательно.
SanekPlus
12.01.2017 11:03Да но они не сравнивают ноутбуки между собой. Они советуют ноутбук к покупке.
И если 99% пользователей не включает такие настройки по которым тестировался ноутбук, то какая польза от подобного тестирования? Ответ — никакой? Или я где-то не прав?
p.s. Разве Apple не права тут? Ведь Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи, а на деле у 99% людей они будут работать штатно.Chamie
12.01.2017 13:45Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи
А это вы откуда взяли? Consumer Reports не рекомендуют не в смысле «рекомендуем не покупать», а в смысле «не можем поручиться, что это хорошая покупка». Т.е. всё равно как если бы не тестировали.
dmitryredkin
12.01.2017 13:52+1Вы вообще поняли, о чем речь? Настройка включена именно для того, чтобы имитировать работу нормального пользователя.
То, что баг в сафари проявился именно с этой настройкой, отнюдь не говорит, что он не проявится, если ее отключить. Просто галочка — это путь к стабильному воспроизведению блуждающего бага.
Отзывы пользователей о случайном проявлении того же бага при (я уверен) отключенной настройке это подтверждают.
ClearAirTurbulence
12.01.2017 14:37+1Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи,
Не так. Они утверждали, что ноутбуки про проведении нескольких повторных, одинаковых тестов показывали существенно различные результаты, что неправильно.
99% пользователей не включает такие настройки по
То кричат, мол маки — для разаработчиков и вебдизайнеров, то выясняется, что их 1% от ЦА…
И ниже отписалась еще одна потенциальная жертва бага, пострадавшая неколько иным образом:
Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
OlegYch_real
11.01.2017 23:36-1какое-то тестирование сферического коня в вакууме
вот поэтому нельзя верить любым тестам которые невозможно воспроизвести
на заметку consumer reports — можно просто загружать каждый раз новый урл (хоть и с одинаковым контентом) вместо ломания браузера
Garrynych
11.01.2017 23:37+8Как тестировщик, считаю нужным отметить, что неправы именно журналисты, но ошибка в методике не тестирования, а оценки результатов.
Поясню. Ключевой момент: «активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага»
Если бы баг проявлялся всегда, а настройка всего лишь помогла его найти — виноваты были бы Apple, которые не нашли критичный баг из-за своих неизобретательных тестеров.
Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
И в результате неправы уже не яблоки, а журналисты — из-за того, что раздули некритичный баг до определяющего при выставлении оценки. А с методологией тестирования у них порядок.
Так что не надо коленным рефлексом сразу хаять яблок, всегда лучше разобраться.
Jogger
12.01.2017 00:18+1Насколько я понял из прочтения статей — Эпл просто объясняет, что неверные результаты теста были из-за бага. А то что у Consumer Reports неправильная методолгия — утверждает какой-то сраный журналист по имени Jim Dalrymple, видимо потому что он — безголовый фанат техники эпл (и скорее всего в технике вообще ничего не понимает). Жаль что не принято журналистов привлекать к судебной ответственности за клевету.
dredd_krd
12.01.2017 00:41Я не тестировщик и опыта в тестировании у меня нет, но субъективно, некая доля вины Apple в наличии бага всё же есть, пусть даже незначительная. Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа? Настройку может включить любой и она должна правильно работать? Конечно! Но результат при этом ухудшается, и не важно, насколько популярна эта настройка, если она делает этот тест возможным в принципе. ИМХО. И журналистов не оправдываю.
leopoldthecat
13.01.2017 10:40Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа?
Это звучит, будто ноутбук делается не для потребителя/продаж, а затачивается для прохождения конкретного теста.
Раз есть баг — косяк Эплов. Нашли его благодаря Consumer Reports — круто. Думаю еще и спасибо сказали.
Тема слишком раздута…
Tujh
13.01.2017 11:20звучит, будто ноутбук делается не для потребителя/продаж, а затачивается для прохождения конкретного теста
Вот сейчас вы открыли для себя всё суть прохождения автопроизводителями краштестов по методике EuroNCAP :)
Marsikus
12.01.2017 04:07Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
Смотря какую категорию пользователей рассматривать. У веб-разработчика или тестировщика в веб-проекте эта опция бывает очень актуальной и может быть постоянно включена.
foundout
12.01.2017 11:05+2Не соглашусь: надстройка режима разработки открывает ряд функций, необходимых не только для разработчика, но и для сколь бы то ни было опытного пользователя — скажем, супруга время от времени вынуждена что-то из них использовать.
Например, без режима разработки нельзя:
- Очистить кэш
- Посмотреть код элемента
- Посмотреть активный код страницы (после выполнения скриптов)
- Отключить скрипты
- Отключить изображения
- Посмотреть ресурсы страницы
- Выполнять действительно «девелоперские» функции — менять user-agent, дебажить JS и т.п.
Кроме того, с багом сталкивался лично, и он действительно прискорбный.
Баг не требует галочки на «Очистить кэши» — он работает при включенном Safari и активированном меню разработки. У меня показывается активная оперативка — и в течение последних двух-трёх недель Safari за 5-6 часов работы умудрялся съесть от 5 до 12 гигабайт, после чего компьютер подвисал, включался вентилятор, а закончить беспорядок можно было только через killall в терминале. Даже после этого Мак продолжает сбрасывать кэш иконок и отрисовывает их «на глазах» при открытии любого меню — но я даже подумать не мог, что это может быть связано с опцией в браузере.
Скрин меню «разработки»:
Garrynych
12.01.2017 15:51-2А я не соглашусь с вами. Вы забываете, что «сколько-нибудь опытные пользователи» — это 5% аудитории браузера, остальное — бабушки, домохозяйки, гуманитарии. И они за 5 лет никогда не воспользуются этой настройкой и, скорее всего, даже не увидят ее.
А «общая» оценка ноута должна исходить именно из этих 95%, а не гиков вроде нас с вами.
Баг, не могу спорить, прискорбный. Для вас, для меня. Но — повторюсь — НЕ критичный в общей картине вещей.
wided
12.01.2017 20:51Вы точно про MacBook говорите? Основная аудитория пользователей, как по мне, это программисты, блогеры и множество прочих специалистов, которым нужен надежный инструмент для работы. И обычно эти люди продвинутые пользователи.
Garrynych
13.01.2017 11:40Ок, соглашаюсь, не подумал.
По основному вопросу это означает, что мое мнение теперь зависит от того, на какой же настройке «висел» баг. Если на отключении кэшей, как написано в статье и в источнике, то по-прежнему не критичен. Если на верхнем уровне, «девелоперских настройках», как утверждает foundout — то соглашусь, что баг переходит в критичные.
vlivyur
13.01.2017 09:41Как тестировщик вы гарантируете что это баг возникает только при активации этой конкретной настройки? Судя по всему — нет. А значит обычные пользователи тоже встречаются с этим багом, тыкая в другие пункты меню.
Garrynych
14.01.2017 00:26Простите, у вас логика поломалась. Ваш аргумент вида «не доказано, что A неверно»=>«A верно».
Я исхожу из доступной информации, а не домыслов о возможном.
А еще тестировщики никому ничего не гарантируют, эта профессия о другом.
r0mik
11.01.2017 23:37> Высочайшее качество ноутбуков Apple всем известно
телефонов — еще куда ни шло. то есть даже соглашусь пожалуй, что тут почти нет им равных.
что же касается планшетов и тем более ноутбуков, то лично я тут в корне не согласен. это с т.з. как рядового потребителя, так и человека много лет занимающегося ремонтом мобильной техники.
tema_sun
12.01.2017 01:37+4В целом, зашел из-за этой же ультражелтушной строки.
В последнее время приходится сталкиваться в работе с теми или иными продуктами Эпла. И почти каждый раз я задаюсь одним и тем же вопросом «Почему? Почему они смогла заработать столько денег на этом?».Garbus
12.01.2017 06:04+2Почему? Почему они смогла заработать столько денег на этом?
В ответ вспоминается фрагмент мультфильма, где старик продавал на рынке корову. Без пиара нынче никак.
Конечно яблочная техника неплоха, но не идеальна. А то, что могло бы быть лучше, не обладало простым интерфейсом «для домохозяек», на чем и не смогло завоевать такую аудиторию.
bkotov
12.01.2017 08:39Что именно не так? Лично у меня противоположные наблюдения. Те же макбуки показали себя как крайне надежные и продуманные решения. Планшеты тоже многое пережили. С айфонами были нюансы и по качеству сборки и по работе и по надежности.
dzikar
12.01.2017 09:59+1Я свой телефон топил в унитазе, булькал в слив. Падал с металической лестницы пересчитав все ступени. Грызли коты. Падал со второго этажа на металлическую плитку. При этом телефон работает до сих пор и при этом ни разу не эппл и не водонепроницаемый, а тем более не ударазащищенный. Из повреждений, разболтавшиеся салазки, скол на стекле, обшарпанность лакированного покрытия, отломал блокировку аккумулятора.
dadyjo
12.01.2017 18:28+1А я на свой айпад мини 2 случайно сел опой, он погнулся. После этого я его разогнул и продолжаю пользоваться.
Lenivoe
12.01.2017 11:04-1Позвольте с Вами не согласиться, 90% нашей страны вообще не знает что такое Apple, зная только iPhone, а 99% населения в руках даже его не держало. То есть как минимум большинству неизвестно качество продукции какой-то там «апле».
Art3
12.01.2017 11:04человека много лет занимающегося ремонтом мобильной техники
У вас классический пример ошибки выжившего )
outcoldman
12.01.2017 01:34Самое ценное в Apple для меня было то, что это одна компания, которая ответственна за железо и операционную систему, когда у меня проблема — я просто иду к ним и они исправляют эту проблему.
А вот когда у меня был телефон Nokia, купленный у ATT с операционной системой от Microsoft, и у этого телефона была проблема с батареей — меня просто каждая компания отфутболивала к следующей по кругу.sotnikdv
12.01.2017 11:12+3Когда у нас на всех маках с выходом Yosemite начал отваливаться wi-fi, Apple не просто отфутболивала по кругу, она просто забила огромный болт. На форуме у них был тред на несколько сотен страниц, куда представители компании просто не заходили. Фикс занял больше полугода. А господин Тим Кук собрал пресс-конференцию срочную и мы ждали, что будет обьявлено об отзыве Yosemite или о фиксе. Но он вышел и сказал, что у него важное известие, он гей!
Когда с выходом El Capitan батарея начала разряжаться за часы, а в отдельных случаях за 1.5 часа (1 минута — 1% в простое), Apple аналогично забила болт с предложением сбросить что-то-там при загрузке или обратиться в сервис (хотя проблема не аппаратная!). Фикс выкатили где-то через 4 месяца.
Поэтому я-бы не стал идеализировать Apple. Железо классное, а с софтом нужно, как и везде, быть ооочень аккуратным. У Apple добавился какой-то полный пофигизм на софтварные проблемы macOS после апдейта.
P.S. У меня на руках 3 макбука про 2012, 2014 и 2016 годов. Плюс десяток у коллег. Все проблемы воспроизводились синхронно при обновлениях на всех доступных железках.outcoldman
12.01.2017 17:17Да, я про эту проблему с WiFi слышал. У меня этой проблемы не было. Слышал, что она возникает с определенными WiFi роутерами (поэтому, наверное, и видели на всех железках в округе).
У меня были другие проблемы с ноутбуком. Одна из них очень редкие зависания видеокарты. Сходил в Apple Store — за 3 дня поменяли материнскую плату, проблема ушла.
lavmax
12.01.2017 02:57Баги бывают как в софте, так и в методологии тестирования. В данном случае имхо нашли по багу и там и там. Apple свой исправила. CR тоже не мешало бы свой исправить и сделать методологию тестирования более приближенной к реальным условиям. На будущее.
Fagot63
12.01.2017 03:10+2И сделать неактуальной всю старую базу тестов?
taras
12.01.2017 03:53-2Вместо того чтобы рефрешить одну и туже страницу, можно было бы подгружать контент с разных страниц, что бы избежать этой проблемы и сохранить актуальность базы тестов.
dzikar
12.01.2017 10:04Гугл хрень сейчас на половине сайтов если брать случайные.
Статичных сайтов без рекламы не сыскать.
Писать ? своих сайтов, которые ни разу не пересекутся в течении 20 часов работы при загрузке одной страницы каждую секунду.
Вот как выглядит моя мысля.Chamie
12.01.2017 13:39Можно ещё настроить, чтобы по всем адресам вида *.mydomain.com открывался один и тот же сайт, и открывать каждый раз страницу с адресом {new GUID}.mydomain.com
Правда, всё равно страницу придётся писать специальную, чтобы никакие вызовы внешних API не ломались.
Jogger
12.01.2017 19:39То есть методология тестирования, выявившая реальный баг, неверная? Вы точно ничего не попутали?
mayorovp
12.01.2017 22:57В данном случае цель тестирования — сравнение разных продуктов, а не выявление багов. Да, выявление редкого бага, не воспроизводящегося при заявленном сценарии использования, в таком случае является ошибкой.
Выражаясь языком статистики, наличие или отсутствие одного единственного бага нельзя считать достоверным критерием сравнения из-за низкой p-value
Jogger
13.01.2017 00:41+1Продукты с багами — не качественные. Методика служит для определения качественных продуктов. Методика показала что продукт некачественный, потому что в продукте содержался баг. Не вижу в данном силлогизме никаких ошибок и противоречий, методика отработала верно. В общем-то, компания Apple со мной согласна, и принзнала что это их баг виноват, смотрите их ответ по ссылке в статье.
mayorovp
13.01.2017 06:04Баги есть всюду, и тот факт что в других продуктах баги не обнаружены, ничего не говорит об их качестве. Поэтому использовать "признак наличие бага" при сравнении — неправильно.
Jogger
13.01.2017 15:38Разумеется речь не об абстрактных необнаруженных багах, они могут быть везде. Если угодно, я перефразирую: «Продукты с уже найденными, но ещё не исправленными багами — не качественные».
qwerty1023
12.01.2017 11:02Я все больше и больше убеждаюсь в том, что похоже уже никто не знает как все устроено «глубоко внутри», сами разработчики в том числе… Всякие фрейморки, библиотеки, оболочки, и вообще новый код, появляются с такой скоростью, что люди уже просто не способны отследить все, что происходит и как это все взаимодействует.
isden
12.01.2017 11:30+3> активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага, который перезагружал иконки
Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
И еще стал понятен постоянный входящий трафик с районе 100-200К (в частности с хабра/GT). Вот сейчас включил кэширование — трафик пропал.foundout
12.01.2017 21:02Гениально.
Ровно та же проблема, а я грешил на провайдера. При трассировке URL все узлы выдавали 2к+ пинг, скорость доходила до 10КБ/сек, при том макбук загружал всю сетку, и на всех домашних устройствах были проблемы с доступом к сети.
Сколько нервов вымотал себе и интернет-провайдеру, но и подумать не мог, что это в Safari сделали новую фичу. В последние 2-3 дня интернет «стабилизировался» — судя по всему, именно в этом интервале у меня и встал фикс.
Mad__Max
19.01.2017 06:54При невозможности записать объект в кэш начинаешь какие-то из ресурсов страницы грузить в бесконечном цикле?
A-Stahl
Охренеть: «Да, у нас баг, то вы не должны были его найти! А раз нашли, то вы редиски, а мы — яблоки».
Shifty_Fox
Просто баг не связан с временем работы, того что требовал тест. По правилам, им следовало эмулировать загрузки с разных адресов и разным контентом, чтобы не участвовал кэш, однако они _зачем_ то залезли в настройки разработчика, чтобы отключить кэш браузера. Честное слово, эппл на свое усмотрение мог бы сделать так, что при включенном режиме разработчика задействовались бы какие-то тяжелые сервисы, из за которых тест был бы провальным. В этом случае тоже бы сказали что виноваты эппл? Баг конечно баг, но проблема в методе тестирования.
Chamie
И да: можно поменять методику, но тогда придётся ещё и выкинуть в помойку данные по всем тестам, проведённым по существующей методике на ?140 других ноутбуках.
Carburn
Можно грузить одну и ту же страницу, но под случайным именем.
Chamie
Только если на случайном домене, иначе придётся рандомизировать ещё и имена всех подключаемых на ней файлов.
mayorovp
Можно и рандомизировать имена всех файлов, это не трудно. А можно использовать относительные пути и рандомизировать только базовый путь.
Fagot63
Смысл теста в его одинаковости для всех. Иначе не имеет смысла сравнивать время работы разных ноутбуков.
Shifty_Fox
Тест использует режим разработчика, который вполне может нагружать компьютер, результаты теста справедливо могут отличаться от реальных кейсов использования. Демонстрация правильного прогноза разве не назначение задачи теста? Если тест выдает неправильный результат, может ли это быть виной продукта? Продукт это черный ящик.
Tujh
Продукт — чёрный ящик, всё правильно, поэтому тест должен быть таким, что бы не учитывать особенности этого чёрного ящика. До этого же всё работало много лет, и на макбуках тоже. И тут раз и всё сломалось на последних версиях ПО. Так почему вдруг это стало «ошибкой теста»?
Segmentq
А с чего опция отключения кэша делает в режиме разработчика? И почему помимо отключения кэша происходят какие-то другие чудеса?
Varim
Но вопрос в том, что другие пользователи, которые жаловались на эту проблему, они что то же отключали кэш, а зачем им это? Может те пользователи были разработчиками которым нужно было отключать кэш для работы, а тогда это баг эппла.
VaalKIA
Нет, просто в одно и то же понятие «методология тестирования» впихнуто две темы.
По факту, Эппл не правы в том, что тестирование без кеша — неправильное, но при этом правы, в том, что опции для разработчиков могут быть непредсказуемы, поэтому, их действия по переключению чего бы то ни было в этом режиме на Маке — некорректны. А то что, по другому не октлючить, ту уж — извините.
Так что методология тестирования с учётом Мак машин — неправильная, подход с отключеним кеша верен, но не реализуем в данном случае, ну и, конечно, баг в сафари был, но не это не означает, что режим для разработчиков работает так же как для пользователей.
Ghost_nsk
По моему вы путаете опции разработчика и что то из разряда инженерного меню. Опции для разработчиков должны вести себя предсказуемо, иначе как разработчикам разрабатывать?
GoldJee
Разработчик по-твоему не пользователь?
VaalKIA
Когда вы компилируете программу с отладочной информацией и без, с уровнем оптимизации позволяющим компилятору очень вольно интерпретировать программу, сильно ли отличается её код и производительность? Судя по тормозам в сетевых видеограх, сразу после глобального патча (его обычно с отладкой выставляют, потом минипач убирающий это дело) — да, сильно. Это было лирическое отступление, теперь по сути:
Кроме того, разработчикам важен процесс, поэтому допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительность, что естественно не факт, потому как не я делал сафари и не знаю, но аналогию я привёл выше.
Tujh
Ни кто так делать не будет, поверьте, в этом смысла просто нет. А лаги после выхода патча связаны с лимитами инфраструктуры игровых серверов, с которых и обновления качают и играть пытаются. Ни кто же не будет держать отдельные дата-центры только для обновлений.
Конкретно при отключении кеша, или другими настройками? Догадываетесь, или знаете? А то больше походит на «не смотрел, но осуждаю» :)