Category: компьютеры

Air upgrade.

По заказу gliv пишу пост об апгрейде. Апгрейднул свой Air:

11" Core 2 Duo 1.4 GHz, 4GB @ 1000 DDR3, 128 GB
на
11" i5 1.7 GHz, 8GB @ 1600 DDR3, 256 GB.

Когда покупал первый в (2010 году), стандартно он шёл с двумя гигами памяти и 64 GB диска. Понятно, что этого не хватило бы, и поэтому я его разогнал по-полной. Тогда это значило 4/128.

Теперь же по-полной значит зарядить 512 флэша под 800 баксов, но я не готов столько переплачивать.

Впрочем, что тогда, в 2010 году, что сейчас, получилось наконфигурить на одну и ту же сумму — $1500. Нормальный комп всегда стоит $1.5k, во все времена.

По ощущениям — лучше. Качественно лучше. Кроме очевидных вещей, таких как улучшенный процессор и скорость работы с памятью, на новых эйрах стоит гораздо более быстрый SSD. Кроме того, заработал AirPlay-шаринг экрана на Apple TV. Это было недоступно для модели 2010 года (они там какую-то фишку видеокарты используют, по всей видимости).

Измерять ничего не буду, так как гнался не за перформансом, а за размером диска: хаскель, TeX, эрланг, и всякие другие штуки уже не умещались на 128 GB. На глаз, разница очевидна.

Cache Performance of Lazy Functional Programs on Current Hardware

Arbob Ahmad and Henry DeYoung


http://www.google.com/search?q=Cache%20Performance%20of%20Lazy%20Functional%20Programs%20on%20Current%20Hardware

Cache Performance of Lazy Functional Programs on Current Hardware


Известно, что рантаймы функциональных языков зачастуют имеют отличные от императивных паттерны доступа к данным в памяти. А современные процессоры оптимизируются под паттерны поведения обычных программ, написанных на более распространённых языках.

Существует несколько исследований, показывающих, где и как функциональные языки неоптимально используют ресурсы процессора. Например, в исследовании 2002 года Nethercote и Mycroft исследовали поведение кэша при выполнении нескольких хаскель-программ, и нашли, что ожидания процессора при отсутствии данных в L2 кэше (cache miss stalls) составляли до 60% задержек при работе программ.

Товарищи из Carnegie Mellon решили ещё раз воспроизвести результаты теста 2002 года. Хардвер за десять лет поменялся довольно сильно, и хотелось определить, так ли пессимистично хаскель работает с кэшем второго уровня.

Использовали валграйндовый Cachegrind и Perf, в частности.

Короче, опредилили, что на тех же данных процессор теперь практически не ждёт на миссах в L2. В 2002 году кэша было 256k, а в 2009 году кэша было уже 4 мега.

К сожалению, они ещё внезапно нашли, что дефольтный размер для нового поколения (nursery) в GC хаскеля составляел 256 kb. То есть, старые тесты 2002 года наверняка упирались именно в то, что дефолтные значения были слишком большими для имеющегося размера кэша. В 2009 году этот же размер оказался более приемлемым.

На мой взгляд, эта находка практически полностью переводит обе статьи, и старую и новую, из подобия науки в разряд тыкания палочкой. Авторы старого исследования не заметили, что упираются в nursery, а авторы нового даже не отметили роль влияния GC-опций GHC на скорость программ. Кроме того, за семь лет изменился и характер нагрузки, а считалось всё на тех же тестах с почти теми же параметрами. Ещё одним соображением являются не абсолютные цифры неоптимальностей в хаскель-программах, а сравнения с эффективностью обычных императивных программ, написанных, скажем, на C или C++. Как поменялась относительная эффективность за эти годы? Нет ответа.
As a result, we conclude that the change in L2 cache size is responsible for most of the performance improvement.
Перевожу: «увеличили кэш, стало быстрее работать». Вау.

И всё же, даже до такого уровня исследования абсолютному большинству российских студентов пилить и пилить.

Волонтёрство в школе Марка

Записался волонтёром в школу Марка. Буду помогать в компьютерном кабинете. Теперь каждый четверг примерно полчаса будут уходить на то, чтобы помогать деткам разбираться с виндами.

Первый раз ходил в прошедший четверг. Кроме меня волонтёром вызвался ещё один папа, менеджер в компании, занимающейся сборкой white-label серверов. Потом на эти сервера лепят шильдики Dell и HP, продавая под своим именем.

Детки, которым от 5 до 6 лет, были первый раз в компьютерном кабинете. Их посадили посередине между рядов с компами и прочитали микро-лекцию о том, чего не надо делать: не надо трогать лицо и нос, а затем брать мышку, и наоборот, чтобы не разносить заразу.

— Многим из вас дома дают трогать экран, но у нас это не разрешено. Вы должны использовать мышку для того, чтобы управлять компьютером. Не трогайте экран.

О новое поколение, взращенное на тачскринах!
Collapse )

SSD restart hell

SSD hell, выжимка из тикета в OPS трекере:
So x0307/8/9/10 started to hang every hour since last night.

Apparently this is a bug we've hit:
http://www.theverge.com/2012/1/17/2713178/crucial-m4-ssd-firmware-update-fixes-recurring-bsod
and firmware 0309 fixes it. I've installed it on x0309 and it indeed stopped it from hanging every hour (though i do not know if this fixes long-term problem). I do expect it to start shutting down x0303/x0304/x0305/x0306 very soon.

They start to fail @ 5,184 hours, so we've 76..190 hours to upgrade the firmware.

@#$%^ Crucial.

--igor

Вот фоллоу-ап с is39, нашим главным по железу:
У нас скиснут все Сrucial SSD в течение 3..7 суток (если не впаять update); 4 хоста уже скисли, один я починил.

После 5184 часов uptime они дохнут каждый час.

Ты, зараза, это предугадал в начале этой недели ;-)

А чё — я ничё! ;)

В начале недели я высказал предположение, что все наши SSD, купленные в одно время, эксплуатируются одинаково, и поэтому помрут в один час. Почему? Потому что диски вылетают не сами по себе, а по какому-то поводу: флуктуация питания, температуры и загрузки. И что у SSD очень узкие тех. допуски и очень ровные техпроцессы. Поэтому, если загрузка и питание более-менее стабильны, то спокойное время между аномалиями загрузки и питания будет как раз способствовать тому, чтобы за это время несколько дисков одновременно выработали свой ресурс. И следующий клиентский шторм или, скажем, переключение коло на дизель с шумом в сети, вырубит сразу все подшедшие к своему лимиту диски.

Но зверёк подкрался совсем не с той стороны ;) Оказывается, в эти SSD просто таймер встроен (они называют это «баг»), похожий на таймер в картриджах для принтеров от HP, ограничивающий их жизнь. И есть патч для этого таймера, для особо вздорных админов, не желающих платить за поддержку ;)

P.S. еще стоит упомянуть, что такое дерьмо мы купили не по выбору, а по причине отсутствия Intel SSD 320, с которыми (в других ящиках) таких проблем у нас нет.

P.P.S. Вот ещё разговорчик:
— На тех хостах, которые сейчас раз в час падают: как так получилось, что баг раньше проявился на них, а не на продакшене?
— Они были включены на ~ неделю раньше.

P.P.P.S. От lazy_neko: А вот тут чуваки попали: http://blog.mailchimp.com/planned-server-maintenance-and-followup-to-server-outage/

Предсказания про Apple

Обещал отслеживать предсказания про Apple — выполняю.

> Например, в следующей ревизии iPad появится front-facing camera: под неё в железе уже и дырка есть, и по логике должна быть. Скорее всего выйдет к крисмасу, или по крайней мере в районе января.

Выполнилось: даже две камеры.
Не выполнилось: вышла весной, а не зимой, и достать почти невозможно. aznakai пришлось пилить до Тахо чтобы один айпад забрать. В Тахо они были в одном месте, ближе к Долине — болт.

> Ну и iPhone белый должен быть. Скорее всего будет к весне — я видел его уже в соседней кафешке у чела, который с ним ходил и тестировал. Но говорят с его стеклом траблы какие-то, поэтому не успеют к крисмасу.

Выполнилось: Белый iPhone появился. К весне или весной — это не суть важно, на мой взгляд. Когда я делал предсказание, белый iPhone многие уже заочно похоронили.

> Дело в том, что тринашка уже и так набита почти под технологическую завязку, а из-за лицензионных граблей они не могут перейти на Core i5/i7 на ограниченном пространстве. Есть очень небольшая вероятность, что придумают что-то с AMD или поставят какой-то совсем странный интеловский чип, но это я не считаю за существенный апгрейд.

Вау, действительно поставили Core i5/i7, и действительно странный чип — про sandy bridge + Intel HD Graphics 3000 было неизвестно [мне] на момент предсказания. Но не к июню, а раньше. Не ожидал.

> [к июню] на 13" модели сделают SSD 128g дефолтом.

Ждём июня. Скорее всего не выполнится.

Короче, хреновый из меня предсказатель — всё очевидно и так было.

P.S. gliv в том треде таки купил MacBook Air 11", а aznakai — MacBook Air 13".

AAPL + MSFT = Bank Fraud

Для работы веб-программистом нужна винда. Хотя бы только для того, чтобы проверять, не стряслось ли ничего в IE 6, 7, 8 или 9 с твоей вёрсткой. Винда на маке — это Boot Camp (нужно ребутаться), или три средства виртуализации: бесплатный некошерный1 VirtualBox, платный кошерный Parallels ($80), и платный буржуйский VMWare Fusion ($80).

Я сделал ошибку, попытавшись купить Windows 7 с сайта MSFT на ту же карточку, с которой неделей раньше купил MacBook. Карточку банк тут же заблокировал. Видимо, очень подозрительная транзакция — покупать что-то у Майкрософта, когда только что уже сдавал деньги эплу.

В MacBook Air нет DVD привода, поэтому 2.3 GB образа Windows 7 после покупки пришлось просто скачать. Скачанный образ встал как влитой в триальник Parallels.
Collapse )

Macbook Air 11.6", первые впечатления

Сегодня по почте пришёл мой заказ — MacBook Air 11.6".

Смотря на Эйры в магазине, долго сомневался по поводу размера дисплея. У моего верного коня PowerBook G4 12" размер дисплея — 12.1", форм-фактор 3:4. Имея два варианта MacBook Air непосредственно перед собой, сложно было выбрать между дисплеями 11.6" или 13.3" — первый казался слишком маленьким, второй — слишком большим. Скажем так, экран у большого мне нравился больше — сложно не нравить себе больший экран. Но хуже всего было то, что после рассматривания экрана 13.3" казалось, что на 11.6" работать будет невозможно.

Так вот, всё фигня, товарищи. Из-за того, что разрешение 11.6" экрана чуть больше, чем у старой двенашки (1366x768 vs. 1024x768), к экрану привыкаешь буквально в считанные минуты. По экрану можно считать, что 11.6" является достойной заменой 12". Да, размер на полдюйма поменьше, зато разрешение чуть побольше, и оно достаточно компенсирует друг друга. После нескольких минут работы на 11.6" кажется, что всё в порядке и ты работаешь со старой доброй двенашкой.

Резюмирую: если кто с G4 12" переходит на Air, то 11.6" является аналогом 12", ментально ужиматься не придётся.
Collapse )

RSI — как бороться с туннельным синдромом

Начальные симптомы туннельного синдрома у меня появились в конце девяностых. И конечно же, как и все другие будущие пациенты с RSI, я их проигнорировал. В 2000 году oleyka прислала мне клавиатуру Acer Ergo 61 (ошибочно прозванную «13R Future» в Компьютерре), с которой первые симптомы практически исчезли, и я смог ещё несколько лет поработать в своём обычном темпе. Но клавиатура всего лишь позволила мне продолжать травмирующую активность более интенсивно.

А затем наступил звездец. Переработав более суток без перерыва при сдаче релиза, первого сентября 2005 года я не смог почистить себе зубы, так как не сумел открыть зубную пасту. Была дикая боль и одновременно слабость в руках.

Месяц спустя врач, к которому уговорили пойти меня коллеги в Cisco, диагностировал «a mild case of RSI/CTS» (repetitive strain injury / carpal tunnel syndrome). Первые три месяца я практически не прикасался к программированию. Затем ещё полгода делал минимально общественно полезную деятельность: 50 строчек в день считалось удачей. Это с учётом написания писем. Код же, с его постоянными двух- или трёхклавишными комбинациями (скобки, подчёркивания, camelcase) набирать было особо неприятно. Если это считается «mild case», тогда что же такое severe case?..

Зато болезнь помогла мне читать книжки — а что ещё оставалось делать? Так был прочитан завал литературы, выучен Haskell, проштудирован Tufte.


Проверка предрасположенности к RSI у мужчин.
Я пытался применить систему голосового распознавания, но быстро бросил: она посадила мне голосовые связки так, что я не мог разговаривать в голос. Оказывается, у людей с врождённой предрасположенностью к RSI (предрасположенность проверяется путём доставания большим пальцем запястья той же руки), голосовые связки очень быстро садятся от постоянной активности. Так что, voice recognition мне не помог. Единственное, что осталось от этого эксперимента — неплохая USB-гарнитура, которую использую для Skype-переговоров.

Человеческий организм очень неумело заживляет внутренние травмы, типа RSI: эволюционно человек не предрасположен к монотонной многочасовой деятельности, и у него нет развитых механизмов обнаружения (например, рецепторов боли, как на коже) и лечения внутренних травм сухожильной сумки.

Соответственно, полугодового «отдыха от работы» мне не хватило. Я мог написать 50-100 строк кода в один день, но потом боль не давала мне работать всю оставшуюся неделю. Я пытался отдыхать от клавиатуры неделю, две без перерыва. Работать тыльной стороной ладони — суставом мизинца. Это снимало боль, но как только я начинал программировать, боль возвращалась буквально через несколько написанных строк.

Позволить себе год держать руки абсолютно без травмирующей активности я не мог — или по крайней мере думал, что не мог. Кроме того, в 2006 у меня родился сын.

В конце концов, после многих экспериментов с тем, сколько же я «теперь» могу работать, с периодами воодушевления (о, я уже второй день не чувствую боли!) и разочарования (уже неделю отдыхаю, но попытка нажать клавишу всё равно ведёт к болезненным ощущениям), у меня сформировалась некоторая система. Система не привела к тому, что у меня пропал RSI. Система другого рода — она позволила планировать мою активность, знать, сколько я могу работать, и точнее предсказывать сроки, в которые работа будет завершена.

Сначала замечу, что RSI почти не лечится, или лечится десятилетиями. То, на что вы можете рассчитывать — это законсервировать процесс на текущем уровне. Главное, что может в перспективе хоть как-то помочь — это прекращение травмирующей активности, то есть программирования и работы с клавиатурой. Уйдите в менеджмент, в конце концов: email меньше травмирует, чем кодирование кода. Используйте менее многословные языки программирования, например функциональные языки программирования, Perl. В этом отношении PHP лучше, чем многословная Java, а Haskell лучше, чем PHP.

Рекомендую книгу Dr. Pascarelli's Complete Guide to Repetitive Strain Injury: What You Need to Know About RSI and Carpal Tunnel Syndrome.

Так вот, нехитрый список правил того, как жить с RSI:
  1. Мышку использовать нельзя. В списках причин RSI мышь стоит на первом месте. В опросниках у врачей по поводу RSI мышь стоит на первом месте: «Используете ли вы компьютерную мышку?» Используйте точпад. У меня есть точпад и планшет, но планшет мне неудобен для повседневной работы всё-таки. Некоторые говорят, что приноровившись, планшет эргономичнее. Чем что? Чем мышка — конечно. Чем точпад? Сомневаюсь.
  2. Используйте vi, а не Emacs. Многоклавишные комбинации вредят эргономике процесса http://xahlee.org/emacs/emacs_hand_pain_celebrity.html
  3. Коротко стригите ногти Обрезайте ногти под ноль. Два миллиметра — уже много. Нажатие на клавиатуру подушечками пальцев щадит связки сильнее, чем нажатие или задевание части поверхности клавиши ногтями.
  4. Используйте клавиатуру с мягким ходом клавиш, без «дребезга» и щелчков. Шелчки передаются связкам и травмируют их.
  5. Сухожилия давят на сухожильную сумку и перетирают, раздирают её изнутри. Вывод: нужно держать руки так, чтобы сухожилие не проходило в запястье под углом. Эргономические клавиатуры нехило помогают, но не все клавиатуры, на которых написано «Ergonomic» являются такими. Например, клавиатуры с верхним рядом клавиш, расположенным выше (дальше от поверхности стола), чем нижний, такими не являются. Некоторые модели Kinesis рулят, Acer Ergo 31/61 рулит (но её невозможно достать). В крайнем случае, если уж совсем ничего нет, сойдёт Microsoft Ergonomic Keyboard.
  6. Печатайте размеренно, в одном ритме и подчёркнуто медленно. Старайтесь делать одинаковые интервалы между нажатиями клавиш, и не допускайте особо вредных взрывных нагрузок, когда после относительно долгого обдумывания строчка или токен набиваются моментально, одним проходом рук. Лучше помедленней набрать, чем сорвать руку таким образом.
  7. Для того, чтобы кисти приучались не изгибаться в процессе работы, нужны развитые кости и мышечный корсет. Если вам до 25 лет — идите в качалку, тренируйте мышцы рук. Это будет способствовать развитию костей. Если вы старше, то кости уже сформировались, и изменить их практически невозможно. Так что берите PowerBall и/или занимайтесь спортом, адресно тренирующим мышцы кистей: скалолазание или бадминтон, например. Не теннис.
  8. Будете использовать PowerBall — используйте без фанатизма. Регулярное превышение 6-8 тысяч оборотов на нём вам сделает RSI, если его даже не было. Для того, чтобы укрепить мышцы, надо систематично крутить его на относительно небольших оборотах: «столько, пока комфортно терпишь, плюс ещё тридцать секунд».
  9. Рука в процессе работы не должна лежать на клавиатуре или столе, а должна держаться на весу. Класть руку на подушку клавиатуры или на стол можно только если в это время не происходит нажатий на клавиши.
  10. Для больших движений используйте большие мышцы, для малых — малые. Это значит, что набирать на верхних рядах клавиш нужно перемещая всю руку, а не путём доставания до крайних рядов клавиш вытягиванием пальцев. Во время печати кисть не должна двигаться влево-вправо или вниз-вверх, следите!
  11. Сплинты — это такие медицинские перчатки без пальцев, укрепляющие кисть. Использовать их при работе нельзя, они приводят к деградации мышц при относительно недолгом использовании. Через неделю работы в сплинтах мышцы атрофируются настолько, что есть шанс совсем не суметь работать без сплинтов. Сплинты можно иногда использовать на ночь, чтобы во время сна не перегибать кисть. Но в конце концов надо от сплинтов избавиться. Я был только первые полтора года в сплинтах — спал в них, и лишь очень изредка работал.
  12. Ибупрофен — копеечное, но очень действенное лекарство, с минимумом побочных эффектов. Оно эффективно снимает боль и обладает противовоспалительным эффектом. Оба свойства подходят для снятия симптомов боли и/или онемения. Но использовать его во время работы нельзя — воспаление-то оно чуть притушит (хорошо), но симптом боли снимет. В итоге вы не будете чувствовать, когда требуется срочно прекращать активность. Короче, если пользоваться ибупрофеном — а на начальных этапах лечения именно его и рекомендуют — ибупрофен надо принимать после травмирующей работы, или перед сном. Чтобы боль во время работы никуда не исчезала и была индикатором того, что надо завершать процесс.
  13. Перед работой руки следует прогревать. Сначала тёплой водой под краном, затем разминающие, разогревающие мышцы и чуть-чуть растягивающие действия кистями.
  14. Не работайте на ноутбучной клавиатуре, и тем более, не работайте на ноутбуке лёжа. День работы на ноутбуке мне стоит трёх дней отходняка.
  15. Алкоголь дополнительно повреждает нервы в воспалённом районе кисти и, похоже, смазку сухожилий. FYI: пить вредно.

Следуя этой системе, теперь — через пять лет после пика травмы — я могу ежедневно писать до 100 строк кода или пропорциональное количество плейнтекста, не боясь долгое время провести в отходняке. Ну или можно написать до 300 строк, если знать, что следующие два-три дня можно устроить себе выходной и «отлежаться».

Feeding Frenzy: Selectively Materializing Users’ Event Feeds

Adam Silberstein, Jeff Terrace, Brian F. Cooper, Raghu Ramakrishnan

http://www.google.com/search?q=pdf+selectively+materializing+user%27s+event+feeds

Feeding Frenzy: Selectively Materializing Users’ Event Feeds


Народ из Yahoo! Research и Princeton University разбирает проблему глобальной оптимизации расходования машинных ресурсов для поддержки передачи реал-таймовых фидов.

Существуют поставщики фидов (те, кто пишет твиты, например, или RSS провайдеры) и есть потребители фидов (аггрегаторы, странички на фейсбуке, поисковые интерфейсы). Каждый потребитель может быть подписан на неограниченное количество поставщиков фидов. Поставщики могут поставлять фиды в реал-тайме (чтобы ембедщики не смеялись под влиянием своей профдеформации, сразу пишу, что вебовый реалтайм — это человеческий реал-тайм: секунды и десятки секунд задержек между отправкой и получения сообщения считается «реальным временем» в современном вебеlionet), а потребители — в реал-тайме же хотят его потреблять. А могут и не поставлять, и, соответственно, не хотеть. Наивно полагать, что в каждом случае, когда потребитель хочет посмотреть на свой фид (френдленту, например), мы должны шерстить базу поставщиков и формировать фид: существуют механизмы кеширования, материализации фидов. Это позволяет потребителям получать уже кешированный фид, практически мгновенно (из кэша).

Теперь проблема: если есть быстрые поставщики фидов и огромное количество не очень часто посещающих свои фиды потребителей, то материализация фидов для такой толпы становится накладной операцией. Например, в твиттере есть такой пользователь «Ashton Kutcher», каждое сообщение которого расходится по «френдлентам» почти пяти миллионов подписчиков. То есть, каждое сообщение от него должно повлиять на миллионы материализованных представлений.

Статья обсуждает следующее решение: что если мы можем выбирать, использовать ли для фида материализованное представление, или нет (идти в сторадж более низкого уровня), базируясь [только] на свойствах пары поставщик/потребитель? По сравнению с другими статьями на эту тему, данная статья демонстрирует, что принятие решения о материализации не может быть принято только на основании свойств поставщика (частоты обновлений, например). Авторы разрабатывают механизм вычисления необходимости материализовывать фид исходя, одновременно, из отношений скорости генерации событий и и частоты их потребления.

Ключевой результат таков: авторы показали, что принятие решений исходя из локальных соображений (свойств поставщика и потребителя) приводит к глобальной оптимизации производительности в целом всей системы поддержки графа передачи информации от поставщиков к потребителям. Авторы демонстрируют это, в частности, экспериментами над своей реальной системой такого рода, которую они разрабатывают и поддерживают в Yahoo.

Авторы вводят понятие k,t-diversity. Неформально это можно понимать так: если приходит событие от Боба в последние t квантов времени, тогда мы не показываем более k событий от Алисы, ежели мы не показываем в это же время событие от Боба.

Рассматриваются две модели когерентности: per-producer и global (эта деталь неважна сейчасlionet). В модели per-producer, стоимость события для конкретного потребителя зависит от частоты актов потребления (рефреша страницы френдленты) и событий поставщика. В глобальной модели когерентности, стоимость события зависит от частоты актов потребления и суммы частоты событий от всех поставщиков событий для данного потребителя.

Что такое стоимость — это выраженная в CPU или в disk IO операциях сложность обслуживания события для системы.

Адаптивный алгоритм, который они предлагают ("правильный" knapsack алгоритм — NP-hard) выглядит примерно так:

We simply sort the pull edges by descending, and shift some number of top-ranked edges to push. Then, if our latency is higher than the SLA, we incrementally shift the top-ranked pull edges to push. If our latency is lower than the SLA, we incrementally shift the lowest-ranked push edges back to pull (note that we never shift edges to pull if they are assigned to push).


От себя:

В этой области всё интуитивно понятно было как оптимизировать и без статьи, но хорошо, что кто-то пошёл и чуть более формально отнёсся к проблеме. Опять же, экспериментальная проверка добавляет уровня доверия результатам статьи. Для эховцев будет небезынтересно поверхностно ознакомиться с параграфами начиная с 4.1 Architecture, в которых рассказывается, как конкретно делается система материализованных представлений на яховской PNUTS.

Хотите узнать главное отличие Маков от Винды?

Сергей Булаев (Интернетные штучки, etc) наткнулся на известный эффект различия в идеологии многооконной работы между маком и виндой.

Не знаю почему, но стоит виндоузятнику сесть за мой ноут, скажем проверить почту, первым делом производится попытка увеличить окно браузера до максимума. И это при разрешении монитора 1920x1200. Я давно уже отвык от этих странностей.

Это абсолютно стандартная практика, проверенная уже на десятках друзей. Единственное что я могу предположить - походу в винде, в отличии от маков, не особо удобно работать с несколькими окнами на десктопе.
http://bulaev.org/10150221

Этот эффект неоднократно описан в литературе по UI дизайну, и замечается достаточно быстро с переходом на мак.

По дефолту (без использования плагинов типа MegaZoomer, RightZoom) мак не позволяет распахнуть окна на полный экран — зелёная кнопка делает что-то неуловимое глазу, меняя форму окна, но окно на полный экран так и не разворачивает. Новичок в маках чертыхается и затем отучается щёлкать по этой зелёной кнопке, образуя бардак на своём столе из множества нераспахнутых окон, перекрывающих друг друга. А затем к нему приходит друг, и пытается, в свою очередь, щёлкнуть по зелёной кнопке в желании распахнуть очередное окно. А оно не работает — форма окна меняется, но как-то странно, неочевидно. И так происходит круговорот в природе.



В чём прикол? В маках зелёная кнопка со значком плюсик не предназначена для распахивания окна на полный экран. В наш век экранов с двухтысячепиксельными разрешениями мало какое приложение может рационально отобразить информацию на таком пространстве. Открой тот же браузер на полный экран — и все эти «тянущиеся» дизайны, не говоря уж про plain text, превратятся в набор длинных строк. Длинные строки — это зло, пока переносишь взгляд от правого края экрана до левого, ты забываешь на какой строчке этот взгляд должен в итоге остановиться. Ширина строчек в книгах — 60-70 букв по горизонтали, не больше. Журнальная и газетная вёрстка — и того у́же, и не без причины. Распахивание на полный экран — неработоспособная парадигма для современных разрешений.

Вместо этого на маках предлагается другая модель для распахивающего действия. Эта модель удивительно проста, но абсолютно неочевидна, если ты сталкиваешься с ней впервые.

Нажатие на зелёную кнопку убирает скроллбары.

Иными словами, нажатие зелёной кнопки приводит к тому, что окно начинает расширяться направо и вниз (а если не получилось — то двигается влево и вверх) пока содержимое окна (документ, веб страница) не сможет отобразиться в этом окне полностью, не приводя к необходимости интерфейсу отрисовывать к окну вертикальные или горизонтальные скроллбары.

Не во всех приложениях эта модель уместна. Например, как в текстовом редакторе без концепции постраничной разбивки (TextEdit, это что-то типа Notepad) определить, влез контент, или нет, если мы пишем свободно перетекающий в зависимости от размеров окна долгий текст? Для подобных приложений зелёная кнопка может работать несколько иначе. Но основной момент именно таков — зелёная кнопка расширяет окно до размера контента в нём.

Что применённая эпловцами модель действия зелёной кнопки даёт на практике? Первый эффект, это то что пользователь — хорошо ли это, или плохо — отучается распахивать окна на весь экран. Видимо, в глубокой фрустрации от процесса нажимания на зелёную кнопку. Второй эффект — это то, что в полном соответствии со Стокгольмским синдромом пользователь начинает находить для себя в этой патовой ситуации положительные моменты. При работе над приложениями виден весь контекст: можно одновременно работать в текстовом редакторе, браузере и фотошопе не занимаясь переключением окон. Все они видны на экране одновременно. Из-за того, что в маке настоящий драг-н-дроп, открытые и видные одновременно приложения этот драг-н-дроп стимулируют и поощряют.

Естественно, контекста может быть слишком много: никому не нравится, когда из его экрана торчит множество одновременно движущихся червяков и выедают мозг. Защита от распыления внимания на маке состоит из следующих моментов:
  • Реальный, (почти) удобный механизм рабочих столов. Да, как на юниксах. В отличие от винды, в которой приложения упорно не желают мириться с разными десктопообразующими тулзами, и постоянно брыкаются. В итоге разные активности просто размещаются в разных рабочих пространствах, группируясь по любым критериям, типа "работа1", "работа2", "развлечения", и поэтому один визуальный контекст с несколькими одновременно видимыми приложениями не мешает другому.

  • В маке нет этих вечных всплывающих балунов. Сеть воткнули, выткнули, потеряли устройство, вставили устройство, нужен апдейт, апдейт устанавливается, апдейт установлен, антивирус протух, антивирус просканировал и не нашёл, антивирус просканировал, нашёл и полечил, etc. Эти вещи назойливо вмешиваются в рабочий процесс даже если распахиваешь какое-то окно на полный экран. Винда просто задолбает асинхронными нотификациями. Мак обычно таких вещей себе не позволяет.


Так всё же, как более удобно, с распахиванием окон на полный экран, или без этого? Думаю, что лучше всего иметь гостевой комп с виндой, если уж гости такие гики, что предпочитают клавиатуру водке.