Comments 106
По правилам, им следовало эмулировать загрузки с разных адресов и разным контентом, чтобы не участвовал кэшЭто что за правила такие? У них их собственный тест с их собственными правилами, по которым они его проводят одинаково на всех ноутбуках.
И да: можно поменять методику, но тогда придётся ещё и выкинуть в помойку данные по всем тестам, проведённым по существующей методике на ≈140 других ноутбуках.
Если тест выдает неправильный результат, может ли это быть виной продукта? Продукт это черный ящик.В этой цитате не достаёт логики.
Продукт — чёрный ящик, всё правильно, поэтому тест должен быть таким, что бы не учитывать особенности этого чёрного ящика. До этого же всё работало много лет, и на макбуках тоже. И тут раз и всё сломалось на последних версиях ПО. Так почему вдруг это стало «ошибкой теста»?
эппл на свое усмотрение мог бы сделать так, что при включенном режиме разработчика задействовались бы какие-то тяжелые сервисыЕсли бы Apple сделала так, что при отключении кэша, включались какие то тяжелые сервисы, это было бы странно, на грани нового бага. В таком случае на мой взгляд оказался бы виноват эпл, из за недокументированного поведения.
Но вопрос в том, что другие пользователи, которые жаловались на эту проблему, они что то же отключали кэш, а зачем им это? Может те пользователи были разработчиками которым нужно было отключать кэш для работы, а тогда это баг эппла.
По факту, Эппл не правы в том, что тестирование без кеша — неправильное, но при этом правы, в том, что опции для разработчиков могут быть непредсказуемы, поэтому, их действия по переключению чего бы то ни было в этом режиме на Маке — некорректны. А то что, по другому не октлючить, ту уж — извините.
Так что методология тестирования с учётом Мак машин — неправильная, подход с отключеним кеша верен, но не реализуем в данном случае, ну и, конечно, баг в сафари был, но не это не означает, что режим для разработчиков работает так же как для пользователей.
Кроме того, разработчикам важен процесс, поэтому допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительность, что естественно не факт, потому как не я делал сафари и не знаю, но аналогию я привёл выше.
Когда вы компилируете программу с отладочной информацией и без, с уровнем оптимизации позволяющим компилятору очень вольно интерпретировать программу, сильно ли отличается её код и производительность?Порой разница очень огромна. Один раз тестировал такое поведение на алгоритме перемножения больших матриц. Отладочная версия отрабатывала минут (!) за 30, а релизная (-О2) — минуты за 3-4.
Судя по тормозам в сетевых видеограх, сразу после глобального патча (его обычно с отладкой выставляют, потом минипач убирающий это дело) — да, сильно.Ни кто так делать не будет, поверьте, в этом смысла просто нет. А лаги после выхода патча связаны с лимитами инфраструктуры игровых серверов, с которых и обновления качают и играть пытаются. Ни кто же не будет держать отдельные дата-центры только для обновлений.
допускаю, что в этом режиме (пункты меню появляются только после включения режима) могут включаться множество логирующих и проверяющих элементов сильно влиящих на производительностьКонкретно при отключении кеша, или другими настройками? Догадываетесь, или знаете? А то больше походит на «не смотрел, но осуждаю» :)
Его не стало — вот и результат.
Чего? Хакеры используют BackTrack какой-нибудь, а не наглухо проприетарным софтом, который ваши отпечатки пальцев с облаком синхронизирует.
Противоречий никаких нет.
Для логина сенсор передаёт данные в Secure Enclave, и получает подписанный идентификатором процессора ответ о (не)совпадении.
Как по мне, так это весьма часто встречается и совсем не профессионально, в противном случае Consumer Reports уже изменили бы технологию тестирования.
«Apple стала использовать посредственное железо»
Да, но они тестируют не так, как это будет делать обычный consumer. Видимо их тест это тупо перезагрузка одной и той же страницы с отключенным cache.
Одна страница от нескольких отличается не сильно. В любом случае, это совсем не похоже на работу обычного пользователя. Не нужно сажать пользователя, один раз записать тест и использовать его постоянно. Производители часто делают много разного, чтобы пользователям было удобно, а не тестам. Chrome с его автоматической подгрузкой страниц, наверное, вообще убивают батарейку только потому, что кеш отключен, а браузер в пустую постоянно подгружает страницы, которые потом не используются.
Иными словами, иная реализация крайне затруднительна
Я не понял, а если сделать просто на странице автоперезагрузку по таймауту (как делают в самых простых веб-чатах, это ни разу не затруднительно и не требует никакого отключения кэшей) — это будет чем-то хуже? Страницу каждый раз совершенно новую генерировать, включая все стили и мелкую графику, как-нибудь даже детерминированно это можно сделать, чтобы все девайсы в совершенно одинаковых условиях.
Очевидно, картинки и прочее надо точно так же по новым URL размещать.
mymotherfuckingpicture0000024123412.png
, при следующем обращении будет называться mymotherfuckingpicture0000024123413.png
, и прописано в динамически сгенерированном теле страницы будет под этим, новым, уникальным урлом, и отдаваться будет уже по этому, новому, уникальному урлу.А в чем проблема?
Он напишет серверную часть, которая будет выдавать под множеством разных имен одну и ту же страницу. Точно ту же самую, которая использовалась в тесте ранее.
Это уже необязательная фича.
Достаточно генерации имён, чтобы браузер загружал файлы заново. Более того, можно вместо изменения имени просто приписывать параметр, типа index.html?1, этого достаточно, чтобы файл загрузился заново.
Ну да, и ещё location, style и link. Разве что фавиконка закешируется всё равно, но я думаю этим можно пожертвовать.
А зачем менять хеш тела? И что вы вообще имеете в виду под "хешем тела"?
Проще, удобнее, понятнее обновлять одну и ту же страницу. Ну, а то, что есть галочка для разработчиков, которая отключает кеширование, не значит что кривые руки у создателей теста. Галочка есть? Есть. Каждый может её щёлкнуть? Каждый. Тогда в чём проблема обсуждаемая в данной дискуссии, не ясно, баг браузера. Сам же тест прост, прозрачен, не позволяет никому сказать что мухлевали. А кто проконтролирует кучу одинаковых страниц? Будут сравнивать их хеш? Но ведь странички разные должны быть что бы не кешировались, при том одинаковые. Проблема реализации, как никогда остро. Вроде всё просто, но на мой взгляд нуба, я бы не поверил тесту отличимому от постоянной перезагрузки одной и той же страницы, того же размера.
И если 99% пользователей не включает такие настройки по которым тестировался ноутбук, то какая польза от подобного тестирования? Ответ — никакой? Или я где-то не прав?
p.s. Разве Apple не права тут? Ведь Consumer Reports утверждает что ноутбуки будут работать мало времени от батареи, а на деле у 99% людей они будут работать штатно.
Consumer Reports утверждает что ноутбуки будут работать мало времени от батареиА это вы откуда взяли? Consumer Reports не рекомендуют не в смысле «рекомендуем не покупать», а в смысле «не можем поручиться, что это хорошая покупка». Т.е. всё равно как если бы не тестировали.
То, что баг в сафари проявился именно с этой настройкой, отнюдь не говорит, что он не проявится, если ее отключить. Просто галочка — это путь к стабильному воспроизведению блуждающего бага.
Отзывы пользователей о случайном проявлении того же бага при (я уверен) отключенной настройке это подтверждают.
вот поэтому нельзя верить любым тестам которые невозможно воспроизвести
на заметку consumer reports — можно просто загружать каждый раз новый урл (хоть и с одинаковым контентом) вместо ломания браузера
Поясню. Ключевой момент: «активация этой конкретной настройки для разработчиков одновременно приводила к срабатыванию «неясного и прерывистого» бага»
Если бы баг проявлялся всегда, а настройка всего лишь помогла его найти — виноваты были бы Apple, которые не нашли критичный баг из-за своих неизобретательных тестеров.
Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
И в результате неправы уже не яблоки, а журналисты — из-за того, что раздули некритичный баг до определяющего при выставлении оценки. А с методологией тестирования у них порядок.
Так что не надо коленным рефлексом сразу хаять яблок, всегда лучше разобраться.
Настройка, отключающая кэш есть? Есть. Методика требует? Требует, т.к. без кэша результат будет более «составным» и объективным, ведь это именно тестирование на выносливость, а какая выносливость может быть проверена, когда данные можно не добывать извне, а брать из-под носа?
Это звучит, будто ноутбук делается не для потребителя/продаж, а затачивается для прохождения конкретного теста.
Раз есть баг — косяк Эплов. Нашли его благодаря Consumer Reports — круто. Думаю еще и спасибо сказали.
Тема слишком раздута…
Но баг проявляется только при включении непопулярной настройки, т.е. автоматом перестает быть критичным вместе со всеми последствиями (вроде высадки батареи). High severity, low priority.
Смотря какую категорию пользователей рассматривать. У веб-разработчика или тестировщика в веб-проекте эта опция бывает очень актуальной и может быть постоянно включена.
Например, без режима разработки нельзя:
- Очистить кэш
- Посмотреть код элемента
- Посмотреть активный код страницы (после выполнения скриптов)
- Отключить скрипты
- Отключить изображения
- Посмотреть ресурсы страницы
- Выполнять действительно «девелоперские» функции — менять user-agent, дебажить JS и т.п.
Кроме того, с багом сталкивался лично, и он действительно прискорбный.
Баг не требует галочки на «Очистить кэши» — он работает при включенном Safari и активированном меню разработки. У меня показывается активная оперативка — и в течение последних двух-трёх недель Safari за 5-6 часов работы умудрялся съесть от 5 до 12 гигабайт, после чего компьютер подвисал, включался вентилятор, а закончить беспорядок можно было только через killall в терминале. Даже после этого Мак продолжает сбрасывать кэш иконок и отрисовывает их «на глазах» при открытии любого меню — но я даже подумать не мог, что это может быть связано с опцией в браузере.
![image](https://habrastorage.org/getpro/geektimes/comment_images/90e/e17/5fa/90ee175fa71c0a38fee844d24ca83b05.png)
А «общая» оценка ноута должна исходить именно из этих 95%, а не гиков вроде нас с вами.
Баг, не могу спорить, прискорбный. Для вас, для меня. Но — повторюсь — НЕ критичный в общей картине вещей.
По основному вопросу это означает, что мое мнение теперь зависит от того, на какой же настройке «висел» баг. Если на отключении кэшей, как написано в статье и в источнике, то по-прежнему не критичен. Если на верхнем уровне, «девелоперских настройках», как утверждает foundout — то соглашусь, что баг переходит в критичные.
телефонов — еще куда ни шло. то есть даже соглашусь пожалуй, что тут почти нет им равных.
что же касается планшетов и тем более ноутбуков, то лично я тут в корне не согласен. это с т.з. как рядового потребителя, так и человека много лет занимающегося ремонтом мобильной техники.
В последнее время приходится сталкиваться в работе с теми или иными продуктами Эпла. И почти каждый раз я задаюсь одним и тем же вопросом «Почему? Почему они смогла заработать столько денег на этом?».
Почему? Почему они смогла заработать столько денег на этом?
В ответ вспоминается фрагмент мультфильма, где старик продавал на рынке корову. Без пиара нынче никак.
Конечно яблочная техника неплоха, но не идеальна. А то, что могло бы быть лучше, не обладало простым интерфейсом «для домохозяек», на чем и не смогло завоевать такую аудиторию.
человека много лет занимающегося ремонтом мобильной техники
У вас классический пример ошибки выжившего )
Самое ценное в Apple для меня было то, что это одна компания, которая ответственна за железо и операционную систему, когда у меня проблема — я просто иду к ним и они исправляют эту проблему.
А вот когда у меня был телефон Nokia, купленный у ATT с операционной системой от Microsoft, и у этого телефона была проблема с батареей — меня просто каждая компания отфутболивала к следующей по кругу.
Да, я про эту проблему с WiFi слышал. У меня этой проблемы не было. Слышал, что она возникает с определенными WiFi роутерами (поэтому, наверное, и видели на всех железках в округе).
У меня были другие проблемы с ноутбуком. Одна из них очень редкие зависания видеокарты. Сходил в Apple Store — за 3 дня поменяли материнскую плату, проблема ушла.
Баги бывают как в софте, так и в методологии тестирования. В данном случае имхо нашли по багу и там и там. Apple свой исправила. CR тоже не мешало бы свой исправить и сделать методологию тестирования более приближенной к реальным условиям. На будущее.
Статичных сайтов без рекламы не сыскать.
Писать ∞ своих сайтов, которые ни разу не пересекутся в течении 20 часов работы при загрузке одной страницы каждую секунду.
Вот как выглядит моя мысля.
В данном случае цель тестирования — сравнение разных продуктов, а не выявление багов. Да, выявление редкого бага, не воспроизводящегося при заявленном сценарии использования, в таком случае является ошибкой.
Выражаясь языком статистики, наличие или отсутствие одного единственного бага нельзя считать достоверным критерием сравнения из-за низкой p-value
Баги есть всюду, и тот факт что в других продуктах баги не обнаружены, ничего не говорит об их качестве. Поэтому использовать "признак наличие бага" при сравнении — неправильно.
Теперь понятно, почему меня банили в админке Vultr через несколько минут после логина, когда заходил туда из Сафари с отключенным кэшированием. Включаешь кэширование — все ок. Комментарии от саппорта — с вашего адреса идет слишком много запросов, срабатывает наша anti-DDoS система.
И еще стал понятен постоянный входящий трафик с районе 100-200К (в частности с хабра/GT). Вот сейчас включил кэширование — трафик пропал.
Ровно та же проблема, а я грешил на провайдера. При трассировке URL все узлы выдавали 2к+ пинг, скорость доходила до 10КБ/сек, при том макбук загружал всю сетку, и на всех домашних устройствах были проблемы с доступом к сети.
Сколько нервов вымотал себе и интернет-провайдеру, но и подумать не мог, что это в Safari сделали новую фичу. В последние 2-3 дня интернет «стабилизировался» — судя по всему, именно в этом интервале у меня и встал фикс.
один вопрос. А когда это отключение кэша стало опцией разработчика?
Apple исправила баг и обвиняет Consumer Reports в неправильной методологии тестирования